[RESULT] Release Compress 1.6 based on RC3

With +1s by Torsten Curdt Emmanuel Bourg Benedikt Ritter Gary Gregory Stefan Bodewig and no other votes the vote has passed. I'll copy around the release artifacts but will give the mirrors a bit of time to catch up before I announce the release and update the site. S

Re: svn commit: r1535923 - in /commons/proper/compress/trunk: pom.xml src/site/site.xml

On 2013-10-26, sebb wrote: > On 26 October 2013 06:30, wrote: >>> >>>org.apache.maven.plugins >>>maven-scm-publish-plugin >>> >>> >>>javadocs** > That expression looks a bit odd. > Should it be as follows? > javadocs/** No idea, this is st

[ANNOUNCE] Apache Commons Compress 1.6 Released

-234. Thanks to BELUGA BEHR. 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 Apache Commons commu

[compress] Build Problems with JDK8

Hi, I'm currently using JDK 1.8 build 113 on some projects as we had reports of incompatibilities on the Gump list. It may be worth doing that for other components as well. Anyway, two tests fail, both for the same reason: org.tukaani.xz.XZIOException: Stream finished or closed at org.tukaa

Re: can't move files from dev to release

On 2013-10-28, Henning Schmiedehausen wrote: > Seems I am missing some permissions here. I filed > https://issues.apache.org/jira/browse/INFRA-6942 for that. Not exactly sure but ISTR you also get this response when you try to overwite an existing file using mv - cp is fine. In the interim I can

Re: can't move files from dev to release

On 2013-10-28, Stefan Bodewig wrote: > In the interim I can move the files for you - at least last Saturday I > posessed the karma required to do so. Done, but there didn't seem to be a README to replace the existing one wi

Re: can't move files from dev to release

On 2013-10-28, Henning Schmiedehausen wrote: > Thanks Stefan. I will look into the README issue. I've modified the README doing s/1.9/1.10/g Let me know if more needs to be done. Stefan - To unsubscribe, e-mail: dev-unsubscr..

Re: Huh? Only two people can do releases?

release > software. > I know that one is Stefan Bodewig. Can one of you please open a ticket with > infra as requested. I'm hardly the only PMC member around :-) Stefan - To unsubscribe, e-mail: dev-unsubscr...@c

Re: Huh? Only two people can do releases?

On 2013-10-28, Henning Schmiedehausen wrote: > Sorry for singling you out, Stefan; np > again thanks a lot for moving the files over. I will fix the README > later today. Would it be possible that you also remove the 1.9 files > from the binaries and sources folders? will do so in a few hours,

[VOTE] Allow "plain committers" to publish releases

Hi all making this a formal vote so it doesn't fall through the cracks. We allow committers who are not PMC members to be release managers but they are not allowed to write to the release branch of the dist repository. This seems to be the default setting for the dist repo and could be easily fi

Re: [VOTE] Allow "plain committers" to publish releases

On 2013-11-05, Mark Thomas wrote: > Arguably any committer involved enough in the project to be a release > manager should be on the PMC. unless we overlook that he/she isn't, I agree. > (I assume that Nexus is already configured this way else that will > need tweaking too.) Yes. This vote ste

Re: Snapshot vs. release sites.

On 2013-11-07, sebb wrote: > On 6 November 2013 15:53, Gary Gregory wrote: >> Hi All: >> I find it unhelpful and confusing at times to see Commons sites for >> -SNAPSHOT version. > +1, it's annoying and unhelpful to have the main site refer to a > version that has not been released. I tend to

[RESULT] Allow "plain committers" to publish releases

Hi all I count +1s by Stefan Bodewig Emmanuel Bourg Phil Steitz Luc Maisonobe Henning Schmiedehausen and a +0 by Mark Thomas so the vote has passed. I've opened INFRA-6978. Stefan - To unsubscribe, e-mail: dev-uns

Re: [RESULT] Allow "plain committers" to publish releases

On 2013-11-08, Stefan Bodewig wrote: > I've opened INFRA-6978. which has just been resolved. Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] Release of Commons Collections 4.0 based on RC4

+1 for the release Thanks for your patience Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org

Re: [COLLECTIONS] Advice on API Changes?

On 2009-09-17, Henri Yandell wrote: > Though it wouldn't make Gump's life any easier. In fact life would get > worse until they set up a separate v3 version anyway. Which I think is > what's happened for Lang. Yes this is what we did - and likely will do for collections. So the answer to my ini

Re: [COLLECTIONS] Advice on API Changes?

On 2009-09-18, Stefan Bodewig wrote: > On 2009-09-17, Henri Yandell wrote: >> Though it wouldn't make Gump's life any easier. In fact life would get >> worse until they set up a separate v3 version anyway. Which I think is >> what's happened for Lang. &g

Re: [COLLECTIONS] Advice on API Changes?

On 2009-09-18, Henri Yandell wrote: > On Thu, Sep 17, 2009 at 9:08 PM, Stefan Bodewig wrote: >> On 2009-09-18, Stefan Bodewig wrote: >>> On 2009-09-17, Henri Yandell wrote: >>>> Though it wouldn't make Gump's life any easier. In fact life would get &g

Re: [lang] Lang package name change. Was: [(LANG-561) unescapeHtml has been dropped without going through deprecation]

On 2009-12-09, sebb wrote: > Also, we probably ought to make 2.x the 'default' Gump project for > LANG, so other projects have to deliberately choose lang-3. I'd assume the Maven groupId would change as well, so any projects building with mvn will only ever see one of either. For Ant and Maven

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 r

[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 c

[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 lower

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 tha

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 m

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

On 2010-02-18, Mladen Turk wrote: > On 02/18/2010 11:13 AM, Gump wrote: >> To whom it may engage... >> -ERROR- Missing Output: >> /srv/gump/public/workspace/apache-commons/daemon/dist/commons-daemon-18022010.jar >> -ERROR- Missing Output: >> /srv/gump/public/workspace/apache-commons/daemon/

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

On 2010-02-18, Mladen Turk wrote: > On 02/18/2010 01:09 PM, Stefan Bodewig wrote: >> For commons-daemon the descriptor assumes there'd be an Ant property >> named component.name that it needs to override on the command line in >> order to get a reproducable file name.

Re: svn commit: r911797 - /commons/proper/compress/trunk/src/changes/changes.xml

On 2010-02-19, Torsten Curdt wrote: > While I am fine with the changes itself I find the naming "canRead" on > an InputStream a little ambiguous. > Maybe "canReadArchiveEntry"? Open to other suggestions. I'm not attached to names and can live with either. I don't feel stream.canRead(anEntry) is

Re: svn commit: r911797 - /commons/proper/compress/trunk/src/changes/changes.xml

On 2010-02-20, Torsten Curdt wrote: >> Then maybe: >> canReadEntry(entry) >> canWriteEntry(entry) >> to go confirm with: >> getNextEntry() > Better ... but still. I've already read the entry and then ask whether > I can read it (again)? Technically you haven't read the entry but only its met

Re: svn commit: r911797 - /commons/proper/compress/trunk/src/changes/changes.xml

On 2010-02-22, Torsten Curdt wrote: > On Mon, Feb 22, 2010 at 06:11, Stefan Bodewig wrote: >> Technically you haven't read the entry but only its metadata and are now >> asking whether you can also read the actual contents of the entry. > Right. So wouldn't

Re: [codec] gump failure

On 2010-02-24, Julius Davies wrote: > What's this about? Is this something we should take seriously? It says commons-codec is no longer producing the jar Gump expects it to create. Gump uses something close to ant -Dcomponent.version=23022010 dist to build commons-codec and currently the res

[COMPRESS] Jar*Stream COMPRESS-18

Hi, while investigating an Ant issue I recently had a look at how Harmony implements JarInputStream and friends. If we wanted to enable the usual JarEntry fields on top of ZipArchiveInputStream we'd be forced to re-implement the whole verification process for signed jars that the class library ca

Re: [COMPRESS] Jar*Stream COMPRESS-18

On 2010-03-04, sebb wrote: > On 04/03/2010, Stefan Bodewig wrote: >> The more I think about this, the more I believe we should make >> JarArchiveInputStream use the java.util.jar package rather than extend >> ZipArchiveInputStream - this would also mean we'd break

Re: [COMPRESS] Jar*Stream COMPRESS-18

On 2010-03-05, sebb wrote: > On 05/03/2010, Stefan Bodewig wrote: >> On 2010-03-04, sebb wrote: >>> On 04/03/2010, Stefan Bodewig wrote: >>>> The more I think about this, the more I believe we should make >>>> JarArchiveInputStream use th

[compress] Please Review COMPRESS-18

Hi, I've attached a patch that would fix COMPRESS-18 at the price of sacrificing backwards compatibility of the jar package to COMPRESS-18. I'm not sure whether the impact of that change is small enough to allow the patch in or whether it is not acceptable, that's why I haven't committed it direct

Re: FW: Compress 1.1 release?

On 2010-03-10, Simon Tyler wrote: > Do we have a date yet for the compress 1.1 release? What Christian said. > Also, is there time to add a couple of minor feature enhancements? I could > do with access to the following: > 1. A public method to check if a ZipArchiveInputStream has a data > des

Re: FW: Compress 1.1 release?

On 2010-03-11, Christian Grobmeier wrote: > Stefan/Torsten - you are mainly active on compress right now, how is > the state? So far I don't itend to make any changes before the release, unless Simon's changes are really small. If COMPRESS-18 gets accepted it may need some documentation updates

Re: Compress 1.1 release?

On 2010-03-12, Simon Tyler wrote: > If I explain the scenario in more detail then it might become clearer. > I am seeing issues with certain zip files and file format based on zip (such > as docx and zip). We are reading these files from a stream so are using the > ZipArchiveInputStream. > What

Re: Compress 1.1 release?

I got it wrong, ZipArchiveInputStream relied on the data descriptor to have a signature - it will now deal with entries without one as well. Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional comma

Re: Compress 1.1 release?

On 2010-03-12, Simon Tyler wrote: > The file called Word.xps at: > http://www.wssdemo.com/XPS/Forms/AllItems.aspx > exhibits the problem. COMPRESS-103 > You are entirely correct the entry is STORED so COMPRESS-100 does the > trick for me. Well, it will signal an error but not allow you to sk

Re: [ALL] protections on commons websites and dist

On 2010-04-30, sebb wrote: > It looks as though there are also some problems with the file and > directory protections for the commons websites, which are located on > minotaur (people) under: > /www/commons.apache.org > There are quite a lot of files which don't have group commons. > I think t

Re: [compress] New release soon?

On 2010-05-05, Christian Grobmeier wrote: > The review has been asked from Stefan Tue, Mar 9, 2010 at 7:35 PM Its > on COMPRESS-18, but my last inforamtion was its not in the codebase This is correct. I'm not sure whether we want to fix COMPRESS-18 for 1.1 at all or simply postpone that. Stefa

Re: svn commit: r941242 - in /commons/proper/compress/trunk: RELEASE-NOTES.txt src/changes/changes.xml

On 2010-05-05, wrote: > Changes: >> o COMPRESS-106: Remove unnecessary method >> ZipFile.OFFSET_COMPARATOR.new Comparator() {...}.equals(Object o) That method never existed in 1.0, it was added and later removed between 1.0 and now. I may have a different idea about what constitutes REL

Re: svn commit: r941242 - in /commons/proper/compress/trunk: RELEASE-NOTES.txt src/changes/changes.xml

On 2010-05-05, sebb wrote: > That part of the change has been reverted. Thank you Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org

Re: [COMPRESS] Tar directory name format - append / ?

On 2010-05-10, sebb wrote: > For consistency, I propose to append the "/" to directory names if > required when parsing a tar file. +1 Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands

Re: [COMPRESS] Add getArchiveType() method to [Archive|Compressor]InputStream classes?

On 2010-05-12, sebb wrote: > Can we restart this? > Compress currently has Archiver and Compressor InputStreamFactory > classes which have the following signatures: > public ArchiveInputStream createArchiveInputStream( > final String archiverName, final InputStream in) > public Co

Re: [COMPRESS] Add getArchiveType() method to [Archive|Compressor]InputStream classes?

On 2010-05-14, sebb wrote: > On 14/05/2010, Stefan Bodewig wrote: >> On 2010-05-12, sebb wrote: >>> Can we restart this? >>> Compress currently has Archiver and Compressor InputStreamFactory >>> classes which have the following signat

Re: [COMPRESS] Add getArchiveType() method to [Archive|Compressor]InputStream classes?

So for I don't think we are really in any sort of disagreement, so we should be able to cut this thread soon 8-) On 2010-05-14, sebb wrote: > On 14/05/2010, Stefan Bodewig wrote: >> On 2010-05-14, sebb wrote: >>> On 14/05/2010, Stefan Bodewig wrote: >>

Re: [compress] Last issues before 1.1

On 2010-05-21, Christian Grobmeier wrote: > COMPRESS-75 > ZipArchiveInputStream does not show location in file where a problem occurred > Seems to be fixed Agreed (with the "seems to be fixed" part). > COMPRESS-113 > TarArchiveEntry.parseTarHeader() includes the trailing space/NUL when > parsing

Re: [compress] Last issues before 1.1

On 2010-05-22, Christian Grobmeier wrote: >> What about COMPRESS-108 - Command-line interface? >> Any objections if I add it to SVN, and change the pom to define it as >> the Main-Class? > I was under the impression that it was a first draft. If you feel > thats already doing whats expected of i

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

On 2010-06-27, Emmanuel Bourg wrote: > Le 26/06/2010 15:34, Oliver Heger a écrit : >> Does anybody have an idea what is going on here? It seems that the tests >> related to XML processing are broken. > No idea, this isn't the first time Gump breaks on the test cases > involving a XML parser. > T

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

On 2010-06-28, Stefan Bodewig wrote: > Inside Gump you get the trunk of Xerces and the trunk of xml-commons' > java/external. Right now it looks as if Xerces wouldn't see the > xml-apis jar you've downloaded (since that should contain > ElementTranversal). It may be

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

On 2010-06-28, Oliver Heger wrote: > Maybe it helps GUMP to update the Xerces version. No, the version inside the POM doesn't make any difference for Gump because it is completely ignored - you will always get Xerces' trunk from Gump anyway. Stefan --

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

On 2010-06-26, Oliver Heger wrote: > Does anybody have an idea what is going on here? It seems that the > tests related to XML processing are broken. Mea culpa. It seems to be working again now. For a few days Gump was broken and really provided the version of xml-apis that mvn built projects a

[JEXL] Problem Integrating JEXL 1.x Branch and Cocoon 2.2.x

Hi, after a very long time Gump has started to build larger parts of Cocoon again and we've run into an issue. Cocoon's expression language uses JEXL 1.x and in Gump it builds against the the 1.x svn branch of JEXL. Unfortunately the VelPropertyGet interface inside that branch contains a method

Re: [JEXL] Problem Integrating JEXL 1.x Branch and Cocoon 2.2.x

Thank you for looking into this Henrib On 2010-07-01, henrib wrote: > I've had a quick look at the jexl-1.x source; the VelPropertyGet.isAlive > method is not called anywhere in jexl's code or tests. Commenting it out > from the interface does the trick. > The real problem lies in changing this p

Re: [JEXL] Problem Integrating JEXL 1.x Branch and Cocoon 2.2.x

On 2010-07-01, Stefan Bodewig wrote: > On 2010-07-01, henrib wrote: >> A cleaner more future-proof alternative might be to use jexl-2 and the >> jexl-1 compatibility layer which is part of the distribution as source only >> ( >> http://svn.apache.org/viewvc/commons/pro

Re: [JEXL] Problem Integrating JEXL 1.x Branch and Cocoon 2.2.x

On 2010-07-01, Stefan Bodewig wrote: > From a Gump POV if you ever expect to do another JEXL 1.x release we > should keep tracking the branch and help the JEXL and Cocoon devs > figure out which way to go. If the branch is a dead-end anyway, we > can as well stop tracking it and prov

Re: [NET] Make 2.x branch into trunk and 1.x into branch

On 2010-07-12, sebb wrote: > There does not seem to be any need for a further release of the NET > 1.x line, which is currently the trunk version, so I propose to: > * rename trunk as branches/NET_1_x > * rename branches/NET_2_0 as trunk +1 A while back the Ant folks were informed that the FTP

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

it looks as if the jaxme taglib was incompatible with newer versions of jaxme which isn't too surprising. It doesn't look as if anybody was interested in keeping Jelly up-to-date, shall we remove the Gump build of the jaxme tags? Stefan ---

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

I don't know what triggered the test failures, but in some cases tests now fail because the order of namespace declarations is different from the expected order - while the XML documents themselves should semantically be the same. Is anybody interested on looking into this or should we disable the

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

Some change in Ant has broken the property handling in the Jelly/Ant integration. By manually replacing jars in my local repository I found out that the tests pass with Ant 1.8.0 but fail with 1.8.1. Given that Ant's property handling has changed dramatically in 1.8.x and Ant even marked this as

Re: [compress] release 1.1?

On 2010-07-19, Torsten Curdt wrote: > Ups - thought we already released it!? What about a release now-ish? +1 in general, but I'll be on vacation until end of July with only random internet access (like just now 8-) so won't be much help over the next two weeks. Stefan -

Re: [compress] release 1.1?

On 2010-07-20, Torsten Curdt wrote: > ...maybe then there is one more thing to squeeze in then > ...or at least start the discussion so you can think about while lying > in the sun ;-) In my case it's more like herding cats, err, kids. > I was thinking... > whenever one want to get to the prope

Re: [compress] release 1.1?

On 2010-07-22, Torsten Curdt wrote: >> Between 1.0 and 1.1 I pushed getLastModifiedDate into ArchiveEntry to >> simplify a very common case. > Maybe we should add some more there. >>> If a particular ArchiveEntry doesn't support e.g. getGroup() it would >>> just return null ...but I am a little

Re: [compress] release 1.1?

On 2010-08-02, Jukka Zitting wrote: > Hi, > On Tue, Jul 20, 2010 at 10:57 AM, Torsten Curdt wrote: >> ...maybe then there is one more thing to squeeze in then > Unless there's already a ready patch for this, I'd rather see the 1.1 > release out than wait for a new improvement. +1 We'll probab

Re: [compress] release 1.1?

On 2010-08-02, Torsten Curdt wrote: >> class PosixAttributes { >>    /* nine constants */ >>    static final int OWNER_CAN_READ = ... >>    /* set of the constants that apply */ >>    Set getPermissions(); >>    /* could be mixed with permissions if we wanted to */ >>    Boolean isSetUserId(); >

