On Tue, Oct 11, 2011 at 11:21 AM, Stefan Bodewig <bode...@apache.org> wrote:
> On 2011-10-11, Gary Gregory wrote: > > > On Tue, Oct 11, 2011 at 10:20 AM, Stefan Bodewig <bode...@apache.org> > wrote: > > >> Hi all, > > >> its been quite some time since I finished the Zip64 stuff and I think we > >> are at the point we discussed three month ago or so: release Compress > >> 1.3 even if it doesn't have many big changes when compared to 1.2. In > >> addition to Zip64 we have read-only support for Unix dump and also > >> Pack200 "compression". Documentation is fairly complete IMHO. > > >> One thing that we may or may not want to address are the integration > >> tests for Zip64 which are currently only run when the run-it profile is > >> enabled. These tests need some zips generated by other tools that are > >> currently not part of svn and we discussed publishing them as separate > >> artifacts - personally I wouldn't even know where to start for this. > > >> Then we do have some JIRAs with patches in particular one for XZ > >> compression and patches for compressors where a single container stream > >> contains multiple compressed streams (I didn't know gzip and bzip2 could > >> do that, I must admit), all by Lasse Collin. > > >> The XZ patch has the "problem" that it introduces a new dependency - do > >> we want that or would we prefer a separate module? In addition XZ for > >> Java is not available via any Maven repo, yet, this may require some > >> tweaking during build time (Ant <get> task?). Shall we defer this until > >> after the 1.3 release? > > > Yes, release early, release often. > > > I am not in favor of code all over the place, it should all be in the > > project, whether or not or when it is run is a different story. > > > If these are data/resource files, why not put them in a resource jar in > MC? > > Are you talking about the zips needed for the ZIP64 tests? I should > have been clearer. Those zips have been generated by myself using > InfoZIP, WinZip and so on and all have the same contents (albeit all are > slightly different). > > By "put them in a resource jar in MC" you mean I'd assemble a single jar > file commons-compress-testresources-1.0.jar that contains all those zips > and publish it, right? > Yep. Because third party programs were used to create the files, they should be saved somewhere. We have two options: (1) SVN is not acceptable it seems. Could SVN even handle a giant file? (2) That leaves some place that the build can handle downloading and caching automatically, which is what Maven and Ivy are good at doing. Gary > > > If something is not in MC, you can always ask to have it put there. The > > issue is that you might have to edit the POM and rebuild the software if > the > > POM does not adhere to Apache/MC standards. > > In this case I'd have to write the POM myself anyway. > > Stefan > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0 Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
