date:20051201

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=37727.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=37727





--- Additional Comments From [EMAIL PROTECTED]  2005-12-01 10:15 ---
(In reply to comment #2)
 So the reasoning is (I hope you're right, it'll be good to be wrong here) -
  * BasicMessage has this field - Object[] values
  * Therefore, one may not guarantee serializability of BasicMessage
 The rest is just a cascading effect since BasicMessage's go everywhere. Am I 
 being too convoluted about some corner cases? ;-) The more I think about the 
 above, there is little that can be done either way.

OK, I understand where you're coming from now. My view is as long as we (the 
libarary developers) haven't put anything that would prevent serializabilty 
then thats good enough. If a user adds a non-serializable object as a 
replacement parameter then thats their issue.

 And I agree with you when you say that there is little that we can do with 
the 
 other classes we *surely* know are not serializable. Maybe its best to leave 
 a known issue in the release notes about these and move on?

Personally I would rather the webapp implementations were removed from Commons 
Resources - it would be one less off putting dependency (even if it is 
realistically optional) and theres so little to the implementations. I also 
think we could probably refactor XMLResources and PropertyResources so that 
its straightforward to customize how the InputStreanm is acquired - which 
means Webapp implementations of these would be simpler to do.

I also think we should remove the ResourcesBundle implementation - the main 
point of Commons Resources is to provide an alternative to that class - so I 
don't see much merit in wrapping it.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Release Configuration 1.2

2005-12-01 Thread Niall Pemberton

On 12/1/05, Nicolas De Loof [EMAIL PROTECTED] wrote:
  Can't this dependency be solved using jdbc2.0-stdext.jar ? I'm using
  Jdk 1.3 and cannot upgrade. Not supporting 1.3 anymore will stop my
  migration to commons-configuration.
 
  Nico.
 
 
  Yes, with jdbc2.0-stdext.jar commons-configuration can be compiled and
  run under a JDK 1.3.
 
  Unfortunately this jar cannot be distributed via ibiblio because of
  licence issues, which makes the build a bit unconvenient. But I guess
  I will have to update the pom to declare this dependency because
  DatabaseConfiguration needs the DataSource interface. Would be a good
  idea to update documentation in this respect, too.
 
  Oliver

 AFAIK, other apache projects require sun jars to compile. You may ask
 commons-dbcp commiters that seem to have the same requirement :
 
!-- Note JDBC 2.0 is a pain, because it must be manually
 downloaded to your Maven repository, and it's not even
 required on JDK 1.4.  Maybe we should remove it from
 this dependency list so Maven doesn't choke?
--
dependency
  idjdbc/id
  version2.0/version
/dependency
 

It would be neater if something could be done in the maven.xml to
detect JDK 1.3 and add it into the class path from a property
specified in the build.properties. I'm going to face the same issue in
Commons Resources - we have 1 class that relies on JDBC 2.

Niall

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Release Configuration 1.2

2005-12-01 Thread Nicolas De Loof



Can the project.xml be customized using jelly ?
something like this :

j:if test=${java.version == '1.3'}
   dependency
   idjdbc/id
  /dependency
/j:if



It would be neater if something could be done in the maven.xml to
detect JDK 1.3 and add it into the class path from a property
specified in the build.properties. I'm going to face the same issue in
Commons Resources - we have 1 class that relies on JDBC 2.

Niall

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


 



This message contains information that may be privileged or confidential and is 
the property of the Capgemini Group. It is intended only for the person to whom 
it is addressed. If you are not the intended recipient,  you are not authorized 
to read, print, retain, copy, disseminate,  distribute, or use this message or 
any part thereof. If you receive this  message in error, please notify the 
sender immediately and delete all  copies of this message.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r350235 - /jakarta/commons/proper/jelly/trunk/jelly-tags/tag-project.xml

Author: dion
Date: Thu Dec  1 04:10:18 2005
New Revision: 350235

URL: http://svn.apache.org/viewcvs?rev=350235view=rev
Log:
Use groupId/artifactId consistently instead of simply id

Modified:
jakarta/commons/proper/jelly/trunk/jelly-tags/tag-project.xml

Modified: jakarta/commons/proper/jelly/trunk/jelly-tags/tag-project.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/jelly/trunk/jelly-tags/tag-project.xml?rev=350235r1=350234r2=350235view=diff
==
--- jakarta/commons/proper/jelly/trunk/jelly-tags/tag-project.xml (original)
+++ jakarta/commons/proper/jelly/trunk/jelly-tags/tag-project.xml Thu Dec  1 
04:10:18 2005
@@ -238,47 +238,56 @@
  
 
 dependency
-  idxml-apis/id
+  groupIdxml-apis/groupId
+  artifactIdxml-apis/artifactId
   version1.0.b2/version
 /dependency
 
 dependency
-  idcommons-beanutils/id
+  groupIdcommons-beanutils/groupId
+  artifactIdcommons-beanutils/artifactId
   version1.6/version
 /dependency
 
 dependency
-  idcommons-collections/id
+  groupIdcommons-collections/groupId
+  artifactIdcommons-collections/artifactId
   version2.1/version
 /dependency
 
 dependency
-  idcommons-jexl/id
+  groupIdcommons-jexl/groupId
+  artifactIdcommons-jexl/artifactId
   version1.0/version
 /dependency
 
 dependency
-  idcommons-jelly/id
+  groupIdcommons-jelly/groupId
+  artifactIdcommons-jelly/artifactId
   version1.0/version
 /dependency
 
 dependency
-  idcommons-logging/id
+  groupIdcommons-logging/groupId
+  artifactIdcommons-logging/artifactId
   version1.0.3/version
 /dependency
 
 dependency
-  iddom4j/id
+  groupIddom4j/groupId
+  artifactIddom4j/artifactId
   version1.5/version
 /dependency
 
 dependency
-  idjaxen/id
+  groupIdjaxen/groupId
+  artifactIdjaxen/artifactId
   version1.1-beta-2/version
 /dependency
 
 dependency
-  idxerces/id
+  groupIdxerces/groupId
+  artifactIdxerces/artifactId
   version2.2.1/version
   properties
 gump.projectxml-xerces/gump.project



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r350237 - /jakarta/commons/proper/jelly/trunk/jelly-tags/threads/project.xml

Author: dion
Date: Thu Dec  1 04:15:22 2005
New Revision: 350237

URL: http://svn.apache.org/viewcvs?rev=350237view=rev
Log:
Use groupId/artifactId consistently instead of simply id

Modified:
jakarta/commons/proper/jelly/trunk/jelly-tags/threads/project.xml

Modified: jakarta/commons/proper/jelly/trunk/jelly-tags/threads/project.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/jelly/trunk/jelly-tags/threads/project.xml?rev=350237r1=350236r2=350237view=diff
==
--- jakarta/commons/proper/jelly/trunk/jelly-tags/threads/project.xml (original)
+++ jakarta/commons/proper/jelly/trunk/jelly-tags/threads/project.xml Thu Dec  
1 04:15:22 2005
@@ -16,7 +16,7 @@
 --
 project
   extend${basedir}/../tag-project.xml/extend
-  idcommons-jelly-tags-threads/id
+  artifactIdcommons-jelly-tags-threads/artifactId
   namecommons-jelly-tags-threads/name
   currentVersion1.0.1-SNAPSHOT/currentVersion
   packageorg.apache.commons.jelly.tags.threads/package
@@ -43,6 +43,9 @@
   artifactIdcommons-jelly-tags-junit/artifactId
   version1.0/version
   urlhttp://jakarta.apache.org/commons/jelly/libs/junit//url
+  properties
+scopetest/scope
+  /properties
 /dependency
 
 !-- END for test --



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r350238 - /jakarta/commons/proper/jelly/trunk/jelly-tags/util/project.xml

Author: dion
Date: Thu Dec  1 04:17:44 2005
New Revision: 350238

URL: http://svn.apache.org/viewcvs?rev=350238view=rev
Log:
Use groupId/artifactId consistently instead of simply id

Modified:
jakarta/commons/proper/jelly/trunk/jelly-tags/util/project.xml

Modified: jakarta/commons/proper/jelly/trunk/jelly-tags/util/project.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/jelly/trunk/jelly-tags/util/project.xml?rev=350238r1=350237r2=350238view=diff
==
--- jakarta/commons/proper/jelly/trunk/jelly-tags/util/project.xml (original)
+++ jakarta/commons/proper/jelly/trunk/jelly-tags/util/project.xml Thu Dec  1 
04:17:44 2005
@@ -18,7 +18,7 @@
 
 project
   extend${basedir}/../tag-project.xml/extend
-  idcommons-jelly-tags-util/id
+  artifactIdcommons-jelly-tags-util/artifactId
   namecommons-jelly-tags-util/name
   currentVersion1.1.2-SNAPSHOT/currentVersion
   packageorg.apache.commons.jelly.tags.util/package
@@ -44,7 +44,8 @@
   dependencies
 !-- START for compilation --
 dependency
-  idcommons-lang/id
+  groupIdcommons-lang/groupId
+  artifactIdcommons-lang/artifactId
   version2.0/version
 /dependency
 dependency
@@ -61,6 +62,9 @@
   artifactIdcommons-jelly-tags-junit/artifactId
   version1.0/version
   urlhttp://jakarta.apache.org/commons/jelly/tags/junit//url
+  properties
+scopetest/scope
+  /properties
 /dependency
 !-- END for test --
 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [all] Together, and bricks apart

2005-12-01 Thread Tim Roberts