Re: [lang] Usage statistics

On 2010-08-07, Oliver Heger wrote: > For instance, are there statistics about downloads from the Maven > central repository or something like that? Since mvn itself and lots of the mvn plugins use commons-lang such a statistic would only tell you how many people use mvn and not whether the projec

Re: [VOTE] Release Commons Compress based on RC1

On 2010-08-10, Christian Grobmeier wrote: > Site: > http://people.apache.org/builds/commons/compress/1.1/RC1/ Talks about 1.0 being the latest release at several places, easy to be fixed later and indepent of the release. > Binaries: and sources > https://repository.apache.org/content/reposit

Re: Future of RAT

On 2010-08-10, Mattmann, Chris A (388J) wrote: > However, I'm not sure I get the whole reasoning below RE: TLP? Why not > have a RAT TLP? The overhead of filing board reports and not knowing > anyone on the team that would be able to? Jochen has sure be joking here. The team list he pointed at c

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

On 2010-08-12, Gump wrote: > [INFO] Compilation failure > /srv/gump/public/workspace/apache-commons/lang/src/main/java/org/apache/commons/lang3/reflect/ConstructorUtils.java:[272,52] > incompatible types > found : java.lang.reflect.Constructor[] > required: java.lang.reflect.Constructor[] This

Re: [VOTE] Release Commons Compress based on RC1

