[CANCEL][VOTE] Release Compress 1.11 Based on RC1

On 2016-04-01, Stian Soiland-Reyes wrote: > You didn't include the checksums in the mail, but the svn revision > 12931 matched. Never did, can certainly do that in the future. > My vote: -1 (Non-binding) > Due to additional file commons-compress-1.11-SNAPSHOT.jar Ouch. I have no idea how this

[VOTE] Release Compress 1.11 Based on RC2

Hi all due to a packaging glitch I had to re-roll the release. It is based on the same commit that was used for RC1, so both tags refer to the same commit. For this reason I haven't even re-created the site. Compress 1.11 RC2 is available for review here: https://dist.apache.org/repos/dist/de

Re: [VOTE] Release Compress 1.11 Based on RC2

On 2016-04-03, Stian Soiland-Reyes wrote: > Could we delete the tag 1.11-RC1 now? AFAIR we keep all tags, even those for failed RC votes. Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional comman

Re: [VOTE] Release Compress 1.11 Based on RC2

On 2016-04-03, sebb wrote: > On 3 April 2016 at 06:01, Stefan Bodewig wrote: >> On 2016-04-03, Stian Soiland-Reyes wrote: >>> Could we delete the tag 1.11-RC1 now? >> AFAIR we keep all tags, even those for failed RC votes. > Sometimes tags are withdrawn before a v

[compress] bytesRead and bytesWritten in our streams

Hi while looking into generalizing COMPRESS-207 I realized our CompressorOutputStreams didn't provide bytesWritten - unlike the ArchiverOutputStreams - while the InputStreams all provide a bytesRead. And I also realized I didn't really know what bytesRead actually meant - bytes read from the comp

Re: [VOTE] Release Compress 1.11 Based on RC2

On 2016-04-03, Matt Sicker wrote: > I thought Infra disabled the ability to delete tags in git anyways unless > they reverted that recently. Only tags under rel/ cannot get deleted, all others can. Therefore final release tags should be created as rel/THE_TAG_NAME. Stefan --

Re: [CANCEL][VOTE] Release Compress 1.11 Based on RC1

On 2016-04-04, Gary Gregory wrote: > So we have an RC2 coming? Just checking... The RC2 vote thread is still open for about 23 hours (you even responded to it when we talked about deleting tags :-) Stefan - To unsubscribe, e-ma

[RESULT][VOTE] Release Compress 1.11 Based on RC2

Hi with +1s by Stian Soiland-Reyes Oliver Heger (binding) Torsten Curdt (binding) Emmanuel Bourg (binding) and my own implied one - and no other votes - the vote has passed. I'll start the usual process of publishing the artifacts and giving the mirrors time to catch up before announcing the r

[ANN] Apache Commons Compress 1.11 Released

he central directory. Issue: COMPRESS-321. For complete information on Commons Compress, including instructions on how to submit bug reports, patches, or suggestions for improvement, see the Apache Commons Compress website: http://commons.apache.org/compress/ Stefan Bodewig, on behalf of the Apac

Re: [compress] test failures in master

On 2016-04-06, Gary Gregory wrote: > Is this a Windows only issue? Likely. This could be testcases that are sensitive to line-ends. Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e

Re: [compress] test failures in master

On 2016-04-07, sebb wrote: > On 7 April 2016 at 10:19, Stefan Bodewig wrote: > I set up > https://builds.apache.org/job/Commons-Compress-Windows/ Thanks! > Most tests failed with > java.lang.OutOfMemoryError: Java heap space > If someone can suggest a suitable settin

Re: Jenkins build is back to normal : Commons-Compress-Windows #13

On 2016-04-08, sebb wrote: > The Windows issues all seem to have been caused by the move to Git. > It appears that the move did not preserve EOL or binary file settings. > So some .ar files were being corrupted on Windows. > And some sample files were being converted to CRLF so they did not > ma

Re: [compress] Update Java version