+1 (can't really say non-binding ;-)

Would also like to help revive sandbox functor if I have time. Whats needs
to be done to get it this project into commons proper and build a community?

Someone else made the point that it would be good to know what needs to be
done to make a release. I agree that would useful (wiki?) (I'll take another
look).

I still think it would be good to have a set of standard functors
interfaces. Functor based programming in java is verbose enough without
having to wrap implementations. I know people have said these are different
but there are in fact quite a few similarities (e.g. composition functions).


Tim.

-Original Message-
From: Niall Pemberton [mailto:[EMAIL PROTECTED] 
Sent: 01 December 2005 08:40
To: Jakarta Commons Developers List
Subject: Re: [all] Together, and bricks apart

On 12/1/05, Phil Steitz [EMAIL PROTECTED] wrote:
 On 11/30/05, Martin Cooper [EMAIL PROTECTED] wrote:
  On 11/30/05, Niall Pemberton [EMAIL PROTECTED] wrote:
  
   On 12/1/05, Stephen Colebourne [EMAIL PROTECTED] wrote:
Release managers are also facing tougher release checkers now IMHO.
For
instance, I haven't ignored configuration, but haven't had the time
to
check it out properly (way too much to do). I try to only give a +1
if I
genuinely am happy. Perhaps I'm now applying too high a standard?
Its a
tough balance.
  
   Adding to what Stephen said, voting +1 to me means at a minimum you're
   indicating knowledge of the code and/or an intention to support it in
   some way. For me I can do that on only 3 to 5 of the Commons
   components. A good example is FileUpload - as a user I would like to
   see a release, but I only recently looked at a bit of the code and
   made a minor contribution. When it comes to a vote I'm not sure
   whether I'll vote for it or not as I don't think I have the time to
   actually provide any support. Is this the generally accepted criteria
   or do others follow more or less lenient criteria?
 
 
  I think most people voting +1 are _not_ saying they're prepared to
support
  it. Rather, they're saying something more like I've checked out the
  proposed distribution, and didn't see any issues, so I'm happy for the
  Commons Foo team to release it as is. How much work is behind each +1
I'm
  sure varies from person to person. Some, like Stephen, are putting more
  effort into checking out the builds than they used to, while I'm sure
others
  are more lenient.
 
  I hope I'm not wrong on this. If I am, and you're right, Niall, then I
might
  as well give up on ever getting another FileUpload release out the door,
  based on how few people other than myself have ever touched the code
base
  over the last several years.
 
  --
 For me +1 means pretty much what Martin describes above.  I check the
 release contents, make sure required elements are there and in jars,
 make sure there is nothing funny included.  I test the builds,
 validate sigs, etc and inspect the web site and, if present,
 clirr/jdiff and look carefully at the release notes.  I also review
 the javadoc, maven reports and POM.   I do try to learn a little more
 with each release that I review; but at this point I can only provide
 support for a handful of commons components personally, so my +1
 really just means I have validated the release and based on what I see
 and have seen on the list the release is good to go.

 I have been derelict over the past couple of weeks though, due to this
 being a very busy time of year and my trying to get [math] released.
 I will review the outstanding candidates ASAP.

OK this is good to know - checking a release is doable. I think I'd
come to the view I had based on the type of thing people put in a
vote:

[ ] +1 I support this release and am willing to help
[ ] +0 I support this release and am unable to help

The difference between +1 and +0 here implies some further commitment
after the vote.

Niall

 Phil

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
MailScanner thanks transtec Computers for their support.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r350240 - in /jakarta/commons/proper/jelly/trunk: jelly-tags/validate/project.xml jelly-tags/velocity/project.xml jelly-tags/xml/project.xml jelly-tags/xmlunit/project.xml parent-project.x

Author: dion
Date: Thu Dec  1 04:36:47 2005
New Revision: 350240

URL: http://svn.apache.org/viewcvs?rev=350240view=rev
Log:
Use groupId/artifactId consistently instead of simply id

Modified:
jakarta/commons/proper/jelly/trunk/jelly-tags/validate/project.xml
jakarta/commons/proper/jelly/trunk/jelly-tags/velocity/project.xml
jakarta/commons/proper/jelly/trunk/jelly-tags/xml/project.xml
jakarta/commons/proper/jelly/trunk/jelly-tags/xmlunit/project.xml
jakarta/commons/proper/jelly/trunk/parent-project.xml
jakarta/commons/proper/jelly/trunk/project.xml

Modified: jakarta/commons/proper/jelly/trunk/jelly-tags/validate/project.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/jelly/trunk/jelly-tags/validate/project.xml?rev=350240r1=350239r2=350240view=diff
==
--- jakarta/commons/proper/jelly/trunk/jelly-tags/validate/project.xml 
(original)
+++ jakarta/commons/proper/jelly/trunk/jelly-tags/validate/project.xml Thu Dec  
1 04:36:47 2005
@@ -18,7 +18,7 @@
 
 project
   extend${basedir}/../tag-project.xml/extend
-  idcommons-jelly-tags-validate/id
+  artifactIdcommons-jelly-tags-validate/artifactId
   namecommons-jelly-tags-validate/name
   currentVersion1.0.1-SNAPSHOT/currentVersion
   packageorg.apache.commons.jelly.tags.validate/package
@@ -43,11 +43,13 @@
   /properties
 /dependency
 dependency
-  idjunit/id
+  groupIdjunit/groupId
+  artifactIdjunit/artifactId
   version3.8.1/version
 /dependency
 dependency
-  idmsv/id
+  groupIdmsv/groupId
+  artifactIdmsv/artifactId
   version20030807/version
 /dependency
 !-- END for compilation --
@@ -74,12 +76,16 @@
   artifactIdcommons-jelly-tags-junit/artifactId
   version1.0/version
   urlhttp://jakarta.apache.org/commons/jelly/libs/junit//url
+  properties
+scopetest/scope
+  /properties
 /dependency
 !-- END for test --
 !-- START for running demos --
 
 dependency
-  idcommons-cli/id
+  groupIdcommons-cli/groupId
+  artifactIdcommons-cli/artifactId
   version1.0/version
 /dependency
 !-- END for running demos --

Modified: jakarta/commons/proper/jelly/trunk/jelly-tags/velocity/project.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/jelly/trunk/jelly-tags/velocity/project.xml?rev=350240r1=350239r2=350240view=diff
==
--- jakarta/commons/proper/jelly/trunk/jelly-tags/velocity/project.xml 
(original)
+++ jakarta/commons/proper/jelly/trunk/jelly-tags/velocity/project.xml Thu Dec  
1 04:36:47 2005
@@ -16,9 +16,9 @@
 --
 project
   extend${basedir}/../tag-project.xml/extend
-  idcommons-jelly-tags-velocity/id
+  artifactIdcommons-jelly-tags-velocity/artifactId
   namecommons-jelly-tags-velocity/name
-  currentVersion1.0/currentVersion
+  currentVersion1.0.1-SNAPSHOT/currentVersion
   
   packageorg.apache.commons.jelly.tags.velocity/package
 
@@ -39,7 +39,8 @@
 
 !-- START for compilation --
 dependency
-  idvelocity/id
+  groupIdvelocity/groupId
+  artifactIdvelocity/artifactId
   version1.3/version
   urlhttp://jakarta.apache.org/velocity//url
   properties

Modified: jakarta/commons/proper/jelly/trunk/jelly-tags/xml/project.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/jelly/trunk/jelly-tags/xml/project.xml?rev=350240r1=350239r2=350240view=diff
==
--- jakarta/commons/proper/jelly/trunk/jelly-tags/xml/project.xml (original)
+++ jakarta/commons/proper/jelly/trunk/jelly-tags/xml/project.xml Thu Dec  1 
04:36:47 2005
@@ -18,7 +18,7 @@
 
 project
   extend${basedir}/../tag-project.xml/extend
-  idcommons-jelly-tags-xml/id
+  artifactIdcommons-jelly-tags-xml/artifactId
   namecommons-jelly-tags-xml/name
   currentVersion1.2-SNAPSHOT/currentVersion
   packageorg.apache.commons.jelly.tags.xml/package
@@ -38,14 +38,16 @@
   /versions
   dependencies
 dependency
-  idcommons-jelly/id
+  groupIdcommons-jelly/groupId
+  artifactIdcommons-jelly/artifactId
   versionSNAPSHOT/version
 /dependency
 
 !-- run time / in testing--
 
 dependency
-  idxalan/id
+  groupIdxalan/groupId
+  artifactIdxalan/artifactId
   version2.3.1/version
 /dependency
 dependency
@@ -53,6 +55,9 @@
   artifactIdcommons-jelly-tags-junit/artifactId
   version1.0/version
   urlhttp://jakarta.apache.org/commons/jelly/libs/junit//url
+  properties
+scopetest/scope
+  /properties
 /dependency
   /dependencies
 /project

Modified: jakarta/commons/proper/jelly/trunk/jelly-tags/xmlunit/project.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/jelly/trunk/jelly-tags/xmlunit/project.xml?rev=350240r1=350239r2=350240view=diff

svn commit: r350241 - in /jakarta/commons/proper: jexl/trunk/project.xml jxpath/trunk/project.xml

Author: dion
Date: Thu Dec  1 04:46:43 2005
New Revision: 350241

URL: http://svn.apache.org/viewcvs?rev=350241view=rev
Log:
Use groupId/artifactId consistently instead of simply id

Modified:
jakarta/commons/proper/jexl/trunk/project.xml
jakarta/commons/proper/jxpath/trunk/project.xml

Modified: jakarta/commons/proper/jexl/trunk/project.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/jexl/trunk/project.xml?rev=350241r1=350240r2=350241view=diff
==
--- jakarta/commons/proper/jexl/trunk/project.xml (original)
+++ jakarta/commons/proper/jexl/trunk/project.xml Thu Dec  1 04:46:43 2005
@@ -18,7 +18,8 @@
 
 project
   pomVersion3/pomVersion
-  idcommons-jexl/id
+  groupIdcommons-jexl/groupId
+  artifactIdcommons-jexl/artifactId
   inceptionYear2003/inceptionYear
   currentVersion1.0.1-SNAPSHOT/currentVersion
   nameCommons JEXL/name
@@ -116,11 +117,13 @@
   /developers
   dependencies
 dependency
-  idjunit/id
+  groupIdjunit/groupId
+  artifactIdjunit/artifactId
   version3.8.1/version
 /dependency
 dependency
-  idcommons-logging/id
+  groupIdcommons-logging/groupId
+  artifactIdcommons-logging/artifactId
   version1.0.3/version
 /dependency
   /dependencies

Modified: jakarta/commons/proper/jxpath/trunk/project.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/jxpath/trunk/project.xml?rev=350241r1=350240r2=350241view=diff
==
--- jakarta/commons/proper/jxpath/trunk/project.xml (original)
+++ jakarta/commons/proper/jxpath/trunk/project.xml Thu Dec  1 04:46:43 2005
@@ -17,8 +17,9 @@
 project
   pomVersion3/pomVersion
   nameJXPath/name
-  idcommons-jxpath/id
-  currentVersion1.2/currentVersion
+  groupIdcommons-jxpath/groupId
+  artifactIdcommons-jxpath/artifactId
+  currentVersion1.3-SNAPSHOT/currentVersion
   inceptionYear2001/inceptionYear
   shortDescriptionXPath for Java Objects/shortDescription
   descriptionA package of Java utility methods for accessing and modifying 
object properties/description
@@ -92,41 +93,50 @@
   
   dependencies
 dependency
-  idxerces/id
+  groupIdxerces/groupId
+  artifactIdxerces/artifactId
   version1.2.3/version
 /dependency
 dependency
-  idservletapi/id
+  groupIdservletapi/groupId
+  artifactIdservletapi/artifactId
   version2.2/version
 /dependency
 dependency
-  idjunit/id
+  groupIdjunit/groupId
+  artifactIdjunit/artifactId
   !-- typerequired/type--
   version3.8/version
 /dependency
 dependency
-  idant+optional/id
+  groupIdant/groupId
+  artifactIdant-optional/artifactId
   version1.5.1/version
 /dependency
 dependency
-  idxml-apis/id
+  groupIdxml-apis/groupId
+  artifactIdxml-apis/artifactId
   version2.0.2/version
 /dependency
 dependency
-  idjdom/id
+  groupIdjdom/groupId
+  artifactIdjdom/artifactId
   version1.0/version
   urlhttp://www.jdom.org/url 
 /dependency
 dependency 
-  idcommons-beanutils/id
+  groupIdcommons-beanutils/groupId
+  artifactIdcommons-beanutils/artifactId
   version1.4/version
 /dependency
 dependency 
-  idcommons-logging/id
+  groupIdcommons-logging/groupId
+  artifactIdcommons-logging/artifactId
   version1.0/version
 /dependency
 dependency 
-  idcommons-collections/id 
+  groupIdcommons-collections/groupId
+  artifactIdcommons-collections/artifactId
   version2.0/version 
 /dependency 
 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r350242 - /jakarta/commons/proper/lang/trunk/project.xml

Author: dion
Date: Thu Dec  1 04:51:41 2005
New Revision: 350242

URL: http://svn.apache.org/viewcvs?rev=350242view=rev
Log:
Use groupId/artifactId consistently instead of simply id

Modified:
jakarta/commons/proper/lang/trunk/project.xml

Modified: jakarta/commons/proper/lang/trunk/project.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/lang/trunk/project.xml?rev=350242r1=350241r2=350242view=diff
==
--- jakarta/commons/proper/lang/trunk/project.xml (original)
+++ jakarta/commons/proper/lang/trunk/project.xml Thu Dec  1 04:51:41 2005
@@ -363,12 +363,13 @@
 !-- Lang should depend on very little --
 dependencies
 dependency
-idjunit/id
+groupIdjunit/groupId
+artifactIdjunit/artifactId
 version3.8.1/version
 /dependency
 !--
 dependency
-  groupIdmaven-pluginss/groupId
+  groupIdmaven-plugins/groupId
   artifactIdmaven-findbugs-plugin/artifactId
   version0.7.1/version
   urlhttp://maven-plugins.sourceforge.net/maven-findbugs-plugin//url



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: DO NOT REPLY [Bug 37363] - [email] Address char-set can not be individuallyset

2005-12-01 Thread Eric Pugh


James,

We should keep this discussion on the commons-dev email list, I'll cc  
it there.   I would love to take a patch file for you, and if you  
haven't worked with Open Source before and Apache specifically I can  
help you.  In terms of getting the changes in, well we are ALL apache  
developers!   In order to submit a patch, all you have to do is check  
out the source, make the change, write a unit test, and then create a  
patch file.  I find Eclipse and Maven make this very very easy.


I suggest you read http://www.apache.org/foundation/how-it-works.html  
for more about Apache Foundation and how you can become involved.


Eric


On Nov 30, 2005, at 10:44 PM, James Huang wrote:

Well, my use case is simpler but I know for sure it is happening in  
real word: the encoding of email addresses is different from that  
of the whole message. This happens to some Japanese mail systems,  
as I was told.


To cope with my use case, the fix is extremely easy: in the  
org.apache.commons.mail.Email class, just add a few more methods to  
take javax.mail.internet.InternetAddress as parameter. Afterall, I  
believe InternetAddress is used internally anyway.


I don't want to go through the hassle of creating accounts, etc.,  
in order to submit patches, and just hoping some apache mail  
developer will make this easy fix. Your scenario is interesting but  
different; I'd imaging you'll have to change the encoding for the  
message body itself in order to send to different recipients  
(expecting specific encoding)?


Cheers,
-James



From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: DO NOT REPLY [Bug 37363]  -[email] Address char-set  
can not be individually set

Date: Tue, 29 Nov 2005 15:36:57 +0100 (CET)

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=37363.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=37363



--- Additional Comments From [EMAIL PROTECTED]  2005-11-29  
15:36 ---
Would you like to submit a patch and a unit test?  Basically, what  
this allows you to do is send a single
email to multiple recipients, and each recipient gets their own  
charset for their email?


--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi? 
tab=email

--- You are receiving this mail because: ---
You reported the bug, or are watching the reporter.






-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 25527] - [fileupload] process lynx linemode browser's multipart form post too!

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=25527.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=25527


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |




--- Additional Comments From [EMAIL PROTECTED]  2005-12-01 16:26 ---
again having some problems with the latest lynx --version
Lynx Version 2.8.5rel.1 (04 Feb 2004)
libwww-FM 2.14, SSL-MM 1.4.1, GNUTLS 1.0.16
Built on linux-gnu Sep 26 2004 12:53:36

as per apt-get on debian sarge:


Dec 1, 2005 4:18:38 PM org.apache.struts.upload.CommonsMultipartRequestHandler
handleRequest
SEVERE: Failed to parse multipart request
org.apache.commons.fileupload.FileUploadException: Processing of
multipart/form-data request failed. Read timed out
at
org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:376)
at
org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:266)
at
org.apache.struts.upload.CommonsMultipartRequestHandler.handleRequest(CommonsMultipartRequestHandler.java:193)
at org.apache.struts.util.RequestUtils.populate(RequestUtils.java:443)
at
org.apache.struts.action.RequestProcessor.processPopulate(RequestProcessor.java:804)
at
org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:203)
at 
org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196)
at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:432)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:407)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at 
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:526)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:827)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:731)
at
org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:526)
at
org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
at java.lang.Thread.run(Thread.java:595)
Dec 1, 2005 4:18:38 PM org.apache.catalina.core.StandardWrapperValve invoke
SEVERE: Servlet.service() for servlet action threw exception
org.apache.commons.fileupload.FileUploadException: Processing of
multipart/form-data request failed. Read timed out
at
org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:376)
at
org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:266)
at
org.apache.struts.upload.CommonsMultipartRequestHandler.handleRequest(CommonsMultipartRequestHandler.java:193)
at org.apache.struts.util.RequestUtils.populate(RequestUtils.java:443)
at
org.apache.struts.action.RequestProcessor.processPopulate(RequestProcessor.java:804)
at
org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:203)
at 
org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196)
at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:432)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214)
at

RE: [VOTE] Release Configuration 1.2

2005-12-01 Thread Jörg Schaible

Hi Oliver,

Oliver Heger wrote on Thursday, December 01, 2005 9:26 AM:

 Yes, with jdbc2.0-stdext.jar commons-configuration can be compiled and
 run under a JDK 1.3.
 
 Unfortunately this jar cannot be distributed via ibiblio because of 
 licence issues, which makes the build a bit unconvenient. But I guess 
 I will have to update the pom to declare this dependency because
 DatabaseConfiguration needs the DataSource interface. Would be a good
 idea to update documentation in this respect, too.

So, where's the problem (yeah, I know Stephen's blog about Compiling with 
older JDK)? Use 1.4 to compile it and have source/target as 1.3. For M2 you 
can have dependencies depending on the JDK version.

- Jörg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 25527] - [fileupload] process lynx linemode browser's multipart form post too!

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=25527.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=25527


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|ASSIGNED




--- Additional Comments From [EMAIL PROTECTED]  2005-12-01 16:33 ---
admitted, the attachment had 20 MB, but I allow 70 MB

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[Jakarta-commons Wiki] Update of Net by MattTaylor

2005-12-01 Thread Apache Wiki

Dear Wiki user,

You have subscribed to a wiki page or wiki category on Jakarta-commons Wiki 
for change notification.

The following page has been changed by MattTaylor:
http://wiki.apache.org/jakarta-commons/Net

The comment on the change is:
added javadoc URL

--
  
  * /FrequentlyAskedQuestions
  