On 2010-08-12, Torsten Curdt wrote: > Should be fixed in trunk. thanks. > That said: The README is not what I would expect. > I would expect that content to be in the NOTICE. COMPRESS-72 > ...but anyway - let's give it another go? Do you feel this requires another go? So far my vote count is

Re: [VOTE] Release Commons Compress based on RC1

On 2010-08-12, Christian Grobmeier wrote: >>> ...but anyway - let's give it another go? >> Do you feel this requires another go?  So far my vote count is 3 +1s and >> and one -1 which means it is one its way to pass. > Two voted -1: Sebastian + Torsten I thought Torsten was just quoting sebb -

Re: [VOTE] Release Commons Compress based on RC1

On 2010-08-12, Torsten Curdt wrote: > ...but I do think we should remove the dists from the maven repo and > fix them to have the READMEs included. Not sure that makes it a full > +1 or not :) Looks as if Christian deems it important enough to re-roll, so let's just do that. Stefan

Re: [VOTE] Release Commons Compress based on RC2

On 2010-08-13, Christian Grobmeier wrote: > Tag: > https://svn.apache.org/repos/asf/commons/proper/compress/tags/commons-compress-1.1/ > Site: > http://people.apache.org/builds/commons/compress/1.1/RC2/ > Binaries: > https://repository.apache.org/content/repositories/orgapachecommons-098/org/

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