On 2016-04-08, Gary Gregory wrote: > I think it would be good to use try-with-resources in our tests and for > users too. > Thoughts on updating to Java 7? Or, gasp, Java 8? I've had to fix some Java6ism a couple of times after applying patches like @Override on interface implementations - I eve

Re: Build failed in Jenkins: Commons-Compress #87

On 2016-04-09, Apache Jenkins Server wrote: > See > [ggregory] [COMPRESS-349] Update requirement from Java 5 to 6. I've modified the Jenkins configuration to use the java1.6 profile now, hope this fixes the build. Stefan -

Re: Fwd: Build failed in Jenkins: Commons-Compress » Apache Commons Compress #87

On 2016-04-09, Gary Gregory wrote: > I can logon to Jenkins but I do not see how to change the build from Java 5 > to 6. Am I not seeing it or do I not have karma? I'm not sure whether I ever asked for karma myself. Can you access ? Ste

Re: Fwd: Build failed in Jenkins: Commons-Compress » Apache Commons Compress #87

On 2016-04-09, Gary Gregory wrote: > On Sat, Apr 9, 2016 at 9:24 AM, Stefan Bodewig wrote: >> Can you access >> <https://builds.apache.org/job/Commons-Compress/configure> ? > Nope: ggregory is missing the Job/ExtendedRead permission This one may still be correct

Re: Interest in some code to read DMG files?

On 2016-05-21, Stian Soiland-Reyes wrote: > It certainly sounds like it could fit within Commons VFS, or perhaps > Commons Compress. I think VFS would be the better fit as the code that dealt with the underlying file system doesn't sound like it belonged into Compress. But I've not been contribut

Re: [fileupload] Remove Ant, and Gump files

On 2016-05-24, Jochen Wiedmann wrote: > On Mon, May 23, 2016 at 10:13 PM, Gary Gregory wrote: >> TODO: Drop Ant build? Not a blocker. > Unsure. For example, I don't know, whether the Gump build depends on > the Ant build, or not. I'd be ready to remove build.xml, though. Gump builds fileupload

Re: [ANNOUNCE] Apache Commons git repositories now writable for all ASF committers

On 2016-05-24, Jochen Wiedmann wrote: > Doesn't work for my Github User (jochenw): > $ git push > Username for 'https://github.com': > Password for 'https://joch...@github.com': > remote: Permission to apache/commons-fileupload.git denied to jochenw. > fatal: unable to access > 'https://github.co

Re: [fileupload] Remove Ant, and Gump files

On 2016-05-24, Jochen Wiedmann wrote: > thanks very much. In Summary, I understand that I can remove those > files: build.xml, gump.xml, build_gump.xml? Yes, I think so. Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.

[compress] Preparing for 1.12

Hi all we've got a nice set of fixes and new features added since 1.11 and I plan to cut the next release soonish. The only thing I want to do prior to the release is adding a few words of documentation about the IWA support in Snappy. Based on prior experience I'd like to give folks a chance to

Re: [compress] Preparing for 1.12

On 2016-06-10, Torsten Curdt wrote: >> You'll see that findbugs is unhappy about inconsistent synchronization >> introduced when I made the finish method of BZip2CompressorOutputStream >> synchronized due to COMPRESS-357 > My feedback: I'd rather recommend to get rid of the finalize over adding >

Re: [compress] Preparing for 1.12

On 2016-06-10, Stefan Bodewig wrote: > We have it in two cases, ZipFile and BZip2CompressorOutputStream - > ZipFile uses a volatile flag rather than synchronization and > null-assignment, maybe that's the better option anyway. I've changed the code and findbugs is happy again,

[compress] change behavior of bzip-output finalize?

Hi all I'm trying to bring a discussion from COMPRESS-357 over to the list. The bzip2 output stream has a finish method that is used to ensure all data has been written to the stream and a separate close method that invokes finish. And it overrides finalize to invoke finish in case people have fo

Re: [compress] change behavior of bzip-output finalize?