+ * [http://jakarta.apache.org/commons/net/apidocs/index.html Javadoc]
+ 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Release Configuration 1.2


Jörg Schaible wrote:

Yes, with jdbc2.0-stdext.jar commons-configuration can be compiled and
run under a JDK 1.3.

Unfortunately this jar cannot be distributed via ibiblio because of 
licence issues, which makes the build a bit unconvenient. But I guess 
I will have to update the pom to declare this dependency because

DatabaseConfiguration needs the DataSource interface. Would be a good
idea to update documentation in this respect, too.



So, where's the problem (yeah, I know Stephen's blog about Compiling with older 
JDK)? Use 1.4 to compile it and have source/target as 1.3. For M2 you can have 
dependencies depending on the JDK version.
  

But as stated in his blog you have to set the bootclasspath too.

Currently (temporary) I have a similar problem in commons-vfs.
And if it is somehow possible I would like to avoid to release such a 
construct.
If you would like to compile such a beast you have to have two JDKs 
installed. :-(


IMHO Not that nice.

---
Mario


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [all] Together, and bricks apart

2005-12-01 Thread James Carman

Tim, 

I would be willing to help with commons functor, as I have found it useful
in the past and I have familiarity with it.  

James

-Original Message-
From: Tim Roberts [mailto:[EMAIL PROTECTED] 
Sent: Thursday, December 01, 2005 7:31 AM
To: 'Jakarta Commons Developers List'
Subject: RE: [all] Together, and bricks apart

+1 (can't really say non-binding ;-)

Would also like to help revive sandbox functor if I have time. Whats needs
to be done to get it this project into commons proper and build a community?

Someone else made the point that it would be good to know what needs to be
done to make a release. I agree that would useful (wiki?) (I'll take another
look).

I still think it would be good to have a set of standard functors
interfaces. Functor based programming in java is verbose enough without
having to wrap implementations. I know people have said these are different
but there are in fact quite a few similarities (e.g. composition functions).


Tim.

-Original Message-
From: Niall Pemberton [mailto:[EMAIL PROTECTED] 
Sent: 01 December 2005 08:40
To: Jakarta Commons Developers List
Subject: Re: [all] Together, and bricks apart

On 12/1/05, Phil Steitz [EMAIL PROTECTED] wrote:
 On 11/30/05, Martin Cooper [EMAIL PROTECTED] wrote:
  On 11/30/05, Niall Pemberton [EMAIL PROTECTED] wrote:
  
   On 12/1/05, Stephen Colebourne [EMAIL PROTECTED] wrote:
Release managers are also facing tougher release checkers now IMHO.
For
instance, I haven't ignored configuration, but haven't had the time
to
check it out properly (way too much to do). I try to only give a +1
if I
genuinely am happy. Perhaps I'm now applying too high a standard?
Its a
tough balance.
  
   Adding to what Stephen said, voting +1 to me means at a minimum you're
   indicating knowledge of the code and/or an intention to support it in
   some way. For me I can do that on only 3 to 5 of the Commons
   components. A good example is FileUpload - as a user I would like to
   see a release, but I only recently looked at a bit of the code and
   made a minor contribution. When it comes to a vote I'm not sure
   whether I'll vote for it or not as I don't think I have the time to
   actually provide any support. Is this the generally accepted criteria
   or do others follow more or less lenient criteria?
 
 
  I think most people voting +1 are _not_ saying they're prepared to
support
  it. Rather, they're saying something more like I've checked out the
  proposed distribution, and didn't see any issues, so I'm happy for the
  Commons Foo team to release it as is. How much work is behind each +1
I'm
  sure varies from person to person. Some, like Stephen, are putting more
  effort into checking out the builds than they used to, while I'm sure
others
  are more lenient.
 
  I hope I'm not wrong on this. If I am, and you're right, Niall, then I
might
  as well give up on ever getting another FileUpload release out the door,
  based on how few people other than myself have ever touched the code
base
  over the last several years.
 
  --
 For me +1 means pretty much what Martin describes above.  I check the
 release contents, make sure required elements are there and in jars,
 make sure there is nothing funny included.  I test the builds,
 validate sigs, etc and inspect the web site and, if present,
 clirr/jdiff and look carefully at the release notes.  I also review
 the javadoc, maven reports and POM.   I do try to learn a little more
 with each release that I review; but at this point I can only provide
 support for a handful of commons components personally, so my +1
 really just means I have validated the release and based on what I see
 and have seen on the list the release is good to go.

 I have been derelict over the past couple of weeks though, due to this
 being a very busy time of year and my trying to get [math] released.
 I will review the outstanding candidates ASAP.

OK this is good to know - checking a release is doable. I think I'd
come to the view I had based on the type of thing people put in a
vote:

[ ] +1 I support this release and am willing to help
[ ] +0 I support this release and am unable to help

The difference between +1 and +0 here implies some further commitment
after the vote.

Niall

 Phil

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
MailScanner thanks transtec Computers for their support.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [all] Together, and bricks apart

2005-12-01 Thread C. Grobmeier

At least one of you release checkers ;-) should setup a wiki to 
describe every step to do,  this helps the release manager and those 
checking it.
Especially if you are a newbie in the release cycle it might be a great 
start AND it defines standards.


I like Marios idea.

Very new to commons-dev i would like to get more involved. I guess i 
will start with bugfixing, submitting patches all this stuff.
Checking out a potentiel release is work everyone can do- if there is a 
concrete description what to do. I really have a problem with:hey do 
you support this release?- ok, i have no idea if this is all ok cause i 
don't know what i should check. In this case it's better to shut up :-)


If somebody could provide a wiki page it would be a good start for a 
noob like i am to help out with some things.

Namely: gimme a checklist.

Cheers,
Chris


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [all] Together, and bricks apart

2005-12-01 Thread Martin van den Bemt

Mario Ivankovits wrote:

Phil Steitz wrote:

Thats true, I'll learn with every release review too, but can do this
only if another one complains about this and that.
If I read the stuff you do to check a release I am shocked, damn much
work to do.

At least one of you release checkers ;-) should setup a wiki to
describe every step to do, this helps the release manager and those
checking it.
Especially if you are a newbie in the release cycle it might be a great
start AND it defines standards.

Everyone does this in its own way. You can look at outstanding issues, run tests check
for test coverage, look at the preperation that has gone into it (dev traffic, commits
for a component) and the human factor is also important for me. What I also
normally do during development of the applications I make during the day, is make source
dependencies on those components, which will give some kind of feeling about those
components.
Most of the time I will not vote for components I have used myself. VFS, Validator and Configuration fall into that category atm.

And e.g. we started to discuss if we have to convert line-endings -
after years (!) of commons releases - and we were not able to have a
vital discussion about this little topic.

It actually took me 12 days to send a reaction to that one, so not really a
quick response, but I also never received a response to my question /
conclusion. You can only detail read so much, so most of the time I am just
skimming and stop at interesting threads and now and then I actually miss
someting I would like to read.

I tend to focus more on (for me) productive things, since (almost) all of my
open source efforts happens/has to happen in my spare time, which is limited..

Mvgr,
Martin

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [all] Together, and bricks apart

2005-12-01 Thread Martin van den Bemt



I hope I'm not wrong on this. If I am, and you're right, Niall, then I might
as well give up on ever getting another FileUpload release out the door,
based on how few people other than myself have ever touched the code base
over the last several years.



Just about FileUpload : in the coming weeks I am going to use it and as far as 
i've seen it is pretty much in need of a release, since the last was 2003 if I 
am not mistaking and quite a few issues (esp memory leaks) have been fixed 
after that.
So at this stage I would already support a release.
I'll ping the dev list when I started using it..

Mvgr,
Martin

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [all] Together, and bricks apart

On 11/30/05, Rahul Akolkar [EMAIL PROTECTED] wrote:

 I'm also seeing a trend that is a tad disappointing. The last three
 successive release votes each needed to make pleas for a better
 response from the developer community. We've witnessed this for, in
 chronological order:

  * VFS [1]
  * Validator [2]
  * Configuration [3]

Viewing it slightly more abstractedly:

1) We have areas of inactivity.
2) We don't notice those areas.
3) We are thusly unable to encourage increased activity.

 I'm afraid it might be easy to misunderstand or ridicule this email,
 point to the some Apache voting FAQ, and move on. This is not a
 statement about individuals -- rather the community -- indeed,
 personally, I've done nothing to help in the above cases, including
 even choosing not to cast non-binding opinions when the votes came up.

 I'll be glad if I'm told I've misunderstood the current state of
 affairs, maybe RMs are just anxious by nature (comes with the
 territory), this is all *expected* to happen, and I'm the only one who
 sees things in a different light. I'll be happier still if this were
 an abberation rather than the norm.

You're spot on. Even going inactive and trying to get active again,
it's hard for me to pick up what's different in the release management
etc.

Documentation is one thing, so that if someone is able to find it they
can follow it along, but we also need to work together on automation.
It shouldn't be this hard etc :)

Hen

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [all] Together, and bricks apart

On 11/30/05, Stephen Colebourne [EMAIL PROTECTED] wrote:

 You are certainly correct in spotting these cases, however other votes
 will also go through. One of the big issues I have with Apache is the
 amount of procedure and boring stuff necessary to go through to get a
 release released.

 The vote is really the tip of the iceberg, the real effort is in the
 uploading, copying, signing, linking... Releasing at sourceforge is a
 dream by comparison (although its an unfair comparison of course).

Yeah, SF has the step wait for Lag repeated many times over :)

I've been playing with release things on osjava.org. It's still a 22
step process:

http://wiki.osjava.org/confluence/display/IDEAS/OSJava+release+process

Hen

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [all] Together, and bricks apart


Martin van den Bemt wrote:
I tend to focus more on (for me) productive things, since (almost) all 
of my open source efforts happens/has to happen in my spare time, 
which is limited..
Me too, especially the [vfs] thing is a free time job for me. But even 
more it is demotivating if you are blocked due to a more restrictive 
check when it comes to the release vote then you had during your release 
candidates.


I search a little bit, and guess what, we have such a documentation

http://jakarta.apache.org/commons/releases/prepare.html


We have to rework it, tough.

*) In the area of class file format we should state that we not allow 
to use only the target attribute but also require to use the correct 
jdk version: the version the project was designed for.

*) And we need a new point of what files we need to crlf fix.
*) And I dont know why we should fix all bugs, its not very productive 
to mark all bugs as later and after the release revert the status again.


---
Mario



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 25527] - [fileupload] process lynx linemode browser's multipart form post too!

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=25527.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=25527





--- Additional Comments From [EMAIL PROTECTED]  2005-12-01 20:40 ---
Do you have any evidence to support this being a bug in Struts / FileUpload, 
rather than a bug in the latest version of Lynx?

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 25527] - [fileupload] process lynx linemode browser's multipart form post too!

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=25527.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=25527





--- Additional Comments From [EMAIL PROTECTED]  2005-12-01 21:53 ---
Martin, you may be right, I guess the next diagnostic steps would be to post to
http instead of https and then do an ethereal or tcpflow dump. I'll post the
results once I get to them (apologies, may take some time...)

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [all] Together, and bricks apart

2005-12-01 Thread Stephen Colebourne


Mario Ivankovits wrote:

I search a little bit, and guess what, we have such a documentation

http://jakarta.apache.org/commons/releases/prepare.html

We have to rework it, tough.

*) In the area of class file format we should state that we not allow 
to use only the target attribute but also require to use the correct 
jdk version: the version the project was designed for.

+1
I believe that the ideal is to compile with JDK 1.4/1.5 but using 
bootclasspath to pickup the JDK1.2 libraries.


That said, I tend to just use JDK1.3 to compile (no bootclasspath). In 
theory this can affect JDK1.2 users, but

a) there are very few of those
b) there were no bytecode change 1.2-1.3 AFAIN
c) non one has ever reported an overloaded method issue either


*) And we need a new point of what files we need to crlf fix.
I don't intend to -1 a release on this. The key files are the top level 
release notes.


*) And I dont know why we should fix all bugs, its not very productive 
to mark all bugs as later and after the release revert the status again.

Personally, I've never done that.

Stephen

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] New commons proper component - collections-functors

2005-12-01 Thread robert burrell donkin

On Mon, 2005-11-28 at 23:12 +, Stephen Colebourne wrote:

snip

 ---
 [X] +1 I support creating [collection-functors]
 [ ] +0 It's OK
 [ ] +1 If you must
 [ ] -1 I don't support this because
 ---

- robert


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Release Configuration 1.2

2005-12-01 Thread Oliver Heger

snip/

AFAIK, other apache projects require sun jars to compile. You may ask
commons-dbcp commiters that seem to have the same requirement :

   !-- Note JDBC 2.0 is a pain, because it must be manually
downloaded to your Maven repository, and it's not even
required on JDK 1.4.  Maybe we should remove it from
this dependency list so Maven doesn't choke?
   --
   dependency
 idjdbc/id
 version2.0/version
   /dependency




It would be neater if something could be done in the maven.xml to
detect JDK 1.3 and add it into the class path from a property
specified in the build.properties. I'm going to face the same issue in
Commons Resources - we have 1 class that relies on JDBC 2.

Niall

  

I think simply checking for a JDK 1.3 may not be enough because you can
use the maven.compile.executable property to select a compiler from a
different JDK. Then compilation may take place on a JDK 1.3, but maven
is actually running on a JDK 1.4 or whatever.

I just tested the following approach: In maven.xml I added the following
goal:

  !-- Adds the jdbc-stdext to the dependency classpath if the
   dependency.jdbc property is defined.
  --
  preGoal name=java:compile
j:if test=${dependency.jdbc != ''}
  path id=extended.dependency.path
pathelement path=${dependency.jdbc}/
  /path
  maven:addPath id=maven.dependency.classpath
refid=extended.dependency.path/
/j:if
  /preGoal

Now in your build.properties you can define the dependency.jdbc
variable to point to the jdbc jar. If it is set, the dependency will be
added to the classpath; otherwise not. Given that this setup is clearly
documented, do you think this solution is practical?

Oliver

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Feedparser

2005-12-01 Thread karl wettin

Is the sandbox project feed parser abandoned? I have updated the  
source to work with the new jdom and would like to commit my  
updates as I presume they are wanted. Sent an e-mail to Kevin a few  
days ago, but there is no reply.


The whole repository is somewhat a mess too. Maven dependencies are  
bad will not build, et.c. It's a shame on such a nice project. I  
would be happy to fix it up.


--
karl

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [vote][net] Release commons-net 1.4.1?

2005-12-01 Thread robert burrell donkin

-1 to any commons-net new release. see pmc thread for details (if any
committers aren't on the pmc please shout and i'll nominate you)

- robert