On 2010-08-16, Oliver Heger wrote: > Does anybody have an idea what breaks Gump? Looks as if multiple > projects are affected. An idea, yes, but didn't have time to analyze it. Shortly before this - and velocity-engine-test - started breaking I realized Gump was using the CVS HEAD of hsqldb whic

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

On 2010-08-16, Rahul Akolkar wrote: > For the two scxml test failures, there is no such usage. I think I'll > let things settle some before taking a look. No, for scxml things are different. Until last week Gump didn't build scxml (or Sanselan, or Proxy for that matter) and it failed right from

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

On 2010-08-16, Oliver Heger wrote: > Am 16.08.2010 22:03, schrieb Stefan Bodewig: >> On 2010-08-16, Oliver Heger wrote: >>> Does anybody have an idea what breaks Gump? Looks as if multiple >>> projects are affected. >> An idea, yes, but didn't have time

Re: scxml test failures in Gump

On 2010-08-17, Rahul Akolkar wrote: > On Mon, Aug 16, 2010 at 4:53 PM, Stefan Bodewig wrote: >> On 2010-08-16, Rahul Akolkar wrote: >>> For the two scxml test failures, there is no such usage. I think I'll >>> let things settle some before taking a look. >&

Re: scxml test failures in Gump

On 2010-08-17, Rahul Akolkar wrote: > On Tue, Aug 17, 2010 at 11:59 AM, Stefan Bodewig wrote: >> On 2010-08-17, Rahul Akolkar wrote: >>> On Mon, Aug 16, 2010 at 4:53 PM, Stefan Bodewig wrote: >>>> On 2010-08-16, Rahul Akolkar wrote: >>>>> For