On 2016-06-13, Stefan Bodewig wrote: > The bzip2 output stream has a finish method that is used to ensure all > data has been written to the stream and a separate close method that > invokes finish. And it overrides finalize to invoke finish in case > people have forgotten to clos

[VOTE] Release Compress 1.12 based on RC2

Hi all as promised I've cut a RC for Compress 1.12. The Release Candidate is available for review at: https://dist.apache.org/repos/dist/dev/commons/compress/ (svn revision 14040) Maven artifacts are here: https://repository.apache.org/content/repositories/orgapachecommons-1178/org/apache

Re: [ALL] Need help with contributing for first time

Welcome Suresh On 2016-06-20, Suresh Sarda wrote: > I am new to apache commons and want to contribute to the library. I > tried to search for issues in commons-lang but all the issues were > quite old. I need help on which project to contribute or what task to > take. Apart from the advice Stian

Re: [VOTE] Release Compress 1.12 based on RC2

On 2016-06-19, Gary Gregory wrote: > Release notes typo: "Commons Compress 1.12 is the first version to require > Java6 at runtime." > "Java6" -> "Java 6" Yep, will fix it in the announce mail and when I re-create the site. > TODO: > On file:///E:/temp/rc/commons-compress-1.12-src/target/site/l

[RESULT] Release Compress 1.12 based on RC2

Hi all with binding +1s by Benedikt Ritter, Gary Gregory, Oliver Heger and my own implicit one the vote has passed. I'll publish the artifacts and wait with updating the site and sending the announcement until tomorrow morning (UTC). Thanks to all who took the time to review the release

[ANN] Apache Commons Compress 1.12 Released

e for code that relied on the finalizer. Issue: COMPRESS-357. For complete information on Commons Compress, including instructions on how to submit bug reports, patches, or suggestions for improvement, see the Apache Commons Compress website: http://commons.apache.org/compress/ Stefan Bodewig, on

Re: [compress] Update to Java 7?

On 2016-06-24, Gary Gregory wrote: > Hi, > I was looking at some compress code that I wanted to update to > switch-on-string but realized the code is still on Java 6. "still" means 1.12 has been the first release to require Java 6 - 1.11 was at Java 5 :-) > OK to bump to Java 7? If it is usefu

Re: [All] regarding the granting and revoking of commit privileges

On 2016-07-25, Rob Tompkins wrote: > So the question at hand stems from a project at my day job. We, much > like with commons, have the committing members of the project vote on > new folks becoming committers. But we are curious about how to go > about ending someone's commit privileges. How does

Re: [All] Please don't commit while repos are moving

On 2016-07-28, Benedikt Ritter wrote: > Hello Jochen, > Jochen Wiedmann schrieb am Do., 28. Juli 2016 > um 11:06 Uhr: >> Hi, >> please don't commit to repositories, while they are moving to Git. >> AFAIK, this currently covers [io], and [fileupload], but possibly >> others as well. >> We migh

Re: [rng] Setting up Jenkins

On 2016-08-08, Artem Barger wrote: > Do I need to write them directly? Or Posting here will be enough? Posting here should be enough. If https://wiki.apache.org/general/Jenkins?action=show&redirect=Hudson is current I should be one of the folks who can grant you access but you need an ASF accoun

Re: [rng] Setting up Jenkins

On 2016-08-08, Artem Barger wrote: > What is the process of getting an ASF account? Sorry, I wasn't clear. "you need an ASF account" really means "you need to be a committer". Configuring Jenkins builds is one of the - few - areas non-committers ar unable to help out with, unfortunately. Sorry

Re: [rng] Setting up Jenkins

On 2016-08-08, Gilles wrote: > On Mon, 08 Aug 2016 17:41:44 +0200, Stefan Bodewig wrote: >> On 2016-08-08, Artem Barger wrote: >>> What is the process of getting an ASF account? >> Sorry, I wasn't clear. "you need an ASF account" really means "you &g