On Thu, 2005-12-01 at 07:47 +0100, Mario Ivankovits wrote:
 Steve Cohen wrote:
  As I have little time now, I propose the following.  1.4.1 will be 
  just 1.4.0 with whatever changes are needed to reverse the dependency 
  on jdk 1.4.x.  No other bug fixes will be included.
 
  Re-vote
 
  +1 [yes]
  -1 [no]
 +1
 
 ---
 Mario
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 


signature.asc
Description: This is a digitally signed message part

Re: Feedparser

2005-12-01 Thread robert burrell donkin

On Thu, 2005-12-01 at 22:44 +0100, karl wettin wrote:
 Is the sandbox project feed parser abandoned? I have updated the  
 source to work with the new jdom and would like to commit my  
 updates as I presume they are wanted. Sent an e-mail to Kevin a few  
 days ago, but there is no reply.
 
 The whole repository is somewhat a mess too. Maven dependencies are  
 bad will not build, et.c. It's a shame on such a nice project. I  
 would be happy to fix it up.

good question: i'm not sure. hopefully some folks who know more will
jump in now...

IIRC feedparser had been elected to the commons proper and was being
moved there.

would you mind checking out proper, taking a look around and reporting
back what you find?

- robert


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (JELLY-224) The parser always try to load the DTD even if validate = false

2005-12-01 Thread Philippe Kernevez (JIRA)

The parser always try to load the DTD even if validate = false
--

 Key: JELLY-224
 URL: http://issues.apache.org/jira/browse/JELLY-224
 Project: jelly
Type: Bug
  Components: taglib.xml  
 Environment: Working of line or behind a proxy
Reporter: Philippe Kernevez


The tag ixml:parse/i always try to load the DTD even if the attribut 
ivalidate=false/i is used.
This cause an error when we use this tag without connection.

See: the linked issue http://jira.codehaus.org/browse/MPDASHBOARD-34 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[sandbox] December dormancy proposal

As per the Sandbox pruning proposal
(http://wiki.apache.org/jakarta-commons/ProposalSandboxPruning), I
propose to archive the following 'inactive' components (ie nothing
changed in over 6 months):

benchmark
contract
servlet

Unless I hear a -1 by the 7th, I'll move them to dormancy.

Hen

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [all] Together, and bricks apart

2005-12-01 Thread Martin van den Bemt

Mario Ivankovits wrote:

Martin van den Bemt wrote:

I tend to focus more on (for me) productive things, since (almost) all
of my open source efforts happens/has to happen in my spare time,
which is limited..

Me too, especially the [vfs] thing is a free time job for me. But even
more it is demotivating if you are blocked due to a more restrictive
check when it comes to the release vote then you had during your release
candidates.

More involvment in the RC's is what I can think of for myself here, also for projects I don't use.

I search a little bit, and guess what, we have such a documentation

http://jakarta.apache.org/commons/releases/prepare.html

We have to rework it, tough.

*) In the area of class file format we should state that we not allow
to use only the target attribute but also require to use the correct
jdk version: the version the project was designed for.

*) And we need a new point of what files we need to crlf fix.

To reask the question in this thread : what is broken with crlf ?
I use both windows and linux (and mix zips and tgz on both platforms) and never
had a single issue with this. It could be the way I work though :)

*) And I dont know why we should fix all bugs, its not very productive
to mark all bugs as later and after the release revert the status again.

You don't have to fix all bugs, but the number and kind of bugs solved / still
open can be a good indicator of how the project is doing.

Mvgr,
Martin

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [vote][net] Release commons-net 1.4.1?

2005-12-01 Thread Stephen Colebourne


robert burrell donkin wrote:

-1 to any commons-net new release. see pmc thread for details (if any
committers aren't on the pmc please shout and i'll nominate you)


I am on the PMC but haven't got mails for a long time :-/

Stephen

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [all] Together, and bricks apart

2005-12-01 Thread Oliver Heger

Stephen Colebourne wrote:

 Mario Ivankovits wrote:

 I search a little bit, and guess what, we have such a documentation

 http://jakarta.apache.org/commons/releases/prepare.html

 We have to rework it, tough.

 *) In the area of class file format we should state that we not
 allow to use only the target attribute but also require to use the
 correct jdk version: the version the project was designed for.

 +1
 I believe that the ideal is to compile with JDK 1.4/1.5 but using
 bootclasspath to pickup the JDK1.2 libraries.

 That said, I tend to just use JDK1.3 to compile (no bootclasspath). In
 theory this can affect JDK1.2 users, but
 a) there are very few of those
 b) there were no bytecode change 1.2-1.3 AFAIN
 c) non one has ever reported an overloaded method issue either

What about using maven's maven.compile.executable property to point to
the target JDK? This is what I have done with the RCs for configuration.
This seems to be convenient, but has the disadvantage that the manifest
in the generated jar contains the version of the JDK on which maven is
running (not the target JDK). Or does anybody know a trick how to handle
this?


 *) And we need a new point of what files we need to crlf fix.

 I don't intend to -1 a release on this. The key files are the top
 level release notes.

There has been a longer discussion about this subject. I wonder if a
user has already complained about that. I mean, if I open a file with
Windows notepad and find out that the line endings are incorrect, I open
it again with Wordpad. So what? I assume that our target group (i.e.
programmers) use editors that can handle such things.


 *) And I dont know why we should fix all bugs, its not very
 productive to mark all bugs as later and after the release revert
 the status again.

 Personally, I've never done that.

+1 That really doesn't make much sense.

Oliver

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r351532 - /jakarta/commons/sandbox/scxml/trunk/src/main/java/org/apache/commons/scxml/semantics/SCXMLSemanticsImpl.java

2005-12-01 Thread rahul

Author: rahul
Date: Thu Dec  1 16:12:22 2005
New Revision: 351532

URL: http://svn.apache.org/viewcvs?rev=351532view=rev
Log:
Treat a NFE as an immediate send.

Modified:

jakarta/commons/sandbox/scxml/trunk/src/main/java/org/apache/commons/scxml/semantics/SCXMLSemanticsImpl.java

Modified: 
jakarta/commons/sandbox/scxml/trunk/src/main/java/org/apache/commons/scxml/semantics/SCXMLSemanticsImpl.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/scxml/trunk/src/main/java/org/apache/commons/scxml/semantics/SCXMLSemanticsImpl.java?rev=351532r1=351531r2=351532view=diff
==
--- 
jakarta/commons/sandbox/scxml/trunk/src/main/java/org/apache/commons/scxml/semantics/SCXMLSemanticsImpl.java
 (original)
+++ 
jakarta/commons/sandbox/scxml/trunk/src/main/java/org/apache/commons/scxml/semantics/SCXMLSemanticsImpl.java
 Thu Dec  1 16:12:22 2005
@@ -249,9 +249,19 @@
 params.put(varName, varObj);
 }
 }
+String delay = snd.getDelay();
+long wait = 0L;
+if (delay != null  delay.length()  0) {
+try {
+wait = Long.parseLong(delay.trim());
+} catch (NumberFormatException nfe) {
+APP_LOG.warn(Could not parse delay for send, 
++ it will be treated as immediate, nfe);
+}
+}
 evtDispatcher.send(snd.getSendid(),
 snd.getTarget(), snd.getTargettype(), snd.getEvent(),
-params, hints, Long.parseLong(snd.getDelay()));
+params, hints, wait);
 } else if (a instanceof Var) {
 Var vr = (Var) a;
 String varName = vr.getName();



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r351534 - /jakarta/commons/sandbox/scxml/trunk/src/main/java/org/apache/commons/scxml/SCXMLDigester.java

2005-12-01 Thread rahul

Author: rahul
Date: Thu Dec  1 16:17:41 2005
New Revision: 351534

URL: http://svn.apache.org/viewcvs?rev=351534view=rev
Log:
 ** Support for corner cases where the SCXML document resides in:
   * A java or web archive
   * A compound document where it has already been parsed
   (In such cases, there shouldn't be any external src references)
 ** Some Javadoc and whitespace changes

Modified:

jakarta/commons/sandbox/scxml/trunk/src/main/java/org/apache/commons/scxml/SCXMLDigester.java

Modified: 
jakarta/commons/sandbox/scxml/trunk/src/main/java/org/apache/commons/scxml/SCXMLDigester.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/scxml/trunk/src/main/java/org/apache/commons/scxml/SCXMLDigester.java?rev=351534r1=351533r2=351534view=diff
==
--- 
jakarta/commons/sandbox/scxml/trunk/src/main/java/org/apache/commons/scxml/SCXMLDigester.java
 (original)
+++ 
jakarta/commons/sandbox/scxml/trunk/src/main/java/org/apache/commons/scxml/SCXMLDigester.java
 Thu Dec  1 16:17:41 2005
@@ -56,6 +56,7 @@
 
 import org.xml.sax.Attributes;
 import org.xml.sax.ErrorHandler;
+import org.xml.sax.InputSource;
 
 /**
  * pThe SCXMLDigester provides the ability to digest a SCXML document into
@@ -70,7 +71,7 @@
 
 //-- PUBLIC METHODS --//
 /**
- * API for standalone usage where the SCXML document is a URL.
+ * pAPI for standalone usage where the SCXML document is a URL./p
  *
  * @param scxmlURL
  *a canonical absolute URL to parse (relative URLs within the
@@ -120,14 +121,14 @@
 }
 
 /**
- * API for standalone usage where the SCXML document is a URI.
- * A PathResolver must be provided.
+ * pAPI for standalone usage where the SCXML document is a URI.
+ * A PathResolver must be provided./p
  *
  * @param pathResolver
  *The PathResolver for this context
  * @param documentRealPath
  *The String pointing to the absolute (real) path of the
- *   SCXML config
+ *SCXML document
  * @param errHandler
  *The SAX ErrorHandler
  * @param evalCtx
@@ -161,6 +162,57 @@
 documentRealPath, e.getMessage()
 });
 log.error(errMsg, e);
+}
+
+if (scxml != null) {
+updateSCXML(scxml, evalCtx, evalEngine);
+}
+
+return scxml;
+
+}
+
+/**
+ * pAPI for standalone usage where the SCXML document is an
+ * InputSource. This method may be used when the SCXML document is
+ * packaged in a Java archive, or part of a compound document
+ * where the SCXML root is available as a
+ * codeorg.w3c.dom.Element/code or via a codejava.io.Reader/code.
+ * /p
+ *
+ * pemNote:/em Since there is no path resolution, the SCXML document
+ * must not have external state sources./p
+ *
+ * @param documentInputSource
+ *The InputSource for the SCXML document
+ * @param errHandler
+ *The SAX ErrorHandler
+ * @param evalCtx
+ *the document-level variable context for guard condition
+ *evaluation
+ * @param evalEngine
+ *the scripting/expression language engine for creating local
+ *state-level variable contexts (if supported by a given
+ *scripting engine)
+ *
+ * @return SCXML The SCXML object corresponding to the file argument
+ *
+ * @see Context
+ * @see ErrorHandler
+ * @see Evaluator
+ */
+public static SCXML digest(final InputSource documentInputSource,
+final ErrorHandler errHandler, final Context evalCtx,
+final Evaluator evalEngine) {
+
+Digester scxmlDigester = SCXMLDigester.newInstance(null, null);
+scxmlDigester.setErrorHandler(errHandler);
+
+SCXML scxml = null;
+try {
+scxml = (SCXML) scxmlDigester.parse(documentInputSource);
+} catch (Exception e) {
+log.error(Could not parse SCXML, e);
 }
 
 if (scxml != null) {



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [vote][net] Release commons-net 1.4.1?

2005-12-01 Thread Rory Winston

Can you just summarize what your objections are instead of referencing 
some location that most people don't have access to?


robert burrell donkin wrote:

-1 to any commons-net new release. see pmc thread for details (if any
committers aren't on the pmc please shout and i'll nominate you)

- robert

On Thu, 2005-12-01 at 07:47 +0100, Mario Ivankovits wrote:
  

Steve Cohen wrote:

As I have little time now, I propose the following.  1.4.1 will be 
just 1.4.0 with whatever changes are needed to reverse the dependency 
on jdk 1.4.x.  No other bug fixes will be included.


Re-vote

+1 [yes]
-1 [no]
  

+1

---
Mario


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]







-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: commons-concoct - new project proposal

2005-12-01 Thread Giorgio Gallo


I might be wrong, but I think I've seen an URI implementation in Axis
(don't know if it's a strict RFC-2396 implementation, a java.net.URI
backport, just something they needed or something that does its best to
interpret any messy string passed in)

For me, I buy the simply use the : as a delimiter part :-)

To be honest, the very first scratch of the library relied on URIs, but
on a second thought I think URIs do not fit well in a library like this...

java.net.URIs:
- They are only available from jdk1.4 - of course ;-)
- They don't require the scheme to be specified, and I don't think
  there's a way to properly implement relative URI semantic in
  concoct
- They don't parse string:a string (  must be escaped with %20)
- They don't parse string:##
- They don't really provide any useful functionality for the lib, aside
  for syntax checking - which is not really useful IMHO

RFC-2396 URIs:
- defaulting to string: when no scheme is specified - a welcome
  feature IMHO, and one that would ease adoption of the lib in with
  .properties files - does not fit well with relative URI semantics
- the grammar is more strict than needed (see deviations in java.net.URI
  code)
- all the path stuff is irrelevant for the lib
- they require escaping beyond that of the scheme used and (possibly)
  the file format they are stored in (such as entity escape for xml).


Mario Ivankovits wrote:
 Hi Giorgio!
 Its purpose is to parse URI-like strings (anything in the form
 somescheme:somestring) into java objects according to a
 scheme-specific syntax (which is straightforward in most cases)
 Do you plan to support the full URI specification of do you simply use
 the : as delimiter ;-)
 But then the URI stuff of your project should be splitted out into its
 own project e.g. commons-uri
 
 In [vfs] we have needs for a jdk independend URI library.
 
 
 ---
 Mario
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [vote][net] Release commons-net 1.4.1?

2005-12-01 Thread Steve Cohen


robert burrell donkin wrote:

-1 to any commons-net new release. see pmc thread for details (if any
committers aren't on the pmc please shout and i'll nominate you)

- robert

On Thu, 2005-12-01 at 07:47 +0100, Mario Ivankovits wrote:


Steve Cohen wrote:

As I have little time now, I propose the following.  1.4.1 will be 
just 1.4.0 with whatever changes are needed to reverse the dependency 
on jdk 1.4.x.  No other bug fixes will be included.


Re-vote

+1 [yes]
-1 [no]


+1

---
Mario


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


OK.  Robert is referring to a serious issue here.  It's prudent to wait. 
 There are questions about copyright on one of our classes.


The thread Robert refers to has the subject