Re: [nexus] Releasing with nexus

On 2010-08-18, Christian Grobmeier wrote: > I cannot speak for infra - you know more. If following your path I would: > - wget the stuff to people > - check the hashes > - copy stuff to dist > - remove commons-compress-1.1-bin.* and commons-compress-1.1-src.* from nexus > - hit nexus release butt

Re: [nexus] Releasing with nexus

On 2010-08-18, Christian Grobmeier wrote: > Is that correct? I have no problems with doing it like this but would > like to find some consens on the commons project. I should add that this discussion shouldn't stop you from just doing it. "it" being > - wget the stuff to people > - check the has

[Compress] Nexus Promotion Gone Wrong?

Hi, at least from where I sit only contains the binary jar and the POM, no checksums, no signatures. Is the promotion still going on and I need to re-check later? Is this expected behavior? Stefan

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

On 2010-08-17, Oliver Heger wrote: > The test tries to execute a CLEAN_INSERT database operation in order > to setup test data in the database which results in the following > error: > It seems like the table is no more created automatically? hsqldb 2.x (which is the trunk Gump is building) has

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

On 2010-08-27, Oliver Heger wrote: > Am 23.08.2010 11:49, schrieb Stefan Bodewig: >> On 2010-08-17, Oliver Heger wrote: >>> The test tries to execute a CLEAN_INSERT database operation in order >>> to setup test data in the database which results in the following >&g

