[EMAIL PROTECTED]: Project commons-launcher (in module jakarta-commons) 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-launcher has an issue affecting its community integration. This issue affects 3 projects. The current state of this project is 'Failed', with reason 'Missing Build Outputs'. For reference only, the following projects are affected by this: - commons-launcher : Jakarta commons - jakarta-tomcat-catalina : Servlet 2.4 Reference Implementation - jakarta-tomcat-jk : Connectors to various web servers Full details are available at: http://vmgump.apache.org/gump/public/jakarta-commons/commons-launcher/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-launcher.jar] identifier set to project name -DEBUG- Dependency on ant exists, no need to add for property ant.home. -INFO- Failed with reason missing build outputs -ERROR- Missing Output: /usr/local/gump/public/workspace/jakarta-commons/launcher/dist/bin/commons-launcher.jar -ERROR- See Directory Listing Work for Missing Outputs -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/jakarta-commons/commons-launcher/gump_work/build_jakarta-commons_commons-launcher.html Work Name: build_jakarta-commons_commons-launcher (Type: Build) Work ended in a state of : Success Elapsed: 13 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dant.home=/usr/local/gump/public/workspace/ant/dist dist [Working Directory: /usr/local/gump/public/workspace/jakarta-commons/launcher] CLASSPATH: /opt/jdk1.5/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/packages/junit3.8.1/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar - [javadoc] at com.sun.tools.doclets.formats.html.HtmlDocletWriter.printCommentTags(HtmlDocletWriter.java:1397) [javadoc] at com.sun.tools.doclets.formats.html.HtmlDocletWriter.printSummaryComment(HtmlDocletWriter.java:1370) [javadoc] at com.sun.tools.doclets.formats.html.HtmlDocletWriter.printSummaryComment(HtmlDocletWriter.java:1366) [javadoc] at com.sun.tools.doclets.formats.html.AbstractIndexWriter.printComment(AbstractIndexWriter.java:192) [javadoc] at com.sun.tools.doclets.formats.html.AbstractIndexWriter.printDescription(AbstractIndexWriter.java:126) [javadoc] at com.sun.tools.doclets.formats.html.AbstractIndexWriter.generateContents(AbstractIndexWriter.java:91) [javadoc] at com.sun.tools.doclets.formats.html.SingleIndexWriter.generateIndexFile(SingleIndexWriter.java:76) [javadoc] at com.sun.tools.doclets.formats.html.SingleIndexWriter.generate(SingleIndexWriter.java:52) [javadoc] at com.sun.tools.doclets.formats.html.HtmlDoclet.generateOtherFiles(HtmlDoclet.java:103) [javadoc] at com.sun.tools.doclets.internal.toolkit.AbstractDoclet.startGeneration(AbstractDoclet.java:122) [javadoc] at com.sun.tools.doclets.internal.toolkit.AbstractDoclet.start(AbstractDoclet.java:64) [javadoc] at com.sun.tools.doclets.formats.html.HtmlDoclet.start(HtmlDoclet.java:42) [javadoc] at com.sun.tools.doclets.standard.Standard.start(Standard.java:23) [javadoc] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [javadoc] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [javadoc] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [javadoc] at java.lang.reflect.Method.invoke(Method.java:585) [javadoc] at com.sun.tools.javadoc.DocletInvoker.invoke(DocletInvoker.java:269) [javadoc] at com.sun.tools.javadoc.DocletInvoker.start(DocletInvoker.java:143) [javadoc] at com.sun.tools.javadoc.Start.parseAndExecute(Start.java:340) [javadoc] at com.sun.tools.javadoc.Start.begin(Start.java:128) [javadoc] at com.sun.tools.javadoc.Main.execute
[EMAIL PROTECTED]: Project commons-launcher (in module jakarta-commons) 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-launcher has an issue affecting its community integration. This issue affects 3 projects. The current state of this project is 'Failed', with reason 'Missing Build Outputs'. For reference only, the following projects are affected by this: - commons-launcher : Jakarta commons - jakarta-tomcat-catalina : Servlet 2.4 Reference Implementation - jakarta-tomcat-jk : Connectors to various web servers Full details are available at: http://vmgump.apache.org/gump/public/jakarta-commons/commons-launcher/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-launcher.jar] identifier set to project name -DEBUG- Dependency on ant exists, no need to add for property ant.home. -INFO- Failed with reason missing build outputs -ERROR- Missing Output: /usr/local/gump/public/workspace/jakarta-commons/launcher/dist/bin/commons-launcher.jar -ERROR- See Directory Listing Work for Missing Outputs -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/jakarta-commons/commons-launcher/gump_work/build_jakarta-commons_commons-launcher.html Work Name: build_jakarta-commons_commons-launcher (Type: Build) Work ended in a state of : Success Elapsed: 13 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dant.home=/usr/local/gump/public/workspace/ant/dist dist [Working Directory: /usr/local/gump/public/workspace/jakarta-commons/launcher] CLASSPATH: /opt/jdk1.5/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/packages/junit3.8.1/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar - [javadoc] at com.sun.tools.doclets.formats.html.HtmlDocletWriter.printCommentTags(HtmlDocletWriter.java:1397) [javadoc] at com.sun.tools.doclets.formats.html.HtmlDocletWriter.printSummaryComment(HtmlDocletWriter.java:1370) [javadoc] at com.sun.tools.doclets.formats.html.HtmlDocletWriter.printSummaryComment(HtmlDocletWriter.java:1366) [javadoc] at com.sun.tools.doclets.formats.html.AbstractIndexWriter.printComment(AbstractIndexWriter.java:192) [javadoc] at com.sun.tools.doclets.formats.html.AbstractIndexWriter.printDescription(AbstractIndexWriter.java:126) [javadoc] at com.sun.tools.doclets.formats.html.AbstractIndexWriter.generateContents(AbstractIndexWriter.java:91) [javadoc] at com.sun.tools.doclets.formats.html.SingleIndexWriter.generateIndexFile(SingleIndexWriter.java:76) [javadoc] at com.sun.tools.doclets.formats.html.SingleIndexWriter.generate(SingleIndexWriter.java:52) [javadoc] at com.sun.tools.doclets.formats.html.HtmlDoclet.generateOtherFiles(HtmlDoclet.java:103) [javadoc] at com.sun.tools.doclets.internal.toolkit.AbstractDoclet.startGeneration(AbstractDoclet.java:122) [javadoc] at com.sun.tools.doclets.internal.toolkit.AbstractDoclet.start(AbstractDoclet.java:64) [javadoc] at com.sun.tools.doclets.formats.html.HtmlDoclet.start(HtmlDoclet.java:42) [javadoc] at com.sun.tools.doclets.standard.Standard.start(Standard.java:23) [javadoc] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [javadoc] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [javadoc] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [javadoc] at java.lang.reflect.Method.invoke(Method.java:585) [javadoc] at com.sun.tools.javadoc.DocletInvoker.invoke(DocletInvoker.java:269) [javadoc] at com.sun.tools.javadoc.DocletInvoker.start(DocletInvoker.java:143) [javadoc] at com.sun.tools.javadoc.Start.parseAndExecute(Start.java:340) [javadoc] at com.sun.tools.javadoc.Start.begin(Start.java:128) [javadoc] at com.sun.tools.javadoc.Main.execute
[jira] Commented: (LANG-316) Enable CaseInsensitivity in EqualsBuilder and HashCodeBuilder
[ https://issues.apache.org/jira/browse/LANG-316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12471170 ] Stephen Kestle commented on LANG-316: - No - someone really should read up on Collators etc before jumping into this. equalsIgnoreCase is an English/ASCII hack, and does not scale well. A solution should be append(Object lhs, Object rhs, Comparator c) PS. passing booleans around is not very nice, and also becomes problematic... > Enable CaseInsensitivity in EqualsBuilder and HashCodeBuilder > - > > Key: LANG-316 > URL: https://issues.apache.org/jira/browse/LANG-316 > Project: Commons Lang > Issue Type: New Feature >Affects Versions: 2.3 > Environment: Any >Reporter: Nelson Carpentier >Priority: Minor > Fix For: 3.0 > > Attachments: lang_20070206.diff > > > Sometimes I want a String property containing "ThisString" to be seen as > equal to "THISstring". EqualsBuilder (and HashCodeBuilder) should be > enhanced to optionally handle this requirement. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r504732 - /jakarta/commons/proper/lang/trunk/build.xml
Author: bayard Date: Wed Feb 7 15:19:35 2007 New Revision: 504732 URL: http://svn.apache.org/viewvc?view=rev&rev=504732 Log: And clean up so they don't end up in other things Modified: jakarta/commons/proper/lang/trunk/build.xml Modified: jakarta/commons/proper/lang/trunk/build.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/lang/trunk/build.xml?view=diff&rev=504732&r1=504731&r2=504732 == --- jakarta/commons/proper/lang/trunk/build.xml (original) +++ jakarta/commons/proper/lang/trunk/build.xml Wed Feb 7 15:19:35 2007 @@ -101,11 +101,13 @@ + + - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r504729 - /jakarta/commons/proper/lang/trunk/build.xml
Author: bayard Date: Wed Feb 7 15:09:31 2007 New Revision: 504729 URL: http://svn.apache.org/viewvc?view=rev&rev=504729 Log: Include the license/notice in the source/javadoc jars Modified: jakarta/commons/proper/lang/trunk/build.xml Modified: jakarta/commons/proper/lang/trunk/build.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/lang/trunk/build.xml?view=diff&rev=504729&r1=504728&r2=504729 == --- jakarta/commons/proper/lang/trunk/build.xml (original) +++ jakarta/commons/proper/lang/trunk/build.xml Wed Feb 7 15:09:31 2007 @@ -97,8 +97,14 @@ + + + + + + - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Lang 2.3 (RC2)
Lack of license/notice is a -1. *grumble at self* thought Lang had that already. *whines...are we ready for maven2 yet?* Hen On 2/7/07, Stephen Colebourne <[EMAIL PROTECTED]> wrote: Its at the RMs discretion as to whether he wants a new RC. James Carman wrote: > Is that a -1? > > On 2/7/07, Stephen Colebourne <[EMAIL PROTECTED]> wrote: >> >> Missing LICENSE and NOTICE in -sources.jar and -javadoc.jar. >> Missing pom.xml in src bundle. >> >> Stephen >> >> >> Henri Yandell wrote: >> > Here's the 2nd release candidate for Lang 2.3: >> > >> > http://people.apache.org/~bayard/commons-lang/commons-lang-2.3-rc2/ >> > >> > Clirr, Jardiff + Site included. >> > >> > [ ] +1 >> > [ ] -1 >> > >> > Vote to close on Saturday if it gets that far. >> > >> > >> > 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] >> >> > > - > 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: [VOTE] Lang 2.3 (RC2)
Its at the RMs discretion as to whether he wants a new RC. James Carman wrote: Is that a -1? On 2/7/07, Stephen Colebourne <[EMAIL PROTECTED]> wrote: Missing LICENSE and NOTICE in -sources.jar and -javadoc.jar. Missing pom.xml in src bundle. Stephen Henri Yandell wrote: > Here's the 2nd release candidate for Lang 2.3: > > http://people.apache.org/~bayard/commons-lang/commons-lang-2.3-rc2/ > > Clirr, Jardiff + Site included. > > [ ] +1 > [ ] -1 > > Vote to close on Saturday if it gets that far. > > > 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] - 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] Lang 2.3 (RC2)
Is that a -1? On 2/7/07, Stephen Colebourne <[EMAIL PROTECTED]> wrote: Missing LICENSE and NOTICE in -sources.jar and -javadoc.jar. Missing pom.xml in src bundle. Stephen Henri Yandell wrote: > Here's the 2nd release candidate for Lang 2.3: > > http://people.apache.org/~bayard/commons-lang/commons-lang-2.3-rc2/ > > Clirr, Jardiff + Site included. > > [ ] +1 > [ ] -1 > > Vote to close on Saturday if it gets that far. > > > 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] PassiveTimeOutMapDecorator
In my experience, you wouldn't want the map to return null if the time
has expired. You would want it to return a "refreshed" value. So,
you would want to have the user provide a RefreshProvider (or whatever
you want to call it):
public interface RefreshProvider
{
public Object getValueForKey( Object key );
}
That way, if the value is expired, it could check with the provider to
get a fresh copy of the value.
On 2/7/07, Stephen Colebourne <[EMAIL PROTECTED]> wrote:
This sounds a little too specific for me. I suspect that most people
that want an expiring map will want it to be active not passive.
Stephen
Elifarley wrote:
> I've developed a Map decorator which passively evicts expired entries once
their
> expiry time has been reached.
>
> When putting an item in the map, the decorator calls the 'expiryTime' method,
> passing the key and the value as parameters, and uses the returned value as
the
> expiry time for that entry.
>
> The default implementation of 'expiryTime' just assigns a time 60 seconds in
the
> future for every entry, but subclasses can provide their own policy.
>
> When getting the value for an entry, its expiry time is checked, and if its
> greater than the current time, the value is returned. Otherwise, the entry is
> removed from the decorated map, and null is returned.
> Doing so, there's no need to have a separate, active thread (hence the name
> 'passive') to check expiry times - the check is performed on demand.
>
> I've developed it for my own use, but maybe this could be useful to others
too.
>
> Any thoughts ?
>
> Regards,
> Elifarley
>
>
> -
> 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: [collections] PassiveTimeOutMapDecorator
This sounds a little too specific for me. I suspect that most people that want an expiring map will want it to be active not passive. Stephen Elifarley wrote: I've developed a Map decorator which passively evicts expired entries once their expiry time has been reached. When putting an item in the map, the decorator calls the 'expiryTime' method, passing the key and the value as parameters, and uses the returned value as the expiry time for that entry. The default implementation of 'expiryTime' just assigns a time 60 seconds in the future for every entry, but subclasses can provide their own policy. When getting the value for an entry, its expiry time is checked, and if its greater than the current time, the value is returned. Otherwise, the entry is removed from the decorated map, and null is returned. Doing so, there's no need to have a separate, active thread (hence the name 'passive') to check expiry times - the check is performed on demand. I've developed it for my own use, but maybe this could be useful to others too. Any thoughts ? Regards, Elifarley - 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: Release commons-fileupload 1.2 (3rd attempt)
LICENSE and NOTICE missing from -sources.jar and -javadoc.jar Website has lost a lot of stuff compared to existing website Stephen Jochen Wiedmann wrote: On 2/7/07, Oliver Heger <[EMAIL PROTECTED]> wrote: Hm, I probably did not follow this thread in the past, so can you please point me to where I find the files of this rc? Awfully sorry, and thanks for asking. The files are available from http://people.apache.org/~jochen/commons-fileupload/dist/ A file rat.txt (RAT report) is included. The proposed site is at http://people.apache.org/~jochen/commons-fileupload/site/ Clirr and checkstyle reports are included in the site. Jochen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Lang 2.3 (RC2)
Missing LICENSE and NOTICE in -sources.jar and -javadoc.jar. Missing pom.xml in src bundle. Stephen Henri Yandell wrote: Here's the 2nd release candidate for Lang 2.3: http://people.apache.org/~bayard/commons-lang/commons-lang-2.3-rc2/ Clirr, Jardiff + Site included. [ ] +1 [ ] -1 Vote to close on Saturday if it gets that far. 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]
[jira] Commented: (IO-113) FileUtils.readFileToString is not static
[ https://issues.apache.org/jira/browse/IO-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12471121 ] Raul Acevedo commented on IO-113: - I would fix it in 1.3.1 with a binary incompatible change. One time pain for long term gain... It's really nice that all the methods are sensibly and compatibly named. However, it's easy for me to say, I'll go with whatever the wider community supports, especially those who are more aware of the impacts of a binary incompatible change. > FileUtils.readFileToString is not static > > > Key: IO-113 > URL: https://issues.apache.org/jira/browse/IO-113 > Project: Commons IO > Issue Type: Bug > Components: Utilities >Affects Versions: 1.3 >Reporter: Raul Acevedo > Fix For: 1.4 > > > FileUtils.readFileToString isn't static. It should be; since the constructor > for FileUtils says "Instances should NOT be constructed in standard > programming", this makes readFileToString unusable. Right now I'm using > FileUtils.readBytesToByteArray(file).toString(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r504710 - /jakarta/commons/proper/commons-parent/trunk/src/site/site.xml
Author: dennisl Date: Wed Feb 7 14:00:15 2007 New Revision: 504710 URL: http://svn.apache.org/viewvc?view=rev&rev=504710 Log: Use the released version of commons-skin. Modified: jakarta/commons/proper/commons-parent/trunk/src/site/site.xml Modified: jakarta/commons/proper/commons-parent/trunk/src/site/site.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/commons-parent/trunk/src/site/site.xml?view=diff&rev=504710&r1=504709&r2=504710 == --- jakarta/commons/proper/commons-parent/trunk/src/site/site.xml (original) +++ jakarta/commons/proper/commons-parent/trunk/src/site/site.xml Wed Feb 7 14:00:15 2007 @@ -15,7 +15,7 @@ org.apache.commons commons-skin -1.0-SNAPSHOT +1.0 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (IO-113) FileUtils.readFileToString is not static
[ https://issues.apache.org/jira/browse/IO-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12471117 ] Stephen Colebourne commented on IO-113: --- Problem is that the fix is binary incompatible :-( It is source compatible though. Two choices: a) use a different method name b) produce 1.3.1 now with the binary incompatible change as 1.3 was only just completed > FileUtils.readFileToString is not static > > > Key: IO-113 > URL: https://issues.apache.org/jira/browse/IO-113 > Project: Commons IO > Issue Type: Bug > Components: Utilities >Affects Versions: 1.3 >Reporter: Raul Acevedo > Fix For: 1.4 > > > FileUtils.readFileToString isn't static. It should be; since the constructor > for FileUtils says "Instances should NOT be constructed in standard > programming", this makes readFileToString unusable. Right now I'm using > FileUtils.readBytesToByteArray(file).toString(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VOTE: Release commons-fileupload 1.2 (3rd attempt)
On 2/7/07, Oliver Heger <[EMAIL PROTECTED]> wrote: Hm, I probably did not follow this thread in the past, so can you please point me to where I find the files of this rc? Awfully sorry, and thanks for asking. The files are available from http://people.apache.org/~jochen/commons-fileupload/dist/ A file rat.txt (RAT report) is included. The proposed site is at http://people.apache.org/~jochen/commons-fileupload/site/ Clirr and checkstyle reports are included in the site. Jochen -- How fast can a year go? As fast as your childs first year. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Lang 2.3 (RC2)
Not intended, but probably not a blocker. Hen On 2/7/07, Oliver Heger <[EMAIL PROTECTED]> wrote: +1, looks good to me. Only thing I noticed is that the maven 2 pom is not contained in the source distribution. Is this intended? Oliver Henri Yandell wrote: > Here's the 2nd release candidate for Lang 2.3: > > http://people.apache.org/~bayard/commons-lang/commons-lang-2.3-rc2/ > > Clirr, Jardiff + Site included. > > [ ] +1 > [ ] -1 > > Vote to close on Saturday if it gets that far. > > > 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r504696 - /jakarta/commons/proper/configuration/trunk/xdocs/howto_configurationbuilder.xml
Author: brett Date: Wed Feb 7 13:21:19 2007 New Revision: 504696 URL: http://svn.apache.org/viewvc?view=rev&rev=504696 Log: fix typo Modified: jakarta/commons/proper/configuration/trunk/xdocs/howto_configurationbuilder.xml Modified: jakarta/commons/proper/configuration/trunk/xdocs/howto_configurationbuilder.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/configuration/trunk/xdocs/howto_configurationbuilder.xml?view=diff&rev=504696&r1=504695&r2=504696 == --- jakarta/commons/proper/configuration/trunk/xdocs/howto_configurationbuilder.xml (original) +++ jakarta/commons/proper/configuration/trunk/xdocs/howto_configurationbuilder.xml Wed Feb 7 13:21:19 2007 @@ -388,7 +388,7 @@ CombinedConfiguration cc = builder.getConfiguration(true); ]]> - It would have been possible to specifiy the location of the configuration + It would have been possible to specify the location of the configuration definition file in multiple other ways, e.g. as a URL. The boolean argument in the call to getConfiguration() determines whether the configuration definition file should be loaded. For our simple example we @@ -520,4 +520,4 @@ - \ No newline at end of file + - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VOTE: Release commons-fileupload 1.2 (3rd attempt)
Hm, I probably did not follow this thread in the past, so can you please point me to where I find the files of this rc? Thanks Oliver Jochen Wiedmann wrote: Hi, I have prepared commons-fileupload-1.2rc3. Compared to 1.2rc2, the following changes have been made: - The sources are now available as tar.gz and .zip file. - The build has been made with JDK 1.5.0_11, rather than 1.6.0rc1. Please note, that this release (like all releases) requires, in particular, 3 positive votes from PMC members. Thanks, Jochen [ ] +1 [ ] =0 [ ] -1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Lang 2.3 (RC2)
+1, looks good to me. Only thing I noticed is that the maven 2 pom is not contained in the source distribution. Is this intended? Oliver Henri Yandell wrote: Here's the 2nd release candidate for Lang 2.3: http://people.apache.org/~bayard/commons-lang/commons-lang-2.3-rc2/ Clirr, Jardiff + Site included. [ ] +1 [ ] -1 Vote to close on Saturday if it gets that far. 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: [all] RCs and version numbers
On 2/7/07, Phil Steitz <[EMAIL PROTECTED]> wrote: On 2/6/07, Henri Yandell <[EMAIL PROTECTED]> wrote: > > 2) Create the release and have it be voted on. The version number of > the source is 1.4, the svn tag is 1.4-rc1, the 1.4 files are put in a > 1.4-rc1 directory on your ~foo/ account. It's intended to let us vote > on the actual release and not to be used in production. (snip) Could be this is the direction that we need to go for the heavily reused components. I cut an RC1 for [dbcp] a couple of weeks ago and published the RC1 snap to the snapshot repo so people could download and test. I was afraid to do what I would have liked to - make it a "public" RC as we used to do, announcing it on tomcat-user, Jakarta general, etc, but I really think that is the right way to go. Testing RCs is an important part of getting to GA, IMHO and if it offends the gods to put RCs out for general consumption, then I think we need to move to the initial release, GA labelling. I don't like the idea of having people download and test *different* jars with the same names / artifact ids and I don't like releasing components that have not been tested. Yeah, the IO release in which a user has just reported that one of the methods wasn't static is an example of something that would lead to needing another release and wanting to have had that be something less definitive as a release. Perhaps its the terminology. What you're describing is an alpha/beta to me. We have two levels of quality: 1) Design/code quality. 2) Release quality. The first is alpha/beta/final, though putting final in the version name always seems lame. The second is whether the release was correctly built. So I'd envisage calling a vote on: dbcp-1.2.2-alpha-rc1/dbcp-1.2.2-alpha.jar This is what Struts et al mean when they do their GA stuff (I think) - except that they found that they got more people looking at something if they do: 1.2.2 and then 1.2.2-GA, than if they do: 1.2.2-alpha and then 1.2.2. Which I think is just gaming the users. The problem with the release-then-fix approach is it leads to lots of dot-different release jars out in production use, some of them potentially bugged, and I don't see that as good in a mavenized world or for heavily reused libraries in general. It works OK for "top predators" like Struts, Tomcat, HTTPd, but could get dicey lower down in the food chain, IMHO. I could be cracked here - pls let me know if I am the only one thinking this way. I think it's a problem, but it's no different in the alternative world. httpclient-rc3 was in many many production environments. I'm strongly in favour of 2). It's safer and it makes the release > easier. The only negatives are: > > 1) There's a chance that someone might take a jar from the rc1/ > directory in ~bayard and charge off to use it. So be it - that's there > risk. > > 2) I don't like leaving svn in a state of having a release version, so > I roll the version back from 1.4 to 1.4-SNAPSHOT after doing the > release. An alternative might be to branch 1.4 off for the release and > have a 1.4-release branch for preparing the release on, but that a) > still makes me uncomfortable to have a release version in and b) will > be messy having one of those for every release. If we have to do things this way, I would use a release branch, but I still don't yet see the compelling need to reverse history - i.e., what problem exactly are we needing to solve here? If the reverse history bit means the rolling back - I don't like to ever have release versions in a trunk or branch. Too easy for mistakes to happen. What exactly is illegal about publishing release candidates and having people test them? We publish nightlies now and the "RC" designation, which is clear and in all of the names, tells users that the artifacts are not yet official releases. I am not trying to be difficult here, just want to understand what the issue is. As I understand it from Roy's view on a long thread on infra list: ["UH WHAT? www.apache.org/dist? YOU MUST BE JOKING, RIGHT?" thread - for some reason infrastructure@ isn't archived so I can't link to it. As you'll see in the thread, I was 'somewhat' -1 and I suspect I'm not an efficient messenger for the message] Nightly - Tests the build system. Intended for the development community. Not advertised. Releases - Actual release voted on by PMC. Advertised. A not-voted on release is a contradiction in those terms. So we can have an rc that is mentioned to the development community and not the general public and people can look at it - but it definitely hasn't been released. I think the -user@ list is part of the development community, so I think this just means not putting it on the distribution mechanisms (maven central repo, www.apache.org/dist) or the website. If we use RC to mean this, then I think we should use something else for the 'getting the release itself right' as opposed to the code. -- As a parallel to the "Wha
[VOTE] Release Commons Configuration 1.4 based on RC1
The files of the first release candidate for Configuration 1.4, including the site and a Clirr report, are available for inspection at http://people.apache.org/~oheger/commons-configuration-1.4rc1/ [ ] +1 Go ahead and release it [ ] -1 Don't release it because... Vote will close on Saturday night (CET). Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] RCs and version numbers
Phil Steitz wrote: On 2/6/07, Henri Yandell <[EMAIL PROTECTED]> wrote: On 2/5/07, Oliver Heger <[EMAIL PROTECTED]> wrote: > Hi all, > > I am just in the progress of preparing the first RC for the Commons > Configuration 1.4 release, but I am unsure about the version number to > choose. As I understand it, before the vote is called the number has to > be set to the final version of this release, i.e. 1.4 in my case. > > But before the vote, should the version number be 1.4-rc1? I think this > would make sense, especially if this version is to hang around for a > week or two giving users opportunity to test it and report issues they find. > > Is this the correct way to proceed? We have two ways: 1) Do a mock release called 1.4-rc1. The version number of the source is 1.4-rc1, it's tagged 1.4-rc1 etc. It can hang around for ages and go into production if a user happens to find it and take it there. What we are voting on is the release manager and not the release. I believe I'm right in saying that this is becoming frowned on at the ASF - but it might just be loud views from a minority - the central release faq (http://www.apache.org/dev/release.html) doesn't mention it yet. 2) Create the release and have it be voted on. The version number of the source is 1.4, the svn tag is 1.4-rc1, the 1.4 files are put in a 1.4-rc1 directory on your ~foo/ account. It's intended to let us vote on the actual release and not to be used in production. I don't know of Commons components (beside httpclient who have been a separate community for a long time) who have intended rc1's etc to be used by users. There's a definite problem with an rc1 being used by users - if we tell users to use it then it becomes a release and if we've not voted on releasing it then it can't be a release (see release faq). It's better to just do the release and then release a bugfix if people have problems. Some projects have a GA label they apply after a release lasts a while without having a lot of bugs applied to it, but I don't see the point of that, and especially don't see the point of that for the size of our components. Could be this is the direction that we need to go for the heavily reused components. I cut an RC1 for [dbcp] a couple of weeks ago and published the RC1 snap to the snapshot repo so people could download and test. I was afraid to do what I would have liked to - make it a "public" RC as we used to do, announcing it on tomcat-user, Jakarta general, etc, but I really think that is the right way to go. Testing RCs is an important part of getting to GA, IMHO and if it offends the gods to put RCs out for general consumption, then I think we need to move to the initial release, GA labelling. I don't like the idea of having people download and test *different* jars with the same names / artifact ids and I don't like releasing components that have not been tested. The problem with the release-then-fix approach is it leads to lots of dot-different release jars out in production use, some of them potentially bugged, and I don't see that as good in a mavenized world or for heavily reused libraries in general. It works OK for "top predators" like Struts, Tomcat, HTTPd, but could get dicey lower down in the food chain, IMHO. I could be cracked here - pls let me know if I am the only one thinking this way. I'm strongly in favour of 2). It's safer and it makes the release easier. The only negatives are: 1) There's a chance that someone might take a jar from the rc1/ directory in ~bayard and charge off to use it. So be it - that's there risk. 2) I don't like leaving svn in a state of having a release version, so I roll the version back from 1.4 to 1.4-SNAPSHOT after doing the release. An alternative might be to branch 1.4 off for the release and have a 1.4-release branch for preparing the release on, but that a) still makes me uncomfortable to have a release version in and b) will be messy having one of those for every release. If we have to do things this way, I would use a release branch, but I still don't yet see the compelling need to reverse history - i.e., what problem exactly are we needing to solve here? What exactly is illegal about publishing release candidates and having people test them? We publish nightlies now and the "RC" designation, which is clear and in all of the names, tells users that the artifacts are not yet official releases. I am not trying to be difficult here, just want to understand what the issue is. Phil Thanks for all the replies. I went for option 2) mentioned above because this seems to be the recommended way ATM (and probably more convenient, too). However I agree with Phil in most of his points. Having a jar labeled as the release version floating around, which is not the real release, seems to be dangerous. Further I still think that an official announced RC is a good way of getting users to test the code. Many users hesitate to use nightly builds. But a RC suggests that
[jira] Updated: (EMAIL-62) Ant patch to enforce source 1.4 and target 1.4 when compiling
[ https://issues.apache.org/jira/browse/EMAIL-62?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben Speakmon updated EMAIL-62: -- Attachment: build.xml.patch > Ant patch to enforce source 1.4 and target 1.4 when compiling > - > > Key: EMAIL-62 > URL: https://issues.apache.org/jira/browse/EMAIL-62 > Project: Commons Email > Issue Type: Bug >Affects Versions: 1.1 >Reporter: Ben Speakmon > Fix For: 1.1 > > Attachments: build.xml.patch > > > Suppresses spurious 1.5 type safety warnings when building commons-email on > JDK >= 1.5. Attaching patch shortly... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (EMAIL-62) Ant patch to enforce source 1.4 and target 1.4 when compiling
Ant patch to enforce source 1.4 and target 1.4 when compiling - Key: EMAIL-62 URL: https://issues.apache.org/jira/browse/EMAIL-62 Project: Commons Email Issue Type: Bug Affects Versions: 1.1 Reporter: Ben Speakmon Fix For: 1.1 Attachments: build.xml.patch Suppresses spurious 1.5 type safety warnings when building commons-email on JDK >= 1.5. Attaching patch shortly... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r504681 - in /jakarta/commons/proper/configuration/trunk: default.properties pom.xml project.xml
Author: oheger
Date: Wed Feb 7 12:40:33 2007
New Revision: 504681
URL: http://svn.apache.org/viewvc?view=rev&rev=504681
Log:
Rolling back version numbers to 1.4-SNAPSHOT until the final release
Modified:
jakarta/commons/proper/configuration/trunk/default.properties
jakarta/commons/proper/configuration/trunk/pom.xml
jakarta/commons/proper/configuration/trunk/project.xml
Modified: jakarta/commons/proper/configuration/trunk/default.properties
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/configuration/trunk/default.properties?view=diff&rev=504681&r1=504680&r2=504681
==
--- jakarta/commons/proper/configuration/trunk/default.properties (original)
+++ jakarta/commons/proper/configuration/trunk/default.properties Wed Feb 7
12:40:33 2007
@@ -27,7 +27,7 @@
component.title = Configuration Utilities
# The current version number of this component
-component.version = 1.4
+component.version = 1.4-SNAPSHOT
# The name that is used to create the jar file
final.name = ${component.name}-${component.version}
Modified: jakarta/commons/proper/configuration/trunk/pom.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/configuration/trunk/pom.xml?view=diff&rev=504681&r1=504680&r2=504681
==
--- jakarta/commons/proper/configuration/trunk/pom.xml (original)
+++ jakarta/commons/proper/configuration/trunk/pom.xml Wed Feb 7 12:40:33 2007
@@ -30,7 +30,7 @@
4.0.0
commons-configuration
commons-configuration
- 1.4
+ 1.4-SNAPSHOT
Commons Configuration
2001
Modified: jakarta/commons/proper/configuration/trunk/project.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/configuration/trunk/project.xml?view=diff&rev=504681&r1=504680&r2=504681
==
--- jakarta/commons/proper/configuration/trunk/project.xml (original)
+++ jakarta/commons/proper/configuration/trunk/project.xml Wed Feb 7 12:40:33
2007
@@ -24,7 +24,7 @@
commons-configuration
commons-configuration
- 1.4
+ 1.4-SNAPSHOT
2001
Commons Configuration
Common Configuration
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 2 (WAS: [VOTE] commons-fileupload 1.2 (rc2))
Jörg Schaible wrote: Hi Dennis, Dennis Lundberg wrote: Henri Yandell wrote: On 2/5/07, Jörg Schaible <[EMAIL PROTECTED]> wrote: Hi Jochen, Jochen Wiedmann wrote on Monday, February 05, 2007 9:03 AM: I'm thinking: * Change group id? Couldn't we do that *after* the release, please? I would clearly prefer *not* to introduce any incompatible changes in that stage. +1 from my personal experience with a different project all I can say is that changing the groupId is a task that is not very well supported by M2. The available docs are spare, do not work as they are described or are out of date. So changing the groupId is a task that should be done for a reference project that volunteers to go through all the hassle with a direct helping hand from some Maven folks. I put together this document when I was trying to pull through the whole groupId change last time: http://maven.apache.org/guides/mini/guide-relocation.html There is never a good time to change the groupId. My view is that we should do it when we move to M2, both as a build tool and as the target repository. Yes, I tried to use this description for a M1 -> M2 situation. In the end Carlos' advice was to ignore all the old versions and simply start with the new M2 releases also to use the new groupId and add for those releases only a relocation POM. That is a much easier way to do it. I'm starting to think that this is the way to go for Commons. Just change the groupId when we release with M2 and don't relocate older versions. The problem with adjusting the old releases is, that the location for the relocation POMs is already occupied by the automatically generated POMs for M2 on the global M2 repo (see http://mirrors.ibiblio.org/pub/mirrors/maven2/commons-logging/commons-logging/1.1/). And since they're already published, they cannot be changed anymore. I think you are allowed to add a relocation section to an already published pom. I vaguely remember discussing this with Carlos back then. [snip] - Jörg -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r504679 - /jakarta/commons/proper/configuration/tags/CONFIGURATION_1_4RC1/
Author: oheger Date: Wed Feb 7 12:36:35 2007 New Revision: 504679 URL: http://svn.apache.org/viewvc?view=rev&rev=504679 Log: Tagging 1.4rc1 Added: jakarta/commons/proper/configuration/tags/CONFIGURATION_1_4RC1/ - copied from r504678, jakarta/commons/proper/configuration/trunk/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r504677 - in /jakarta/commons/proper/configuration/trunk: default.properties maven.xml pom.xml project.xml xdocs/changes.xml
Author: oheger
Date: Wed Feb 7 12:31:14 2007
New Revision: 504677
URL: http://svn.apache.org/viewvc?view=rev&rev=504677
Log:
Setting version number to 1.4 for opening the release vote
Modified:
jakarta/commons/proper/configuration/trunk/default.properties
jakarta/commons/proper/configuration/trunk/maven.xml
jakarta/commons/proper/configuration/trunk/pom.xml
jakarta/commons/proper/configuration/trunk/project.xml
jakarta/commons/proper/configuration/trunk/xdocs/changes.xml
Modified: jakarta/commons/proper/configuration/trunk/default.properties
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/configuration/trunk/default.properties?view=diff&rev=504677&r1=504676&r2=504677
==
--- jakarta/commons/proper/configuration/trunk/default.properties (original)
+++ jakarta/commons/proper/configuration/trunk/default.properties Wed Feb 7
12:31:14 2007
@@ -27,7 +27,7 @@
component.title = Configuration Utilities
# The current version number of this component
-component.version = 1.4-dev
+component.version = 1.4
# The name that is used to create the jar file
final.name = ${component.name}-${component.version}
Modified: jakarta/commons/proper/configuration/trunk/maven.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/configuration/trunk/maven.xml?view=diff&rev=504677&r1=504676&r2=504677
==
--- jakarta/commons/proper/configuration/trunk/maven.xml (original)
+++ jakarta/commons/proper/configuration/trunk/maven.xml Wed Feb 7 12:31:14
2007
@@ -44,6 +44,7 @@
+
Modified: jakarta/commons/proper/configuration/trunk/pom.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/configuration/trunk/pom.xml?view=diff&rev=504677&r1=504676&r2=504677
==
--- jakarta/commons/proper/configuration/trunk/pom.xml (original)
+++ jakarta/commons/proper/configuration/trunk/pom.xml Wed Feb 7 12:31:14 2007
@@ -30,7 +30,7 @@
4.0.0
commons-configuration
commons-configuration
- 1.4-SNAPSHOT
+ 1.4
Commons Configuration
2001
Modified: jakarta/commons/proper/configuration/trunk/project.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/configuration/trunk/project.xml?view=diff&rev=504677&r1=504676&r2=504677
==
--- jakarta/commons/proper/configuration/trunk/project.xml (original)
+++ jakarta/commons/proper/configuration/trunk/project.xml Wed Feb 7 12:31:14
2007
@@ -24,7 +24,7 @@
commons-configuration
commons-configuration
- 1.4-SNAPSHOT
+ 1.4
2001
Commons Configuration
Common Configuration
Modified: jakarta/commons/proper/configuration/trunk/xdocs/changes.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/configuration/trunk/xdocs/changes.xml?view=diff&rev=504677&r1=504676&r2=504677
==
--- jakarta/commons/proper/configuration/trunk/xdocs/changes.xml (original)
+++ jakarta/commons/proper/configuration/trunk/xdocs/changes.xml Wed Feb 7
12:31:14 2007
@@ -22,7 +22,7 @@
-
+
The dependencies to Commons Collections and Commons Digester are
updated to use the recent available version. However older versions
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] RCs and version numbers
On 2/6/07, Henri Yandell <[EMAIL PROTECTED]> wrote: On 2/5/07, Oliver Heger <[EMAIL PROTECTED]> wrote: > Hi all, > > I am just in the progress of preparing the first RC for the Commons > Configuration 1.4 release, but I am unsure about the version number to > choose. As I understand it, before the vote is called the number has to > be set to the final version of this release, i.e. 1.4 in my case. > > But before the vote, should the version number be 1.4-rc1? I think this > would make sense, especially if this version is to hang around for a > week or two giving users opportunity to test it and report issues they find. > > Is this the correct way to proceed? We have two ways: 1) Do a mock release called 1.4-rc1. The version number of the source is 1.4-rc1, it's tagged 1.4-rc1 etc. It can hang around for ages and go into production if a user happens to find it and take it there. What we are voting on is the release manager and not the release. I believe I'm right in saying that this is becoming frowned on at the ASF - but it might just be loud views from a minority - the central release faq (http://www.apache.org/dev/release.html) doesn't mention it yet. 2) Create the release and have it be voted on. The version number of the source is 1.4, the svn tag is 1.4-rc1, the 1.4 files are put in a 1.4-rc1 directory on your ~foo/ account. It's intended to let us vote on the actual release and not to be used in production. I don't know of Commons components (beside httpclient who have been a separate community for a long time) who have intended rc1's etc to be used by users. There's a definite problem with an rc1 being used by users - if we tell users to use it then it becomes a release and if we've not voted on releasing it then it can't be a release (see release faq). It's better to just do the release and then release a bugfix if people have problems. Some projects have a GA label they apply after a release lasts a while without having a lot of bugs applied to it, but I don't see the point of that, and especially don't see the point of that for the size of our components. Could be this is the direction that we need to go for the heavily reused components. I cut an RC1 for [dbcp] a couple of weeks ago and published the RC1 snap to the snapshot repo so people could download and test. I was afraid to do what I would have liked to - make it a "public" RC as we used to do, announcing it on tomcat-user, Jakarta general, etc, but I really think that is the right way to go. Testing RCs is an important part of getting to GA, IMHO and if it offends the gods to put RCs out for general consumption, then I think we need to move to the initial release, GA labelling. I don't like the idea of having people download and test *different* jars with the same names / artifact ids and I don't like releasing components that have not been tested. The problem with the release-then-fix approach is it leads to lots of dot-different release jars out in production use, some of them potentially bugged, and I don't see that as good in a mavenized world or for heavily reused libraries in general. It works OK for "top predators" like Struts, Tomcat, HTTPd, but could get dicey lower down in the food chain, IMHO. I could be cracked here - pls let me know if I am the only one thinking this way. I'm strongly in favour of 2). It's safer and it makes the release easier. The only negatives are: 1) There's a chance that someone might take a jar from the rc1/ directory in ~bayard and charge off to use it. So be it - that's there risk. 2) I don't like leaving svn in a state of having a release version, so I roll the version back from 1.4 to 1.4-SNAPSHOT after doing the release. An alternative might be to branch 1.4 off for the release and have a 1.4-release branch for preparing the release on, but that a) still makes me uncomfortable to have a release version in and b) will be messy having one of those for every release. If we have to do things this way, I would use a release branch, but I still don't yet see the compelling need to reverse history - i.e., what problem exactly are we needing to solve here? What exactly is illegal about publishing release candidates and having people test them? We publish nightlies now and the "RC" designation, which is clear and in all of the names, tells users that the artifacts are not yet official releases. I am not trying to be difficult here, just want to understand what the issue is. Phil
[jira] Commented: (IO-113) FileUtils.readFileToString is not static
[ https://issues.apache.org/jira/browse/IO-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12471077 ] Raul Acevedo commented on IO-113: - :) No worries, I'm just surprised someone didn't catch this earlier. Thanks! > FileUtils.readFileToString is not static > > > Key: IO-113 > URL: https://issues.apache.org/jira/browse/IO-113 > Project: Commons IO > Issue Type: Bug > Components: Utilities >Affects Versions: 1.3 >Reporter: Raul Acevedo > Fix For: 1.4 > > > FileUtils.readFileToString isn't static. It should be; since the constructor > for FileUtils says "Instances should NOT be constructed in standard > programming", this makes readFileToString unusable. Right now I'm using > FileUtils.readBytesToByteArray(file).toString(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (IO-113) FileUtils.readFileToString is not static
[ https://issues.apache.org/jira/browse/IO-113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell closed IO-113. Resolution: Fixed I'm a moron - thanks for reporting this Raul. svn ci -m "IO-113 points out that readFileToString(File) was not static. *hits self*" src/ Sendingsrc/java/org/apache/commons/io/FileUtils.java Transmitting file data . Committed revision 504659. > FileUtils.readFileToString is not static > > > Key: IO-113 > URL: https://issues.apache.org/jira/browse/IO-113 > Project: Commons IO > Issue Type: Bug > Components: Utilities >Affects Versions: 1.3 >Reporter: Raul Acevedo > Fix For: 1.4 > > > FileUtils.readFileToString isn't static. It should be; since the constructor > for FileUtils says "Instances should NOT be constructed in standard > programming", this makes readFileToString unusable. Right now I'm using > FileUtils.readBytesToByteArray(file).toString(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r504659 - /jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileUtils.java
Author: bayard
Date: Wed Feb 7 11:37:06 2007
New Revision: 504659
URL: http://svn.apache.org/viewvc?view=rev&rev=504659
Log:
IO-113 points out that readFileToString(File) was not static. *hits self*
Modified:
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileUtils.java
Modified:
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileUtils.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileUtils.java?view=diff&rev=504659&r1=504658&r2=504659
==
---
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileUtils.java
(original)
+++
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileUtils.java
Wed Feb 7 11:37:06 2007
@@ -975,7 +975,7 @@
* @throws IOException in case of an I/O error
* @since Commons IO 1.3
*/
-public String readFileToString(File file) throws IOException {
+public static String readFileToString(File file) throws IOException {
return readFileToString(file, null);
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (IO-113) FileUtils.readFileToString is not static
FileUtils.readFileToString is not static Key: IO-113 URL: https://issues.apache.org/jira/browse/IO-113 Project: Commons IO Issue Type: Bug Components: Utilities Affects Versions: 1.3 Reporter: Raul Acevedo Fix For: 1.4 FileUtils.readFileToString isn't static. It should be; since the constructor for FileUtils says "Instances should NOT be constructed in standard programming", this makes readFileToString unusable. Right now I'm using FileUtils.readBytesToByteArray(file).toString(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Status of components
On 2/7/07, Niall Pemberton <[EMAIL PROTECTED]> wrote: On 2/7/07, Craig McClanahan <[EMAIL PROTECTED]> wrote: > > Digester - ?? > > > Recently had a 1.8 release to clean up memory leaks and a few other bugs. > For a 1.x release it seems like you could call it stable. But the > architectural approach (including its dependence on the six year old > BeanUtils architecture) could certainly use a remodel. Do you have a suggestion/idea on what you would replace BeanUtils with? I'm biased by my own experience, of course :-), but any implementation of an expression language has to solve the same set of problems that BeanUtils solves, plus a whole lot more. Coupled with the fact that the JSP/JSF expression language APIs are being split out into a separate spec so you could have implementations of it that have nothing to do with the web tier, if I were building Digester today I would likely think about mapping the property setter type rules to EL evaluations. (Of course, because we're dealing with XML directly here, XPath expressions might be another choice ... but they will be less familiar to Java developers.) Craig
[EMAIL PROTECTED]: Project commons-jelly-tags-fmt-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-fmt-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 17 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-fmt-test : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-fmt-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/fmt/build.properties] -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/target/test-reports The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-fmt-test/gump_work/build_commons-jelly_commons-jelly-tags-fmt-test.html Work Name: build_commons-jelly_commons-jelly-tags-fmt-test (Type: Build) Work ended in a state of : Failed Elapsed: 18 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt] CLASSPATH: /opt/jdk1.5/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/packages/bsh-2.0b4/bsh-commands-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-classpath-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-core-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-bsf-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-reflect-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-util-2.0b4.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-07022007.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-07022007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-07022007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/beanshell/target/commons-jelly-tags-beanshell-07022007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-07022007.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-07022007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-07022007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-07022007.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-07022007.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/target/commons-jelly-tags-fmt-07022007.jar - [junit] at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) [junit] at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) [junit] at java.net.URLClassLoader.access$100(URLClassLoader.java:56) [junit] at java.net.URLClassLoader$1.run(URLClassLoader.java:195) [junit] at java.security.AccessController.doPrivileged(Native Method) [junit] at java.net.URLClassLoader.findClass(URLClassLoader.java:188) [junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:306) [junit] at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268) [junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:251) [junit] at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) [junit] at org.apache.commons.jelly.tags.ant.AntTagLibrary.createProject(AntTagLibrary.java:128) [ju
[EMAIL PROTECTED]: Project commons-jelly-tags-fmt-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-fmt-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 17 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-fmt-test : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-fmt-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/fmt/build.properties] -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/target/test-reports The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-fmt-test/gump_work/build_commons-jelly_commons-jelly-tags-fmt-test.html Work Name: build_commons-jelly_commons-jelly-tags-fmt-test (Type: Build) Work ended in a state of : Failed Elapsed: 18 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt] CLASSPATH: /opt/jdk1.5/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/packages/bsh-2.0b4/bsh-commands-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-classpath-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-core-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-bsf-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-reflect-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-util-2.0b4.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-07022007.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-07022007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-07022007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/beanshell/target/commons-jelly-tags-beanshell-07022007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-07022007.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-07022007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-07022007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-07022007.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-07022007.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/target/commons-jelly-tags-fmt-07022007.jar - [junit] at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) [junit] at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) [junit] at java.net.URLClassLoader.access$100(URLClassLoader.java:56) [junit] at java.net.URLClassLoader$1.run(URLClassLoader.java:195) [junit] at java.security.AccessController.doPrivileged(Native Method) [junit] at java.net.URLClassLoader.findClass(URLClassLoader.java:188) [junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:306) [junit] at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268) [junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:251) [junit] at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) [junit] at org.apache.commons.jelly.tags.ant.AntTagLibrary.createProject(AntTagLibrary.java:128) [ju
[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 17 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: 26 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl] CLASSPATH: /opt/jdk1.5/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/commons-cli-1.0.x/target/commons-cli-07022007.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-07022007.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-07022007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-07022007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-07022007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-07022007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-07022007.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-07022007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-07022007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-07022007.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-07022007.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar - [junit] at org.apache.commons.jelly.tags.junit.AssertTagSupport.fail(AssertTagSupport.java:64) [junit] at org.apache.commons.jelly.tags.junit.AssertTag.doTag(AssertTag.java:59) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:263) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:96) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:187) [junit] at org.apache.commons.jelly.impl.StaticTag.doTag(StaticTag.java:66) [junit] at org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:113) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:96) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:187) [junit] at org.apache.commons.jelly.tags.jsl.TemplateTag$1.run(TemplateTag.java:161) [junit] at org.dom4j.rule.Mode.fireRule(Mode.java:59) [junit] at org.dom4j.rule.Mode.applyTemplates(Mode.java:80) [junit] at org.dom4j.rule.RuleManager$1.run(RuleManager.java:171) [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 17 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: 26 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl] CLASSPATH: /opt/jdk1.5/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/commons-cli-1.0.x/target/commons-cli-07022007.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-07022007.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-07022007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-07022007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-07022007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-07022007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-07022007.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-07022007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-07022007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-07022007.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-07022007.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar - [junit] at org.apache.commons.jelly.tags.junit.AssertTagSupport.fail(AssertTagSupport.java:64) [junit] at org.apache.commons.jelly.tags.junit.AssertTag.doTag(AssertTag.java:59) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:263) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:96) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:187) [junit] at org.apache.commons.jelly.impl.StaticTag.doTag(StaticTag.java:66) [junit] at org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:113) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:96) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:187) [junit] at org.apache.commons.jelly.tags.jsl.TemplateTag$1.run(TemplateTag.java:161) [junit] at org.dom4j.rule.Mode.fireRule(Mode.java:59) [junit] at org.dom4j.rule.Mode.applyTemplates(Mode.java:80) [junit] at org.dom4j.rule.RuleManager$1.run(RuleManager.java:171) [junit] at
Re: [all] Status of components
On 2/7/07, Niall Pemberton <[EMAIL PROTECTED]> wrote: Rather than inactive or dormant I think a label like "maintenance mode" is better for something like this - someone prepared to maintain it (e.g. me) but no ongoing development, inactive/dormant implies abandonned in my mind. Should have said this rather than my reply to Craig - +1 to this definition :) Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Status of components
On 2/6/07, Craig McClanahan <[EMAIL PROTECTED]> wrote: Couple of thoughts intermixed. A key one is whether "inactive" and "heading for dormancy" should mean the same thing. A stable library used by other projects, with no significant bugs, seems to fit the former descriptor, while a project nobody uses or cares about would certainly fit the latter. That kind of distinction is not clear in your first crack at ranking these things. Definitely different things. Inactive means there's not much work going on it, it's the opposite of active. It's a symptom. Dormancy is a plan. Maintenance would be another. Release planned would be another. I think the key difference between dormancy and maintenance is that in the latter case there is someone who is monitoring it. DbUtils is definitely in Maintenance - I've no plans to work on a new release and don't know of anyone who is, but if the issues show up then I'll be aiming to get involved and get a release out. On 2/6/07, Henri Yandell <[EMAIL PROTECTED]> wrote: The specific EL version this implemented was before the separation of the JSP 2.1 / JSF 1.2 expression language APIs into their own spec. Ideally, this library would become an implementation of that API ... otherwise dormancy seems reasonable. I don't think Tomcat uses it anymore, so I think it's dormant time. > Jelly - ?? Dormancy candidate? Maven1 users don't count as a pretty large audience? I sometimes suspect we are the major Maven1 users :) > Modeler - Inactive - dormancy? Better ask the Tomcat folks, since they use (used?) it. Daemon too. Dims did a release of Modeler recently, so someone else uses it too. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Status of components
--- Henri Yandell <[EMAIL PROTECTED]> wrote: > I made a stab of defining the current status for > Commons for the > Jakarta board report: > > http://wiki.apache.org/jakarta/JakartaBoardReport-current [SNIP] JXPath seems to have been effectively abandoned, but is overall quite stable. It is, IMHO, very close to being ready for a 1.3 release (a couple of JIRA issues still need attention). After 1.3 is released it can likely languish in the "maintenance mode" that IIRC was proposed by Niall on this thread. My intent is to act as curator for this project. However all that condenses into a summary status. ;) -Matt Bored stiff? Loosen up... Download and play hundreds of games for free on Yahoo! Games. http://games.yahoo.com/games/front - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-jelly-tags-jaxme (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-jaxme has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 88 runs. The current state of this project is 'Failed', with reason 'Configuration Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-jaxme : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jaxme/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-jaxme-07022007.jar] identifier set to project name -ERROR- No such project [ws-jaxme] for property. -ERROR- No such project [ws-jaxme] for property. -ERROR- No such project [ws-jaxme] for property. -ERROR- No such project [ws-jaxme] for property. -ERROR- Cannot resolve output/outputpath of *unknown* [ws-jaxme] -ERROR- Unhandled Property: maven.jar.jaxme-js on: Maven on Project:commons-jelly-tags-jaxme -ERROR- Cannot resolve output/outputpath of *unknown* [ws-jaxme] -ERROR- Unhandled Property: maven.jar.jaxme on: Maven on Project:commons-jelly-tags-jaxme -ERROR- Cannot resolve output/outputpath of *unknown* [ws-jaxme] -ERROR- Unhandled Property: maven.jar.jaxme-api on: Maven on Project:commons-jelly-tags-jaxme -ERROR- Cannot resolve output/outputpath of *unknown* [ws-jaxme] -ERROR- Unhandled Property: maven.jar.jaxme-xs on: Maven on Project:commons-jelly-tags-jaxme -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -INFO- Failed with reason configuration failed -ERROR- Bad Dependency. Project: ws-jaxme unknown to *this* workspace -INFO- Failed to extract fallback artifacts from Gump Repository To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jaxme/rss.xml - Atom: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jaxme/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 2207022007, vmgump.apache.org:vmgump-public:2207022007 Gump E-mail Identifier (unique within run) #42. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-jelly-tags-jaxme (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-jaxme has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 88 runs. The current state of this project is 'Failed', with reason 'Configuration Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-jaxme : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jaxme/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-jaxme-07022007.jar] identifier set to project name -ERROR- No such project [ws-jaxme] for property. -ERROR- No such project [ws-jaxme] for property. -ERROR- No such project [ws-jaxme] for property. -ERROR- No such project [ws-jaxme] for property. -ERROR- Cannot resolve output/outputpath of *unknown* [ws-jaxme] -ERROR- Unhandled Property: maven.jar.jaxme-js on: Maven on Project:commons-jelly-tags-jaxme -ERROR- Cannot resolve output/outputpath of *unknown* [ws-jaxme] -ERROR- Unhandled Property: maven.jar.jaxme on: Maven on Project:commons-jelly-tags-jaxme -ERROR- Cannot resolve output/outputpath of *unknown* [ws-jaxme] -ERROR- Unhandled Property: maven.jar.jaxme-api on: Maven on Project:commons-jelly-tags-jaxme -ERROR- Cannot resolve output/outputpath of *unknown* [ws-jaxme] -ERROR- Unhandled Property: maven.jar.jaxme-xs on: Maven on Project:commons-jelly-tags-jaxme -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -INFO- Failed with reason configuration failed -ERROR- Bad Dependency. Project: ws-jaxme unknown to *this* workspace -INFO- Failed to extract fallback artifacts from Gump Repository To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jaxme/rss.xml - Atom: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jaxme/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 2207022007, vmgump.apache.org:vmgump-public:2207022007 Gump E-mail Identifier (unique within run) #42. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-jelly-tags-soap (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-soap has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 88 runs. The current state of this project is 'Failed', with reason 'Configuration Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-soap : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-soap/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-soap-07022007.jar] identifier set to project name -ERROR- No such project [ws-jaxme] for property. -ERROR- Cannot resolve output/outputpath of *unknown* [ws-jaxme] -ERROR- Unhandled Property: maven.jar.jaxme-api on: Maven on Project:commons-jelly-tags-soap -DEBUG- Dependency on ws-axis exists, no need to add for property maven.jar.axis. -DEBUG- Dependency on ws-axis exists, no need to add for property maven.jar.jaxrpc-api. -DEBUG- Dependency on ws-axis exists, no need to add for property maven.jar.saaj-api. -DEBUG- Dependency on jakarta-servletapi-5-servlet exists, no need to add for property maven.jar.servletapi. -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -INFO- Failed with reason configuration failed -ERROR- Bad Dependency. Project: ws-jaxme unknown to *this* workspace -INFO- Failed to extract fallback artifacts from Gump Repository To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-soap/rss.xml - Atom: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-soap/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 2207022007, vmgump.apache.org:vmgump-public:2207022007 Gump E-mail Identifier (unique within run) #39. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-jelly-tags-soap (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-soap has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 88 runs. The current state of this project is 'Failed', with reason 'Configuration Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-soap : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-soap/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-soap-07022007.jar] identifier set to project name -ERROR- No such project [ws-jaxme] for property. -ERROR- Cannot resolve output/outputpath of *unknown* [ws-jaxme] -ERROR- Unhandled Property: maven.jar.jaxme-api on: Maven on Project:commons-jelly-tags-soap -DEBUG- Dependency on ws-axis exists, no need to add for property maven.jar.axis. -DEBUG- Dependency on ws-axis exists, no need to add for property maven.jar.jaxrpc-api. -DEBUG- Dependency on ws-axis exists, no need to add for property maven.jar.saaj-api. -DEBUG- Dependency on jakarta-servletapi-5-servlet exists, no need to add for property maven.jar.servletapi. -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -INFO- Failed with reason configuration failed -ERROR- Bad Dependency. Project: ws-jaxme unknown to *this* workspace -INFO- Failed to extract fallback artifacts from Gump Repository To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-soap/rss.xml - Atom: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-soap/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 2207022007, vmgump.apache.org:vmgump-public:2207022007 Gump E-mail Identifier (unique within run) #39. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Status of components
On 2/7/07, Craig McClanahan <[EMAIL PROTECTED]> wrote: Couple of thoughts intermixed. A key one is whether "inactive" and "heading for dormancy" should mean the same thing. A stable library used by other projects, with no significant bugs, seems to fit the former descriptor, while a project nobody uses or cares about would certainly fit the latter. That kind of distinction is not clear in your first crack at ranking these things. On 2/6/07, Henri Yandell <[EMAIL PROTECTED]> wrote: > > I made a stab of defining the current status for Commons for the > Jakarta board report: > > http://wiki.apache.org/jakarta/JakartaBoardReport-current > > Here's the summary. Any thoughts on the ?? marks and the dormancy > candidates? Feel free to add things to the wiki page. I've not added > all of this yet. > > Attributes - Needs a new release, after that a dormancy candidate. > BeanUtils - Inactive. 1.8.0 slowly being worked on. > Betwixt - Just released. > Chain - ?? Inactive but stable. Used by a few projects (including Shale) and libraries, but not widespread. Limited in scope due to awkard support for conditional processing, so not likely to be aggressively enhanced (at least by me ... others may disagree :-). +1 - from memory could do with a release just to improve the pom (provided scope) and make life easier for m2 users - also I think theres a couple of tickets I didn't have time to look at (catalog support on features I don't use) for the last release. I'll probably look at doing this once another component(s) has taken the m2 plunge with a release. Rather than inactive or dormant I think a label like "maintenance mode" is better for something like this - someone prepared to maintain it (e.g. me) but no ongoing development, inactive/dormant implies abandonned in my mind. CLI - Inactive. Dormancy candidate? > Codec - Inactive. > Collections - Inactive - new releases discussed but not much movement. Some work started on a JDK 1.5 version in the sandbox a few months back. > Configuration - Active. > Daemon - ?? Dormancy candidate? > DBCP - 1.2.2 release in the works. > DbUtils - 1.1 release made. No plans for 1.2. > Digester - ?? Recently had a 1.8 release to clean up memory leaks and a few other bugs. For a 1.x release it seems like you could call it stable. But the architectural approach (including its dependence on the six year old BeanUtils architecture) could certainly use a remodel. Do you have a suggestion/idea on what you would replace BeanUtils with? Discovery - 0.4 release made, nothing new planned. Dormancy candidate. > EL - ?? Dormancy candidate? The specific EL version this implemented was before the separation of the JSP 2.1 / JSF 1.2 expression language APIs into their own spec. Ideally, this library would become an implementation of that API ... otherwise dormancy seems reasonable. Email - Maybe a 1.1 release in the works. Not much activity yet. > FileUpload - 1.2 release in the works. > IO - 1.3 just released. > Jelly - ?? Dormancy candidate? Maven1 users don't count as a pretty large audience? Jexl - ?? Dormancy candidate? > JXPath - ?? Dormancy candidate? > Lang - 2.3 release in the works. > Launcher - Inactive. Dormancy candidate. > Logging - Needs a 1.1.1 release, no plans beyond that. > Math - Slow activity. > Modeler - Inactive - dormancy? Better ask the Tomcat folks, since they use (used?) it. Net - New JDK 1.5 version in the works. > Pool - New version in the works. > Primitives - Inactive. Dormancy candidate? > SCXML - Active, just released. > Transaction - Release being discussed. > Validator - Active. > VFS - Active and releasing. > > Dormant - Nothing likely to leave dormancy. > > Sandbox - Nothing that looks like moving to proper anytime soon. Some > for dormancy (finder, id). Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
VOTE: Release commons-fileupload 1.2 (3rd attempt)
Hi, I have prepared commons-fileupload-1.2rc3. Compared to 1.2rc2, the following changes have been made: - The sources are now available as tar.gz and .zip file. - The build has been made with JDK 1.5.0_11, rather than 1.6.0rc1. Please note, that this release (like all releases) requires, in particular, 3 positive votes from PMC members. Thanks, Jochen [ ] +1 [ ] =0 [ ] -1 -- How fast can a year go? As fast as your childs first year. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r504493 - /jakarta/commons/proper/fileupload/tags/commons-fileupload-1.2rc3/
Author: jochen Date: Wed Feb 7 02:44:34 2007 New Revision: 504493 URL: http://svn.apache.org/viewvc?view=rev&rev=504493 Log: (empty) Added: jakarta/commons/proper/fileupload/tags/commons-fileupload-1.2rc3/ - copied from r504492, jakarta/commons/proper/fileupload/branches/b1_2/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r504491 - in /jakarta/commons/proper/fileupload/branches/b1_2: build.xml pom.xml project.xml
Author: jochen
Date: Wed Feb 7 02:29:27 2007
New Revision: 504491
URL: http://svn.apache.org/viewvc?view=rev&rev=504491
Log:
Release of 1.2rc3
Modified:
jakarta/commons/proper/fileupload/branches/b1_2/build.xml
jakarta/commons/proper/fileupload/branches/b1_2/pom.xml
jakarta/commons/proper/fileupload/branches/b1_2/project.xml
Modified: jakarta/commons/proper/fileupload/branches/b1_2/build.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/branches/b1_2/build.xml?view=diff&rev=504491&r1=504490&r2=504491
==
--- jakarta/commons/proper/fileupload/branches/b1_2/build.xml (original)
+++ jakarta/commons/proper/fileupload/branches/b1_2/build.xml Wed Feb 7
02:29:27 2007
@@ -1,141 +1,95 @@
-
-
+
-
-
-
-
-
+
+
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+
+
+
+
+
-
-
-
-
-
-
-
-
+
+
+
+
+
+
-
-
+
-
-
+
-
-
-
+
-
-
-
+
-
-
+
-
-
+
-
-
+
-
-
+
-
-
+
-
-
+
-
-
+
-
-
-
-
+
+
-
-
+
-
-
-
-
+
+
-
-
+
-
-
+
-
-
-
-
-
-
+
+
+
-
-
-
-
-
-
+
+
+
-
-
+
@@ -146,112 +100,103 @@
==
-
-
+
-
-
+
-
-
-
-
+
+
-
-
+
-
-
+
-
-
+
-
-
-
-
+
+
-
-
+
-
-
-http://www.ibiblio.org/maven/commons-io/jars/commons-io-1.3.jar";>
-
+
+http://repo1.maven.org/maven/commons-io/jars/commons-io-1.3.jar";>
+http://people.apache.org/repo/m1-snapshot-repository/commons-io/jars/commons-io-1.3.jar";>
-
-
-
-
+
+
-
-
-http://www.ibiblio.org/maven/javax.servlet/jars/servlet-api-2.3.jar";>
-
+
+http://repo1.maven.org/maven/javax.servlet/jars/servlet-api-2.3.jar";>
+http://people.apache.org/repo/m1-snapshot-repository/javax.servlet/jars/servlet-api-2.3.jar";>
-
-
-
-
+
+
-
-
-http://www.ibiblio.org/maven/javax.portlet/jars/portlet-api-1.0.jar";>
-
+
+http://repo1.maven.org/maven/javax.portlet/jars/portlet-api-1.0.jar";>
+http://people.apache.org/repo/m1-snapshot-repository/javax.portlet/jars/portlet-api-1.0.jar";>
-
-
-
-
+
+
-
-
-http://www.ibiblio.org/maven/junit/jars/junit-3.8.1.jar";>
-
+
+http://repo1.maven.org/maven/junit/jars/junit-3.8.1.jar";>
+http://people.apache.org/repo/m1-snapshot-repository/junit/jars/junit-3.8.1.jar";>
-
-
-
-
+
+
-
+
+
+http://repo1.maven.org/maven/maven/plugins/maven-xdoc-plugin-1.9.2.jar";>
+http://people.apache.org/repo/m1-snapshot-repository/maven/plugins/maven-xdoc-plugin-1.9.2.jar";>
+
+
+
+
+
+
+
+http://repo1.maven.org/maven/maven/plugins/maven-changelog-plugin-1.9.1.jar";>
+http://people.apache.org/repo/m1-snapshot-repository/maven/plugins/maven-changelog-plugin-1.9.1.jar";>
+
+
+
+
+
-
Proxy used :
Proxy host [${proxy.host}]
Proxy port [${proxy.port}]
Proxy user [${proxy.username}]
-
-
+
Proxy not used.
-
-
-
-
+
+
-
+
\ No newline at end of file
Modified: jakarta/commons/proper/fileupload/branches/b1_2/pom.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/branches/b1_2/pom.xml?view=diff&rev=504491&r1=504490&r2=504491
==
--- jakarta/commons/proper/fileupload/branches/b1_2/pom.xml (original)
+++ jakarta/commons/proper/fileupload/branches/b1_2/pom.xml Wed Feb 7 02:29:27
2007
@@ -27,7 +27,7 @@
4.0.0
commons-fileupload
commons-fileupload
- 1.2rc2
+ 1.2rc3
FileUpload
The FileUpload component provides a simple yet f
[EMAIL PROTECTED]: Project commons-launcher (in module jakarta-commons) 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-launcher has an issue affecting its community integration. This issue affects 3 projects, and has been outstanding for 36 runs. The current state of this project is 'Failed', with reason 'Missing Build Outputs'. For reference only, the following projects are affected by this: - commons-launcher : Jakarta commons - jakarta-tomcat-catalina : Servlet 2.4 Reference Implementation - jakarta-tomcat-jk : Connectors to various web servers Full details are available at: http://vmgump.apache.org/gump/public/jakarta-commons/commons-launcher/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-launcher.jar] identifier set to project name -DEBUG- Dependency on ant exists, no need to add for property ant.home. -INFO- Failed with reason missing build outputs -ERROR- Missing Output: /usr/local/gump/public/workspace/jakarta-commons/launcher/dist/bin/commons-launcher.jar -ERROR- See Directory Listing Work for Missing Outputs -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/jakarta-commons/commons-launcher/gump_work/build_jakarta-commons_commons-launcher.html Work Name: build_jakarta-commons_commons-launcher (Type: Build) Work ended in a state of : Success Elapsed: 14 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dant.home=/usr/local/gump/public/workspace/ant/dist dist [Working Directory: /usr/local/gump/public/workspace/jakarta-commons/launcher] CLASSPATH: /opt/jdk1.5/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/packages/junit3.8.1/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar - [javadoc] at com.sun.tools.doclets.formats.html.HtmlDocletWriter.printCommentTags(HtmlDocletWriter.java:1397) [javadoc] at com.sun.tools.doclets.formats.html.HtmlDocletWriter.printSummaryComment(HtmlDocletWriter.java:1370) [javadoc] at com.sun.tools.doclets.formats.html.HtmlDocletWriter.printSummaryComment(HtmlDocletWriter.java:1366) [javadoc] at com.sun.tools.doclets.formats.html.AbstractIndexWriter.printComment(AbstractIndexWriter.java:192) [javadoc] at com.sun.tools.doclets.formats.html.AbstractIndexWriter.printDescription(AbstractIndexWriter.java:126) [javadoc] at com.sun.tools.doclets.formats.html.AbstractIndexWriter.generateContents(AbstractIndexWriter.java:91) [javadoc] at com.sun.tools.doclets.formats.html.SingleIndexWriter.generateIndexFile(SingleIndexWriter.java:76) [javadoc] at com.sun.tools.doclets.formats.html.SingleIndexWriter.generate(SingleIndexWriter.java:52) [javadoc] at com.sun.tools.doclets.formats.html.HtmlDoclet.generateOtherFiles(HtmlDoclet.java:103) [javadoc] at com.sun.tools.doclets.internal.toolkit.AbstractDoclet.startGeneration(AbstractDoclet.java:122) [javadoc] at com.sun.tools.doclets.internal.toolkit.AbstractDoclet.start(AbstractDoclet.java:64) [javadoc] at com.sun.tools.doclets.formats.html.HtmlDoclet.start(HtmlDoclet.java:42) [javadoc] at com.sun.tools.doclets.standard.Standard.start(Standard.java:23) [javadoc] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [javadoc] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [javadoc] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [javadoc] at java.lang.reflect.Method.invoke(Method.java:585) [javadoc] at com.sun.tools.javadoc.DocletInvoker.invoke(DocletInvoker.java:269) [javadoc] at com.sun.tools.javadoc.DocletInvoker.start(DocletInvoker.java:143) [javadoc] at com.sun.tools.javadoc.Start.parseAndExecute(Start.java:340) [javadoc] at com.sun.tools.javadoc.Start.begin(Start.java:128) [javadoc]
[EMAIL PROTECTED]: Project commons-launcher (in module jakarta-commons) 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-launcher has an issue affecting its community integration. This issue affects 3 projects, and has been outstanding for 36 runs. The current state of this project is 'Failed', with reason 'Missing Build Outputs'. For reference only, the following projects are affected by this: - commons-launcher : Jakarta commons - jakarta-tomcat-catalina : Servlet 2.4 Reference Implementation - jakarta-tomcat-jk : Connectors to various web servers Full details are available at: http://vmgump.apache.org/gump/public/jakarta-commons/commons-launcher/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-launcher.jar] identifier set to project name -DEBUG- Dependency on ant exists, no need to add for property ant.home. -INFO- Failed with reason missing build outputs -ERROR- Missing Output: /usr/local/gump/public/workspace/jakarta-commons/launcher/dist/bin/commons-launcher.jar -ERROR- See Directory Listing Work for Missing Outputs -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/jakarta-commons/commons-launcher/gump_work/build_jakarta-commons_commons-launcher.html Work Name: build_jakarta-commons_commons-launcher (Type: Build) Work ended in a state of : Success Elapsed: 14 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dant.home=/usr/local/gump/public/workspace/ant/dist dist [Working Directory: /usr/local/gump/public/workspace/jakarta-commons/launcher] CLASSPATH: /opt/jdk1.5/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/packages/junit3.8.1/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar - [javadoc] at com.sun.tools.doclets.formats.html.HtmlDocletWriter.printCommentTags(HtmlDocletWriter.java:1397) [javadoc] at com.sun.tools.doclets.formats.html.HtmlDocletWriter.printSummaryComment(HtmlDocletWriter.java:1370) [javadoc] at com.sun.tools.doclets.formats.html.HtmlDocletWriter.printSummaryComment(HtmlDocletWriter.java:1366) [javadoc] at com.sun.tools.doclets.formats.html.AbstractIndexWriter.printComment(AbstractIndexWriter.java:192) [javadoc] at com.sun.tools.doclets.formats.html.AbstractIndexWriter.printDescription(AbstractIndexWriter.java:126) [javadoc] at com.sun.tools.doclets.formats.html.AbstractIndexWriter.generateContents(AbstractIndexWriter.java:91) [javadoc] at com.sun.tools.doclets.formats.html.SingleIndexWriter.generateIndexFile(SingleIndexWriter.java:76) [javadoc] at com.sun.tools.doclets.formats.html.SingleIndexWriter.generate(SingleIndexWriter.java:52) [javadoc] at com.sun.tools.doclets.formats.html.HtmlDoclet.generateOtherFiles(HtmlDoclet.java:103) [javadoc] at com.sun.tools.doclets.internal.toolkit.AbstractDoclet.startGeneration(AbstractDoclet.java:122) [javadoc] at com.sun.tools.doclets.internal.toolkit.AbstractDoclet.start(AbstractDoclet.java:64) [javadoc] at com.sun.tools.doclets.formats.html.HtmlDoclet.start(HtmlDoclet.java:42) [javadoc] at com.sun.tools.doclets.standard.Standard.start(Standard.java:23) [javadoc] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [javadoc] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [javadoc] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [javadoc] at java.lang.reflect.Method.invoke(Method.java:585) [javadoc] at com.sun.tools.javadoc.DocletInvoker.invoke(DocletInvoker.java:269) [javadoc] at com.sun.tools.javadoc.DocletInvoker.start(DocletInvoker.java:143) [javadoc] at com.sun.tools.javadoc.Start.parseAndExecute(Start.java:340) [javadoc] at com.sun.tools.javadoc.Start.begin(Start.java:128) [javadoc]
Re: [all] Status of components
I'm still trying to find time to get proxy out of the sandbox and into proper. On 2/7/07, Jörg Schaible <[EMAIL PROTECTED]> wrote: Hi Hen, Henri Yandell wrote on Wednesday, February 07, 2007 2:07 AM: [snip] > > Sandbox - Nothing that looks like moving to proper anytime soon. Some > for dormancy (finder, id). id is still on my todo list, it's simply a time/prio problem. Nevertheless I answer activly any questions about the component here. - Jörg - 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]