Re: Does Apache have agreement to use other open source code outside of 
Apache?


and it's all in the last couple of days.

So we have to wait.

Which is just as well.  Because I have another issue.  I don't 
understand the maven.compile.target property.  Working from the net 
1.4.0 tag, I change only project.properties to set maven.compile.target 
back to 1.2.  Since there are a few places in 1.4.0 that depend on jdk 
1.4, my expectation was that changing the project properties would cause 
the compile to break on those places.  But it did not.  It compiled 
successfully.


Why wouldn't it break?

Can someone explain how this works?







-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [vote][net] Release commons-net 1.4.1?

For the thread's info; Robert's cc'd Rory on the pmc email.

This is legal shit and irritatingly it seems there are increased
liability issues when you talk publically.

Any active committer should be on the PMC, unless they've only
recently joined, so if you're active kick away and one of us will
gladly nominate you.

--

Stephen: I'm guessing you didn't get my reply when you asked about not
getting mail from the list a while back. [EMAIL PROTECTED] is
subscribed, which forwards to [EMAIL PROTECTED] Is that still
active?

Hen

On 12/1/05, Rory Winston [EMAIL PROTECTED] wrote:
 Can you just summarize what your objections are instead of referencing
 some location that most people don't have access to?

 robert burrell donkin wrote:
  -1 to any commons-net new release. see pmc thread for details (if any
  committers aren't on the pmc please shout and i'll nominate you)
 
  - robert
 
  On Thu, 2005-12-01 at 07:47 +0100, Mario Ivankovits wrote:
 
  Steve Cohen wrote:
 
  As I have little time now, I propose the following.  1.4.1 will be
  just 1.4.0 with whatever changes are needed to reverse the dependency
  on jdk 1.4.x.  No other bug fixes will be included.
 
  Re-vote
 
  +1 [yes]
  -1 [no]
 
  +1
 
  ---
  Mario
 
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 



 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: commons-concoct - new project proposal

2005-12-01 Thread Giorgio Gallo


I've read trough the charter and will post a formal proposal as soon as
I get the time to write it down ;)

In the meantime, is there anyway I could upload the code (its around
60k, zipped), in a quest for initial committers to include on the proposal?


As regards incubation:
- The code have never been released, whether on its own or inside a
larger application/library
- I'm the sole copyright owner of the code
- I am (of course) willing to donate it to ASF

Does this imply it needs to be incubated?

Rahul Akolkar wrote:
 On 11/30/05, Matt Benson [EMAIL PROTECTED] wrote:
 Oddly enough, I have spent the last week point five
 working on a similar setup at $work.  My syntax is
 slightly different (extended I would say).  If this
 proposal is accepted in principle, I could query my
 boss whether we could make any contributions.  As an
 Apache committer, I believe I have the right to work
 in the Jakarta commons sandbox on such a project.

 Commons people?

 snip/
 
 Indeed, the Commons charter says you're welcome :-)
 
 Procedurally, its nice to start with a [proposal] thread, in the
 format specified by the Example Package Proposal section of the
 charter [1], and obtain feedback from existing Commons committers.
 
 If the code was *not* developed in the ASF repository, you will have
 to incubate [2] it first. Someone with more incubator-related
 experience will probably clarify once the details are posted in the
 proposal.
 
 -Rahul
 
 [1] http://jakarta.apache.org/commons/charter.html
 [2] http://incubator.apache.org/
 
 
 
 
 -Matt

 --- Giorgio Gallo [EMAIL PROTECTED] wrote:

 I've been working on a library I aim to contribute
 to the commons
 bazaar (as a standalone lib or maybe as part of
 commons-transform), but:

 - I'm not sure mine is a good idea for a commons
 library
 - I'm not a commons committer
 - The lib still needs work (it is a prototype right
 now)

 The library, which is named Concoct for now, should
 come handy in
 configuration files (that is, I think so :).

 Its purpose is to parse URI-like strings (anything
 in the form
 somescheme:somestring) into java objects according
 to a
 scheme-specific syntax (which is straightforward in
 most cases): for now
 it can only handle strings like

 int:189
 - new Integer(189)

 string:foo
 - new String(foo)

 null:whatever
 - null

 class:oracle.jdbc.driver.OracleDriver
 - oracle.jdbc.driver.OracleDriver.class

 and convert expressions like


 bean:org.example.MyClass(foo=string:foo,bar=null:null)
 into an instance of MyClass, with attributes set as
 specified.

 Plans are to add many other schemes, eg:
 - jdbc: to produce Connections
 - jdbc-datasource: to produce DataSources (via
 commons-dbcp)
 - singleton: to return the same Object if the
 expression is evaluated
 more than once
 - proxy: to build a dynamic proxy
 - file:,http:,ftp: to read the specified url
 into a java.net.URL
 - deserialize: to read an object from an URL
 - ...

 The idea is to enable the combination of different
 schemes in
 expressions (such as in the bean: scheme example -
 above).



 -
 To unsubscribe, e-mail:
 [EMAIL PROTECTED]
 For additional commands, e-mail:
 [EMAIL PROTECTED]






 __
 Yahoo! Mail - PC Magazine Editors' Choice 2005
 http://mail.yahoo.com

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]


 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Committer cleanup

I'd like to go ahead and remove all the committers from subversion for
commons, and then add back anyone who has committed in the last 6
months.

We have 105 commons committers, and 36 additional sandbox committers.

We've had 43 committers committing to proper, and 7 extra committing
to sandbox in the last 6 months.

Then we'd add back anyone else on request if need be.

Anyone against the idea?

Hen

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: commons-concoct - new project proposal

On 12/1/05, Giorgio Gallo [EMAIL PROTECTED] wrote:

 I've read trough the charter and will post a formal proposal as soon as
 I get the time to write it down ;)

 In the meantime, is there anyway I could upload the code (its around
 60k, zipped), in a quest for initial committers to include on the proposal?

Either attach it to a bugzilla entry, or mail it to me and I'll put it
in my ~ space

 As regards incubation:
 - The code have never been released, whether on its own or inside a
 larger application/library
 - I'm the sole copyright owner of the code
 - I am (of course) willing to donate it to ASF

 Does this imply it needs to be incubated?

Depends on the people interested. If there are no/few existing
committers interested, then yes you'd need to be incubated. If however
the majority of interested committers are existing committers, then
we'll go with a code grant and goto the sandbox.

Hen

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[all] short critique of site

Some thoughts on the site.

A] Looking at the front page.

1) Jakarta link on the bar is redundant. We already have a huge logo
in the top left.
2) No need to include the direct svn link, just use viewcvs. Simpler
for the user.
3) Korea translation link is dead.
4) Japanese translation link is out of date.
5) While the wiki is unofficial documentation, it is an official resource.
6) DB Commons is empty.
7) Contributor page. Is this worth the effort of the maintenance?

B] Clicking on sandbox.

1) There are many projects which have become dormant. How should we be
changing the site?
2) Corresponding Wiki page needs changing [my fault :) ]

Okay, onto something else next.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[Jakarta-commons Wiki] Update of AutomatedIdeas by HenriYandell

2005-12-01 Thread Apache Wiki

Dear Wiki user,

You have subscribed to a wiki page or wiki category on Jakarta-commons Wiki 
for change notification.

The following page has been changed by HenriYandell:
http://wiki.apache.org/jakarta-commons/AutomatedIdeas

The comment on the change is:
Fixing urls to latest versions

--
  
  Steps?
  
- Obviously I'm (HenriYandell) tied to my own tools and need kicking to use 
something else. I'd use an improved variant of [http://builds.osjava.org 
Integration] for the automated developer site and [http://multidoc.osjava.org 
Multidoc] as the wrapping-interface.
+ Obviously I'm (HenriYandell) tied to my own tools and need kicking to use 
something else. I'd use an improved variant of [http://builds.osjava.org/osjava 
Integration] for the automated developer site and 
[http://dist.osjava.org/releases/multidoc-jnr/ Multidoc] as the 
wrapping-interface.
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[Jakarta-commons Wiki] Update of TheSandbox by HenriYandell

2005-12-01 Thread Apache Wiki

Dear Wiki user,

You have subscribed to a wiki page or wiki category on Jakarta-commons Wiki 
for change notification.

The following page has been changed by HenriYandell:
http://wiki.apache.org/jakarta-commons/TheSandbox

The comment on the change is:
An attempt at an update.

--
  
  ||'''Component'''||'''State'''||'''Plan'''||
  
+ ||VFS||Promoted||under active development again.||
- ||Cache||Published
- ||Clazz||Published||Dormant, no clear use case, no community, stable code. 
Was too complex for many (who could use DynaBean), and not complex enough for 
others (who needed a Java syntax tree as found in Eclipse/Netbeans)||
  ||Compress||Published||Dormant, no current community, code extracted from 
Ant.||
- ||CommonsConvert||Published||Development intended, strong use case. Various 
conversion ideas extracted from BeanUtils.||
- ||Events||Published||Dormant, no current community.||
- ||Functor||Published||Dormant, no current community, stable code.||
  ||Id||Published||In development, promotion target, strong use case, stable 
code. Parts from Lang, parts new.||
- ||JJar||Published||ready to die as superseded by Apache Depot.||
- ||Mapper||Published
- ||Messenger||Published
- ||Scaffold||Published|| is a toolkit for building web applications, to 
complement web application frameworks (such as Struts).||
  ||[:SCXML]||Published||Reference Implementation of State Chart XML (SCXML), 
currently a W3C Working Draft.||
+ ||SQL||Published||Moved to db.apache.org as DdlUtils||
- ||SQL||Published
- ||ThreadPool||Published
- ||VFS||Published||under active development again.||
- ||Workflow||Published
  ||FeedParser||Published
  
- ||Filters||Unpublished||meant to contain servlet filters, but not yet come 
alive||
- ||HTTP||Unpublished||handful of classes for use with http connections||
  ||Jex||Unpublished
  ||Launcher||Unpublished
- ||Periodicity||Unpublished
- ||Reflect||Unpublished||Extracted from BeanUtils, but unfinished and in a 
coma. Proved to difficult to test across JVMs and for little benefit.||
  ||Servlet||Unpublished||not enough here to justify a component||
- ||Threading||Unpublished||migrated over from Avalon Excalibur. Currently 
inactive.||
- ||xo||Unpublished||XML to Bean mapper.||
  ||Benchmark||Unpublished
  
  ||Altrmi||Dead||Moved from the Incubator to Codehaus now 
[http://jremoting.codehaus.org JRemoting].||
  ||Graph||Dead||rewritten as graph2||
- ||JJar||Dead||superseded by [http://incubator.apache.org/depot/ Apache Depot] 
(currently in the incubator)||
  ||JRCS||Dead||no longer really hosted by Jakarta. It has moved to Codehaus 
[http://cvs.codehaus.org/viewcvs.cgi/jrcs/?root=codehaus Codehaus CVS]||
  ||Pattern||Dead||code moved to lang and id projects.||
  
- ||cache||??
- ||grant||??
- ||graph2||??
- ||joran||??
- ||jux||??
- ||rupert||??
- ||services||??
+ ||Filters||-dormant||meant to contain servlet filters, but not yet come 
alive||
+ ||HTTP||-dormant||handful of classes for use with http connections||
+ ||Periodicity||-dormant
+ ||Reflect||-dormant||Extracted from BeanUtils, but unfinished and in a coma. 
Proved to difficult to test across JVMs and for little benefit.||
+ ||Threading||-dormant||migrated over from Avalon Excalibur. Currently 
inactive.||
+ ||xo||-dormant||XML to Bean mapper.||
+ ||cache||-dormant
+ ||grant||-dormant
+ ||graph2||-dormant
+ ||jux||-dormant
+ ||rupert||-dormant
+ ||services||-dormant
- ||simplestore||??
+ ||simplestore||-dormant
- ||workflow||??
- ||xmlunit||??
+ ||xmlunit||-dormant
+ ||Cache||-dormant
+ ||Clazz||-dormant||Dormant, no clear use case, no community, stable code. 
Was too complex for many (who could use DynaBean), and not complex enough for 
others (who needed a Java syntax tree as found in Eclipse/Netbeans)||
+ ||CommonsConvert||-dormant||Development intended, strong use case. Various 
conversion ideas extracted from BeanUtils.||
+ ||Events||-dormant||Dormant, no current community.||
+ ||Functor||-dormant||Dormant, no current community, stable code.||
+ ||JJar||-dormant||superseded by [http://incubator.apache.org/depot/ Apache 
Depot] (currently in the incubator)||
+ ||Mapper||-dormant
+ ||Messenger||-dormant||In fact dead, real version is at Codehaus nowadays||
+ ||Scaffold||-dormant|| is a toolkit for building web applications, to 
complement web application frameworks (such as Struts).||
+ ||ThreadPool||-dormant
+ ||Workflow||-dormant
  ||periodicity_1||-dormant
  ||joran||-dormant
  ||launcher||-dormant
@@ -75, +72 @@

  ||Util||Deleted||this component split into many others and eventually the 
original component was left with nothing.||
  ||Armi||Deleted||prior name of 'altrmi'.||
  ||uid||Deleted||prior name of 'id'.||
+ ||joran||Deleted

[jelly] Gump failures

These seem to have been going on for months.

Any chance they can be fixed and stop spamming us?

Hen

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jelly] Gump failures

2005-12-01 Thread Dion Gillard

It's a break in how Jaxen works.

Unless we upgrade all of Jelly to work with the code changes in Jaxen,
the failures will continue.

Personally, I'd rather stick where we are with jaxen in Jelly and stop
Gump from nagging us.

On 12/2/05, Henri Yandell [EMAIL PROTECTED] wrote:
 These seem to have been going on for months.

 Any chance they can be fixed and stop spamming us?

 Hen

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




--
http://www.multitask.com.au/people/dion/
You are going to let the fear of poverty govern your life and your
reward will be that you will eat, but you will not live. - George
Bernard Shaw

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[EMAIL PROTECTED]: Project commons-jelly-test (in module commons-jelly) failed

2005-12-01 Thread commons-jelly development

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project commons-jelly-test has an issue affecting its community integration.
This issue affects 1 projects.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-jelly-test :  Commons Jelly


Full details are available at:

http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-test/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Dependency on jakarta-servletapi-5-servlet exists, no need to add for 
property maven.jar.servletapi.
 -DEBUG- Dependency on jakarta-taglibs-standard exists, no need to add for 
property maven.jar.jstl.
 -DEBUG- Dependency on xml-xerces exists, no need to add for property 
maven.jar.xerces.
 -WARNING- Overriding Maven properties: 
[/usr/local/gump/public/workspace/commons-jelly/build.properties]
 -DEBUG- (Gump generated) Maven Properties in: 
/usr/local/gump/public/workspace/commons-jelly/build.properties
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: 
/usr/local/gump/public/workspace/commons-jelly/project.xml
 -DEBUG- Maven project properties in: 
/usr/local/gump/public/workspace/commons-jelly/project.properties
 -INFO- Project Reports in: 
/usr/local/gump/public/workspace/commons-jelly/target/test-reports



The following work was performed:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-test/gump_work/build_commons-jelly_commons-jelly-test.html
Work Name: build_commons-jelly_commons-jelly-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 54 secs
Command Line: maven --offline jar 
[Working Directory: /usr/local/gump/public/workspace/commons-jelly]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-01122005.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-01122005.jar:/usr/local/gump/public/workspace/jakarta-commons/discovery/dist/commons-discovery.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-01122005.jar:/usr/local/gump/public/workspace/jakarta-commons/lang/dist/commons-lang-01122005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-01122005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api-01122005.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/forehead/forehead-1.0-beta-5.jar:/usr/local/gump/public/workspace/jakarta-servletapi-5/jsr154/dist/lib/servlet-api.jar:/usr/local/gump/public/workspace/jakarta-taglibs/dist/standard/lib/jstl.jar:/usr/local/gump/packages/jaxen-1.1-beta-6/jaxen-1.1-beta-6.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar
-
[junit] Expected expression: ${singleSize*2}
[junit] Actual expression: ${doubleSize} File: 
file:/x1/gump/public/workspace/commons-jelly/target/test-classes/org/apache/commons/jelly/suite.jelly
 At tag test:assertEquals: line: 359 column: 75
[junit] org.apache.commons.jelly.JellyTagException: 
file:/x1/gump/public/workspace/commons-jelly/target/test-classes/org/apache/commons/jelly/suite.jelly:359:75:
 test:assertEquals  expected:[22] but was:[22]
[junit] Expected expression: ${singleSize*2}
[junit] Actual expression: ${doubleSize} File: 
file:/x1/gump/public/workspace/commons-jelly/target/test-classes/org/apache/commons/jelly/suite.jelly
 At tag test:assertEquals: line: 359 column: 75
[junit] at 
org.apache.commons.jelly.impl.TagScript.handleException(TagScript.java:712)
[junit] at 
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:282)
[junit] at 
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
[junit] at 
org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59)
[junit] Caused by: 
org.apache.commons.jelly.tags.junit.JellyAssertionFailedError:  expected:[22] 
but was:[22]
[junit] Expected expression: ${singleSize*2}
[junit] Actual expression: ${doubleSize} File: 
file:/x1/gump/public/workspace/commons-jelly/target/test-classes/org/apache/commons/jelly/suite.jelly
 At tag test:assertEquals: line: 359 column: 75
[junit] at 
org.apache.commons.jelly.tags.junit.AssertTagSupport.fail(AssertTagSupport.java:39)
[junit] at 
org.apache.commons.jelly.tags.junit.AssertTagSupport.failNotEquals(AssertTagSupport.java:62)
[junit] at 
org.apache.commons.jelly.tags.junit.AssertEqualsTag.doTag(AssertEqualsTag.java:55)
[junit] at

[EMAIL PROTECTED]: Project commons-jelly-test (in module commons-jelly) failed

2005-12-01 Thread commons-jelly development

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project commons-jelly-test has an issue affecting its community integration.
This issue affects 1 projects.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-jelly-test :  Commons Jelly


Full details are available at:

http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-test/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Dependency on jakarta-servletapi-5-servlet exists, no need to add for 
property maven.jar.servletapi.
 -DEBUG- Dependency on jakarta-taglibs-standard exists, no need to add for 
property maven.jar.jstl.
 -DEBUG- Dependency on xml-xerces exists, no need to add for property 
maven.jar.xerces.
 -WARNING- Overriding Maven properties: 
[/usr/local/gump/public/workspace/commons-jelly/build.properties]
 -DEBUG- (Gump generated) Maven Properties in: 
/usr/local/gump/public/workspace/commons-jelly/build.properties
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: 
/usr/local/gump/public/workspace/commons-jelly/project.xml
 -DEBUG- Maven project properties in: 
/usr/local/gump/public/workspace/commons-jelly/project.properties
 -INFO- Project Reports in: 
/usr/local/gump/public/workspace/commons-jelly/target/test-reports



The following work was performed:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-test/gump_work/build_commons-jelly_commons-jelly-test.html
Work Name: build_commons-jelly_commons-jelly-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 54 secs
Command Line: maven --offline jar 
[Working Directory: /usr/local/gump/public/workspace/commons-jelly]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-01122005.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-01122005.jar:/usr/local/gump/public/workspace/jakarta-commons/discovery/dist/commons-discovery.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-01122005.jar:/usr/local/gump/public/workspace/jakarta-commons/lang/dist/commons-lang-01122005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-01122005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api-01122005.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/forehead/forehead-1.0-beta-5.jar:/usr/local/gump/public/workspace/jakarta-servletapi-5/jsr154/dist/lib/servlet-api.jar:/usr/local/gump/public/workspace/jakarta-taglibs/dist/standard/lib/jstl.jar:/usr/local/gump/packages/jaxen-1.1-beta-6/jaxen-1.1-beta-6.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar
-
[junit] Expected expression: ${singleSize*2}
[junit] Actual expression: ${doubleSize} File: 
file:/x1/gump/public/workspace/commons-jelly/target/test-classes/org/apache/commons/jelly/suite.jelly
 At tag test:assertEquals: line: 359 column: 75
[junit] org.apache.commons.jelly.JellyTagException: 
file:/x1/gump/public/workspace/commons-jelly/target/test-classes/org/apache/commons/jelly/suite.jelly:359:75:
 test:assertEquals  expected:[22] but was:[22]
[junit] Expected expression: ${singleSize*2}
[junit] Actual expression: ${doubleSize} File: 
file:/x1/gump/public/workspace/commons-jelly/target/test-classes/org/apache/commons/jelly/suite.jelly
 At tag test:assertEquals: line: 359 column: 75
[junit] at 
org.apache.commons.jelly.impl.TagScript.handleException(TagScript.java:712)
[junit] at 
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:282)
[junit] at 
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
[junit] at 
org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59)
[junit] Caused by: 
org.apache.commons.jelly.tags.junit.JellyAssertionFailedError:  expected:[22] 
but was:[22]
[junit] Expected expression: ${singleSize*2}
[junit] Actual expression: ${doubleSize} File: 
file:/x1/gump/public/workspace/commons-jelly/target/test-classes/org/apache/commons/jelly/suite.jelly
 At tag test:assertEquals: line: 359 column: 75