Re: scxml test failures in Gump

On 2010-08-27, Rahul Akolkar wrote: > It'd be great if you or anyone else with access to vmgump could try a > 'mvn test' on a fresh scxml trunk checkout and see if we get the same > 2 failures. No, that works just fine. > Since this was never passing in a gump run, I'd like to get that > baselin

Re: [commons-compress] traditional zip encryption patch to come

On 2016-02-15, Bear Giles wrote: > We discussed adding support for the traditional zip encryption algorithm a > while back. IIRC the concensus was loosely against it since it's so weak > and we don't want to mislead people. I'm pretty sure we should ad a big warning about the quality of encryptio

Re: [commons-compress] traditional zip encryption patch to come

On 2016-02-16, Bear Giles wrote: > I can create test files. (I still need to create some PKWare test files as > well...). This would be good. > I also need to figure out a way to extract the encrypted content to I > can verify my implementation of the crypto logic itself. I think that > will jus

Re: [compress] BZip2 block size is invalid

On 2016-02-21, Gary Gregory wrote: > Caused by: java.io.IOException: BZip2 block size is invalid > at > > org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.init(BZip2CompressorInputStream.java:251) Are you sure this is a valid bzip2 file - i.e. can command line

[compress] 1.11 RC in about two weeks?

Hi all it looks as if we had a decent set of changes for a new release. There are a few ongoing things that I know of, but haven't got a clear idea of when they might be done: * Damjan's changes to allow for non-File reading of ZIP (and with some effort of 7zip archives) - COMPRESS-327 * Bear'

