Re: [vote][net] Release commons-net 1.4.1?
i'm now +1 i'd like to thanks rory for his quick response. i'm now satisfied that there are substantive issues with the net code and so i'm happy to change my -1 to a +1. - robert On Thu, 2005-12-01 at 22:08 +, 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] signature.asc Description: This is a digitally signed message part
[logging] [PROPOSAL] strategy for JCL1.1 release
thanks to dennis for the release plan page (http://wiki.apache.org/jakarta-commons/Logging/1%2e1%2e0ReleasePlan). i'd like to propose the following solutions to the design issues highlighted. please indicate opinions in the conventional fashion :) 1 eliminate optional jar IMHO sub-components don't work very well. in particular, i think too many users are going to get too confused by yet another jar. WeakHashMap will go into the base distribution, other classes will be moved into contrib. perhaps another component (logging-extras) would be good or perhaps moving them off shore. 2 clean up source demonstration will be moved into contrib 3 improve support for downstream packagers add an ant task that creates a distribution with minimal dependencies. create guide to help people understand the distribution with section on dependencies. 4 log4j loggers log4j 1.3 is still not released. the new JCL release cannot depend on unreleased code. the 1.3 implementation will be moved into contrib. Log4JLogger and Log4J12Logger will be shipped with notes that direct use of log4jlogger is deprecated and will be replaced by a logical logger when log4j 1.3 ships. 5 ServletContextCleaner this will be shipped 6 IoC friendly design postponed - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Feedparser
On Fri, 2005-12-02 at 19:46 +0100, karl wettin wrote: 1 dec 2005 kl. 23.35 skrev 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. IIRC? If I Recall Correctly would you mind checking out proper, taking a look around and reporting back what you find? The last activity I found was from march on this list, when Kevin was voting for 0.5rc. He was also talking about 0.6rc and 1.0, but did not get the +3. darn :( collectively, we've become a little dysfunctional. I'll wait another week for his reply. please make sure you let us all know what happens... - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ALL] [WAS Re: Committer cleanup]
On Fri, 2005-12-02 at 10:14 -0500, Eric Pugh wrote: I agree with the 1 year mark. I know that there are projects that I haven't worked on for six months until the itch came back and I had to scratch it! Is there any reason to remove committers? Performance? Security? It seems to raise a barrier to reentry for dormant committers. i'm also a little concerned about barriers to (re-) entry: the higher the barrier to re-entry, the more strain this places on the core commons committers. in terms of removing commit access, 6 months seems too short but is probably too long to help to highlight problems with components. 1 year is more acceptable but IMHO this is a jakarta-wide issue. but i agree with the general strategy. we need to find out when the number of active committers reaches a minimal threshold. a more pressing problem is voting: there have been a number of votes which have failed due to apathy. given the new understanding about the legal status of pmc's, the commons voting procedures are now seem out dated. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-jelly-test (in module commons-jelly) failed
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,
and has been outstanding for 5 runs.
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: 55 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-03122005.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-03122005.jar:/usr/local/gump/public/workspace/jakarta-commons/discovery/dist/commons-discovery.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-03122005.jar:/usr/local/gump/public/workspace/jakarta-commons/lang/dist/commons-lang-03122005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-03122005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api-03122005.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
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,
and has been outstanding for 5 runs.
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: 55 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-03122005.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-03122005.jar:/usr/local/gump/public/workspace/jakarta-commons/discovery/dist/commons-discovery.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-03122005.jar:/usr/local/gump/public/workspace/jakarta-commons/lang/dist/commons-lang-03122005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-03122005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api-03122005.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
[configuration][ALL] compatibility issues with hsqldb
Hi all, ATM I am facing a problem with hsqldb and JDK 1.3 compatibility and would like to know if the same occurred for other components (and if already a solution exists). Commons Configuration contains a class DatabaseConfiguration whose test class makes use of hsqldb. When trying to build the distros on JDK 1.3 (which is the minimum supported JDK, so the release should be built with that) TestDatabaseConfiguration causes test failures: a class not found exception for java.sql.SavePoint. As I found out the cause for that is the hsqldb.jar distributed through ibiblio, which was built for JDK 1.4 and later. Indeed I was able to recompile hsqldb on JDK 1.3 and then the problem disappears. Unfortunately there does not seem to be a JDK 1.3 compatible version of a hsqldb.jar on the ibiblio maven reository (at least I did not find one). So this makes the build process on a JDK 1.3 very hard because the correct hsqldb.jar cannot be automatically downloaded. Do other components have the same constellation (dependency to hsqldb and minimum required JDK 1.3)? How is this handled there? Thanks Oliver - 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
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, and has been outstanding for 5 runs. 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-03122005.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-03122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-03122005.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-03122005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-03122005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api-03122005.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
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, and has been outstanding for 5 runs. 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-03122005.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-03122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-03122005.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-03122005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-03122005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api-03122005.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-swing (in module commons-jelly) failed
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, and has been outstanding for 5 runs. 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-03122005.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: 3 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-03122005.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-03122005.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-03122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/target/commons-jelly-tags-define-03122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/interaction/target/commons-jelly-tags-interaction-03122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-03122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-03122005.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-03122005.jar:/usr/local/gump/public/workspace/jakarta-commons/lang/dist/commons-lang-03122005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-03122005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api-03122005.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
[EMAIL PROTECTED]: Project commons-jelly-tags-swing (in module commons-jelly) failed
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, and has been outstanding for 5 runs. 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-03122005.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: 3 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-03122005.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-03122005.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-03122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/target/commons-jelly-tags-define-03122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/interaction/target/commons-jelly-tags-interaction-03122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-03122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-03122005.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-03122005.jar:/usr/local/gump/public/workspace/jakarta-commons/lang/dist/commons-lang-03122005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-03122005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api-03122005.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
Re: [VOTE] Release Configuration 1.2
Oliver Heger wrote: --- [ ] +1 I support this release and am willing to help [ ] +0 I support this release but am unable to help [ ] -0 I do not support this release [X] -1 I do not support this release, and here are my reasons --- Finally had time to check it (and note down what I did for the future). Apologies for it being a late -1. -1: Usage of Simian. This is a commercial product which requires a license. They state that they will grant a license to OSS, but we should confirm whether ASF/Jakarta has such a license. The simplest thing for now is to remove this report from the website until the PMC can confirm the legal position. -1: jar file manifest: Built-By: hacker I assume 'hacker' is a username of yours. However, I think its unsuitable for an ASF distribution. -0: jar file manifest: Build-Jdk: 1.4.2_04 Also, I assume that the build-jdk has come from the jdk running maven and is not the version configuration supports? Not sure what the solution to this is except using ant for the build running JDK 1.3. -0: The xdocs are not included in the src download. Other recommended changes: - Digester dependency states v1.5, but v1.6 is now released. - You specify the two separate beanutils jar files when you could specify just beanutils-core (there is no dependency on beanutils-collections). Other optional ideas: - Ensure that the source zip unzips to a directory name ending with -src. There is a maven setting for this, but I can't find it quickly. - Include a -src-ide.zip file in the binary release. See commons-io. This can only be done with ant AFAIK. - Line endings. It seems that you are converting txt files in the root folder. Personally I would like to see all text files in the root folder converted. This can only be done with ant AFAIK. - Ensure that the jar uploaded to ibiblio is exactly the same as that in the binary release - including date and timestamp. This makes problem resolution easier. This can only be done manually AFAIK. You may notice that ant is needed to achieve much of the above. But maven vs ant is a debate for a separate thread. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-jelly-tags-define-test (in module commons-jelly) failed
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, and has been outstanding for 5 runs. 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-03122005.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-03122005.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-03122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/dynabean/target/commons-jelly-tags-dynabean-03122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-03122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-03122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-03122005.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-03122005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-03122005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api-03122005.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
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, and has been outstanding for 5 runs. 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-03122005.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-03122005.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-03122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/dynabean/target/commons-jelly-tags-dynabean-03122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-03122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-03122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-03122005.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-03122005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-03122005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api-03122005.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
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, and has been outstanding for 5 runs. 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-03122005.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-03122005.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-03122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-03122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-03122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-03122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-03122005.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-03122005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-03122005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api-03122005.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
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, and has been outstanding for 5 runs. 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-03122005.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-03122005.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-03122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-03122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-03122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-03122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-03122005.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-03122005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-03122005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api-03122005.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-html (in module commons-jelly) failed
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, and has been outstanding for 5 runs. 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-03122005.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: 16 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-03122005.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-03122005.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-03122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/target/commons-jelly-tags-jsl-03122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-03122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-03122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-03122005.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-03122005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-03122005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api-03122005.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
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, and has been outstanding for 5 runs. 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-03122005.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: 16 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-03122005.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-03122005.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-03122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/target/commons-jelly-tags-jsl-03122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-03122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-03122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-03122005.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-03122005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-03122005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api-03122005.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: r351936 - /jakarta/commons/proper/net/branches/NET_1_4_1/
Author: scohen Date: Sat Dec 3 05:06:11 2005 New Revision: 351936 URL: http://svn.apache.org/viewcvs?rev=351936view=rev Log: cut branch for NET_1_4_1 from tag of NET_1_4_0 to fix jdk incompatibility problems. Added: jakarta/commons/proper/net/branches/NET_1_4_1/ - copied from r351935, jakarta/commons/proper/net/tags/NET_1_4_0/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r351942 - in /jakarta/commons/proper/net/branches/NET_1_4_1/src/java/org/apache/commons/net: ftp/FTPClientConfig.java nntp/Article.java
Author: scohen
Date: Sat Dec 3 05:34:01 2005
New Revision: 351942
URL: http://svn.apache.org/viewcvs?rev=351942view=rev
Log:
Apply patch from Andrea Rombald to restore JDK 1.3 compatibility.
Modified:
jakarta/commons/proper/net/branches/NET_1_4_1/src/java/org/apache/commons/net/ftp/FTPClientConfig.java
jakarta/commons/proper/net/branches/NET_1_4_1/src/java/org/apache/commons/net/nntp/Article.java
Modified:
jakarta/commons/proper/net/branches/NET_1_4_1/src/java/org/apache/commons/net/ftp/FTPClientConfig.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/net/branches/NET_1_4_1/src/java/org/apache/commons/net/ftp/FTPClientConfig.java?rev=351942r1=351941r2=351942view=diff
==
---
jakarta/commons/proper/net/branches/NET_1_4_1/src/java/org/apache/commons/net/ftp/FTPClientConfig.java
(original)
+++
jakarta/commons/proper/net/branches/NET_1_4_1/src/java/org/apache/commons/net/ftp/FTPClientConfig.java
Sat Dec 3 05:34:01 2005
@@ -245,17 +245,17 @@
LANGUAGE_CODE_MAP.put(en, Locale.ENGLISH);
LANGUAGE_CODE_MAP.put(de,Locale.GERMAN);
LANGUAGE_CODE_MAP.put(it,Locale.ITALIAN);
- LANGUAGE_CODE_MAP.put(es, new Locale(es)); // spanish
- LANGUAGE_CODE_MAP.put(pt, new Locale(pt)); // portuguese
- LANGUAGE_CODE_MAP.put(da, new Locale(da)); // danish
- LANGUAGE_CODE_MAP.put(sv, new Locale(sv)); // swedish
- LANGUAGE_CODE_MAP.put(no, new Locale(no)); // norwegian
- LANGUAGE_CODE_MAP.put(nl, new Locale(nl)); // dutch
- LANGUAGE_CODE_MAP.put(ro, new Locale(ro)); // romanian
- LANGUAGE_CODE_MAP.put(sq, new Locale(sq)); // albanian
- LANGUAGE_CODE_MAP.put(sh, new Locale(sh)); // serbo-croatian
- LANGUAGE_CODE_MAP.put(sk, new Locale(sk)); // slovak
- LANGUAGE_CODE_MAP.put(sl, new Locale(sl)); // slovenian
+ LANGUAGE_CODE_MAP.put(es, new Locale(es, , )); //
spanish
+ LANGUAGE_CODE_MAP.put(pt, new Locale(pt, , )); //
portuguese
+ LANGUAGE_CODE_MAP.put(da, new Locale(da, , )); // danish
+ LANGUAGE_CODE_MAP.put(sv, new Locale(sv, , )); //
swedish
+ LANGUAGE_CODE_MAP.put(no, new Locale(no, , )); //
norwegian
+ LANGUAGE_CODE_MAP.put(nl, new Locale(nl, , )); // dutch
+ LANGUAGE_CODE_MAP.put(ro, new Locale(ro, , )); //
romanian
+ LANGUAGE_CODE_MAP.put(sq, new Locale(sq, , )); //
albanian
+ LANGUAGE_CODE_MAP.put(sh, new Locale(sh, , )); //
serbo-croatian
+ LANGUAGE_CODE_MAP.put(sk, new Locale(sk, , )); //
slovak
+ LANGUAGE_CODE_MAP.put(sl, new Locale(sl, , )); //
slovenian
// some don't
Modified:
jakarta/commons/proper/net/branches/NET_1_4_1/src/java/org/apache/commons/net/nntp/Article.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/net/branches/NET_1_4_1/src/java/org/apache/commons/net/nntp/Article.java?rev=351942r1=351941r2=351942view=diff
==
---
jakarta/commons/proper/net/branches/NET_1_4_1/src/java/org/apache/commons/net/nntp/Article.java
(original)
+++
jakarta/commons/proper/net/branches/NET_1_4_1/src/java/org/apache/commons/net/nntp/Article.java
Sat Dec 3 05:34:01 2005
@@ -113,7 +113,7 @@
if (references == null)
return new String[0];
ArrayList list = new ArrayList();
- int terminator = references.indexOf(:);
+ int terminator = references.toString().indexOf(':');
StringTokenizer st =
new StringTokenizer(references.substring(terminator),
\t);
while (st.hasMoreTokens()) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r351944 - /jakarta/commons/proper/net/branches/NET_1_4_1/project.properties
Author: scohen Date: Sat Dec 3 05:43:06 2005 New Revision: 351944 URL: http://svn.apache.org/viewcvs?rev=351944view=rev Log: change maven.compile.target to 1.2 from 1.4 Modified: jakarta/commons/proper/net/branches/NET_1_4_1/project.properties Modified: jakarta/commons/proper/net/branches/NET_1_4_1/project.properties URL: http://svn.apache.org/viewcvs/jakarta/commons/proper/net/branches/NET_1_4_1/project.properties?rev=351944r1=351943r2=351944view=diff == --- jakarta/commons/proper/net/branches/NET_1_4_1/project.properties (original) +++ jakarta/commons/proper/net/branches/NET_1_4_1/project.properties Sat Dec 3 05:43:06 2005 @@ -18,7 +18,7 @@ maven.changelog.factory=org.apache.maven.svnlib.SvnChangeLogFactory maven.jar.excludes=**/examples/** -maven.compile.target=1.4 +maven.compile.target=1.2 # commons site LF maven.xdoc.jsl=../commons-build/commons-site.jsl - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r351950 - /jakarta/commons/proper/net/branches/NET_1_4_1/project.xml
Author: scohen Date: Sat Dec 3 06:07:00 2005 New Revision: 351950 URL: http://svn.apache.org/viewcvs?rev=351950view=rev Log: update for version 1.4.1 Modified: jakarta/commons/proper/net/branches/NET_1_4_1/project.xml Modified: jakarta/commons/proper/net/branches/NET_1_4_1/project.xml URL: http://svn.apache.org/viewcvs/jakarta/commons/proper/net/branches/NET_1_4_1/project.xml?rev=351950r1=351949r2=351950view=diff == --- jakarta/commons/proper/net/branches/NET_1_4_1/project.xml (original) +++ jakarta/commons/proper/net/branches/NET_1_4_1/project.xml Sat Dec 3 06:07:00 2005 @@ -19,7 +19,7 @@ nameJakarta Commons Net/name idcommons-net/id - currentVersion1.4.0-dev/currentVersion + currentVersion1.4.1/currentVersion inceptionYear1997/inceptionYear shortDescriptionJakarta Commons Net/shortDescription description/ @@ -99,6 +99,16 @@ id1.3.0/id name1.3.0/name tagNET_1_3_0/tag + /version + version + id1.4.0/id + name1.4.0/name + tagNET_1_4_0/tag + /version + version + id1.4.1/id + name1.4.1/name + tagNET_1_4_1/tag /version /versions - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r351951 - /jakarta/commons/proper/net/branches/NET_1_4_1/xdocs/changes.xml
Author: scohen Date: Sat Dec 3 06:20:49 2005 New Revision: 351951 URL: http://svn.apache.org/viewcvs?rev=351951view=rev Log: update for version 1.4.1 Modified: jakarta/commons/proper/net/branches/NET_1_4_1/xdocs/changes.xml Modified: jakarta/commons/proper/net/branches/NET_1_4_1/xdocs/changes.xml URL: http://svn.apache.org/viewcvs/jakarta/commons/proper/net/branches/NET_1_4_1/xdocs/changes.xml?rev=351951r1=351950r2=351951view=diff == --- jakarta/commons/proper/net/branches/NET_1_4_1/xdocs/changes.xml (original) +++ jakarta/commons/proper/net/branches/NET_1_4_1/xdocs/changes.xml Sat Dec 3 06:20:49 2005 @@ -22,6 +22,11 @@ body + release version=1.4.1 date=December 3, 2005 description=fix release to restore jdk 1.3 compatability + action dev=scohen type=fix + Applied fix to fix incompatibilites. Original patch submitted by lt;Andrea Rombaldgt; + /action + /release release version=1.4.0 date=February 9, 2005 description=fixes action dev=dfs type=fix Fixed typo in method name. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jelly] Gump failures
Gump's drive has always been to let people know of problems in the future (at least that's how I've always seen it). By compiling head of each project against each other, they discover when a problem is in the pipeline. It seems that we should be able to freeze the version of Jaxen that Jelly uses in the gump descriptor and it'll stop complaining. Hen On 12/2/05, Paul Libbrecht [EMAIL PROTECTED] wrote: Do i not understand Gump or the fact that we stick Jaxen head is something that could be changed ? Indeed, no-one really wishes to work with the latest jaxen currently. thanks paul Dion Gillard 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Pool: comments requested for a new implementation
On Tue, 2005-11-29 at 00:51 -0500, Sandy McArthur wrote: Since my last update I've made some performance improvements and made my composite object pool both serializable and cloneable. I've improved the construction so that the internal List that holds idle objects is either an ArrayList or a LinkedList based on which will give the best performance. An ArrayList is used when the max number of idle object is small (under 10) or when the pool is a LIFO. When it makes sense to use an ArrayList it can improve the composite object pool performance by as much as 7% compared to only using LinkedLists which is cool. +1 When implementing Serializable and Cloneable I decided it doesn't make sense for deserialized/cloned instances to share or have a copy of active or idle objects. This limits these features to little more than a method to save a object pool's configuration or as a way to acquire a similarly configured object pool. +1 I can currently think of no other improvements to the implementation. Feedback welcomed. I'm just waiting on my employer's lawyers before the code can go into the incubator. great :) i can confirm that your CLA has been received and logging by jim. so, just waiting for the CCLA now... the source won't actually go into the incubator so much as through it: in the case of an external donation to an existing project, the incubator just acts to ensure that the legal paperwork is in order and is recorded in the right place. the good news is that the process seems to have been sorted out now. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Together, and bricks apart
Hi all, Like your list Henri. Here is my list (with some overlap..) My ideas to improve things are : - Move sandbox components to the background (at least on the commons page). If the components are worthy, they will pick up interest without it. For now it looks like just another list of components from commons and that's the way it is used currently by a lot people. Most of the time promotion of components take place because people are screaming for a release, even though the component might not be ready, community wise or code wise. A possible user base should not be a consideration for promotion. At least put up a big disclaimer : use at own risk and if you really want to use it, build it yourself. - Let (*) people who work on components, improve communication (eg in todo's, future or ideas kind of files in svn) to what they are thinking or what direction they want to see the component go. This is more obvious with components that don't have a big developer base (fileupload comes to mind, with just martinc active) Not saying it isn't currently done this way, so this is just a generalisation.. - Somehow keep track of committers actively involved / interested. Eg for betwixt the list is pretty big, although I pretty much know for sure some people (ehh me) are not active on the component. Maybe just adding active as a role to the project.xml and removing that when not active anymore or moving the more active ones to the top ? Current people involved could keep track of that list. - See if some components can find a home in other projects. (jexl and el could nicely fit in taglibs, though the project name taglibs probably needs some reconsideration if that is going to happen). - Create problem space groupings where possible (at least on the commons page). eg servlet/jsp fileupload, jexl, el, email, validator, latka java extensions (lang, collections, io) xml (betwixt, digester, jelly others Grouping can be pretty hard to achieve in some cases and if I am not mistaking this was proposed in the past. (*) No forcing involved :) Mvgr, Martin Henri Yandell wrote: On 12/2/05, Martin Cooper [EMAIL PROTECTED] wrote: IMO, what this tells us is the Commons isn't scaling, and that doesn't surprise me at all. In the old days, there were a *lot* fewer components. Right now, I count 35 components in Proper and 9 more active components in the Sandbox (excluding the ones Henri is about to make dormant). That is a lot of stuff! Very few people, if any, are going to keep tabs on all of it, and most are likely to only track a handful, if that. When Commons was much smaller, the community was much more integrated, in that there was more overlap between the pieces (people-wise, not code-wise), and so we all watched each others' backs. We're no longer in that state. The inability to scale, is, in my opinion, an issue the ASF as a whole is also facing. Unfortunately, as with Commons, I don't have any good ideas. Other than to consciously stop growing, that is, but that doesn't appear to be a popular direction. [long reply...sorry] Yep. It's my belief that Commons represents the ASF in microcosm, so trying to find solutions in Commons is a) easier than the whole ASF and b) useful to finding the whole ASF problem. I see two directions: 1) Hope a few more projects move out of Jakarta, then promote every Commons component to Jakarta subprojects and revolutionise Jakarta with some Commons concepts. It doesn't solve the problems, but it does accept that the components are increasingly being held up on the shoulders of 1 committer each, and makes us solve it at a Jakarta level, not a Commons level. 2) Reinvigorate ourselves as a community. The lip service is that we're all Commons committers and not individual component committers, but the reality is that not one of us is interested in 43+ components. We need to accept that and adapt. So I think we'd end up at 2) eventually even if 1) happens :) -- So how can we rejuvenate a community without the mantra that we don't have focus? a) Work together. I don't mean that in a hippy peacenik way. I mean actually work together. We need to get a plan for the future of each component and then form groups attacking each target, but not at the same time. So Lang 2.2 might be held up because 3 of us need to work on Collections 2.2. Etc. b) Increase ease of bringing people into the community. Three problems to hit. 1) Encouraging people to get involved (it's hard). 2) Educating people. 3) Communication noise. b-1) is always hard. We encourage this mostly by being open and by broadcasting a sense of enjoyment. Another trick is to leave the easy jobs; don't gobble up easy fun bits (which is hard, they're fun :) ). b-2) is about making the information easier to find. We've a lot of it on the site etc, but we need to take the water more to the horse's mouth. So collating it into a single document etc is my aim. b-3) The mailing list is noisy. There are
JavaPolis, who's coming ?
Hi everyone, I will be at javapolis from 12 till 16 december (the whole week). Anyone else coming, so we can meet for eg drinks ? On monday night there is already a meeting with some myfaces folks.. Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration][ALL] compatibility issues with hsqldb
Oliver Heger wrote: As I found out the cause for that is the hsqldb.jar distributed through ibiblio, which was built for JDK 1.4 and later. Indeed I was able to recompile hsqldb on JDK 1.3 and then the problem disappears. Unfortunately there does not seem to be a JDK 1.3 compatible version of a hsqldb.jar on the ibiblio maven reository (at least I did not find one). So this makes the build process on a JDK 1.3 very hard because the correct hsqldb.jar cannot be automatically downloaded. Maybe we could request the JDK 1.3 version of hsql to be uploaded in the repository at Ibiblio ? As hsqldb-x.y.z-jdk13.jar for example ? Emmanuel Bourg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 37401] - [net] allow listing of hidden files
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=37401. 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=37401 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||LATER -- 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]
DO NOT REPLY [Bug 36473] - [Net] FTPClient.storeFile keeps returning false on XP only, stores nothing to FTP server
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=36473. 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=36473 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||LATER -- 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]
DO NOT REPLY [Bug 36249] - [net] MVSFTPEntryParser setRawListing
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=36249. 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=36249 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||LATER -- 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]
DO NOT REPLY [Bug 35863] - [net] retrieveFileStream fails randomly
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=35863. 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=35863 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||LATER -- 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]
DO NOT REPLY [Bug 35592] - [net] Unix parser not handling filenames beginning with whitespace
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=35592. 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=35592 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||LATER -- 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]
DO NOT REPLY [Bug 35338] - [net] FTPClient.listFiles() hangs on Red Hat Linux
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=35338. 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=35338 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||LATER -- 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]
DO NOT REPLY [Bug 35260] - [net] FTPClient.retrieveFile() results in 0 byte files
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=35260. 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=35260 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||LATER -- 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]
DO NOT REPLY [Bug 35185] - [net] NullpointerException on FTPClient.disconnect() if an Exception occured while FTPClient.connect
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=35185. 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=35185 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||LATER -- 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]
[net] Minimum jdk/jvm version for net ( future ) ( was: Re: [vote][net] Release commons-net 1.4.1? )
I understand the issues involved with pending release of vfs and compatibility with net, but I thought we discussed during the last release or so of net that we cut a 1.2/1.3 compatible release and from that release forward we were using 1.4 stuff ( nio I believe was the issue ). So projects that wanted to use net, but required older jvm/class compatibility would use the old version. Maybe I am mistaken though, did we just discuss this and never implement it? Just wondering about the future releases. Is there now a min or max jdk version for all commons projects? Steve Cohen wrote: [SNIPPED] 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. Of course, we did use new APIs, so for the purpose I had in mind, this property is useless. 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. I'll have to dig out a 1.3.1 compiler then. I don't even think 1.2.x is available anymore. -- = Jeffrey D. Brekke [EMAIL PROTECTED] Wisconsin, USA [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.bloglines.com/blog/jbrekke/ [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34778] - [net] FTP CWD command seems not to trigger server responses properly
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=34778. 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=34778 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||LATER -- 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]
DO NOT REPLY [Bug 34763] - [net] TelnetClient broken for binary transmissions + solution
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=34763. 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=34763 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||LATER -- 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]
DO NOT REPLY [Bug 32579] - [net] Nullpointer exception after using parseFTPEntry in FTPFileEntryParser
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=32579. 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=32579 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||LATER -- 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]
DO NOT REPLY [Bug 31108] - [net] FTP does not work on zos (ebcdic platform)
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=31108. 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=31108 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||LATER -- 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]
DO NOT REPLY [Bug 29613] - [net] Commons RLogin timeout
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=29613. 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=29613 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||LATER -- 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]
DO NOT REPLY [Bug 26296] - [net] TelnetClient#disconnect() causes NullPointerException from Linux when connected to Windows 2000 Telnet Server
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=26296. 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=26296 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||LATER -- 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]
DO NOT REPLY [Bug 24539] - [net] The telnet client is leaving the connection even after calling the disconnect properly.
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=24539. 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=24539 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||LATER -- 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]
DO NOT REPLY [Bug 24456] - [net] FTPClient.listFiles can not get file list of directorychinese characters
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=24456. 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=24456 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||LATER -- 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]
svn commit: r351961 - /jakarta/commons/proper/net/branches/NET_1_4_1/build.xml
Author: scohen
Date: Sat Dec 3 07:43:40 2005
New Revision: 351961
URL: http://svn.apache.org/viewcvs?rev=351961view=rev
Log:
update for version 1.4.1
Modified:
jakarta/commons/proper/net/branches/NET_1_4_1/build.xml
Modified: jakarta/commons/proper/net/branches/NET_1_4_1/build.xml
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/net/branches/NET_1_4_1/build.xml?rev=351961r1=351960r2=351961view=diff
==
--- jakarta/commons/proper/net/branches/NET_1_4_1/build.xml (original)
+++ jakarta/commons/proper/net/branches/NET_1_4_1/build.xml Sat Dec 3 07:43:40
2005
@@ -1,7 +1,5 @@
?xml version=1.0 encoding=UTF-8?
-!--build.xml generated by maven from project.xml version 1.3.0-dev
- on date September 8 2004, time 2216--
project default=jar name=commons-net basedir=.
property name=defaulttargetdir value=target
@@ -20,7 +18,7 @@
/property
property name=javadocdir value=dist/docs/api
/property
- property name=final.name value=commons-net-1.3.0-dev
+ property name=final.name value=commons-net-1.4.1
/property
path id=build.classpath
fileset dir=${libdir}
@@ -147,7 +145,7 @@
/tstamp
property name=copyright value=Copyright amp;copy; The Apache
Software Foundation. All Rights Reserved.
/property
-property name=title value=Jakarta Commons Net 1.3.0-dev API
+property name=title value=Jakarta Commons Net 1.4.1 API
/property
javadoc use=true private=false destdir=${javadocdir} author=true
version=true sourcepath=src/java packagenames=org.apache.commons.net.*
classpath
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r351968 - /jakarta/commons/proper/net/branches/NET_1_4_1/xdocs/changes.xml
Author: scohen Date: Sat Dec 3 08:03:42 2005 New Revision: 351968 URL: http://svn.apache.org/viewcvs?rev=351968view=rev Log: update changes log Modified: jakarta/commons/proper/net/branches/NET_1_4_1/xdocs/changes.xml Modified: jakarta/commons/proper/net/branches/NET_1_4_1/xdocs/changes.xml URL: http://svn.apache.org/viewcvs/jakarta/commons/proper/net/branches/NET_1_4_1/xdocs/changes.xml?rev=351968r1=351967r2=351968view=diff == --- jakarta/commons/proper/net/branches/NET_1_4_1/xdocs/changes.xml (original) +++ jakarta/commons/proper/net/branches/NET_1_4_1/xdocs/changes.xml Sat Dec 3 08:03:42 2005 @@ -24,7 +24,10 @@ body release version=1.4.1 date=December 3, 2005 description=fix release to restore jdk 1.3 compatability action dev=scohen type=fix - Applied fix to fix incompatibilites. Original patch submitted by lt;Andrea Rombaldgt; + Applied patches for defect 37113. Code incompatible with jdk 1.3. Original patch submitted by lt;Andrea Rombaldgt; + /action + action dev=scohen type=fix + Applied patches for defect 37522. updated project.xml to correct compatibility level. /action /release release version=1.4.0 date=February 9, 2005 description=fixes - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JavaPolis, who's coming ?
Martin van den Bemt wrote: Hi everyone, I will be at javapolis from 12 till 16 december (the whole week). Anyone else coming, so we can meet for eg drinks ? On monday night there is already a meeting with some myfaces folks.. I'll be arriving Monday and I'll be around on Tuesday and Wednesday. Tuesday night is the speaker's dinner. -- Elliotte Rusty Harold [EMAIL PROTECTED] XML in a Nutshell 3rd Edition Just Published! http://www.cafeconleche.org/books/xian3/ http://www.amazon.com/exec/obidos/ISBN=0596007647/cafeaulaitA/ref=nosim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] short critique of site
On Fri, 2005-12-02 at 23:47 +0100, Emmanuel Bourg wrote: Henri Yandell wrote: 7) Contributor page. Is this worth the effort of the maintenance? I don't know how this page is maintained currently, but maybe it could be built automatically from the POMs with a script ? +1 such a script might have other uses as well. any volunteers? - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Configuration 1.2
Stephen, thanks for your feedback. I will address your points. Some questions follow: - What is the purpose of the -src-ide.zip file? I didn't find anything about that in the releasing components instructions. It contains the *.java files and the LICENSE and NOTICE files, right? - Line endings: You mean files like project.xml or project.properties should also be converted? I think many things can be done with maven by tweaking the maven.xml, but the complex line ending stuff probably not. AFAIK a comming up version of the dist plugin should support this. Oliver Stephen Colebourne wrote: Oliver Heger wrote: --- [ ] +1 I support this release and am willing to help [ ] +0 I support this release but am unable to help [ ] -0 I do not support this release [X] -1 I do not support this release, and here are my reasons --- Finally had time to check it (and note down what I did for the future). Apologies for it being a late -1. -1: Usage of Simian. This is a commercial product which requires a license. They state that they will grant a license to OSS, but we should confirm whether ASF/Jakarta has such a license. The simplest thing for now is to remove this report from the website until the PMC can confirm the legal position. -1: jar file manifest: Built-By: hacker I assume 'hacker' is a username of yours. However, I think its unsuitable for an ASF distribution. -0: jar file manifest: Build-Jdk: 1.4.2_04 Also, I assume that the build-jdk has come from the jdk running maven and is not the version configuration supports? Not sure what the solution to this is except using ant for the build running JDK 1.3. -0: The xdocs are not included in the src download. Other recommended changes: - Digester dependency states v1.5, but v1.6 is now released. - You specify the two separate beanutils jar files when you could specify just beanutils-core (there is no dependency on beanutils-collections). Other optional ideas: - Ensure that the source zip unzips to a directory name ending with -src. There is a maven setting for this, but I can't find it quickly. - Include a -src-ide.zip file in the binary release. See commons-io. This can only be done with ant AFAIK. - Line endings. It seems that you are converting txt files in the root folder. Personally I would like to see all text files in the root folder converted. This can only be done with ant AFAIK. - Ensure that the jar uploaded to ibiblio is exactly the same as that in the binary release - including date and timestamp. This makes problem resolution easier. This can only be done manually AFAIK. You may notice that ant is needed to achieve much of the above. But maven vs ant is a debate for a separate thread. Stephen - 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?
Shouldn't that be no substantive issues? ;-) robert burrell donkin wrote: i'm now +1 i'd like to thanks rory for his quick response. i'm now satisfied that there are substantive issues with the net code and so i'm happy to change my -1 to a +1. - robert On Thu, 2005-12-01 at 22:08 +, 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: [vote][net] Release commons-net 1.4.1?
Steve Cohen wrote: Steve Cohen wrote: Mario Ivankovits wrote: Steve Cohen wrote: It has been discovered that 1.4.0 is inadvertently incompatible with jdk 1.3. Please vote on a release of a fixed version. Checked VFS using net svn head and it works. So here is my +1 BTW: maven builds a 1.5.0 version instead of 1.4.1. Do you plan to release svn head or a patched/rebuild 1.4.0? --- Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Please disregard my earlier reply. I realize that I misunderstood you. You are, I presume, talking about the version number of net that maven currently builds. This will have to be changed of course. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] 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] I vote +1. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] The following people voted on release commons-net 1.4.1: Steve Cohen +1 Stefan Bodewig +1 Dion Gilliard +1 Mario Ivankovits +1 Henri Yandell +1 (implied - said if code had already been released, +1, otherwise hold off. Code was in fact in 1.4.0 so +1) robert burrell donkin +1 ( on 12/2 after being -1 on 12/1 and being satisfied with Rory Winston's response to copyright question) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] Minimum jdk/jvm version for net ( future ) ( was: Re: [vote][net] Release commons-net 1.4.1? )
We need to discuss this further. Mario Ivankovits VFS is a client of Net and he has users still on 1.3 who are complaining that Net 1.4 breaks VFS. Jeffrey D. Brekke wrote: I understand the issues involved with pending release of vfs and compatibility with net, but I thought we discussed during the last release or so of net that we cut a 1.2/1.3 compatible release and from that release forward we were using 1.4 stuff ( nio I believe was the issue ). So projects that wanted to use net, but required older jvm/class compatibility would use the old version. Maybe I am mistaken though, did we just discuss this and never implement it? Just wondering about the future releases. Is there now a min or max jdk version for all commons projects? Steve Cohen wrote: [SNIPPED] 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. Of course, we did use new APIs, so for the purpose I had in mind, this property is useless. 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. I'll have to dig out a 1.3.1 compiler then. I don't even think 1.2.x is available anymore. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] Minimum jdk/jvm version for net ( future ) ( was: Re: [vote][net] Release commons-net 1.4.1? )
Steve Cohen wrote: We need to discuss this further. Mario Ivankovits VFS is a client of Net and he has users still on 1.3 who are complaining that Net 1.4 breaks VFS. And not only my users constantly complain about it. AFAIK this is also true for other commons components. Though, there is an end of live for jdk1.3 and so we sould also to define such a point in the future. Personally I see this point reached in 6 months, but understand if we have to stick on 1.3 for the next year. Then we should jump to jdk 1.5 (with jdk 1.4 api) and use retroweaver to provide the jdk 1.4 version. Our releases should then contain jars for both (1.5 and 1.4) I know there are the same issues with api compatibility, but if we run our tests against both jdks we should be fine, also it might be possible to have an api checker which will check the generated classes against the classpath. Whatever, we might find a way to archive this. I know, this is somehow radical, but our code starts to smell and become spider webs if we have to stick on 1.3 for the time being ;-) --- Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Sheesh, the release process has gotten much hairier since I last did it! 5 hours and I'm still not all the way there. And this was supposed to be a simple release. Phooey. I decided that that easiest way to do this simple release fixing ONLY the 1.3 compatibility problem would be to work from a branch cut at 1_4_0. And that is how I built it. Now however, I get to step 10 Publish updated website and maven is failing. Can this even work when deploying from a branch and not the trunk? $ /opt/maven/bin/maven -Dmaven.username=scohen site:deploy __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0-rc2 Attempting to download commons-net-1.1.0.jar. .. . Attempting to download vdoclet-20020711.jar. . . Attempting to download qdox-current.jar. ... . Attempting to download commons-collections-2.1.jar. .. . Attempting to download logkit-1.0.1.jar. ... . Attempting to download statcvs-xml-0.9.4.jar. .. Attempting to download jdom-b10.jar. . . Attempting to download jfreechart-0.9.20.jar. . . Attempting to download jcommon-0.9.5.jar. ... . Attempting to download commons-jexl-1.0-beta-1.jar. ... . Attempting to download jdepend-2.5.jar. ... . Attempting to download checkstyle-3.3.jar. . . Attempting to download checkstyle-optional-3.3.jar. . . Attempting to download regexp-1.3.jar. ... . Attempting to download commons-beanutils-1.6.1.jar. . . Attempting to download simian-1.9.1.jar. . Attempting to download ant-1.6.jar. . build:start: site:deploy: site: xdoc:register-reports: maven-changes-plugin:register: maven-tasklist-plugin:register: statcvs:init: maven-statcvs-plugin:register: maven-junit-report-plugin:register: maven-jdepend-plugin:register: maven-jcoverage-plugin:register: maven-checkstyle-plugin:register: maven-simian-plugin:register: maven-javadoc-plugin:register: maven-jxr-plugin:register: maven-license-plugin:register: site:run-reports: [echo] Generating the Changes... changes:report: [echo] Generating the Task List... xdoc:init: maven-tasklist-plugin:report:
Re: [configuration][ALL] compatibility issues with hsqldb
Emmanuel Bourg wrote: Oliver Heger wrote: As I found out the cause for that is the hsqldb.jar distributed through ibiblio, which was built for JDK 1.4 and later. Indeed I was able to recompile hsqldb on JDK 1.3 and then the problem disappears. Unfortunately there does not seem to be a JDK 1.3 compatible version of a hsqldb.jar on the ibiblio maven reository (at least I did not find one). So this makes the build process on a JDK 1.3 very hard because the correct hsqldb.jar cannot be automatically downloaded. Maybe we could request the JDK 1.3 version of hsql to be uploaded in the repository at Ibiblio ? As hsqldb-x.y.z-jdk13.jar for example ? Emmanuel Bourg +1, I think this would be the best solution. How would we do that? Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
On 12/3/05, Steve Cohen [EMAIL PROTECTED] wrote: Sheesh, the release process has gotten much hairier since I last did it! 5 hours and I'm still not all the way there. And this was supposed to be a simple release. Phooey. I decided that that easiest way to do this simple release fixing ONLY the 1.3 compatibility problem would be to work from a branch cut at 1_4_0. And that is how I built it. Now however, I get to step 10 Publish updated website and maven is failing. Can this even work when deploying from a branch and not the trunk? snip/ [echo] Generating the StatCvs Report... statcvs:init: statcvs:generate: statcvs:init-variables: statcvs:parse-connection: [echo] Using connection: scm:svn:http://svn.apache.org/repos/asf/jakarta/commons/proper/net/trunk BUILD FAILED File.. file:/home/scohen/.maven/plugins/maven-statcvs-plugin-2.5/plugin.jelly Element... ant:fail Line.. 103 Column 19 Unknown SCM method: 'svn' Total time: 19 seconds Finished at: Sat Dec 03 12:34:56 CST 2005 snap/ Sorry, I can't pinpoint whats going on, though I have two suggestions: 1) Turn off the statcvs report (the trunk doesn't have it anyway, and the error message seems to come out of there) 2) If you can generate the site locally (maven site) but can't deploy it -- while you sort it out -- a clearly suboptimal solution that you could consider is to tar/zip the generated site (maven site) and manually expand in the siteDirectory (to avoid undue delay in the releasing process). -Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
You'll ned maven 1.0.2 plus the latest release of any plugin that barfs. Plus you'll need various project properties set. See commons-io for a recent working example. And yes you are right, releasing with svn and maven at ASF is a right royal pain. Stephen Steve Cohen wrote: Sheesh, the release process has gotten much hairier since I last did it! 5 hours and I'm still not all the way there. And this was supposed to be a simple release. Phooey. I decided that that easiest way to do this simple release fixing ONLY the 1.3 compatibility problem would be to work from a branch cut at 1_4_0. And that is how I built it. Now however, I get to step 10 Publish updated website and maven is failing. Can this even work when deploying from a branch and not the trunk? $ /opt/maven/bin/maven -Dmaven.username=scohen site:deploy __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0-rc2 Attempting to download commons-net-1.1.0.jar. .. . Attempting to download vdoclet-20020711.jar. . . Attempting to download qdox-current.jar. ... . Attempting to download commons-collections-2.1.jar. .. . Attempting to download logkit-1.0.1.jar. ... . Attempting to download statcvs-xml-0.9.4.jar. .. Attempting to download jdom-b10.jar. . . Attempting to download jfreechart-0.9.20.jar. . . Attempting to download jcommon-0.9.5.jar. ... . Attempting to download commons-jexl-1.0-beta-1.jar. ... . Attempting to download jdepend-2.5.jar. ... . Attempting to download checkstyle-3.3.jar. . . Attempting to download checkstyle-optional-3.3.jar. . . Attempting to download regexp-1.3.jar. ... . Attempting to download commons-beanutils-1.6.1.jar. . . Attempting to download simian-1.9.1.jar. . Attempting to download ant-1.6.jar. . build:start: site:deploy: site: xdoc:register-reports: maven-changes-plugin:register: maven-tasklist-plugin:register: statcvs:init: maven-statcvs-plugin:register: maven-junit-report-plugin:register: maven-jdepend-plugin:register: maven-jcoverage-plugin:register:
Re: [VOTE] Release Configuration 1.2
Oliver Heger wrote: - What is the purpose of the -src-ide.zip file? I didn't find anything about that in the releasing components instructions. It contains the *.java files and the LICENSE and NOTICE files, right? The purpose is so users can attach the source of the component to the binary jar file in an IDE such as Eclipse. It just contains the java LICENSE and NOTICE files. - Line endings: You mean files like project.xml or project.properties should also be converted? IMHO yes, but this has been an open debate for a while. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Configuration 1.2
On 12/3/05, Oliver Heger [EMAIL PROTECTED] wrote: Stephen, thanks for your feedback. I will address your points. Some questions follow: - What is the purpose of the -src-ide.zip file? I didn't find anything about that in the releasing components instructions. It contains the *.java files and the LICENSE and NOTICE files, right? - Line endings: You mean files like project.xml or project.properties should also be converted? I think many things can be done with maven by tweaking the maven.xml, but the complex line ending stuff probably not. AFAIK a comming up version of the dist plugin should support this. Oliver Stephen Colebourne wrote: Oliver Heger wrote: --- [ ] +1 I support this release and am willing to help [ ] +0 I support this release but am unable to help [ ] -0 I do not support this release [X] -1 I do not support this release, and here are my reasons --- Finally had time to check it (and note down what I did for the future). Apologies for it being a late -1. -1: Usage of Simian. This is a commercial product which requires a license. They state that they will grant a license to OSS, but we should confirm whether ASF/Jakarta has such a license. The simplest thing for now is to remove this report from the website until the PMC can confirm the legal position. -1: jar file manifest: Built-By: hacker I assume 'hacker' is a username of yours. However, I think its unsuitable for an ASF distribution. -0: jar file manifest: Build-Jdk: 1.4.2_04 Also, I assume that the build-jdk has come from the jdk running maven and is not the version configuration supports? Not sure what the solution to this is except using ant for the build running JDK 1.3. -0: The xdocs are not included in the src download. Other recommended changes: - Digester dependency states v1.5, but v1.6 is now released. - You specify the two separate beanutils jar files when you could specify just beanutils-core (there is no dependency on beanutils-collections). Other optional ideas: - Ensure that the source zip unzips to a directory name ending with -src. There is a maven setting for this, but I can't find it quickly. - Include a -src-ide.zip file in the binary release. See commons-io. This can only be done with ant AFAIK. - Line endings. It seems that you are converting txt files in the root folder. Personally I would like to see all text files in the root folder converted. This can only be done with ant AFAIK. - Ensure that the jar uploaded to ibiblio is exactly the same as that in the binary release - including date and timestamp. This makes problem resolution easier. This can only be done manually AFAIK. You may notice that ant is needed to achieve much of the above. But maven vs ant is a debate for a separate thread. Stephen - 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] Sorry to be so late checking / trying to help. I am +1 for the release assuming Stephen's points (other than the ones listed as optional) and the following issues are addressed: - You should either modify configs, fix issues or eliminate PMD and checkstyle reports - Javadoc errors should be fixed so javadoc report is clean - Package javadoc is missing from three of the packages - Apologies if I missed this posted somewhere, but have you done a clirr or jdiff report against 1.0? If there have been incompatible changes since 1.1, these should be called out to users. Its hard to tell from the changes report. Here are some additional comments that you are free to ignore, but which may be useful. 1) The username in the jar manifest is a PITA, since the maven dist plugin does not seem to pay attention to the user.name property that it is supposed to control this (yes, I know, need to open ticket). To work around this, I provide this on the command line: maven -Duser.name=psteitz dist. That works4me. 2) I think the workaround mentioned above for the sun jar is OK, though I don't think its that bad to force the local repo surgery, with a doco note somewhere. 3) You can use maven.compile.executable as described above to force compilation on jdk 1.3 (I personally do not view this as necessary, as long as you test the build on 1.3) and then use the maven.jar.manifest property (http://maven.apache.org/maven-1.x/reference/plugins/jar/properties.html) to specify a text file with lines to be merged in to the manifest to fix the version spec. If you go this route, you should probably check that file into svn so
Re: [Jakarta-commons Wiki] Update of CommonsManual by HenriYandell
Will this eventually be translated to xdoc and included in the commons site? Is it really too painful to just start by developing it in xdoc, or by modifying the commons web site? Much of the content is already there. Generating the commons site is just maven site from commons-build and maven site:sshdeploy to publish ;-) Also, I would prefer to target the whole community in terms of content - i.e., manual for new commons volunteer rather than just committer. We can call out (as we try to on the current site) differences or special things for committers. Phil On 12/2/05, Apache Wiki [EMAIL PROTECTED] wrote: 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/CommonsManual The comment on the change is: A proposal for a one-stop shop for education on Commons New page: = A Manual for new Commons committers = Idea being that we bring the various how-to's and guides into one centralised document/book/site/thing. It should be both easily viewable online, and printable so you can sit on the toilet and read about our goings on. == Table of Contents == * Introduction to Commons - What it's all about. * 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 it's there for. * Legal. How to not screw-up. * How the sandbox works / how components get promoted / how components get made dormant/active/dead. * Programming guidelines. The following links contain material to fill the above with: * JakartaCommonsEtiquette * GettingInvolved * UsingSVN * ProposalSandboxPruning * MovingFromSandboxToProper * MovingFromSandboxToProperSVN * CreatingStandardWebPresence * GettingInvolved * SigningReleases * http://jakarta.apache.org/commons/charter.html * http://jakarta.apache.org/commons/volunteering.html * http://jakarta.apache.org/commons/patches.html * http://jakarta.apache.org/commons/building.html * http://jakarta.apache.org/commons/releases/index.html - 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: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
On 12/3/05, Stephen Colebourne [EMAIL PROTECTED] wrote: You'll ned maven 1.0.2 plus the latest release of any plugin that barfs. Plus you'll need various project properties set. See commons-io for a recent working example. And yes you are right, releasing with svn and maven at ASF is a right royal pain. Been a while since I did a release. What makes it painful? It was always the PGP juggling for me. Maven/svn releases at osjava.org are pretty painless. Probably because they have lower goals: 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: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
statcvs and svn dont work together (yet)... http://www.researchkitchen.co.uk/blog/archives/13 I just turned off the statcvs report last time. Steve Cohen wrote: Sheesh, the release process has gotten much hairier since I last did it! 5 hours and I'm still not all the way there. And this was supposed to be a simple release. Phooey. I decided that that easiest way to do this simple release fixing ONLY the 1.3 compatibility problem would be to work from a branch cut at 1_4_0. And that is how I built it. Now however, I get to step 10 Publish updated website and maven is failing. Can this even work when deploying from a branch and not the trunk? $ /opt/maven/bin/maven -Dmaven.username=scohen site:deploy __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0-rc2 Attempting to download commons-net-1.1.0.jar. .. . Attempting to download vdoclet-20020711.jar. . . Attempting to download qdox-current.jar. ... . Attempting to download commons-collections-2.1.jar. .. . Attempting to download logkit-1.0.1.jar. ... . Attempting to download statcvs-xml-0.9.4.jar. .. Attempting to download jdom-b10.jar. . . Attempting to download jfreechart-0.9.20.jar. . . Attempting to download jcommon-0.9.5.jar. ... . Attempting to download commons-jexl-1.0-beta-1.jar. ... . Attempting to download jdepend-2.5.jar. ... . Attempting to download checkstyle-3.3.jar. . . Attempting to download checkstyle-optional-3.3.jar. . . Attempting to download regexp-1.3.jar. ... . Attempting to download commons-beanutils-1.6.1.jar. . . Attempting to download simian-1.9.1.jar. . Attempting to download ant-1.6.jar. . build:start: site:deploy: site: xdoc:register-reports: maven-changes-plugin:register: maven-tasklist-plugin:register: statcvs:init: maven-statcvs-plugin:register: maven-junit-report-plugin:register: maven-jdepend-plugin:register: maven-jcoverage-plugin:register: maven-checkstyle-plugin:register: maven-simian-plugin:register: maven-javadoc-plugin:register:
Re: [configuration][ALL] compatibility issues with hsqldb
I saw the same problem when I was testing the [configuration] release with a .mavenrc set to force maven itself to run under 1.3. (which, btw is another workaround for the jdk spec in manifest problem), but I did not mention it since the build with maven.compile.executable pointing to jdk 1.3 worked (I guess maven does not fork the test class compiles). From my perspective, test class dependencies on later jdks are not show-stoppers. I think we had the same problem in [lang] in 2.0 and concluded that it was OK to release with tests depending on a later jdk than sources, since what is important from a usage standpoint is that the jar work with the targed jdk. +1, though for getting hsqldb released with 1.3 compatibility. On 12/3/05, Oliver Heger [EMAIL PROTECTED] wrote: Emmanuel Bourg wrote: Oliver Heger wrote: As I found out the cause for that is the hsqldb.jar distributed through ibiblio, which was built for JDK 1.4 and later. Indeed I was able to recompile hsqldb on JDK 1.3 and then the problem disappears. Unfortunately there does not seem to be a JDK 1.3 compatible version of a hsqldb.jar on the ibiblio maven reository (at least I did not find one). So this makes the build process on a JDK 1.3 very hard because the correct hsqldb.jar cannot be automatically downloaded. Maybe we could request the JDK 1.3 version of hsql to be uploaded in the repository at Ibiblio ? As hsqldb-x.y.z-jdk13.jar for example ? Emmanuel Bourg +1, I think this would be the best solution. How would we do that? Oliver - 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]
DO NOT REPLY [Bug 37727] - [resources] Fix serializability contracts
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-03 22:04 --- (In reply to comment #3) 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. snip/ Seems quite reasonable. Personally, I'd be more comfortable if the Javadoc reflected that view (vaguely similar to how collections advertises the need for external synchronization schemes where needed). I'll propose a Javadoc patch for BasicMessage next. 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. snap/ Thanks for your input. Maybe this should move to commons dev? -- 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]
DO NOT REPLY [Bug 37727] - [resources] Fix serializability contracts
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-03 22:15 --- Created an attachment (id=17131) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=17131action=view) Proposed Javadoc patch for BasicMessage Changes: * Added note about serializability of BasicMessage. * Couple of unrelated cosmetic changes. -- 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: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Rory Winston wrote: statcvs and svn dont work together (yet)... http://www.researchkitchen.co.uk/blog/archives/13 I just turned off the statcvs report last time. where do you do that? Project.xml? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all][POLL] what files to fixcrlf for windows distributions
I don't think it is feasible to patch the maven dist plugin or the hand-rolled ant scripts to inspect .svn/props for each file and then change line endings accordingly. I also verified that distros created on Windows are in fact shipping CRLF line endings on all files that have eol=native in their svn props. A recent example is the 1.1 IO release. To me, this is a problem, since it adds to the size of the distros and makes the contents of the distro dependent on the OS used to build it. I see three realistic options to fix this, none of which are ideal, listed in order of how I view them. Other ideas - or statements that this is a non-issue - welcome. I have already done the work for 2 and will submit the patch if that is the preferred solution. 1. Change svn props to get rid of eol=native and specify eol=crlf for .txt. IIUC the docs, lf is the default, so this should make all sources default to lf. It does force Windows users to correctly set line endings on patches, commits, etc. This is essentially going back to the way things were in cvs. 2. Patch the maven dist plugin to put lf line endings on all of the file types listed as recommended to have eol=native on the apache svn pages and crlf on .txt files. I would make both properties configurable in the plugin, with the default for the first being empty and the second .txt The problem with this is getting all of the extents fixed in the lf case. 3. Move to centralized release builds, running all release builds from minotaur. Would have to work through the issues here. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
On 12/3/05, Steve Cohen [EMAIL PROTECTED] wrote: Rory Winston wrote: statcvs and svn dont work together (yet)... http://www.researchkitchen.co.uk/blog/archives/13 I just turned off the statcvs report last time. where do you do that? Project.xml? snip/ Yup, for this project.xml [1], comment out the following report: reportmaven-statcvs-plugin/report When you post the POM to the java repository, you might want to remove the maven-statcvs-plugin dependency as well as the simian report. -Rahul [1] http://svn.apache.org/repos/asf/jakarta/commons/proper/net/branches/NET_1_4_1/project.xml - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Yes, remove the reference to the statcvs report from the reports element. You should obviously also check in the change so the project builds correctly from svn sources. You should have no problem building from branches, tags, etc., as long as commons-build is checked out as a peer. Phil On 12/3/05, Steve Cohen [EMAIL PROTECTED] wrote: Rory Winston wrote: statcvs and svn dont work together (yet)... http://www.researchkitchen.co.uk/blog/archives/13 I just turned off the statcvs report last time. where do you do that? Project.xml? - 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]
svn commit: r352026 - /jakarta/commons/proper/net/branches/NET_1_4_1/project.xml
Author: scohen Date: Sat Dec 3 13:40:38 2005 New Revision: 352026 URL: http://svn.apache.org/viewcvs?rev=352026view=rev Log: remove statcvs plugin which doesn't work. Modified: jakarta/commons/proper/net/branches/NET_1_4_1/project.xml Modified: jakarta/commons/proper/net/branches/NET_1_4_1/project.xml URL: http://svn.apache.org/viewcvs/jakarta/commons/proper/net/branches/NET_1_4_1/project.xml?rev=352026r1=352025r2=352026view=diff == --- jakarta/commons/proper/net/branches/NET_1_4_1/project.xml (original) +++ jakarta/commons/proper/net/branches/NET_1_4_1/project.xml Sat Dec 3 13:40:38 2005 @@ -211,7 +211,6 @@ reports reportmaven-changes-plugin/report reportmaven-tasklist-plugin/report - reportmaven-statcvs-plugin/report reportmaven-junit-report-plugin/report reportmaven-jdepend-plugin/report reportmaven-jcoverage-plugin/report - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Together, and bricks apart
On 12/2/05, Martin Cooper [EMAIL PROTECTED] wrote: snip In the old days we kept lf line endings on all the source files in cvs and hand-rolled ant scripts were used to put crlf on the .txt files in the zips. Between maven and svn's eol=native, that is no longer possible or at least immediate. The real question (see other response) is do we care about this? From lack of response to [poll] thread, could be the answer is no. This is an interesting comment, and indicates that we haven't done things consistently across Commons components (which isn't altogether surprising). All along - including in the old days of CVS - I've worked with CR-LF line ends, and that includes quite a few releases of several different components. So with the change to SVN, I haven't been doing anything differently... See other thread. In the CVS days, commit diffs would flag CRLFs creeping into sources, so we did not need to worry about this. Windows editors would only hose files if set up incorrectly, so we were probably fairly consistent in what we released. Now, the svn client is hosing these files silently when you check them out on Windows (at least, IMHO), so by doing nothing special Windows developers are introducing inconsistency. These are really demotivating things! Agreed and sorry if we seem to be making things harder rather than easier. Patches - or direct commits to - the releases page and any other suggestions to make things easier are most welcome. One other comment that I have on the issue of voting on releases is that the core problem here is lack of component-committed volunteers, IMHO. I remember a couple of years back when we discussed whose votes were binding on component releases. Hen made the interesting comment that he felt that committers not working on the component should vote and their votes were as important / even more important than those of the project team. We have now devolved to the point where without these votes, we will in some cases not be able to get 3 binding +1's. This is not good. Somehow we have to reengage as Rahul pointed out at the top of this thread. IMO, what this tells us is the Commons isn't scaling, and that doesn't surprise me at all. In the old days, there were a *lot* fewer components. Right now, I count 35 components in Proper and 9 more active components in the Sandbox (excluding the ones Henri is about to make dormant). That is a lot of stuff! Very few people, if any, are going to keep tabs on all of it, and most are likely to only track a handful, if that. When Commons was much smaller, the community was much more integrated, in that there was more overlap between the pieces (people-wise, not code-wise), and so we all watched each others' backs. We're no longer in that state. The inability to scale, is, in my opinion, an issue the ASF as a whole is also facing. Unfortunately, as with Commons, I don't have any good ideas. Other than to consciously stop growing, that is, but that doesn't appear to be a popular direction. I agree that it may be unpopular, but I see restricting addition of new components and archiving abandoned ones as the only realistic option at this point. See the recent [feedparser] thread as a pathetic example. I thought about voting -1 on promoting that component from the sandbox because I did not see sufficient community support and in retrospect I should have done this. I have not pushed to get [id] promoted for the same reason. We also need to concentrate hard on getting more volunteers to jump in to working on the existing set of components. Robert and Hen pointed out that making the components more approachable and some straightforward jumping in tasks available would help. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all][POLL] what files to fixcrlf for windows distributions
On 12/3/05, Phil Steitz [EMAIL PROTECTED] wrote: I don't think it is feasible to patch the maven dist plugin or the hand-rolled ant scripts to inspect .svn/props for each file and then change line endings accordingly. I also verified that distros created on Windows are in fact shipping CRLF line endings on all files that have eol=native in their svn props. A recent example is the 1.1 IO release. To me, this is a problem, since it adds to the size of the distros and makes the contents of the distro dependent on the OS used to build it. I really don't think this is an issue. It's been this way for _years_, without any problems that I've been aware of. I see no reason to suddenly declare it's an issue and go to all the lengths being discussed to fix it. As for the size, given that the distributions are compressed, and text compression algorithms are very good indeed, I seriously doubt that it's going to make any significant difference. I see three realistic options to fix this, none of which are ideal, listed in order of how I view them. Other ideas - or statements that this is a non-issue - welcome. I have already done the work for 2 and will submit the patch if that is the preferred solution. 1. Change svn props to get rid of eol=native and specify eol=crlf for .txt. IIUC the docs, lf is the default, so this should make all sources default to lf. It does force Windows users to correctly set line endings on patches, commits, etc. This is essentially going back to the way things were in cvs. -1 First off, as I pointed out elsewhere, this is *not* going back to the way things were with CVS. We had exactly the same issue when we were using CVS, and nobody seemed to want to fix it then. In fact, we've had this same situation since Commons was born. The Windows CVS command line client defaults to CR-LF on checkout, as does WinCVS (which also has a checkbox you need to explicitly check if you want Unix line ends). The more serious issue, though, is that this can end up causing incorrect line number reporting in diffs, exceptions, and in other cases, which is going to make our job as component developers more painful than it already is. 2. Patch the maven dist plugin to put lf line endings on all of the file types listed as recommended to have eol=native on the apache svn pages and crlf on .txt files. I would make both properties configurable in the plugin, with the default for the first being empty and the second .txt The problem with this is getting all of the extents fixed in the lf case. 3. Move to centralized release builds, running all release builds from minotaur. Would have to work through the issues here. That would hurt the whole of Commons, IMO. It would force all of the Windows developers to learn to do development - or at least building releases - in a new environment, which will be more painful. This at a time where we really need to make the release process as painless as possible, so that more people are willing to take it on. -- Martin Cooper Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Thanks guys. statcvs gone. Past that hurdle. Now this one: xdoc:jelly-transform: [echo] Generating /home/scohen/commons-net/branches/NET_1_4_1/target/docs/javadoc.html from /home/scohen/commons-net/branches/NET_1_4_1/target/generated-xdocs/javadoc.xml Could not find the class: org.apache.commons.jelly.tags.fmt.FmtTagLibrary java.lang.ClassNotFoundException: org.apache.commons.jelly.tags.fmt.FmtTagLibrary ... What's up with that? Phil Steitz wrote: Yes, remove the reference to the statcvs report from the reports element. You should obviously also check in the change so the project builds correctly from svn sources. You should have no problem building from branches, tags, etc., as long as commons-build is checked out as a peer. Phil On 12/3/05, Steve Cohen [EMAIL PROTECTED] wrote: Rory Winston wrote: statcvs and svn dont work together (yet)... http://www.researchkitchen.co.uk/blog/archives/13 I just turned off the statcvs report last time. where do you do that? Project.xml? - 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: [all] Together, and bricks apart
On 12/3/05, Phil Steitz [EMAIL PROTECTED] wrote: On 12/2/05, Martin Cooper [EMAIL PROTECTED] wrote: snip In the old days we kept lf line endings on all the source files in cvs and hand-rolled ant scripts were used to put crlf on the .txt files in the zips. Between maven and svn's eol=native, that is no longer possible or at least immediate. The real question (see other response) is do we care about this? From lack of response to [poll] thread, could be the answer is no. This is an interesting comment, and indicates that we haven't done things consistently across Commons components (which isn't altogether surprising). All along - including in the old days of CVS - I've worked with CR-LF line ends, and that includes quite a few releases of several different components. So with the change to SVN, I haven't been doing anything differently... See other thread. In the CVS days, commit diffs would flag CRLFs creeping into sources, so we did not need to worry about this. Windows editors would only hose files if set up incorrectly, so we were probably fairly consistent in what we released. Now, the svn client is hosing these files silently when you check them out on Windows (at least, IMHO), so by doing nothing special Windows developers are introducing inconsistency. Also, see other thread. ;-) We seem to have had totally different CVS experiences. I did *all* my CVS work with CR-LF line ends, and I still have locally checked out CVS trees to prove it. Nothing - *nothing* - has changed with the move to SVN. This whole thing is a non-issue to me. -- Martin Cooper These are really demotivating things! Agreed and sorry if we seem to be making things harder rather than easier. Patches - or direct commits to - the releases page and any other suggestions to make things easier are most welcome. One other comment that I have on the issue of voting on releases is that the core problem here is lack of component-committed volunteers, IMHO. I remember a couple of years back when we discussed whose votes were binding on component releases. Hen made the interesting comment that he felt that committers not working on the component should vote and their votes were as important / even more important than those of the project team. We have now devolved to the point where without these votes, we will in some cases not be able to get 3 binding +1's. This is not good. Somehow we have to reengage as Rahul pointed out at the top of this thread. IMO, what this tells us is the Commons isn't scaling, and that doesn't surprise me at all. In the old days, there were a *lot* fewer components. Right now, I count 35 components in Proper and 9 more active components in the Sandbox (excluding the ones Henri is about to make dormant). That is a lot of stuff! Very few people, if any, are going to keep tabs on all of it, and most are likely to only track a handful, if that. When Commons was much smaller, the community was much more integrated, in that there was more overlap between the pieces (people-wise, not code-wise), and so we all watched each others' backs. We're no longer in that state. The inability to scale, is, in my opinion, an issue the ASF as a whole is also facing. Unfortunately, as with Commons, I don't have any good ideas. Other than to consciously stop growing, that is, but that doesn't appear to be a popular direction. I agree that it may be unpopular, but I see restricting addition of new components and archiving abandoned ones as the only realistic option at this point. See the recent [feedparser] thread as a pathetic example. I thought about voting -1 on promoting that component from the sandbox because I did not see sufficient community support and in retrospect I should have done this. I have not pushed to get [id] promoted for the same reason. We also need to concentrate hard on getting more volunteers to jump in to working on the existing set of components. Robert and Hen pointed out that making the components more approachable and some straightforward jumping in tasks available would help. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
You need to make sure you are running version 1.9.2 of the maven xdoc plugin. maven plugin:install maven maven-xdoc-plugin 1.9.2 Phil On 12/3/05, Steve Cohen [EMAIL PROTECTED] wrote: Thanks guys. statcvs gone. Past that hurdle. Now this one: xdoc:jelly-transform: [echo] Generating /home/scohen/commons-net/branches/NET_1_4_1/target/docs/javadoc.html from /home/scohen/commons-net/branches/NET_1_4_1/target/generated-xdocs/javadoc.xml Could not find the class: org.apache.commons.jelly.tags.fmt.FmtTagLibrary java.lang.ClassNotFoundException: org.apache.commons.jelly.tags.fmt.FmtTagLibrary ... What's up with that? Phil Steitz wrote: Yes, remove the reference to the statcvs report from the reports element. You should obviously also check in the change so the project builds correctly from svn sources. You should have no problem building from branches, tags, etc., as long as commons-build is checked out as a peer. Phil On 12/3/05, Steve Cohen [EMAIL PROTECTED] wrote: Rory Winston wrote: statcvs and svn dont work together (yet)... http://www.researchkitchen.co.uk/blog/archives/13 I just turned off the statcvs report last time. where do you do that? Project.xml? - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all][POLL] what files to fixcrlf for windows distributions
Thanks, Martin. I stand corrected then and will shut up about this. To close this out, I guess we are agreeing that we have no standard for line endings and will make no attempt to make them consistent. I did not know the Windows cvs client was also converting the files, so thought this was a new problem introduced by svn. Sorry for the noise. I also agree (strongly) that we need to make releasing easier. Sorry if I this discussion seemed like negative progress. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r348046 - /jakarta/commons/proper/lang/trunk/project.xml
Author: dion
Date: Mon Nov 21 16:25:08 2005
New Revision: 348046
URL: http://svn.apache.org/viewcvs?rev=348046view=rev
Log:
Removed tabs
Fixed POM as per bug 37314
Use groupId/artifactId instead of 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=348046r1=348045r2=348046view=diff
==
--- jakarta/commons/proper/lang/trunk/project.xml (original)
+++ jakarta/commons/proper/lang/trunk/project.xml Mon Nov 21 16:25:08 2005
@@ -15,357 +15,358 @@
limitations under the License.
--
project
- pomVersion3/pomVersion
- idcommons-lang/id
- nameLang/name
- currentVersion2.2-dev/currentVersion
- inceptionYear2001/inceptionYear
- shortDescriptionJava Common Components/shortDescription
- description
-Commons.Lang, a package of Java utility classes for the
-classes that are in java.lang's hierarchy, or are considered to be so
-standard as to justify existence in java.lang.
- /description
- logo/images/logo.png/logo
-
urlhttp://jakarta.apache.org/commons/${pom.artifactId.substring(8)}//url
- packageorg.apache.commons.${pom.artifactId.substring(8)}/package
- organization
- nameThe Apache Software Foundation/name
- urlhttp://jakarta.apache.org/url
-
logohttp://jakarta.apache.org/images/original-jakarta-logo.gif/logo
- /organization
- licenses
- license
- nameThe Apache Software License, Version 2.0/name
- url/LICENSE.txt/url
- distributionrepo/distribution
- /license
- /licenses
- gumpRepositoryIdjakarta/gumpRepositoryId
- issueTrackingUrlhttp://issues.apache.org/bugzilla//issueTrackingUrl
- siteAddressjakarta.apache.org/siteAddress
-
siteDirectory/www/jakarta.apache.org/commons/${pom.artifactId.substring(8)}//siteDirectory
-
distributionDirectory/www/jakarta.apache.org/builds/jakarta-commons/${pom.artifactId.substring(8)}//distributionDirectory
- repository
-
connectionscm:svn:http://svn.apache.org/repos/asf/jakarta/commons/proper/${pom.artifactId.substring(8)}/trunk/connection
-
urlhttp://svn.apache.org/viewcvs/jakarta/commons/proper/${pom.artifactId.substring(8)}/trunk/url
- /repository
- mailingLists
- mailingList
- nameCommons Dev List/name
- subscribe[EMAIL PROTECTED]/subscribe
- unsubscribe[EMAIL PROTECTED]/unsubscribe
-
archivehttp://mail-archives.apache.org/eyebrowse/[EMAIL PROTECTED]/archive
- /mailingList
- mailingList
- nameCommons User List/name
- subscribe[EMAIL PROTECTED]/subscribe
- unsubscribe[EMAIL PROTECTED]/unsubscribe
-
archivehttp://mail-archives.apache.org/eyebrowse/[EMAIL PROTECTED]/archive
- /mailingList
- /mailingLists
- developers
- developer
- nameDaniel Rall/name
- iddlr/id
- emaildlr@finemaltcoding.com/email
- organizationCollabNet, Inc./organization
- roles
- roleJava Developer/role
- /roles
- /developer
- developer
- nameStephen Colebourne/name
- idscolebourne/id
- email[EMAIL PROTECTED]/email
- organizationSITA ATS Ltd/organization
- timezone0/timezone
- roles
- roleJava Developer/role
- /roles
- /developer
- developer
- nameHenri Yandell/name
- idbayard/id
- email[EMAIL PROTECTED]/email
- organization/
- roles
- roleJava Developer/role
- /roles
- /developer
- developer
- nameSteven Caswell/name
- idscaswell/id
- email[EMAIL PROTECTED]/email
- organization/
- roles
- roleJava Developer/role
- /roles
- timezone-5/timezone
- /developer
- developer
- nameRobert Burrell Donkin/name
- idrdonkin/id
- email[EMAIL PROTECTED]/email
-
Re: [all] Commons Manual
Henri Yandell 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. This also needs specific info on what versions of Maven and it's plugins are needed to build the site. I browsed through Building Components [1] which is quite good, but it lacks the version details. We should also update the section describing the POM elements to use groupId/artifactId instead of just id. Would you like me to write a patch for this? [1] http://jakarta.apache.org/commons/building.html * 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] -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Nope, 1.6. This is sort of what I meant when I said it's harder to do these releases. How is one supposed to KNOW what versions of these 30 or 40 plugins you have to have in order to build a release? Does Jakarta or Jakarta-commons have a page that tells you the minimum maven setup needed to do a site release? If not, it probably should have. I know this is a dynamic process, but this is nuts. And then the other direction. I shudder to think what would have happened if I had tried maven 2.0. Hate to be an old fart here but was ant really all that bad? Anyway, the site is deployed. It's gradually pushing itself out to all the servers. Phil Steitz wrote: You need to make sure you are running version 1.9.2 of the maven xdoc plugin. maven plugin:install maven maven-xdoc-plugin 1.9.2 Phil On 12/3/05, Steve Cohen [EMAIL PROTECTED] wrote: Thanks guys. statcvs gone. Past that hurdle. Now this one: xdoc:jelly-transform: [echo] Generating /home/scohen/commons-net/branches/NET_1_4_1/target/docs/javadoc.html from /home/scohen/commons-net/branches/NET_1_4_1/target/generated-xdocs/javadoc.xml Could not find the class: org.apache.commons.jelly.tags.fmt.FmtTagLibrary java.lang.ClassNotFoundException: org.apache.commons.jelly.tags.fmt.FmtTagLibrary ... What's up with that? Phil Steitz wrote: Yes, remove the reference to the statcvs report from the reports element. You should obviously also check in the change so the project builds correctly from svn sources. You should have no problem building from branches, tags, etc., as long as commons-build is checked out as a peer. Phil On 12/3/05, Steve Cohen [EMAIL PROTECTED] wrote: Rory Winston wrote: statcvs and svn dont work together (yet)... http://www.researchkitchen.co.uk/blog/archives/13 I just turned off the statcvs report last time. where do you do that? Project.xml? - 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] - 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] Commons Manual
On 12/3/05, Dennis Lundberg [EMAIL PROTECTED] wrote: Henri Yandell 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. This also needs specific info on what versions of Maven and it's plugins are needed to build the site. I browsed through Building Components [1] which is quite good, but it lacks the version details. We should also update the section describing the POM elements to use groupId/artifactId instead of just id. Would you like me to write a patch for this? Yes, please! Anything other improvements would also be welcome. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
On 12/3/05, Steve Cohen [EMAIL PROTECTED] wrote: Nope, 1.6. This is sort of what I meant when I said it's harder to do these releases. How is one supposed to KNOW what versions of these 30 or 40 plugins you have to have in order to build a release? Does Jakarta or Jakarta-commons have a page that tells you the minimum maven setup needed to do a site release? If not, it probably should have. I know this is a dynamic process, but this is nuts. Good point. Right now http://jakarta.apache.org/commons/building.html just contains the statement Be sure to follow the instructions for upgrading the plugins to the latest releases. We could either doc the full set there or check in the output of maven --info as a text file in commons-build, making changes to that as necessary. I would recommend the second option, with a link on the building page. I will do that if no one beats me to it. And then the other direction. I shudder to think what would have happened if I had tried maven 2.0. Would have failed (because of POM spec and lots of other incompatibilities), as would the 1.1 beta. I agree we need to make version dependency clear. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
okay, made it down to step 12 now. * Update Jakarta News Page Add a standard news item announcing the release to the current Jakarta news page. Look for the page whose name covers today's date in the site/xdocs/site/news directory. For example, the news for a release created in July 2004 should go into news-2004-2ndHalf.xml. This should be similar to the announcement you'll post later to email lists. Please remember to include a description of your component. Please also add a reminder about verifying signature. * Jakarta Welcome Page News items on the Jakarta welcome page are now automatically generated when you run ant to build the HTML files. However, there is no such file since 2nd quarter of 2005, and the index.xml mentions that this has now been retired, and the apache site now asks you to subscribe to a mailing list for Apache news. Am I right then in thinking that the second part of section 12 (quoted above) is now null and void? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
On 12/3/05, Phil Steitz [EMAIL PROTECTED] wrote: On 12/3/05, Steve Cohen [EMAIL PROTECTED] wrote: Nope, 1.6. This is sort of what I meant when I said it's harder to do these releases. How is one supposed to KNOW what versions of these 30 or 40 plugins you have to have in order to build a release? Does Jakarta or Jakarta-commons have a page that tells you the minimum maven setup needed to do a site release? If not, it probably should have. I know this is a dynamic process, but this is nuts. Good point. Right now http://jakarta.apache.org/commons/building.html just contains the statement Be sure to follow the instructions for upgrading the plugins to the latest releases. Is it just me going blind, or are those instructions missing? All I see is a link to a page that has a big list of plugins. I don't see instructions on upgrading my plugins. ;-( We could either doc the full set there or check in the output of maven --info as a text file in commons-build, making changes to that as necessary. I would recommend the second option, with a link on the building page. I will do that if no one beats me to it. +1 to the second option. +1000 to a script that will automatically update my Maven installation with those versions of the plugins. ;-) -- Martin Cooper And then the other direction. I shudder to think what would have happened if I had tried maven 2.0. Would have failed (because of POM spec and lots of other incompatibilities), as would the 1.1 beta. I agree we need to make version dependency clear. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Pls disregard. I figured it out. Steve Cohen wrote: okay, made it down to step 12 now. * Update Jakarta News Page Add a standard news item announcing the release to the current Jakarta news page. Look for the page whose name covers today's date in the site/xdocs/site/news directory. For example, the news for a release created in July 2004 should go into news-2004-2ndHalf.xml. This should be similar to the announcement you'll post later to email lists. Please remember to include a description of your component. Please also add a reminder about verifying signature. * Jakarta Welcome Page News items on the Jakarta welcome page are now automatically generated when you run ant to build the HTML files. However, there is no such file since 2nd quarter of 2005, and the index.xml mentions that this has now been retired, and the apache site now asks you to subscribe to a mailing list for Apache news. Am I right then in thinking that the second part of section 12 (quoted above) is now null and void? - 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: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
On 12/3/05, Steve Cohen [EMAIL PROTECTED] wrote: okay, made it down to step 12 now. * Update Jakarta News Page Add a standard news item announcing the release to the current Jakarta news page. Look for the page whose name covers today's date in the site/xdocs/site/news directory. For example, the news for a release created in July 2004 should go into news-2004-2ndHalf.xml. This should be similar to the announcement you'll post later to email lists. Please remember to include a description of your component. Please also add a reminder about verifying signature. * Jakarta Welcome Page News items on the Jakarta welcome page are now automatically generated when you run ant to build the HTML files. However, there is no such file since 2nd quarter of 2005, and the index.xml mentions that this has now been retired, and the apache site now asks you to subscribe to a mailing list for Apache news. Am I right then in thinking that the second part of section 12 (quoted above) is now null and void? snip/ You're almost home. Section 12 needs to be updated, I might propose a patch if I find cycles tomorrow. But I wouldn't recommend disregarding it. You're looking for this news.xml file [1]. The background on the change not yet reflected in the Commons docs is in this thread on general@ [2]. -Rahul [1] http://svn.apache.org/repos/asf/jakarta/site/news.xml [2] http://marc.theaimsgroup.com/?l=jakarta-generalm=112957612119868w=2 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
On 12/3/05, Martin Cooper [EMAIL PROTECTED] wrote: On 12/3/05, Phil Steitz [EMAIL PROTECTED] wrote: On 12/3/05, Steve Cohen [EMAIL PROTECTED] wrote: Nope, 1.6. This is sort of what I meant when I said it's harder to do these releases. How is one supposed to KNOW what versions of these 30 or 40 plugins you have to have in order to build a release? Does Jakarta or Jakarta-commons have a page that tells you the minimum maven setup needed to do a site release? If not, it probably should have. I know this is a dynamic process, but this is nuts. Good point. Right now http://jakarta.apache.org/commons/building.html just contains the statement Be sure to follow the instructions for upgrading the plugins to the latest releases. Is it just me going blind, or are those instructions missing? All I see is a link to a page that has a big list of plugins. I don't see instructions on upgrading my plugins. ;-( We could either doc the full set there or check in the output of maven --info as a text file in commons-build, making changes to that as necessary. I would recommend the second option, with a link on the building page. I will do that if no one beats me to it. +1 to the second option. +1000 to a script that will automatically update my Maven installation with those versions of the plugins. ;-) hmmm...I have a bash script ;-) It just consists of a bunch of lines like this: maven plugin:download -DgroupId=maven -DartifactId=maven-ant-plugin -Dversion=1.9 maven plugin:download -DgroupId=maven -DartifactId=maven-artifact-plugin -Dversion=1.5.2 ... Another thing that might work would be to add explicit dependencies to the required versions in commons-build's project.xml. Then executing even the clean target there would make maven download and install them all. I will play with this and if it works, just commit the change there and change the docs to recommend this. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
On 12/3/05, Steve Cohen [EMAIL PROTECTED] wrote: Pls disregard. I figured it out. snip/ Yup, noticed that as I clicked send to the earlier email. I think you've a typo, the id for the net 1.4.1 news item should be 20051203.1 (instead of 2005203.1) -Rahul Steve Cohen wrote: okay, made it down to step 12 now. snap/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r352049 - /jakarta/commons/proper/transaction/trunk/project.xml
Author: mvdb Date: Sat Dec 3 15:26:20 2005 New Revision: 352049 URL: http://svn.apache.org/viewcvs?rev=352049view=rev Log: Added iso-8859-1 encoding, since the u umplaut is not utf-8 Modified: jakarta/commons/proper/transaction/trunk/project.xml Modified: jakarta/commons/proper/transaction/trunk/project.xml URL: http://svn.apache.org/viewcvs/jakarta/commons/proper/transaction/trunk/project.xml?rev=352049r1=352048r2=352049view=diff == --- jakarta/commons/proper/transaction/trunk/project.xml (original) +++ jakarta/commons/proper/transaction/trunk/project.xml Sat Dec 3 15:26:20 2005 @@ -1,7 +1,7 @@ -?xml version=1.0? +?xml version=1.0 encoding=ISO-8859-1 ? project pomVersion3/pomVersion - !--extend../commons-build/project.xml/extend-- + extend../commons-build/project.xml/extend nameTransaction/name idcommons-transaction/id logo/images/transaction-logo-white.png/logo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Phil Steitz wrote: On 12/3/05, Martin Cooper [EMAIL PROTECTED] wrote: On 12/3/05, Phil Steitz [EMAIL PROTECTED] wrote: On 12/3/05, Steve Cohen [EMAIL PROTECTED] wrote: Nope, 1.6. This is sort of what I meant when I said it's harder to do these releases. How is one supposed to KNOW what versions of these 30 or 40 plugins you have to have in order to build a release? Does Jakarta or Jakarta-commons have a page that tells you the minimum maven setup needed to do a site release? If not, it probably should have. I know this is a dynamic process, but this is nuts. Good point. Right now http://jakarta.apache.org/commons/building.html just contains the statement Be sure to follow the instructions for upgrading the plugins to the latest releases. Is it just me going blind, or are those instructions missing? All I see is a link to a page that has a big list of plugins. I don't see instructions on upgrading my plugins. ;-( We could either doc the full set there or check in the output of maven --info as a text file in commons-build, making changes to that as necessary. I would recommend the second option, with a link on the building page. I will do that if no one beats me to it. +1 to the second option. +1000 to a script that will automatically update my Maven installation with those versions of the plugins. ;-) hmmm...I have a bash script ;-) It just consists of a bunch of lines like this: maven plugin:download -DgroupId=maven -DartifactId=maven-ant-plugin -Dversion=1.9 maven plugin:download -DgroupId=maven -DartifactId=maven-artifact-plugin -Dversion=1.5.2 ... Another thing that might work would be to add explicit dependencies to the required versions in commons-build's project.xml. Then executing even the clean target there would make maven download and install them all. I will play with this and if it works, just commit the change there and change the docs to recommend this. Not sure if putting a dependency on a plugin works in Maven 1, I know it works in Maven 2. It would be great if it does though. I'm putting together a patch for http://jakarta.apache.org/commons/building.html on how to install plugins manually. -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Phil Steitz wrote: On 12/3/05, Martin Cooper [EMAIL PROTECTED] wrote: On 12/3/05, Phil Steitz [EMAIL PROTECTED] wrote: On 12/3/05, Steve Cohen [EMAIL PROTECTED] wrote: Nope, 1.6. This is sort of what I meant when I said it's harder to do these releases. How is one supposed to KNOW what versions of these 30 or 40 plugins you have to have in order to build a release? Does Jakarta or Jakarta-commons have a page that tells you the minimum maven setup needed to do a site release? If not, it probably should have. I know this is a dynamic process, but this is nuts. Good point. Right now http://jakarta.apache.org/commons/building.html just contains the statement Be sure to follow the instructions for upgrading the plugins to the latest releases. Is it just me going blind, or are those instructions missing? All I see is a link to a page that has a big list of plugins. I don't see instructions on upgrading my plugins. ;-( We could either doc the full set there or check in the output of maven --info as a text file in commons-build, making changes to that as necessary. I would recommend the second option, with a link on the building page. I will do that if no one beats me to it. +1 to the second option. +1000 to a script that will automatically update my Maven installation with those versions of the plugins. ;-) hmmm...I have a bash script ;-) It just consists of a bunch of lines like this: maven plugin:download -DgroupId=maven -DartifactId=maven-ant-plugin -Dversion=1.9 maven plugin:download -DgroupId=maven -DartifactId=maven-artifact-plugin -Dversion=1.5.2 ... Another thing that might work would be to add explicit dependencies to the required versions in commons-build's project.xml. Then executing even the clean target there would make maven download and install them all. I will play with this and if it works, just commit the change there and change the docs to recommend this. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] that would be a big help, thank you very much. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all][POLL] what files to fixcrlf for windows distributions
Has everyone been following the bit on http://www.apache.org/dev/version-control.html? -- Committers will need to properly configure their svn client. One particular issue is OS-specific line-endings for text files. When you add a new text file, especially when applying patches from Bugzilla, first ensure that the line-endings are appropriate for *your* system, then do ... svn add test.txt svn propset svn:eol-style native test.txt Your svn client can be configured to do that automatically for some common file types. Add the list to your ~/.subversion/config [http://www.apache.org/dev/svn-eol-style.txt] file. However, you should still pay attention to the messages from your svn client when you do 'svn commit'. -- Just checking :) Hen On 12/3/05, Phil Steitz [EMAIL PROTECTED] wrote: Thanks, Martin. I stand corrected then and will shut up about this. To close this out, I guess we are agreeing that we have no standard for line endings and will make no attempt to make them consistent. I did not know the Windows cvs client was also converting the files, so thought this was a new problem introduced by svn. Sorry for the noise. I also agree (strongly) that we need to make releasing easier. Sorry if I this discussion seemed like negative progress. Phil - 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]
svn commit: r352050 - /jakarta/commons/proper/transaction/trunk/project.xml
Author: mvdb Date: Sat Dec 3 15:35:37 2005 New Revision: 352050 URL: http://svn.apache.org/viewcvs?rev=352050view=rev Log: whoops.. recover commented out extend Modified: jakarta/commons/proper/transaction/trunk/project.xml Modified: jakarta/commons/proper/transaction/trunk/project.xml URL: http://svn.apache.org/viewcvs/jakarta/commons/proper/transaction/trunk/project.xml?rev=352050r1=352049r2=352050view=diff == --- jakarta/commons/proper/transaction/trunk/project.xml (original) +++ jakarta/commons/proper/transaction/trunk/project.xml Sat Dec 3 15:35:37 2005 @@ -1,7 +1,7 @@ ?xml version=1.0 encoding=ISO-8859-1 ? project pomVersion3/pomVersion - extend../commons-build/project.xml/extend + !-- extend../commons-build/project.xml/extend -- nameTransaction/name idcommons-transaction/id logo/images/transaction-logo-white.png/logo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Yes, thanks, fixed it now. Rahul Akolkar wrote: On 12/3/05, Steve Cohen [EMAIL PROTECTED] wrote: Pls disregard. I figured it out. snip/ Yup, noticed that as I clicked send to the earlier email. I think you've a typo, the id for the net 1.4.1 news item should be 20051203.1 (instead of 2005203.1) -Rahul Steve Cohen wrote: okay, made it down to step 12 now. snap/ - 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: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Wow, who would have thought the smallest of releases would produce this much email traffic??? Dennis Lundberg wrote: Phil Steitz wrote: On 12/3/05, Martin Cooper [EMAIL PROTECTED] wrote: On 12/3/05, Phil Steitz [EMAIL PROTECTED] wrote: On 12/3/05, Steve Cohen [EMAIL PROTECTED] wrote: Nope, 1.6. This is sort of what I meant when I said it's harder to do these releases. How is one supposed to KNOW what versions of these 30 or 40 plugins you have to have in order to build a release? Does Jakarta or Jakarta-commons have a page that tells you the minimum maven setup needed to do a site release? If not, it probably should have. I know this is a dynamic process, but this is nuts. Good point. Right now http://jakarta.apache.org/commons/building.html just contains the statement Be sure to follow the instructions for upgrading the plugins to the latest releases. Is it just me going blind, or are those instructions missing? All I see is a link to a page that has a big list of plugins. I don't see instructions on upgrading my plugins. ;-( We could either doc the full set there or check in the output of maven --info as a text file in commons-build, making changes to that as necessary. I would recommend the second option, with a link on the building page. I will do that if no one beats me to it. +1 to the second option. +1000 to a script that will automatically update my Maven installation with those versions of the plugins. ;-) hmmm...I have a bash script ;-) It just consists of a bunch of lines like this: maven plugin:download -DgroupId=maven -DartifactId=maven-ant-plugin -Dversion=1.9 maven plugin:download -DgroupId=maven -DartifactId=maven-artifact-plugin -Dversion=1.5.2 ... Another thing that might work would be to add explicit dependencies to the required versions in commons-build's project.xml. Then executing even the clean target there would make maven download and install them all. I will play with this and if it works, just commit the change there and change the docs to recommend this. Not sure if putting a dependency on a plugin works in Maven 1, I know it works in Maven 2. It would be great if it does though. I'm putting together a patch for http://jakarta.apache.org/commons/building.html on how to install plugins manually. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
On 12/3/05, Phil Steitz [EMAIL PROTECTED] wrote: On 12/3/05, Martin Cooper [EMAIL PROTECTED] wrote: On 12/3/05, Phil Steitz [EMAIL PROTECTED] wrote: On 12/3/05, Steve Cohen [EMAIL PROTECTED] wrote: Nope, 1.6. This is sort of what I meant when I said it's harder to do these releases. How is one supposed to KNOW what versions of these 30 or 40 plugins you have to have in order to build a release? Does Jakarta or Jakarta-commons have a page that tells you the minimum maven setup needed to do a site release? If not, it probably should have. I know this is a dynamic process, but this is nuts. Good point. Right now http://jakarta.apache.org/commons/building.html just contains the statement Be sure to follow the instructions for upgrading the plugins to the latest releases. Is it just me going blind, or are those instructions missing? All I see is a link to a page that has a big list of plugins. I don't see instructions on upgrading my plugins. ;-( We could either doc the full set there or check in the output of maven --info as a text file in commons-build, making changes to that as necessary. I would recommend the second option, with a link on the building page. I will do that if no one beats me to it. +1 to the second option. +1000 to a script that will automatically update my Maven installation with those versions of the plugins. ;-) hmmm...I have a bash script ;-) It just consists of a bunch of lines like this: maven plugin:download -DgroupId=maven -DartifactId=maven-ant-plugin -Dversion=1.9 maven plugin:download -DgroupId=maven -DartifactId=maven-artifact-plugin -Dversion=1.5.2 What I was thinking of was some kind of script (language TBD ;) that would take the 'maven --info' file that you mentioned earlier, and use that to update my plugins. That way, when someone updates the info file, I just need to run the script to get all the required updates. Hey, maybe there should be a Maven plugin for that! Building it as a Maven plugin would at least solve the language problem. Hmm... -- Martin Cooper ... Another thing that might work would be to add explicit dependencies to the required versions in commons-build's project.xml. Then executing even the clean target there would make maven download and install them all. I will play with this and if it works, just commit the change there and change the docs to recommend this. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
On 12/3/05, Dennis Lundberg [EMAIL PROTECTED] wrote: Phil Steitz wrote: snip Another thing that might work would be to add explicit dependencies to the required versions in commons-build's project.xml. Then executing even the clean target there would make maven download and install them all. I will play with this and if it works, just commit the change there and change the docs to recommend this. Not sure if putting a dependency on a plugin works in Maven 1, I know it works in Maven 2. It would be great if it does though. Actually, it does seem to work. I will take a stab at specifying all of the relevant ones and commit a change to the commons-build POM for this. I'm putting together a patch for http://jakarta.apache.org/commons/building.html on how to install plugins manually. Great! Include a recommendation to execute the clean target or build the commons web site from commons-build to get the plugins specified there. No harm in also repeating the maven instructions as well. Pls also add make any other improvements you see fit. Phil -- Dennis Lundberg - 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]
[Jakarta-commons Wiki] Update of CreatingStandardWebPresence by RahulAkolkar
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 RahulAkolkar: http://wiki.apache.org/jakarta-commons/CreatingStandardWebPresence The comment on the change is: Update proper components list, please cross-check. -- === Commons Proper Components === + * Attributes - Maven site. - * BeanUtils - /!\ Has Maven site, but b not default/b. + * BeanUtils - /!\ Has Maven site, but '''not default'''. * Betwixt - Maven site. - * Cactus - /!\ bPromoted, but still in Proper CVS./b + * Cactus - /!\ '''Promoted, but still in Proper SVN'''. + * Chain - Maven site. * CLI - Maven site. * Codec - Maven site. - * Collections - /!\ Has Maven site, but b not default/b. + * Collections - /!\ Has Maven site, but '''not default'''. + * Configuration - Maven site. * Daemon - Maven site. * DBCP - Maven site. - * DBUtils - Maven site. + * !DbUtils - Maven site. - * Digester - /!\ Has Maven site, but b not default/b. + * Digester - /!\ Has Maven site, but '''not default'''. - * Discovery - /!\ Has Maven site, but b not default/b. + * Discovery - /!\ Has Maven site, but '''not default'''. - * EL - /!\ bNo Maven site./b + * EL - /!\ '''No Maven site'''. + * Email - Maven site. * FileUpload - Maven site. - * HttpClient - Maven site. + * !HttpClient - Maven site. + * IO - Maven site. * Jelly - Maven site. * Jexl - Maven site. * JXPath - Maven site. - * Lang - /!\ Has Maven site, but b not default/b. + * Lang - /!\ Has Maven site, but '''not default'''. * Latka - Maven site. * Launcher - Maven site. - * Logging - /!\ Has bminimal/b Maven site, but b not default/b. + * Logging - /!\ Has '''minimal''' Maven site, but '''not default'''. * Math - Maven site. - * Modeler - /!\ Has Maven site, but b not default/b. + * Modeler - /!\ Has Maven site, but '''not default'''. * Net - Maven site. * Pool - Maven site. * Primitives - Maven site. + * Resources - Maven site. + * Transaction - Maven site. * Validator - Maven site. + * VFS - Maven site. === Commons Sandbox Components === @@ -153, +161 @@ * Primitives * Proposal * Reflect - * Resources - Maven site. + * Resources - Maven site. * Rupert * Scaffold - Maven site. * Services @@ -168, +176 @@ * XMLUnit * XO - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta-commons Wiki] Update of CreatingStandardWebPresence by JamesCarman
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 JamesCarman: http://wiki.apache.org/jakarta-commons/CreatingStandardWebPresence -- * Periodicity * Primitives * Proposal + * Proxy - Maven site. * Reflect * Resources - Maven site. * Rupert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
On 12/3/05, Martin Cooper [EMAIL PROTECTED] wrote: On 12/3/05, Phil Steitz [EMAIL PROTECTED] wrote: On 12/3/05, Martin Cooper [EMAIL PROTECTED] wrote: On 12/3/05, Phil Steitz [EMAIL PROTECTED] wrote: On 12/3/05, Steve Cohen [EMAIL PROTECTED] wrote: Nope, 1.6. This is sort of what I meant when I said it's harder to do these releases. How is one supposed to KNOW what versions of these 30 or 40 plugins you have to have in order to build a release? Does Jakarta or Jakarta-commons have a page that tells you the minimum maven setup needed to do a site release? If not, it probably should have. I know this is a dynamic process, but this is nuts. Good point. Right now http://jakarta.apache.org/commons/building.html just contains the statement Be sure to follow the instructions for upgrading the plugins to the latest releases. Is it just me going blind, or are those instructions missing? All I see is a link to a page that has a big list of plugins. I don't see instructions on upgrading my plugins. ;-( We could either doc the full set there or check in the output of maven --info as a text file in commons-build, making changes to that as necessary. I would recommend the second option, with a link on the building page. I will do that if no one beats me to it. +1 to the second option. +1000 to a script that will automatically update my Maven installation with those versions of the plugins. ;-) hmmm...I have a bash script ;-) It just consists of a bunch of lines like this: maven plugin:download -DgroupId=maven -DartifactId=maven-ant-plugin -Dversion=1.9 maven plugin:download -DgroupId=maven -DartifactId=maven-artifact-plugin -Dversion=1.5.2 What I was thinking of was some kind of script (language TBD ;) that would take the 'maven --info' file that you mentioned earlier, and use that to update my plugins. That way, when someone updates the info file, I just need to run the script to get all the required updates. I think what I am doing now to the commons-build pom will do that. You will just have to execute any target in commons-build and the plugins will get updated appropriately. We can also use the commons-build POM dependencies section as the place where we maintain the list of required dependency versions. Unless someone sees a problem with this, I will go ahead and commit the change to the commons-build pom. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