[junit] at 
org.apache.commons.jelly.tags.junit.AssertTagSupport.fail(AssertTagSupport.java:39)
[junit] at 
org.apache.commons.jelly.tags.junit.AssertTagSupport.failNotEquals(AssertTagSupport.java:62)
[junit] at 
org.apache.commons.jelly.tags.junit.AssertEqualsTag.doTag(AssertEqualsTag.java:55)
[junit] at

Re: [jelly] Gump failures

Irritating. :)

The classic one, where if we turn it off we'll never turn it on again,
but fixing the problem is not in the forseeable future.

I'm +1 on turning it off. Maybe stick a note in the root dir of the Jelly svn.

Hen

On 12/1/05, Dion Gillard [EMAIL PROTECTED] wrote:
 It's a break in how Jaxen works.

 Unless we upgrade all of Jelly to work with the code changes in Jaxen,
 the failures will continue.

 Personally, I'd rather stick where we are with jaxen in Jelly and stop
 Gump from nagging us.

 On 12/2/05, Henri Yandell [EMAIL PROTECTED] wrote:
  These seem to have been going on for months.
 
  Any chance they can be fixed and stop spamming us?
 
  Hen
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 


 --
 http://www.multitask.com.au/people/dion/
 You are going to let the fear of poverty govern your life and your
 reward will be that you will eat, but you will not live. - George
 Bernard Shaw

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[all] Commons Manual

Let's imagine a manual existed for Commons committers. It would assume
that a committer understands the ASF, ie) they've read the
Apache-Committer-Manual (imagine that exists too). What would the
chapters be?

Initial list:

* Short description of Commons/Introduction.
* Communication. How to use the mailing lists. Voting.
* Subversion information. How to check code out.
* Maven information. How to build.
* Site information. How to generate the site. How to upload your changes.
* Releasing. How to release.
* PMC. What they're there for (Commons point of view).
* Legal. How to not screw-up.

Am I missing anything?

Idea, if it's not obvious, is to bring together the various bits of
information on wiki's, site and more importantly in people's heads.
Stick it in a more concrete form and tell people to go read it.

Hen

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Committer cleanup

2005-12-01 Thread Martin Cooper

On 12/1/05, Henri Yandell [EMAIL PROTECTED] wrote:

 I'd like to go ahead and remove all the committers from subversion for
 commons, and then add back anyone who has committed in the last 6
 months.

 We have 105 commons committers, and 36 additional sandbox committers.

 We've had 43 committers committing to proper, and 7 extra committing
 to sandbox in the last 6 months.

 Then we'd add back anyone else on request if need be.

 Anyone against the idea?


6 months seems quite short if you're only counting commits. Would the
numbers be significantly different if we use 1 year instead?

Where do you plan on keeping the list of people removed? It will need to be
somewhere that we can get at, so that we know who can be added back without
question.

--
Martin Cooper


Hen

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

Re: [all] short critique of site

2005-12-01 Thread Martin Cooper

On 12/1/05, Henri Yandell [EMAIL PROTECTED] wrote:

 Some thoughts on the site.

 A] Looking at the front page.

 1) Jakarta link on the bar is redundant. We already have a huge logo
 in the top left.
 2) No need to include the direct svn link, just use viewcvs. Simpler
 for the user.


Perhaps, but AIUI viewcvs puts a significantly higher load on our
infrastructure, and the infra@ folks have specifically stated that they
would prefer people to use direct links to the SVN repo.

--
Martin Cooper


3) Korea translation link is dead.
 4) Japanese translation link is out of date.
 5) While the wiki is unofficial documentation, it is an official resource.
 6) DB Commons is empty.
 7) Contributor page. Is this worth the effort of the maintenance?

 B] Clicking on sandbox.

 1) There are many projects which have become dormant. How should we be
 changing the site?
 2) Corresponding Wiki page needs changing [my fault :) ]

 Okay, onto something else next.

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

[EMAIL PROTECTED]: Project commons-jelly-tags-xml-test (in module commons-jelly) failed

2005-12-01 Thread commons-jelly-tags-xml development

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project commons-jelly-tags-xml-test has an issue affecting its community 
integration.
This issue affects 1 projects.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-jelly-tags-xml-test :  Commons Jelly


Full details are available at:

http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-xml-test/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Dependency on xml-xerces exists, no need to add for property 
maven.jar.xerces.
 -WARNING- Overriding Maven properties: 
[/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/build.properties]
 -DEBUG- (Gump generated) Maven Properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/build.properties
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/project.xml
 -DEBUG- Maven project properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/project.properties
 -INFO- Project Reports in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/test-reports



The following work was performed:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-xml-test/gump_work/build_commons-jelly_commons-jelly-tags-xml-test.html
Work Name: build_commons-jelly_commons-jelly-tags-xml-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 41 secs
Command Line: maven --offline jar 
[Working Directory: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-01122005.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-01122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-01122005.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-01122005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-01122005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api-01122005.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/jaxen-1.1-beta-6/jaxen-1.1-beta-6.jar
-
[junit] at 
org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59)
[junit] 
[junit] 
[junit] Testcase: 
testSetSingleNodeAndAsString(org.apache.commons.jelly.tags.junit.CaseTag$1):
  Caused an ERROR
[junit] 
file:/x1/gump/public/workspace/commons-jelly/jelly-tags/xml/target/test-classes/org/apache/commons/jelly/tags/xml/suite.jelly:294:81:
 x:set You must define an attribute called 'select' for this tag.
[junit] org.apache.commons.jelly.MissingAttributeException: 
file:/x1/gump/public/workspace/commons-jelly/jelly-tags/xml/target/test-classes/org/apache/commons/jelly/tags/xml/suite.jelly:294:81:
 x:set You must define an attribute called 'select' for this tag.
[junit] at 
org.apache.commons.jelly.tags.xml.SetTag.doTag(SetTag.java:86)
[junit] at 
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262)
[junit] at 
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
[junit] at 
org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59)
[junit] 
[junit] 
[junit] Testcase: 
testSetStringLists(org.apache.commons.jelly.tags.junit.CaseTag$1):
Caused an ERROR
[junit] 
file:/x1/gump/public/workspace/commons-jelly/jelly-tags/xml/target/test-classes/org/apache/commons/jelly/tags/xml/suite.jelly:339:82:
 x:set You must define an attribute called 'select' for this tag.
[junit] org.apache.commons.jelly.MissingAttributeException: 
file:/x1/gump/public/workspace/commons-jelly/jelly-tags/xml/target/test-classes/org/apache/commons/jelly/tags/xml/suite.jelly:339:82:
 x:set You must define an attribute called 'select' for this tag.
[junit] at 
org.apache.commons.jelly.tags.xml.SetTag.doTag(SetTag.java:86)
[junit] at 
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262)
[junit] at 
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
[junit] at 
org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59)
[junit] 
[junit] 
[junit] Testcase: 
testEntities(org.apache.commons.jelly.tags.junit.CaseTag$1):  Caused an 
ERROR
[junit]

[EMAIL PROTECTED]: Project commons-jelly-tags-xml-test (in module commons-jelly) failed

2005-12-01 Thread commons-jelly-tags-xml development

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project commons-jelly-tags-xml-test has an issue affecting its community 
integration.
This issue affects 1 projects.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-jelly-tags-xml-test :  Commons Jelly


Full details are available at:

http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-xml-test/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Dependency on xml-xerces exists, no need to add for property 
maven.jar.xerces.
 -WARNING- Overriding Maven properties: 
[/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/build.properties]
 -DEBUG- (Gump generated) Maven Properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/build.properties
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/project.xml
 -DEBUG- Maven project properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/project.properties
 -INFO- Project Reports in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/test-reports



The following work was performed:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-xml-test/gump_work/build_commons-jelly_commons-jelly-tags-xml-test.html
Work Name: build_commons-jelly_commons-jelly-tags-xml-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 41 secs
Command Line: maven --offline jar 
[Working Directory: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-01122005.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-01122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-01122005.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-01122005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-01122005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api-01122005.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/jaxen-1.1-beta-6/jaxen-1.1-beta-6.jar
-
[junit] at 
org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59)
[junit] 
[junit] 
[junit] Testcase: 
testSetSingleNodeAndAsString(org.apache.commons.jelly.tags.junit.CaseTag$1):
  Caused an ERROR