Re: Request to add into Apache Commons Wiki contributors group

Hi Uma On 2016-03-15, Gangumalla, Uma wrote: > I would like to post Apache Commons Crypto proposal in Apache Commons > Wiki page. For this could you please add me into Wiki contributors > group? Should be done. Cheers Stefan

Re: [compress] 1.11 RC in about two weeks?

we can't. It's sftp only (and sftp doesn't support recursive operations). Stefan > Gary > On Tue, Mar 15, 2016 at 12:50 PM, Stefan Bodewig wrote: >> Hi all >> it looks as if we had a decent set of changes for a new release. There >> are a few ongoing thin

[compress] Trying to Pick up Compress2 Again

Hi all after more than two years of a hiatus I'd like to pick up the compress2 branch again. Back then we decided to embrace Java7 and I've taken the bold step of moving on to Java 8 now. On the API side Java8 is only used for java.time.Instant (for the last modified time of an entry). In additio

[compress] Need Help With Jenkins Failure

Hi the Compress build has started failing about a week ago and I can't seem to figure out why. The log says "compilation failure", but I don't see any. I've thrown in a -X for good measure, see https://builds.apache.org/job/Commons-Compress/66/consoleFull any ideas? The first failing build has

Re: [compress] Need Help With Jenkins Failure

On 2016-03-24, sebb wrote: > On 23 March 2016 at 20:51, Stefan Bodewig wrote: >> Hi >> the Compress build has started failing about a week ago and I can't seem >> to figure out why. The log says "compilation failure", but I don't see >> any

Re: [compress] Trying to Pick up Compress2 Again

On 2016-03-23, Stefan Bodewig wrote: > On the API side Java8 is only used for java.time.Instant (for the last > modified time of an entry). In addition I've used Java7's > SeekableByteChannel for random access and AutoCloseable in place of > Closeable. Actually I've

[compress] progress monitoring

Hi all https://issues.apache.org/jira/browse/COMPRESS-207 asks for progress tracking inside BZip2CompressorInputStream. As such I think the request is to narrow (why add it for bzip2 but not gzip2?) and I created the branch COMPRESS-207 for a prototypical implementation. This is incomplete since I

Re: [compress] 1.11 RC in about two weeks?

Hi all I don't intend to change anything in master before the 1.11 release anymore, so I've created a snapshot site at http://stefan.samaflost.de/staging/COMPRESS-1.11/ that you can use to look at the reports. If you see anything that should get addressed, please yell. Same if you want to add som

Re: [compress] progress monitoring

On 2016-03-28, Emmanuel Bourg wrote: > Le 27/03/2016 18:41, Stefan Bodewig a écrit : >> Is this a feature we generally want to see in compress? And if so, does >> the branch make sense or should we tackle this in a different way? > I like the idea of progress tracking, and the

[VOTE] Release Compress 1.11 Based on RC1

Hi all Foo 1.2 RC1 is available for review here: https://dist.apache.org/repos/dist/dev/commons/compress/ (svn revision 12931) Maven artifacts are here: https://repository.apache.org/content/repositories/orgapachecommons-1144/org/apache/commons/commons-compress/1.11/ Details of chan

Re: [VOTE] Release Compress 1.11 Based on RC1

On 2016-03-30, Gary Gregory wrote: > "Foo 1.2 RC1 is available for review here:" > ;-) I plead guilty on the crime of copy-paste reuse. Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional command

<    4   5   6   7   8   9   10   11   12   13   >