Re: [ALL] Valid reasons for blocking a release?

On 2016-09-15, Gilles wrote: > On Wed, 14 Sep 2016 07:41:01 -0700, Gary Gregory wrote: >> "I'd rather not redo the release steps just for files that are >> meaningful only when browsing the code repository mirror at >> Github." >> I know our release process is a pain, so maybe we should see if we

Re: [ALL] Valid reasons for blocking a release?

On 2016-09-16, Gilles wrote: > Is the site a valid reason? to cancel a release? IMHO no. Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org

Re: [COMPRESS] [MATH] [VALIDATOR] [PARENT] Removing old releases from dist?

On 2016-09-30, Stian Soiland-Reyes wrote: > But there are also these which I don't think we need to keep: > compress/source/commons-compress-1.11-src.tar.gz (1.12 newer) You are correct, I must have forgotten to remove it after I cut the last release. > OK if I remove these? Silence means yes.

[compress] Added in-memory support for zip and 7z

Hi all actually it is SeekableByteChannel-support combined with a byte[] backed implementation of SeekableByteChannel. Over the past few days I've rewritten the zip and 7z packages to become independent of RandomAccessFile and thus no longer require writing to or reading from a file. The required

Re: [compress] Added in-memory support for zip and 7z

On 2016-10-20, M N wrote: > I have created tests for SeekableInMemoryByteChannel and spot small error. Great, thanks Maciej. > Attached is a patch with tests and proposed fix. The mailing list is set up to strip attachments (at least I don't see any). Could you attach it to a JIRA issue? Stefa

Re: [compress] Added in-memory support for zip and 7z

On 2016-10-20, wrote: > Even when a stream is not thread safe I try at least to make close() > safe/atomic as aborts and finalizers or shutdown hooks are natural > sources for concurrency – all using close(). true. > (However I guess it is less problematic for memory resources) In the case of

Re: [compress] Added in-memory support for zip and 7z

Hi Maciej patch applied. On 2016-10-22, M N wrote: > Going back to the fix - first I've done the homework and read the contract of > SeekableByteChannel.position(long) method. > It influences read() and write() operation. > Citation of the most important part: > "Setting the position to a v

Re: Fwd: commons-compress git commit: class is no longer used

On 2016-10-29, Gary Gregory wrote: > Was this class ever in a released version? yes, but it has been package private. > Updated Branches: > refs/heads/master 3d509a082 -> d8d92941d > class is no longer used Stefan - To uns

Re: [compress] Added in-memory support for zip and 7z

On 2016-11-01, M N wrote: >> read never indicates EOF as it stands, I think we should return -1 >> rather than 0 when position equals size. WDYT? > Yes, indeed the contract specifies to return -1 in this case so we > should change this. will do. >>> In resize() method there is also a danger to

Re: Fwd: commons-compress git commit: avoid overflow when resizing

On 2016-11-04, Gary Gregory wrote: >> Repository: commons-compress >> Updated Branches: >> refs/heads/master 46f57bf93 -> f538f38bd > >> avoid overflow when resizing > Isn't this worthy of a JIRA and note in changes.xml? the change is to a class completely new in 1.13. Stefan ---

[g...@vmgump]: Project commons-daemon (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 [EMAIL PROTECTED] Project commons-daemon has an issue affecting its community integration. This issue affec

[g...@vmgump]: Project commons-launcher (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 [EMAIL PROTECTED] Project commons-launcher has an issue affecting its community integration. This issue aff

[EMAIL PROTECTED]: Project commons-openpgp (in module commons-sandbox) 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-openpgp has an issue affecting its community integration. This issue affe

[EMAIL PROTECTED]: Project commons-xmlio (in module commons-dormant) 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-xmlio has an issue affecting its community integration. This issue affect

[g...@vmgump]: Project commons-cli (in module commons-cli-1.0.x) 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-cli has an issue affecting its community integration. This issue affects

[g...@vmgump]: Project commons-el (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 [EMAIL PROTECTED] Project commons-el has an issue affecting its community integration. This issue affects 1

[g...@vmgump]: Project commons-math (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 [EMAIL PROTECTED] Project commons-math has an issue affecting its community integration. This issue affects

[g...@vmgump]: Project commons-net (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 [EMAIL PROTECTED] Project commons-net has an issue affecting its community integration. This issue affects

[g...@vmgump]: Project commons-chain (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 [EMAIL PROTECTED] Project commons-chain has an issue affecting its community integration. This issue affect

Re: [EMAIL PROTECTED]: Project commons-compress (in module commons-sandbox) failed

Hi all, the problem here is that Gump uses the Maven 1 and the Maven 1 descriptor doesn't seem to know about compress' new dependency on commons-io. Should we * switch to build commons-compress with Ant or Maven 2? * fix the Maven 1.x descriptor? * do both ;-) Stefan

Re: [g...@vmgump]: Project commons-net (in module apache-commons) failed

On Mon, 30 Jun 2008, Martin Oberhuber <[EMAIL PROTECTED]> wrote: > Is anybody addressing this Gump Nag message for commons-net > already: It was caused by broken XML in xml-apis' descriptor and fixed a few weeks ago. Stefan - T

[COMPRESS] performance improvement in Ant's ZipOutputStream

Hi all, I couldn't find a JIRA for compress so I'm posting it here. We had a bug report against Ant's ZipOutputStream that showed that the class had a way worse performance compared to java.util.zip's cousin when it was used to compress big files. See https://issues.apache.org/bugzilla/show_bug.

Re: [COMPRESS] performance improvement in Ant's ZipOutputStream

On Wed, 16 Jul 2008, sebb <[EMAIL PROTECTED]> wrote: > On 16/07/2008, Stefan Bodewig <[EMAIL PROTECTED]> wrote: > > > I couldn't find a JIRA for compress so I'm posting it here. > > > > Compress is currently in the Sandbox. Thanks, I didn't

Re: [EMAIL PROTECTED]: Project commons-compress (in module commons-sandbox) failed

Gump still tried to use a Maven 1.x build, but that doesn't work anymore. I've switched the descriptor to use Maven 2 instead, expect a few more nags until we have the correct file name of the generated jar (unfortunately Gump cannot enforce this in mvn anymore) and I am satisified with the depend

Re: [g...@vmgump]: Project commons-compress (in module commons-sandbox) failed

On Wed, 8 Oct 2008, sebb <[EMAIL PROTECTED]> wrote: > Given that compress is in the sandox, it seems strange that it affects > so many projects. > > Do they really all depend on compress? Transitively, commons-vfs depends on commons-compress http://vmgump.apache.org/gump/public/commons-sandbox/

Re: [g...@vmgump]: Project commons-compress (in module commons-sandbox) failed

On Wed, 8 Oct 2008, sebb <[EMAIL PROTECTED]> wrote: > On 08/10/2008, Stefan Bodewig <[EMAIL PROTECTED]> wrote: > > On Wed, 8 Oct 2008, sebb <[EMAIL PROTECTED]> wrote: > > > > > Given that compress is in the sandox, it seems strange that it affects >

Re: [CLI] Building Commons CLI

On Fri, 17 Oct 2008, Hendrik Maryns <[EMAIL PROTECTED]> wrote: >> ant -diagnostics > --- Ant diagnostics report --- > Apache Ant version 1.7.0 compiled on June 7 2008 > > --- > Implementation Version > --- >

Re: [g...@vmgump]: Project commons-cli (in module commons-cli-1.x) failed

On 2008-11-10, Stefan Bodewig <[EMAIL PROTECTED]> wrote: > I'll look into the proxy logs to see whether something unexpected is > being downloaded. INFO: Redirecting via client connector to: http://repo1.maven.org/maven2/org/apa che/maven/plugins/maven-plugins/11/maven-plug

Re: [g...@vmgump]: Project commons-cli (in module commons-cli-1.x) failed

On 2008-11-10, Emmanuel Bourg <[EMAIL PROTECTED]> wrote: > Russel Winder a écrit : >> This command works for me on Ubuntu Hardy with JDK 1.6.0_07-b06 and >> Maven 2.0.9. I have noticed that this build has failed for three weeks >> now but it seems there is no-one around picking up on it. > I gu

Re: [g...@vmgump]: Project commons-jelly-tags-ant (in module commons-jelly) failed

This one is an incompatible interface change in Expression.java (added a throws clause to several methods) introduced with http://svn.apache.org/viewvc/commons/proper/jelly/trunk/src/java/org/apache/commons/jelly/expression/Expression.java?r1=718134&r2=718133&pathrev=718134 Some other jelly-tags

[g...@vmgump]: Project commons-javaflow (in module commons-sandbox) 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-javaflow has an issue affecting its community integration. This is

Re: [compress] Including AL Code from other projects

On 2009-01-08, Antonio wrote: > Well... who is to say that we all didn't steal the code from our > employers and commit it? Everyone of us claimed it when we signed the CLA before getting commit access (well, people as old as me may have committed stuff before signing the CLA, but it applied to

Re: [g...@vmgump]: Project commons-vfs (in module apache-commons) failed

On 2009-01-12, Ralph Goers wrote: > OK. Someone more knowledgeable in Gump is going to have to explain to > me why this failed even though the build succeeded. I'll be happy to. > I can see that it is looking for commons-vfs-2.0-SNAPSHOT.jar? That > jar is created by vfs-core and ends up in cor

Re: [g...@vmgump]: Project commons-configuration-test (in module apache-commons) failed

On 2009-01-12, Ralph Goers wrote: > I could also use some help understanding why these tests are failing. > I can't duplicate these failures. The tests only fail if you use Gump-built artifacts (i.e. trunk instead of the specified versions) for the dependencies. I haven't figured out which arti

Re: [g...@vmgump]: Project commons-configuration-test (in module apache-commons) failed

On 2009-01-12, Ralph Goers wrote: > On Jan 12, 2009, at 7:49 AM, Stefan Bodewig wrote: >> I haven't figured out which artifact it is that breaks configuration's >> tests - but must admit that I didn't try too hard since nobody seemed >> to be interested any

Accessing Reports of Failing Tests in Gump (was Re: [g...@vmgump]: Project commons-configuration-test (in module apache-commons) failed)

If you look at the bottom of http://vmgump.apache.org/gump/public/ivy/ivy-tests/index.html you see links to all the test reports, this is achieved by the element in the Gump descriptor. I have just now added such an element to the descriptor of commons-configuration-test and hope that I've

Debugging Gump Failures for mvn Projects (was Re: [g...@vmgump]: Project commons-configuration-test (in module apache-commons) failed)

Hi all, to be honest I'm not familiar enough with mvn to really know how to debug things, but I'll explain how Gump and mvn play together and toss out some ideas. Maybe at the end of the thread we will know how to really debug things. If you can come up with a better idea, I'll be grateful. Par

Re: [g...@vmgump]: Project commons-configuration-test (in module apache-commons) failed

I've just removed all dependencies from commons-configuration to show that the tests pass and plan to add Xerces and Xalan back in to see whether it really is the XML part that is causing the problems. Stefan - To unsubscribe, e-

Re: [g...@vmgump]: Project commons-configuration-test (in module apache-commons) failed

On 2009-01-13, Stefan Bodewig wrote: > I've just removed all dependencies from commons-configuration to show > that the tests pass this part worked, the build passed. > and plan to add Xerces and Xalan back in to see whether it really is > the XML part that is causing the pr

Re: [g...@vmgump]: Project commons-configuration-test (in module apache-commons) failed

On 2009-01-14, Stefan Bodewig wrote: > On 2009-01-13, Stefan Bodewig wrote: > The next Gump build (after the currently running one) will use Xerces' > and xml-api's trunk. The tests still passed. Next u

Re: [g...@vmgump]: Project commons-configuration-test (in module apache-commons) failed

There have been two changes in parallel, vmgump switched to Java6 and Xalan has been added as a dependency. Given that the tests passed on gump.zones.ao before I added Xalan (and this has been running Java6 before), I'd suggest that the configuration committers experiment with using Xalan 2.7.1 in

Re: [g...@vmgump]: Project commons-configuration-test (in module apache-commons) failed

On 2009-01-17, Oliver Heger wrote: > Stefan Bodewig wrote: >> There have been two changes in parallel, vmgump switched to Java6 and >> Xalan has been added as a dependency. >> Given that the tests passed on gump.zones.ao before I added Xalan (and >> this has been

Re: [g...@vmgump]: Project commons-configuration-test (in module apache-commons) failed

On 2009-01-18, Oliver Heger wrote: > Stefan Bodewig wrote: >> On 2009-01-17, Oliver Heger wrote: >>> I tried this locally, and everything seems to be fine. >> Then the change that breaks your tests must have occured in trunk >> after the release - or Gump is now

Re: [g...@vmgump]: Project commons-configuration-test (in module apache-commons) failed

On 2009-01-19, Oliver Heger wrote: > Stefan Bodewig schrieb: >> The currently failing build of configuration-test uses the configured >> depenencies and downlads them from Maven central except for: >> * Xerces >> * Xalan >> * xml-apis >> * xml-resolver &

[compress] Which Java version to use?

Hi all, I've just merged two changes made to the Ant zip code base - commons-compress' great-grand-parent - into the sandbox and intend to keep doing this as we make changes in Ant. There is another change in Ant that may lead to a tiny performance improvement by using JDK 1.4 collections (Linked

[general] How to link JIRA issues and commits

Hi all, since I'm sort of a new commons committer (technically I've always been, I've just not used it much) I'm unsure whether there is a policy of how you connect svn commits and JIRA issues around here. So far I've named the JIRA issue in the commit message and noted the svn revision inside a

Re: [general] How to link JIRA issues and commits

On 2009-02-04, Rahul Akolkar wrote: > On Wed, Feb 4, 2009 at 12:14 AM, Stefan Bodewig wrote: >> So far I've named the JIRA issue in the commit message and noted the >> svn revision inside a comment to the JIRA issue. Is there anything >> else I should have done like

Re: [general] How to link JIRA issues and commits

On 2009-02-04, Mark Fortner wrote: > I'm not a committer to the project, but I've worked on other projects with > svn and JIRA. If you use the Eclipse, there's a plugin called Mylyn that > you can use that makes this process a little easier. Thanks for the pointer Mark. I've read about Mylyn a

[jira-admin] Please add me to the commons-developer group

Hi, could anybody with the required JIRA privs please add me (the account is bodewig) to the commons developer group? I'd love to be able to assign bugs to myself, at the very least. Thanks Stefan - To unsubscribe, e-m

[compress] SANDBOX-246 remaining Findbugs issues

Since Sebb's original report the code base has changed quite a bit so I reran findbugs. I've fixed most of them, still open are: * JarArchiveEntry certificates and manifestAttributes is never written to, so they are useless. I'm unsure of the class' purpose and simply left things as they are

Re: [compress] SANDBOX-246 remaining Findbugs issues

On 2009-02-05, Christian Grobmeier wrote: >> * ZipOutputStream contains some proteted static final byte[] >> "constants" >> This means any subclass could modify them. Findbugs suggests to >> make the package private. Ant couldn't do that because of backwards >> incompatibility, but a sandb

Re: [dbutils] karma Re: Request sandbox access

On 2009-02-07, Dan Fabulich wrote: > Assuming I don't yet have karma to write to the sandbox, may I > politely ask someone to grant it to me? Should be done now. Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.

[compress] Some merging in zip package

Hi, I've merged ZipEntry into ZipArchiveEntry and ZipOutputStream into ZipArchiveOutputStream. As a side effect ZipArchiveOutputStream now supports encoding of file names and the zip file comment (among other things that it does better than java.util.zip.ZipOutputStream like providing usable Unix

[compress] Let Archive*Stream and Compressor*Stream extend Filter*Stream

Hi, I change ArchiveOutputStream extend FilterOutputStream while I modified ZipArchiveOutputStream and it seems a very natural thing to do for all the other streams as well. All concrete compressor/archiver streams have constructors that take a different stream as their argument and most of them

Re: [compress] Some merging in zip package

On 2009-02-10, Torsten Curdt wrote: >> Ant never had a ZipInputStream replacement, we only use ZipFile since >> the zip format is a lot easier to implement on top of >> RandomAccessFile. > Hm ... never thought this would be a problem for just reading. You need to merge data from the local file

Re: [compress] Let Archive*Stream and Compressor*Stream extend Filter*Stream

On 2009-02-10, Torsten Curdt wrote: > No particular objections. Not sure it helps much though :) True. I'll probably try to find out why ZipArchiveOutputStream extended FilterOutputStream in the first place - probably because java.util.zip.ZipOutputStream does and Ant's class should be as close

Re: [compress] Let Archive*Stream and Compressor*Stream extend Filter*Stream

On 2009-02-10, Stefan Bodewig wrote: > On 2009-02-10, Torsten Curdt wrote: >> No particular objections. Not sure it helps much though :) > True. Actually it hurts. Via FilterOutputStream a call to ArchiveOutputStream.flush() would suddenly flush the wrapped stream where it had

Re: [compress] Some merging in zip package

On 2009-02-10, Mark Fortner wrote: >>> ZipArchiveOutputStream will now use the platform's native encoding >>> instead of UTF8 by default now, while JarArchiveOutputStream >>> explicitly sets the encoding to UTF8. Does anybody consider this a >>> problem? > What happens if you try to take a fil

Re: [compress] Some merging in zip package

On 2009-02-10, Mark Fortner wrote: > I meant specifically if I was using this library at both ends of the > equation. Then if you don't specify an encoding explicitly, you will have a problem, yes. Of course only, if your file names have non-ASCII characters in the first place since most native

Re: [compress] Some merging in zip package

On 2009-02-10, Christian Grobmeier wrote: > Can this be simulated when creating a file within testcase and then > changing java.encoding stuff and extracting it again? Likely. I'm not sure whether String#getBytes consults the system property for each invocation. > If so I can write a testcase

Re: [compress] Some merging in zip package

On 2009-02-11, Torsten Curdt wrote: > I am also not so sure this really all that bad. I guess there are 3 scenarios > 1: the archive standard is known to use a specific encoding > 2: the encoding is specified inside the archive (which is similar to 1) > 3: we have no clue about the encoding of t

Re: [compress] Some merging in zip package

On 2009-02-11, sebb wrote: > That seems likely to produce some confusion - would it not be better > to default to UTF-8? Yes, that's been my initial question. Is it OK to have no default at all or should we keep with UTF-8? Given that ZipArchiveInputStream doesn't support anything but UTF-8 at

Re: [Compress] what Java version is targetted? Pom does not specify

On 2009-02-11, sebb wrote: > The Compress pom.xml does not specify what Java version is being > targetted. Last week it was 1.4 > Perhaps someone could add the source/target properties? No idea how to do that and the POM reference didn't tell me either. Please forgive the mvn neophyte. Stefan

Re: [Compress] what Java version is targetted? Pom does not specify

On 2009-02-12, Christian Grobmeier wrote: > Here it is: > https://issues.apache.org/jira/browse/SANDBOX-288 applied, thanks. > You have to check the compiler-plugin for the information: > http://maven.apache.org/plugins/maven-compiler-plugin/examples/set-compiler-source-and-target.html Thanks

<    5   6   7   8   9   10   11   12   13   >