[junit] 
file:/x1/gump/public/workspace/commons-jelly/jelly-tags/xml/target/test-classes/org/apache/commons/jelly/tags/xml/suite.jelly:294:81:
 x:set You must define an attribute called 'select' for this tag.
[junit] org.apache.commons.jelly.MissingAttributeException: 
file:/x1/gump/public/workspace/commons-jelly/jelly-tags/xml/target/test-classes/org/apache/commons/jelly/tags/xml/suite.jelly:294:81:
 x:set You must define an attribute called 'select' for this tag.
[junit] at 
org.apache.commons.jelly.tags.xml.SetTag.doTag(SetTag.java:86)
[junit] at 
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262)
[junit] at 
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
[junit] at 
org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59)
[junit] 
[junit] 
[junit] Testcase: 
testSetStringLists(org.apache.commons.jelly.tags.junit.CaseTag$1):
Caused an ERROR
[junit] 
file:/x1/gump/public/workspace/commons-jelly/jelly-tags/xml/target/test-classes/org/apache/commons/jelly/tags/xml/suite.jelly:339:82:
 x:set You must define an attribute called 'select' for this tag.
[junit] org.apache.commons.jelly.MissingAttributeException: 
file:/x1/gump/public/workspace/commons-jelly/jelly-tags/xml/target/test-classes/org/apache/commons/jelly/tags/xml/suite.jelly:339:82:
 x:set You must define an attribute called 'select' for this tag.
[junit] at 
org.apache.commons.jelly.tags.xml.SetTag.doTag(SetTag.java:86)
[junit] at 
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262)
[junit] at 
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
[junit] at 
org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59)
[junit] 
[junit] 
[junit] Testcase: 
testEntities(org.apache.commons.jelly.tags.junit.CaseTag$1):  Caused an 
ERROR
[junit]

Re: [all] Commons Manual

2005-12-01 Thread Martin Cooper

On 12/1/05, Henri Yandell [EMAIL PROTECTED] wrote:

 Let's imagine a manual existed for Commons committers. It would assume
 that a committer understands the ASF, ie) they've read the
 Apache-Committer-Manual (imagine that exists too). What would the
 chapters be?

 Initial list:

 * Short description of Commons/Introduction.
 * Communication. How to use the mailing lists. Voting.
 * Subversion information. How to check code out.
 * Maven information. How to build.
 * Site information. How to generate the site. How to upload your changes.
 * Releasing. How to release.
 * PMC. What they're there for (Commons point of view).
 * Legal. How to not screw-up.

 Am I missing anything?


Not sure if these would be in the committers manual or elsewhere, as I'm
similarly not sure that all of the above should be part of the manual rather
than for everyone to read.

* How the sandbox works / how components get promoted.
* The whole active / dormant / dead process.

--
Martin Cooper


Idea, if it's not obvious, is to bring together the various bits of
 information on wiki's, site and more importantly in people's heads.
 Stick it in a more concrete form and tell people to go read it.

 Hen

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

[EMAIL PROTECTED]: Project commons-jelly-tags-swing (in module commons-jelly) failed

2005-12-01 Thread JellySwing development

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project commons-jelly-tags-swing has an issue affecting its community 
integration.
This issue affects 1 projects.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-jelly-tags-swing :  Commons Jelly


Full details are available at:

http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-swing/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [commons-jelly-tags-swing-01122005.jar] identifier set to 
project name
 -DEBUG- Dependency on xml-xerces exists, no need to add for property 
maven.jar.xerces.
 -DEBUG- (Gump generated) Maven Properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/swing/build.properties
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/swing/project.xml
 -DEBUG- Maven project properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/swing/project.properties
 -INFO- Project Reports in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/swing/target/test-reports
 -WARNING- No directory 
[/usr/local/gump/public/workspace/commons-jelly/jelly-tags/swing/target/test-reports]
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-swing/gump_work/build_commons-jelly_commons-jelly-tags-swing.html
Work Name: build_commons-jelly_commons-jelly-tags-swing (Type: Build)
Work ended in a state of : Failed
Elapsed: 4 secs
Command Line: maven --offline jar 
[Working Directory: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/swing]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-01122005.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-01122005.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-01122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/target/commons-jelly-tags-define-01122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/interaction/target/commons-jelly-tags-interaction-01122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-01122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-01122005.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-01122005.jar:/usr/local/gump/public/workspace/jakarta-commons/lang/dist/commons-lang-01122005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-01122005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api-01122005.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/jaxen-1.1-beta-6/jaxen-1.1-beta-6.jar
-
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:274)
at java.lang.Class.newInstance0(Class.java:308)
at java.lang.Class.newInstance(Class.java:261)
at 
org.apache.commons.jelly.JellyContext.getTagLibrary(JellyContext.java:432)
at 
org.apache.maven.jelly.MavenJellyContext.getTagLibrary(MavenJellyContext.java:171)
at 
org.apache.commons.jelly.parser.XMLParser.createTag(XMLParser.java:1033)
at 
org.apache.commons.jelly.parser.XMLParser.startElement(XMLParser.java:647)
at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown 
Source)
at 
org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement(Unknown Source)
at 
org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source)
at 
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
 Source)
at 
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown 
Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at

[EMAIL PROTECTED]: Project commons-jelly-tags-swing (in module commons-jelly) failed

2005-12-01 Thread JellySwing development

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project commons-jelly-tags-swing has an issue affecting its community 
integration.
This issue affects 1 projects.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-jelly-tags-swing :  Commons Jelly


Full details are available at:

http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-swing/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [commons-jelly-tags-swing-01122005.jar] identifier set to 
project name
 -DEBUG- Dependency on xml-xerces exists, no need to add for property 
maven.jar.xerces.
 -DEBUG- (Gump generated) Maven Properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/swing/build.properties
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/swing/project.xml
 -DEBUG- Maven project properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/swing/project.properties
 -INFO- Project Reports in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/swing/target/test-reports
 -WARNING- No directory 
[/usr/local/gump/public/workspace/commons-jelly/jelly-tags/swing/target/test-reports]
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-swing/gump_work/build_commons-jelly_commons-jelly-tags-swing.html
Work Name: build_commons-jelly_commons-jelly-tags-swing (Type: Build)
Work ended in a state of : Failed
Elapsed: 4 secs
Command Line: maven --offline jar 
[Working Directory: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/swing]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-01122005.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-01122005.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-01122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/target/commons-jelly-tags-define-01122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/interaction/target/commons-jelly-tags-interaction-01122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-01122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-01122005.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-01122005.jar:/usr/local/gump/public/workspace/jakarta-commons/lang/dist/commons-lang-01122005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-01122005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api-01122005.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/jaxen-1.1-beta-6/jaxen-1.1-beta-6.jar
-
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:274)
at java.lang.Class.newInstance0(Class.java:308)
at java.lang.Class.newInstance(Class.java:261)
at 
org.apache.commons.jelly.JellyContext.getTagLibrary(JellyContext.java:432)
at 
org.apache.maven.jelly.MavenJellyContext.getTagLibrary(MavenJellyContext.java:171)
at 
org.apache.commons.jelly.parser.XMLParser.createTag(XMLParser.java:1033)
at 
org.apache.commons.jelly.parser.XMLParser.startElement(XMLParser.java:647)
at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown 
Source)
at 
org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement(Unknown Source)
at 
org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source)
at 
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
 Source)
at 
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown 
Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at

[EMAIL PROTECTED]: Project commons-jelly-tags-define-test (in module commons-jelly) failed

2005-12-01 Thread commons-jelly-tags-define development

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project commons-jelly-tags-define-test has an issue affecting its community 
integration.
This issue affects 1 projects.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-jelly-tags-define-test :  Commons Jelly


Full details are available at:

http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-define-test/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Dependency on xml-xerces exists, no need to add for property 
maven.jar.xerces.
 -WARNING- Overriding Maven properties: 
[/usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/build.properties]
 -DEBUG- (Gump generated) Maven Properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/build.properties
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/project.xml
 -DEBUG- Maven project properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/project.properties
 -INFO- Project Reports in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/target/test-reports



The following work was performed:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-define-test/gump_work/build_commons-jelly_commons-jelly-tags-define-test.html
Work Name: build_commons-jelly_commons-jelly-tags-define-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 14 secs
Command Line: maven --offline jar 
[Working Directory: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/define]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-01122005.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-01122005.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-01122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/dynabean/target/commons-jelly-tags-dynabean-01122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-01122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-01122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-01122005.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-01122005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-01122005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api-01122005.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/jaxen-1.1-beta-6/jaxen-1.1-beta-6.jar
-
[junit] at 
org.jaxen.saxpath.base.XPathReader.unionExpr(XPathReader.java:1129)
[junit] at 
org.jaxen.saxpath.base.XPathReader.unaryExpr(XPathReader.java:1117)
[junit] at 
org.jaxen.saxpath.base.XPathReader.multiplicativeExpr(XPathReader.java:1039)
[junit] at 
org.jaxen.saxpath.base.XPathReader.additiveExpr(XPathReader.java:982)
[junit] at 
org.jaxen.saxpath.base.XPathReader.relationalExpr(XPathReader.java:902)
[junit] at 
org.jaxen.saxpath.base.XPathReader.equalityExpr(XPathReader.java:850)
[junit] at 
org.jaxen.saxpath.base.XPathReader.andExpr(XPathReader.java:826)
[junit] at 
org.jaxen.saxpath.base.XPathReader.orExpr(XPathReader.java:804)
[junit] at org.jaxen.saxpath.base.XPathReader.expr(XPathReader.java:797)
[junit] at 
org.jaxen.saxpath.base.XPathReader.parse(XPathReader.java:105)
[junit] at org.jaxen.BaseXPath.init(BaseXPath.java:126)
[junit] at org.jaxen.BaseXPath.init(BaseXPath.java:152)
[junit] at org.jaxen.dom4j.Dom4jXPath.init(Dom4jXPath.java:101)
[junit] at 
org.apache.commons.jelly.expression.xpath.XPathExpression.evaluate(XPathExpression.java:78)
[junit] at 
org.apache.commons.jelly.expression.ExpressionSupport.evaluateRecurse(ExpressionSupport.java:61)
[junit] at 
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:256)
[junit] at 
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
[junit] at 
org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59)
[junit] at junit.framework.TestCase.runBare(TestCase.java:127)
[junit] at junit.framework.TestResult$1.protect(TestResult.java:106)
[junit] at

[EMAIL PROTECTED]: Project commons-jelly-tags-define-test (in module commons-jelly) failed

2005-12-01 Thread commons-jelly-tags-define development

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project commons-jelly-tags-define-test has an issue affecting its community 
integration.
This issue affects 1 projects.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-jelly-tags-define-test :  Commons Jelly


Full details are available at:

http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-define-test/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Dependency on xml-xerces exists, no need to add for property 
maven.jar.xerces.
 -WARNING- Overriding Maven properties: 
[/usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/build.properties]
 -DEBUG- (Gump generated) Maven Properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/build.properties
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/project.xml
 -DEBUG- Maven project properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/project.properties
 -INFO- Project Reports in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/target/test-reports



The following work was performed:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-define-test/gump_work/build_commons-jelly_commons-jelly-tags-define-test.html
Work Name: build_commons-jelly_commons-jelly-tags-define-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 14 secs
Command Line: maven --offline jar 
[Working Directory: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/define]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-01122005.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-01122005.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-01122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/dynabean/target/commons-jelly-tags-dynabean-01122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-01122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-01122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-01122005.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-01122005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-01122005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api-01122005.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/jaxen-1.1-beta-6/jaxen-1.1-beta-6.jar
-
[junit] at 
org.jaxen.saxpath.base.XPathReader.unionExpr(XPathReader.java:1129)
[junit] at 
org.jaxen.saxpath.base.XPathReader.unaryExpr(XPathReader.java:1117)
[junit] at 
org.jaxen.saxpath.base.XPathReader.multiplicativeExpr(XPathReader.java:1039)
[junit] at 
org.jaxen.saxpath.base.XPathReader.additiveExpr(XPathReader.java:982)
[junit] at 
org.jaxen.saxpath.base.XPathReader.relationalExpr(XPathReader.java:902)
[junit] at 
org.jaxen.saxpath.base.XPathReader.equalityExpr(XPathReader.java:850)
[junit] at 
org.jaxen.saxpath.base.XPathReader.andExpr(XPathReader.java:826)
[junit] at 
org.jaxen.saxpath.base.XPathReader.orExpr(XPathReader.java:804)
[junit] at org.jaxen.saxpath.base.XPathReader.expr(XPathReader.java:797)
[junit] at 
org.jaxen.saxpath.base.XPathReader.parse(XPathReader.java:105)
[junit] at org.jaxen.BaseXPath.init(BaseXPath.java:126)
[junit] at org.jaxen.BaseXPath.init(BaseXPath.java:152)
[junit] at org.jaxen.dom4j.Dom4jXPath.init(Dom4jXPath.java:101)
[junit] at 
org.apache.commons.jelly.expression.xpath.XPathExpression.evaluate(XPathExpression.java:78)
[junit] at 
org.apache.commons.jelly.expression.ExpressionSupport.evaluateRecurse(ExpressionSupport.java:61)
[junit] at 
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:256)
[junit] at 
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
[junit] at 
org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59)
[junit] at junit.framework.TestCase.runBare(TestCase.java:127)
[junit] at junit.framework.TestResult$1.protect(TestResult.java:106)
[junit] at

[EMAIL PROTECTED]: Project commons-jelly-tags-jsl-test (in module commons-jelly) failed

2005-12-01 Thread commons-jelly-tags-jsl development

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project commons-jelly-tags-jsl-test has an issue affecting its community 
integration.
This issue affects 1 projects.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-jelly-tags-jsl-test :  Commons Jelly


Full details are available at:

http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Dependency on ant exists, no need to add for property 
maven.jar.ant-optional.
 -DEBUG- Dependency on xml-xerces exists, no need to add for property 
maven.jar.xerces.
 -WARNING- Overriding Maven properties: 
[/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/build.properties]
 -DEBUG- (Gump generated) Maven Properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/build.properties
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.xml
 -DEBUG- Maven project properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.properties
 -INFO- Project Reports in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/target/test-reports



