[math] why no tag for MATH_2_0?
There is a tag for RC2 of 2.0, but not for 2.0 itself. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[g...@vmgump]: Project commons-daemon-native (in module apache-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 gene...@gump.apache.org. Project commons-daemon-native has an issue affecting its community integration. This issue affects 1 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-daemon-native : Native application for daemon Full details are available at: http://vmgump.apache.org/gump/public/apache-commons/commons-daemon-native/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -INFO- Failed with reason build failed The following work was performed: http://vmgump.apache.org/gump/public/apache-commons/commons-daemon-native/gump_work/build_apache-commons_commons-daemon-native.html Work Name: build_apache-commons_commons-daemon-native (Type: Build) Work ended in a state of : Failed Elapsed: Command Line: make [Working Directory: /srv/gump/public/workspace/apache-commons/daemon/src/native/unix] - (cd native; make all) make[1]: Entering directory `/srv/gump/public/workspace/apache-commons/daemon/src/native/unix/native' ccache gcc -g -O2 -DOS_LINUX -DDSO_DLFCN -DCPU=\"i386\" -I/usr/lib/jvm/java-6-sun/include -I/usr/lib/jvm/java-6-sun/include/linux -Wall -Wstrict-prototypes -c jsvc-unix.c -o jsvc-unix.o In file included from jsvc-unix.c:18: jsvc.h:46:21: error: signals.h: No such file or directory make[1]: *** [jsvc-unix.o] Error 1 make[1]: Leaving directory `/srv/gump/public/workspace/apache-commons/daemon/src/native/unix/native' make: *** [native/all] Error 2 - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/apache-commons/commons-daemon-native/rss.xml - Atom: http://vmgump.apache.org/gump/public/apache-commons/commons-daemon-native/atom.xml == Gump Tracking Only === Produced by Gump version 2.3. Gump Run 05001612022010, vmgump:vmgump-public:05001612022010 Gump E-mail Identifier (unique within run) #1. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[continuum] BUILD SUCCESSFUL: Commons - Commons Lang -
Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=283484&projectId=2634 Build statistics: State: Ok Previous State: Failed Started at: Fri 12 Feb 2010 09:29:09 -0800 Finished at: Fri 12 Feb 2010 09:30:49 -0800 Total time: 1m 39s Build Trigger: Schedule Build Number: 20 Exit code: 0 Building machine hostname: vmbuild.apache.org Operating system : Linux(unknown) Java Home version : java version "1.4.2_15" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_15-b02) Java HotSpot(TM) Client VM (build 1.4.2_15-b02, mixed mode) Builder version : Maven version: 2.0.9 Java version: 1.4.2_15 OS name: "linux" version: "2.6.24-23-server" arch: "i386" Family: "unix" SCM Changes: No files changed Dependencies Changes: No dependencies changed Build Definition: POM filename: pom.xml Goals: clean install Arguments: --batch-mode --non-recursive Build Fresh: false Always Build: true Default Build Definition: true Schedule: COMMONS_SCHEDULE Profile Name: Java 1.4 Description: Test Summary: Tests: 1938 Failures: 0 Errors: 0 Success Rate: 100 Total time: 27.341 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [compress] equalsIgnoreCase in Factories
On 2010-02-12, Torsten Curdt wrote: >> While looking through the patch I realized we are using >> equalsIgnoreCase in the factories which is not such a good idea since >> this is locale dependent and the Turkish lowercase of "ZIP" is not >> "zip". > Wow, didn't know that! It's been burnt into my brain even since Ant's wouldn't work in Turkish locales - fond memories of a bug fixed more than nine years ago 8-) Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [compress] Dealing with "invalid" extra fields in ZIPs
>> So that's only a recommendation for a free form field? > > Yes, it's an array of arbitrary many bytes with a recommended internal > structure. I see >>> * do we want to accept invalid extra fields when writing ZIP entries as >>> well? > >> If it really is just a free form field then we should accept anything. >> Otherwise we should not encourage the creation of such files. > > I agree. Just state the recommended format in the javadocs? +1 cheers -- Torsten - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [compress] equalsIgnoreCase in Factories (was Re: New release soon?)
> Saw that. While looking through the patch I realized we are using > equalsIgnoreCase in the factories which is not such a good idea since > this is locale dependent and the Turkish lowercase of "ZIP" is not > "zip". Wow, didn't know that! I found the comment here quite interesting http://nikolajlindberg.blogspot.com/2008/03/beware-of-java-comparing-turkish.html Seems we can easily fix this with toLowerCase(Locale.US) in this case. As a side note: For more serious comparisons it seems like a "Collator" is the right thing to use http://java.sun.com/j2se/1.4.2/docs/api/java/text/Collator.html Never came across that class before :) Interesting! > I'll change that to locale insensitive comparisons - actually > comparisons using the English locale soon. Yeah, we should fix that before the next release as well. cheers -- Torsten - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [compress] Dealing with "invalid" extra fields in ZIPs
On 2010-02-12, Torsten Curdt wrote: >> The semi-official ZIP standard recommends a format for this extra data >> (two-byte tag, two-byte length of data, rest of data) and the current >> ZIP classes in compress go a step further and enforce this >> recommendation. >> There are files out there that contain extra fields that do not follow >> the recommendation. You can find one attached to COMPRESS-62. > So that's only a recommendation for a free form field? Yes, it's an array of arbitrary many bytes with a recommended internal structure. >> When reading such a file InfoZIP's unzip simply ignores the extra fields >> and issues a warning. Our ZipFile and ZipArchiveEntry classes throw an >> exception. >> It wouldn't be too difficult to make the codebase ignore those fields as >> well, but there are a few things to consider: > Maybe we could introduce a boolean on whether we want to enforce this > or not. > Question is where this should be configured best and what the default > behavior is. The flag - if introduced - should be part of the stream classes and ZipFile and apply to them as a whole. When writing archives, you are dealing with ZipArchiveEntry directly, though. >> * do we want to log a warning? Where to? > Using logging is not really a great option for a library IMO. Same here. >> * do we want to accept invalid extra fields when writing ZIP entries as >> well? > If it really is just a free form field then we should accept anything. > Otherwise we should not encourage the creation of such files. I agree. Just state the recommended format in the javadocs? Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[compress] equalsIgnoreCase in Factories (was Re: New release soon?)
On 2010-02-12, Torsten Curdt wrote: > I also wanted to get Compressor detection in ...and just committed that :) Saw that. While looking through the patch I realized we are using equalsIgnoreCase in the factories which is not such a good idea since this is locale dependent and the Turkish lowercase of "ZIP" is not "zip". I'll change that to locale insensitive comparisons - actually comparisons using the English locale soon. Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[continuum] BUILD FAILURE: Commons - Commons Lang -
Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=283398&projectId=2634 Build statistics: State: Failed Previous State: Ok Started at: Fri 12 Feb 2010 06:36:15 -0800 Finished at: Fri 12 Feb 2010 06:37:09 -0800 Total time: 53s Build Trigger: Schedule Build Number: 19 Exit code: 1 Building machine hostname: vmbuild.apache.org Operating system : Linux(unknown) Java Home version : java version "1.4.2_15" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_15-b02) Java HotSpot(TM) Client VM (build 1.4.2_15-b02, mixed mode) Builder version : Maven version: 2.0.9 Java version: 1.4.2_15 OS name: "linux" version: "2.6.24-23-server" arch: "i386" Family: "unix" SCM Changes: No files changed Dependencies Changes: No dependencies changed Build Definition: POM filename: pom.xml Goals: clean install Arguments: --batch-mode --non-recursive Build Fresh: false Always Build: true Default Build Definition: true Schedule: COMMONS_SCHEDULE Profile Name: Java 1.4 Description: Test Summary: Tests: 1938 Failures: 1 Errors: 0 Success Rate: 99 Total time: 20.812004 Test Failures: RandomUtilsTest testNextLongBound : junit.framework.AssertionFailedError junit.framework.AssertionFailedError: mid point chi-square test -- will fail about 1 in 1000 times: 11.664:446,554 at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.assertTrue(Assert.java:20) at org.apache.commons.lang.math.RandomUtilsTest.tstNextLong(RandomUtilsTest.java:224) at org.apache.commons.lang.math.RandomUtilsTest.testNextLongBound(RandomUtilsTest.java:434) - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [compress] Dealing with "invalid" extra fields in ZIPs
> The semi-official ZIP standard recommends a format for this extra data > (two-byte tag, two-byte length of data, rest of data) and the current > ZIP classes in compress go a step further and enforce this > recommendation. > > There are files out there that contain extra fields that do not follow > the recommendation. You can find one attached to COMPRESS-62. So that's only a recommendation for a free form field? > When reading such a file InfoZIP's unzip simply ignores the extra fields > and issues a warning. Our ZipFile and ZipArchiveEntry classes throw an > exception. > > It wouldn't be too difficult to make the codebase ignore those fields as > well, but there are a few things to consider: Maybe we could introduce a boolean on whether we want to enforce this or not. Question is where this should be configured best and what the default behavior is. > * currently the Javadocs of ZipArchiveEntry#setExtra says "Throws an > Exception if extra data cannot be parsed into extra fields." > > Either we change the Javadocs or we add a different method that does > not throw an exceptions, I'm not sure. > > * do we want to log a warning? Where to? Using logging is not really a great option for a library IMO. > * do we want to accept invalid extra fields when writing ZIP entries as > well? If it really is just a free form field then we should accept anything. Otherwise we should not encourage the creation of such files. IMO cheers -- Torsten - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [compress] New release soon?
I also wanted to get Compressor detection in ...and just committed that :) If I read COMPRESS-73 correctly it sounds like a can of worms ...but let's discuss on the new thread. For COMPRESS-82 we could maybe automatically wrap the InputStream if it not already is buffered. Not sure about 1.0.1 vs 1.1 but a new release sounds like a good idea. Quite a few thing have been fixed since. cheers -- Torsten - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[compress] Dealing with "invalid" extra fields in ZIPs
Hi, in ZIP files each entry can be associated with "extra data" for extension stuff, this is available via ZipEntry#getExtra and ZipArchiveEntry#getExtraField(s). The semi-official ZIP standard recommends a format for this extra data (two-byte tag, two-byte length of data, rest of data) and the current ZIP classes in compress go a step further and enforce this recommendation. There are files out there that contain extra fields that do not follow the recommendation. You can find one attached to COMPRESS-62. When reading such a file InfoZIP's unzip simply ignores the extra fields and issues a warning. Our ZipFile and ZipArchiveEntry classes throw an exception. It wouldn't be too difficult to make the codebase ignore those fields as well, but there are a few things to consider: * currently the Javadocs of ZipArchiveEntry#setExtra says "Throws an Exception if extra data cannot be parsed into extra fields." Either we change the Javadocs or we add a different method that does not throw an exceptions, I'm not sure. * do we want to log a warning? Where to? * do we want to accept invalid extra fields when writing ZIP entries as well? Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [compress] New release soon?
On 2010-02-12, Christian Grobmeier wrote: > Stefan has made several bugfixes - I wonder if we should do a 1.1 > quite soon. In parallel I'm planning a release of the Compress Antlib now that Ant 1.8.0 is out. This is supposed to add cpio and ar tasks but to tell the truth neither format works really well with Commons Compress 1.0 (the timestamps and Unix permissions are all wrong) so I'd appreciate a new release soon - and would even withhold the Antlib release for it. There are still a few JIRA issues and I'm currently looking into COMPRESS-73 (will kick of a separate mail for this). COMPRESS-82 sounds serious as well. Many of the other issues are scheduled for the 1.1 release but are unlikely to get done soon - for example ZIP64 or POSIX tar support. We should reschedule those - or call the next release 1.0.1 ;-) I wonder whether we should mark the bigger tasks as things that could be candidates for projects in the mentoring program. > I volunteer for preparing the 1.1 release in three weeks, if we think > its already time. Great. Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[compress] New release soon?
Hi, Stefan has made several bugfixes - I wonder if we should do a 1.1 quite soon. Since I have not done to much code changes lately due to other project, I volunteer for preparing the 1.1 release in three weeks, if we think its already time. And I think it is Cheers Christian - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r909069 - in /commons/proper/daemon/trunk/src/native: nt/moni/ unix/native/
On 02/12/2010 12:23 PM, Rainer Jung wrote: you might want to fix the log message. It looks like that is for DAEMON-40, not DAEMON-47. Done, thanks :) Cheers -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r909069 - in /commons/proper/daemon/trunk/src/native: nt/moni/ unix/native/
Hi Mladen, On 11.02.2010 17:44, mt...@apache.org wrote: Author: mturk Date: Thu Feb 11 16:43:36 2010 New Revision: 909069 URL: http://svn.apache.org/viewvc?rev=909069&view=rev Log: Fix DAEMON-47 by implementing slightly modified patches. Note that this will require reviewing you might want to fix the log message. It looks like that is for DAEMON-40, not DAEMON-47. Thanks and regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[g...@vmgump]: Project commons-daemon-native (in module apache-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 gene...@gump.apache.org. Project commons-daemon-native has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 777 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-daemon-native : Native application for daemon Full details are available at: http://vmgump.apache.org/gump/public/apache-commons/commons-daemon-native/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -INFO- Failed with reason build failed The following work was performed: http://vmgump.apache.org/gump/public/apache-commons/commons-daemon-native/gump_work/build_apache-commons_commons-daemon-native.html Work Name: build_apache-commons_commons-daemon-native (Type: Build) Work ended in a state of : Failed Elapsed: Command Line: make [Working Directory: /srv/gump/public/workspace/apache-commons/daemon/src/native/unix] - (cd native; make all) make[1]: Entering directory `/srv/gump/public/workspace/apache-commons/daemon/src/native/unix/native' ccache gcc -g -O2 -DOS_LINUX -DDSO_DLFCN -DCPU=\"i386\" -I/usr/lib/jvm/java-6-sun/include -I/usr/lib/jvm/java-6-sun/include/linux -Wall -Wstrict-prototypes -c jsvc-unix.c -o jsvc-unix.o In file included from jsvc-unix.c:18: jsvc.h:46:21: error: signals.h: No such file or directory make[1]: *** [jsvc-unix.o] Error 1 make[1]: Leaving directory `/srv/gump/public/workspace/apache-commons/daemon/src/native/unix/native' make: *** [native/all] Error 2 - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/apache-commons/commons-daemon-native/rss.xml - Atom: http://vmgump.apache.org/gump/public/apache-commons/commons-daemon-native/atom.xml == Gump Tracking Only === Produced by Gump version 2.3. Gump Run 0812022010, vmgump:vmgump-public:0812022010 Gump E-mail Identifier (unique within run) #5. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