The following work was performed:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/gump_work/build_commons-jelly_commons-jelly-tags-jsl-test.html
Work Name: build_commons-jelly_commons-jelly-tags-jsl-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 17 secs
Command Line: maven --offline jar 
[Working Directory: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-01122005.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-01122005.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-01122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-01122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-01122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-01122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-01122005.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-01122005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-01122005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api-01122005.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/jaxen-1.1-beta-6/jaxen-1.1-beta-6.jar
-
[junit] at 
org.apache.commons.jelly.tags.xml.ExprTag.doTag(ExprTag.java:46)
[junit] at 
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262)
[junit] at 
org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186)
[junit] at 
org.apache.commons.jelly.TagSupport.getBodyText(TagSupport.java:234)
[junit] at 
org.apache.commons.jelly.tags.core.SetTag.doTag(SetTag.java:90)
[junit] at 
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262)
[junit] at 
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
[junit] at 
org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186)
[junit] at 
org.apache.commons.jelly.tags.jsl.TemplateTag$1.run(TemplateTag.java:160)
[junit] at org.dom4j.rule.Mode.fireRule(Mode.java:58)
[junit] at org.dom4j.rule.Mode.applyTemplates(Mode.java:79)
[junit] at org.dom4j.rule.RuleManager$1.run(RuleManager.java:171)
[junit] at org.dom4j.rule.Mode.fireRule(Mode.java:58)
[junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:102)
[junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:91)
[junit] at

[EMAIL PROTECTED]: Project commons-jelly-tags-jsl-test (in module commons-jelly) failed

2005-12-01 Thread commons-jelly-tags-jsl development

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project commons-jelly-tags-jsl-test has an issue affecting its community 
integration.
This issue affects 1 projects.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-jelly-tags-jsl-test :  Commons Jelly


Full details are available at:

http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Dependency on ant exists, no need to add for property 
maven.jar.ant-optional.
 -DEBUG- Dependency on xml-xerces exists, no need to add for property 
maven.jar.xerces.
 -WARNING- Overriding Maven properties: 
[/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/build.properties]
 -DEBUG- (Gump generated) Maven Properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/build.properties
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.xml
 -DEBUG- Maven project properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.properties
 -INFO- Project Reports in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/target/test-reports



The following work was performed:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/gump_work/build_commons-jelly_commons-jelly-tags-jsl-test.html
Work Name: build_commons-jelly_commons-jelly-tags-jsl-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 17 secs
Command Line: maven --offline jar 
[Working Directory: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-01122005.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-01122005.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-01122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-01122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-01122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-01122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-01122005.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-01122005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-01122005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api-01122005.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/jaxen-1.1-beta-6/jaxen-1.1-beta-6.jar
-
[junit] at 
org.apache.commons.jelly.tags.xml.ExprTag.doTag(ExprTag.java:46)
[junit] at 
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262)
[junit] at 
org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186)
[junit] at 
org.apache.commons.jelly.TagSupport.getBodyText(TagSupport.java:234)
[junit] at 
org.apache.commons.jelly.tags.core.SetTag.doTag(SetTag.java:90)
[junit] at 
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262)
[junit] at 
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
[junit] at 
org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186)
[junit] at 
org.apache.commons.jelly.tags.jsl.TemplateTag$1.run(TemplateTag.java:160)
[junit] at org.dom4j.rule.Mode.fireRule(Mode.java:58)
[junit] at org.dom4j.rule.Mode.applyTemplates(Mode.java:79)
[junit] at org.dom4j.rule.RuleManager$1.run(RuleManager.java:171)
[junit] at org.dom4j.rule.Mode.fireRule(Mode.java:58)
[junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:102)
[junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:91)
[junit] at

Re: [all] Commons Manual

On 12/1/05, Martin Cooper [EMAIL PROTECTED] wrote:
 On 12/1/05, Henri Yandell [EMAIL PROTECTED] wrote:
 
  Let's imagine a manual existed for Commons committers. It would assume
  that a committer understands the ASF, ie) they've read the
  Apache-Committer-Manual (imagine that exists too). What would the
  chapters be?
 
  Initial list:
 
  * Short description of Commons/Introduction.
  * Communication. How to use the mailing lists. Voting.
  * Subversion information. How to check code out.
  * Maven information. How to build.
  * Site information. How to generate the site. How to upload your changes.
  * Releasing. How to release.
  * PMC. What they're there for (Commons point of view).
  * Legal. How to not screw-up.
 
  Am I missing anything?


 Not sure if these would be in the committers manual or elsewhere, as I'm
 similarly not sure that all of the above should be part of the manual rather
 than for everyone to read.

 * How the sandbox works / how components get promoted.
 * The whole active / dormant / dead process.

Definitely good chapters. They are concepts that currently only apply
to Commons, not to all of the ASF.

Hen

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[EMAIL PROTECTED]: Project commons-jelly-tags-html (in module commons-jelly) failed

2005-12-01 Thread commons-jelly-tags-html development

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project commons-jelly-tags-html has an issue affecting its community 
integration.
This issue affects 1 projects.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-jelly-tags-html :  Commons Jelly


Full details are available at:

http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-html/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [commons-jelly-tags-html-01122005.jar] identifier set to 
project name
 -DEBUG- Dependency on xml-xerces exists, no need to add for property 
maven.jar.xerces.
 -DEBUG- (Gump generated) Maven Properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/build.properties
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/project.xml
 -DEBUG- Maven project properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/project.properties
 -INFO- Project Reports in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-reports
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-html/gump_work/build_commons-jelly_commons-jelly-tags-html.html
Work Name: build_commons-jelly_commons-jelly-tags-html (Type: Build)
Work ended in a state of : Failed
Elapsed: 14 secs
Command Line: maven --offline jar 
[Working Directory: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/html]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-01122005.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-01122005.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-01122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/target/commons-jelly-tags-jsl-01122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-01122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-01122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-01122005.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-01122005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-01122005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api-01122005.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/jaxen-1.1-beta-6/jaxen-1.1-beta-6.jar:/usr/local/gump/packages/nekohtml-0.9.5/nekohtml.jar
-
[junit] at 
org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59)
[junit] 
[junit] 
[junit] Testcase: 
testLowerCase(org.apache.commons.jelly.tags.junit.CaseTag$1): Caused an 
ERROR
[junit] 
file:/x1/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-classes/org/apache/commons/jelly/html/suite.jelly:40:48:
 test:assert You must define an attribute called 'test' for this tag.
[junit] org.apache.commons.jelly.MissingAttributeException: 
file:/x1/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-classes/org/apache/commons/jelly/html/suite.jelly:40:48:
 test:assert You must define an attribute called 'test' for this tag.
[junit] at 
org.apache.commons.jelly.tags.junit.AssertTag.doTag(AssertTag.java:54)
[junit] at 
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262)
[junit] at 
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
[junit] at 
org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59)
[junit] 
[junit] 
[junit] Testcase: 
testMixedCase(org.apache.commons.jelly.tags.junit.CaseTag$1): Caused an 
ERROR
[junit] 
file:/x1/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-classes/org/apache/commons/jelly/html/suite.jelly:47:48:
 test:assert You must define an attribute called 'test' for this tag.
[junit] org.apache.commons.jelly.MissingAttributeException: 
file:/x1/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-classes/org/apache/commons/jelly/html/suite.jelly:47:48:
 test:assert You must define an attribute called 'test' for this tag.
[junit] at

[EMAIL PROTECTED]: Project commons-jelly-tags-html (in module commons-jelly) failed

2005-12-01 Thread commons-jelly-tags-html development

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project commons-jelly-tags-html has an issue affecting its community 
integration.
This issue affects 1 projects.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-jelly-tags-html :  Commons Jelly


Full details are available at:

http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-html/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [commons-jelly-tags-html-01122005.jar] identifier set to 
project name
 -DEBUG- Dependency on xml-xerces exists, no need to add for property 
maven.jar.xerces.
 -DEBUG- (Gump generated) Maven Properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/build.properties
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/project.xml
 -DEBUG- Maven project properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/project.properties
 -INFO- Project Reports in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-reports
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-html/gump_work/build_commons-jelly_commons-jelly-tags-html.html
Work Name: build_commons-jelly_commons-jelly-tags-html (Type: Build)
Work ended in a state of : Failed
Elapsed: 14 secs
Command Line: maven --offline jar 
[Working Directory: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/html]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-01122005.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-01122005.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-01122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/target/commons-jelly-tags-jsl-01122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-01122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-01122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-01122005.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-01122005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-01122005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api-01122005.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/jaxen-1.1-beta-6/jaxen-1.1-beta-6.jar:/usr/local/gump/packages/nekohtml-0.9.5/nekohtml.jar
-
[junit] at 
org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59)
[junit] 
[junit] 
[junit] Testcase: 
testLowerCase(org.apache.commons.jelly.tags.junit.CaseTag$1): Caused an 
ERROR
[junit] 
file:/x1/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-classes/org/apache/commons/jelly/html/suite.jelly:40:48:
 test:assert You must define an attribute called 'test' for this tag.
[junit] org.apache.commons.jelly.MissingAttributeException: 
file:/x1/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-classes/org/apache/commons/jelly/html/suite.jelly:40:48:
 test:assert You must define an attribute called 'test' for this tag.
[junit] at 
org.apache.commons.jelly.tags.junit.AssertTag.doTag(AssertTag.java:54)
[junit] at 
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262)
[junit] at 
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
[junit] at 
org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59)
[junit] 
[junit] 
[junit] Testcase: 
testMixedCase(org.apache.commons.jelly.tags.junit.CaseTag$1): Caused an 
ERROR
[junit] 
file:/x1/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-classes/org/apache/commons/jelly/html/suite.jelly:47:48:
 test:assert You must define an attribute called 'test' for this tag.
[junit] org.apache.commons.jelly.MissingAttributeException: 
file:/x1/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-classes/org/apache/commons/jelly/html/suite.jelly:47:48:
 test:assert You must define an attribute called 'test' for this tag.
[junit] at

svn commit: r351602 - /jakarta/commons/proper/daemon/trunk/src/native/unix/native/dso-dyld.c

2005-12-01 Thread billbarker

Author: billbarker
Date: Thu Dec  1 21:28:57 2005
New Revision: 351602

URL: http://svn.apache.org/viewcvs?rev=351602view=rev
Log:
Hide the defs in stdbool.h under Mac.

What brain-dead system includes junk like stdbool.h in the system header 
files?

Fix for Bug #37447


Modified:
jakarta/commons/proper/daemon/trunk/src/native/unix/native/dso-dyld.c

Modified: jakarta/commons/proper/daemon/trunk/src/native/unix/native/dso-dyld.c
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/daemon/trunk/src/native/unix/native/dso-dyld.c?rev=351602r1=351601r2=351602view=diff
==
--- jakarta/commons/proper/daemon/trunk/src/native/unix/native/dso-dyld.c 
(original)
+++ jakarta/commons/proper/daemon/trunk/src/native/unix/native/dso-dyld.c Thu 
Dec  1 21:28:57 2005
@@ -20,6 +20,14 @@
 
 #include mach-o/dyld.h
 
+#ifdef __bool_true_false_are_defined 
+/* We define these differently than stdbool.h, so ignore the defs there */
+#undef bool
+#undef true
+#undef false
+#endif
+
+
 /* Print an error message and abort all if a specified symbol wasn't found */
 static void nosymbol(const char *s) {
 log_error(Cannot find symbol '%s' in library,s);



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 37447] - [daemon] jsvc does not build under 10.4.3

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=37447.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=37447


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2005-12-02 06:32 ---
I choose the opposite of your suggestion (e.g. ignore the settings from 
stdbool.h), but the result should be the same.

If you get commons-daemon from trunk, you should be able to compile it on Mac 
without problems.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [vote][net] Release commons-net 1.4.1?


Steve Cohen wrote:


The thread Robert refers to has the subject

Re: Does Apache have agreement to use other open source code outside 
of Apache?
Has this something to do with an email from IBM in the last few days 
asking me if I am really was the creator of my contributions?
Not that I made any mistake (I guess this was a mail to all commons-net 
developers), but I was a little bit irritated.


Which is just as well.  Because I have another issue.  I don't 
understand the maven.compile.target property.  Working from the net 
1.4.0 tag, I change only project.properties to set 
maven.compile.target back to 1.2.  Since there are a few places in 
1.4.0 that depend on jdk 1.4, my expectation was that changing the 
project properties would cause the compile to break on those places.  
But it did not.  It compiled successfully.
The jdk1.4 compiler creates a class file suitable to run under an 
earlier JVM, this works as long as you do not use any new api. Then 
you'll get the NoSuchMethod Exception.
This is the reason why we should use the least possible compiler and not 
only the target attribute. You didnt notice if you use any new api call 
at compile time.



---
Mario


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Committer cleanup


Henri Yandell wrote:

I'd like to go ahead and remove all the committers from subversion for
commons, and then add back anyone who has committed in the last 6
months.
  
1 year - and if possible take the user/dev mailinglist for this project 
into account.
A commiter active in the mailinglist is also a valuable part of a 
project and for the community.


---
Mario


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [vote][net] Release commons-net 1.4.1?

2005-12-01 Thread Dion Gillard

On 12/2/05, Mario Ivankovits [EMAIL PROTECTED] wrote:
 Steve Cohen wrote:
 
  The thread Robert refers to has the subject
 
  Re: Does Apache have agreement to use other open source code outside
  of Apache?
 Has this something to do with an email from IBM in the last few days
 asking me if I am really was the creator of my contributions?
 Not that I made any mistake (I guess this was a mail to all commons-net
 developers), but I was a little bit irritated.

Probably. The commons-net copyright question was raised by an IBM email.

If you do get those questions, please make sure they get copied to
[EMAIL PROTECTED] The PMC should be the one responsible for
answering questions about our code.

  Which is just as well.  Because I have another issue.  I don't
  understand the maven.compile.target property.  Working from the net
  1.4.0 tag, I change only project.properties to set
  maven.compile.target back to 1.2.  Since there are a few places in
  1.4.0 that depend on jdk 1.4, my expectation was that changing the
  project properties would cause the compile to break on those places.
  But it did not.  It compiled successfully.
 The jdk1.4 compiler creates a class file suitable to run under an
 earlier JVM, this works as long as you do not use any new api. Then
 you'll get the NoSuchMethod Exception.
 This is the reason why we should use the least possible compiler and not
 only the target attribute. You didnt notice if you use any new api call
 at compile time.


 ---
 Mario


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




--
http://www.multitask.com.au/people/dion/
You are going to let the fear of poverty govern your life and your
reward will be that you will eat, but you will not live. - George
Bernard Shaw

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [vote][net] Release commons-net 1.4.1?