Re: Status of the Sandbox?
On Mon, 19 Feb 2007 01:08:19 -0800, Henri Yandell [EMAIL PROTECTED] wrote: On 2/19/07, Torsten Curdt [EMAIL PROTECTED] wrote: compress - Despite our attempt to get this released, nothing seems to have happened here. Anyone? IMO the API still needs work. I was trying to implement another archiver and just gave up on it. With TrueZip working (but being far from perfect either) it is just very hard to justify the time investment in this. I hadn't realised TrueZip supported Tar and BZip as well. Having noticed that VFS was looking at that it does seem that Compress' days are numbered and we should send it to dormancy. There was discussion about TrueZip before: http://mail-archives.apache.org/mod_mbox/jakarta-commons-dev/200603.mbox/[EMAIL PROTECTED] Problem for compress is, that there where several attempts to contribute. But it's quite hard to contribute something, when noone of the comitters is interested in having this released. Thorsten comitted the interface stuff i wrote, but other attempts simply get lost. I know it's not easy to let everybody commit and it's lot of work to bring out a release, but it's still a bit frustrating. I have some code for compress at my local harddrive left which i never finished cause i realized that i am the only one who is interested in this release. And when i am the only one, send it to dormancy :-) Cheers, Chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Commons Parser
Hi all, i am connecting from an Java Appserver to MQ at the moment, and it's the fifth time in my life that i have to handle character-messages from a host. Usually i implement something static to interpret what the host tells me: HV101020060003TESTTESTTEST This String could be read at least like this: Mandant: HV Request-Date: 10.10.2006 Substructure count: 3 3 Substructures with the values: TEST I handle this quite often with substring() and such stuff but this means i have static javacode and when the structure changes, i change my code. Does anyone have similar problems sometimes? If so i wonder why there is no Commons Parser or something like that and if commons would like to have one. I would like to have: Definition d = new Definition(); // first is the name, then the length d.addField(mandant, 2); d.addSubstructure(MyStructure.class); With: new Parser().parse(String message, Definition d); i would like to get an OrderedMap or something like that. or something like that. This would it make easier to handle those streams. I don't have a implementation yet but i am thinking about making one and would like to know if somebody uses an existing lib for this (i didn't find one) and if this would be cool stuff for commons. Cheers, Chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
patch for compress (was: Re: How patching the homepage?)
The homepage is/will get generated by maven so patches to src/site are welcome ...and then someone just needs to get them online. Thanks. Sorry for that idiot question, i should have a closer look... Well here is a patch for the site. It moves out the old examples and includes a new one. Another thing: The packages org.apache.commons.compress.bzip2 has moved to org.apache.commons.compress.archivers.bzip2 Same for the zip package. The tar package has moved to org.apache.commons.compress.compressors.tar. But the old packages are still there as a copy. Can one delete em? This will be a problem, cause the new files have no history at all. Cheers, Chris Index: /Users/cy/Projects/commons-compress/src/site/xdoc/index.xml === --- /Users/cy/Projects/commons-compress/src/site/xdoc/index.xml (revision 477135) +++ /Users/cy/Projects/commons-compress/src/site/xdoc/index.xml (working copy) @@ -30,6 +30,7 @@ liIf you like the code and want to push it towards a release, join the mailing list!/li /ul /p +It is planned to add delete functionality for archives. /subsection /section @@ -40,11 +41,36 @@ liThe a href=http://svn.apache.org/viewcvs/jakarta/commons/sandbox/compress/;SVN repository/a can be browsed./li /ul /p +/section + +section name=A brief example p -There are also 2 example for the bzip2 API: +You can easily create a zip file with this piece of code: +source +Archive archiver = ArchiverFactory.getInstance(zip); +archiver.add( new File(C:\\Temp\\1.html)); +archiver.add( new File(C:\\Temp\\1.html.bz2)); +archiver.save( new File(C:\\Temp\\ZIPTEST.zip)); +/source +/p +p +Or simply decompress a file with gunzip: +source +Compressor decompressor; +decompressor = CompressorFactory.getInstance(bz2); +decompressor.decompressTo( new File(C:\\Temp\\asf-logo-huge.tar.bz2), + new File(C:\\Temp\\asf-logo-huge.tar)); +/source +/p +/section + +section name=More example classes +p +There are some example classes in the repository: ul - lia href=xref-test/org/apache/commons/compress/bzip2/example/Bzip2Compress.htmlBzip2Compress/a/li - lia href=xref-test/org/apache/commons/compress/bzip2/example/Bzip2Uncompress.htmlBzip2UnCompress/a/li + lia href=xref-test/org/apache/commons/compress/bzip2/example/ZipExample.htmlZip/a/li + lia href=xref-test/org/apache/commons/compress/bzip2/example/Bzip2Example.htmlBzip2/a/li + lia href=xref-test/org/apache/commons/compress/bzip2/example/TarExample.htmlTar/a/li /ul /p /section - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[compress] Next steps
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, i would like to start a discussion about the next steps of [compress]. Now that the first code has been checked in, i would like to figure out what we have to do for a 0.1 release. Ideas: - - simplify the interface as Mario suggested - - write the delete-features - - add recursivly files to the archivers - - refactor and rename old methods and types in the legacy classes - - rebuild java doc? Is this enough for a 0.1 release? Btw, i am not thinking that [compress] is a good name for this component- it does archiving aswell. Your comments are highly appreciated :-) Chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE0fwskv8rKBUE/T4RAmibAJ0euyzleXwc7P2638QA8oDFvf/6NgCggyIC 3ip+HgBIZ8006bYrK8CJk50= =JeKQ -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VFS][compress] Re: [EMAIL PROTECTED]: Project commons-compress (in module jakarta-commons-sandbox) failed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rahul Akolkar wrote: (added [vfs] to subject) On 7/31/06, Torsten Curdt [EMAIL PROTECTED] wrote: - commons-compress : Commons Compression Package - commons-vfs : Jakarta commons - excalibur-fortress-bean : Repository of reusable components. - excalibur-fortress-container-impl : Repository of reusable components. - excalibur-fortress-container-test : Repository of reusable components. - excalibur-fortress-examples : Repository of reusable components. - excalibur-fortress-migration : Repository of reusable components. - excalibur-fortress-platform : Repository of reusable components. - excalibur-fortress-testcase : Repository of reusable components. - excalibur-monitor : Repository of reusable components. - excalibur-sourceresolve : Repository of reusable components. - excalibur-xmlutil : Repository of reusable components. Bummer! ...I wasn't aware excalibur was already relying on that code! Now what? snip/ A quick look at the gump metadata seems to suggest that its a cascading effect of breaking [vfs]. compress - vfs - excalibur-sourceresolve - rest of the bunch Mario - Anything I can do to help get the next [vfs] RC out per your two-jar proposal? (might not be immediate help, but doesn't hurt to know) If i can help with [vfs] (testing, junit whatever) or with the gump error let me know. I have no idea of gump so pointers to what to do would be helpful :-) - - Chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEzvrpkv8rKBUE/T4RAsRDAJ9mliBNy0qw8n9Xmybaywc5Yq4PrACeJlqQ Pm3gckqLMmQ+860CyWU+sx4= =d9ae -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [compress] Draft 8
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Great :-) I am eager to do this delete stuff on top of this. - - Chris Torsten Curdt wrote: The grants has been received by Jim. I've merged the changes from Chris into my working copy of compress ...any objections to do a svn commit ? :-) Ok I will go ahead and commit it then :) cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEzeLgkv8rKBUE/T4RAn8HAJ9u6kYi06o47y8EvYX7nTvkugepyQCfYU89 h22qHIZ93+9vAYGpKu3nVjw= =ERsT -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs] split of vfs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Initially, this sandbox contains the following filesystems: * bz2 * tar * webdav * smb The user can activate them by simply plugging the commons-vfs-sandbox.jar into the classpath. I think this is a great idea?and would like to see that this way. This would also take some pressure from the compress project. For the legal issue: if this cannot be solved, a sf.net project would do fine. Maybe this is useful for other commons projects too? my2pence - - Chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEyJ2akv8rKBUE/T4RAkSfAJ41sr/34LXTA7sI3MR7kHrLPRNNqACgin3V +1B7sPVGpruD02P7MXNZgCI= =GCyR -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs] split of vfs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 What legal issues are you refering? - From the users mailinglist: * we depend on jcifs (samba/smb) which changed its license in the past to lgpl, so this is a violation of the ASF rules we currently investigate. (Mario) The ASF has prove it can create anything from scratch under the ASF license :) hehe truly :-) - - Chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEyJ/+kv8rKBUE/T4RAmMIAKCA2VOTtISdA23Yp+4wRbZ9qldIIgCdEsO7 zg63DwxD1IVal5n2+4KNbWY= =EWzJ -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs] split of vfs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This way the core would be independent of the implementation, as well building the .bz2 or something like will not be dependent of the external libs used only by the specifics like webdav, ftp, etc... If some implementation needs an external lib like httpclient, and others don't, then only that component should be dependent of it, not the entire package. i don't like these thousand mini-jars... must there be a vote for every one of these mini-jars? Makes lots of noise -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEyKBmkv8rKBUE/T4RAsmzAKCG6E22wFvojG7hVGJoKlBUAsPl+gCgj4Hj ez/itcSHmOD8XpZmdCGJpyU= =WUrF -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [compress] Status
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Niall Pemberton wrote: Slightly OT for this thread, but compress now has a nightly build: http://people.apache.org/builds/jakarta-commons/nightly/commons-compress/ That's great :-) Will email my fax number to Torsten/Chris and see if I can a) receive fax from Chris and b) give it to Jim at OSCON. I'll resend the fax this evening. Cheers, Chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFExNn7kv8rKBUE/T4RAv5kAJ4yPNHE9z8QKksaZe/i1O/4htrOBACgjs+O nvYsJqSNwYTiswk+5qn7d9I= =8G1W -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [compress] Status
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris - do you have any more recent changes or should we go with draft 8? I think it's better now to commit and let others participate. I have no recent changes and would like to wait till the code is in the repos. Regards, Chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEvdQekv8rKBUE/T4RAqJrAJ0eRO44O5LVrfDptsluTTcGb/BHDACfaRXY /hR9ug2NOPiZHkUpkRaNVrI= =6d8c -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[compress] Draft 8
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hey all, here is draft 8: * http://grobmeier.de/commons-compress-draft-8.zip I mainly have rebuild the factorys: - - Archiver is now know as Archive - - reduced reflection-magic - - Decompressor and Compressor is now know as Compressor (just one factory) - - some moves here an there I have to review comments, docs and if all methods a right in place, but that's the direction i like (at the moment ;-)) Please let me know what you think. Regards, Chris - -- Christian Grobmeier Possessed Management Hurlacher Str. 5 - 86853 Langerringen - Germany E-Mail: [EMAIL PROTECTED] Mobil: +(49)(0)175 57 66830 Fax: +(49) (0)8232 959119 Web: http://www.possessed.de -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEn9KLkv8rKBUE/T4RAs2dAKCOX3Lpzpuzn7V5rSudTJ4+iXFo1gCcCg1G Kjlzfk4ULmO4nsO9yKW7QMU= =D/rF -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [compress] Draft 8
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Some comments: * you use File*Streams instead of simply InputStream/OutputStream, any reason for this?If no, please change it accordingly. sorry, thought i changed that allready. I will do so * simplify the archiver interface. e.g. I think methods like save(File) are useless and we can put it in an utility class if wanted. unsure about this. Personally i find it to simply to say: store it here. BUt on the otherhand, less methods sound great too. * Also I think we can drop things like add(File) when we can do the same with add(ArchiveEntry) Ok, we could do that yes. Same as above: someone always has to instance an ArchiveEntry instead of just dropping a file there. This makes the api easier- but does this make it comfortable? ** If you would like to, we can can use something like *** ArchiveEntryFactory.create(File) - returns a FileArchiveEntry *** ArchiveEntryFactory.create(name, inputStream) - returns a StreamArchiveEntry Another factory? Why not using: new ArchiveEntry(name, inputStream)? * for VFS it would be nice to have methods like Archive.list() to get a list of all entries in the current archive OK :-) * said that we should rename the method getEntryIterator to getPendingOperations (also prepare the internal list for things like delete) getPendingOperations sounds good, but in this list are not always pending operations. It also reflects whats allready in there. Is pendingoperations a good term for this now? My english is a bit buggy i believe what you are saying ;-) * the same for the Compressor interface. I think we should drop the duplicated API - remove all the File stuff and change File*Stream to InputStream/OutputStream. This makes the stuff much simpler. In AbstractCompressor you create temp-files. When removing the File stuff we can get rid of it. Ah, thats a good reason fo getting rid of this methods. Now i am quite sure i'd like to delete the file stuff. If you still would like to have such methods move them to a CompressorUtils class - and consider using Piped streams, then you do not have to deal with temp files no one might ever cleanup - trust me, in VFS I have such a problem too. OK, i'll keep that in mind. I hope I didnt miss anything from the previous discussions which states that you do all the things above, just give me a pointer if this is the case. Thank you for your comments. Within the last 8 drafts this small interface has been grown better and better. 1 or 2 drafts more and its a pretty piece of code, imho. Chris Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEn/Obkv8rKBUE/T4RAhe4AKCOD21wZSOcqsgfwv2RB6tPpXhLAwCeLDaD M/j2GQ01g/EwX2LkeLN2tpI= =Tcdo -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: I wrote several methods for IOCommons FileUtil. How can I donate it to IOCommons?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Are you developer of compress? i am just contributing, as you do. There's no owner at the moment for compress, as far as i know. Regards, Chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFElnECkv8rKBUE/T4RAq1DAJ49JecH/I9w3MPisuKP50rAByKNzgCfW4lV fS4jhjJLfHBl5HM77eUJcUY= =WTIy -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: I wrote several methods for IOCommons FileUtil. How can I donate it to IOCommons?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 search in the mailinglist archives for the reasons to split up IO and compress. Then come back and start a discussion for undo this split. Dakota Jack wrote: What the hell is specialized IO? Someone makes these terms up and then people think they have meaning. Compression is definitely not a specialized aspect of IO. Compression is critical to handling IO well and belongs in an IO package. On 6/18/06, C. Grobmeier [EMAIL PROTECTED] wrote: +1 to put this in Compress. I really don't get the point why this should be in IO. As Martin said, i see compress as specialized IO. For me it would be also OK if IO would depend on compress. in my latest draft is allready a CompressUtils class where it would fit perfectly :-) regards, chris. Torsten Curdt wrote: re:but AFAIK zip and jar share the same compression algorithm anyway. The algorithms are similar but not the same. Educated me ...Jar*putStream extends Zip*putStream and I have never come across a jar I could not unzip with the usual zip command. re:...and then add a methods for bzip2, compress and gzip, too? See where I am heading? Better let's have a CompressUtils in compress. Compress doesn't work with files while IO does. On the other hand IO doesn't work with compression while Compress does ;-) I think it would be good idea to add compress to IO :-) It has been removed from there because it was mixing concerns IIRC. Getting from File to FileInputStream is easy and no reason to add compression algorithms to IO. cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Christian Grobmeier Possessed Management Hurlacher Str. 5 - 86853 Langerringen - Germany E-Mail: [EMAIL PROTECTED] Mobil: +(49)(0)175 57 66830 Fax: +(49) (0)8232 959119 Web: http://www.possessed.de - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFElnG3kv8rKBUE/T4RAozeAJ9z0ZG49GhO5nEa9936UsabsHaGLACeKIZO hNU+IOwz/IpUji5jt8j1e18= =s47f -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: I wrote several methods for IOCommons FileUtil. How can I donate it to IOCommons?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 +1 to put this in Compress. I really don't get the point why this should be in IO. As Martin said, i see compress as specialized IO. For me it would be also OK if IO would depend on compress. in my latest draft is allready a CompressUtils class where it would fit perfectly :-) regards, chris. Torsten Curdt wrote: re:but AFAIK zip and jar share the same compression algorithm anyway. The algorithms are similar but not the same. Educated me ...Jar*putStream extends Zip*putStream and I have never come across a jar I could not unzip with the usual zip command. re:...and then add a methods for bzip2, compress and gzip, too? See where I am heading? Better let's have a CompressUtils in compress. Compress doesn't work with files while IO does. On the other hand IO doesn't work with compression while Compress does ;-) I think it would be good idea to add compress to IO :-) It has been removed from there because it was mixing concerns IIRC. Getting from File to FileInputStream is easy and no reason to add compression algorithms to IO. cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - -- Christian Grobmeier Possessed Management Hurlacher Str. 5 - 86853 Langerringen - Germany E-Mail: [EMAIL PROTECTED] Mobil: +(49)(0)175 57 66830 Fax: +(49) (0)8232 959119 Web: http://www.possessed.de -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFElYfkkv8rKBUE/T4RAseWAJ4tE6gNI9YVWsWBVAFdr05CJ5KPQwCeJeRR fj3SY+DTd0E0HusGSn+snu8= =1GWN -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [compress] Draft 7
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Cheers, o) The usage of the Archiver is still awkward. You create an Archiver, then set the filename of the archive. Why not have an Archive interface representing the archive and a ArchiveFactory Archive arch = ArchiveFactory.getInstance(new File(my.tar); please take a look at the examples: Archiver archiver = ArchiverFactory.getInstance(new File(C:\\Temp\\ZIPTEST.zip)); You can allready do that. Further you can do this: If you don't have one, you are going thru ArchiverFactory.getInstance(zip); And set the name with Archiver.save(File); Please verify if you have draft 7. o) The Archive(r) interface lacks a delete. but you have that in the TODO :) Truely :-) o) The ArchiverFactory uses too much reflection-magic: - Using reflection for instantiation is nice as you can easily add new implementations ..if it's likely to have many custom implementations. I don't think that's the case here ...and you could easily extend the ArchiveFactory to add your own implementation. So I think reflection is not of much use here. Only gives a unnecessary overhead. - Also calling the methods via reflections is not necessary. If you need the methods make them part of the interface. I suggest to add a method isArchive(FileInputStream) to the Archive interface and move the checking into the Archive implementations. (or AbstractArchive). So you delegate the evaluation to the implementation. OK, good point. I agree with with the isArchive method, that's a good thing here. I will do that. I am a bit sorry about the add impl-feature, cause i like it. But i will change this too cause it's really a bit much of reflection. o) Having multiple (De)CompressorFactories with different names is not really nice. I suggest only to have that one (De)CompressorFactory. - then getInstance() needs a parameter to select the implementation. I suggest to use a similar detection scheme as for the ArchiveFactory. Compressor compressor = CompressorFactory.getInstance(new File(file.bz2)); To guess the compressor from the file name. Compressor compressor = CompressorFactory.getInstance(bzip2); To make it easier to select the (de)compressor when the type of compression is only available at runtime. Yes, all true. I will change that. I think it's a good thing to move the Decompressor Interface methods to the Compressor interface too and to delete the Decompressor. This is similar to Archiver, which is a nice thing now. o) If you want a certain compressor without going through the factory I think Compressor compressor = Bzip2Compressor.getInstance(); would be the right way to go. Ok, that's easy. Why would someone like to do that? o) I would get rid of the Entry in the ArchiveEntry methods getEntryName() - getName() getEntryStream() - getInputStream() OK. I don't really like/understand the setters. Why do we need them? We don't need them, i deleted it. I am sorry for that, it seems i am sick with making lots of unnecessary setters. I always do that. Oh ...and maybe there also would be the option to replace arch.add(myinput, new FileInputStream(input)); with arch.add(new ArchiveEntry(myinput, new FileInputStream(input))); Feels good to me. WDYT? I hope my suggestions don't come across too negative. Thanks for all your work. It's really getting there! :) No problem. Sorry for my delay i was at a 5 days festival and needed one week to come back into reality. I know that my code is not (always) the best, so i am glad about the time you (all) spent for review. Looks like i'm a setter-maniac, it's nice to know this :-) - - Chris. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEjRhxkv8rKBUE/T4RAsrjAJ479tE0zqTkkNdmszqVJVBra5moxQCfbfj0 bqyU1USmLIVhiryrVhziKF8= =fAAt -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[compress] Draft 7
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hey all, here is draft 7: http://grobmeier.de/commons-compress-draft-7.zip where mainly the factory has changed. It's possible now to get an archiver by name and by file/extension. As usual, comments are welcome. If there are not too many open issues with this i'll will open an issue and add this file. Regards, Chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEeuMKkv8rKBUE/T4RAsGtAKCDwEUFsSjj+cXicNoSCIy7RVaY3wCgjohh +Tv6yauC+RXYkdCCRoDpvqE= =xLWi -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] latest multidoc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Henri Yandell wrote: I bring this up from time to time; slowly moving it along etc. http://people.apache.org/~bayard/multidoc-jnr/ The current status is that it contains 104 Commons javadocs. It uses both the jars in the maven repository (for jardiff) and an unpacked structure of javadocs to put together the multidoc bit on top of it. The main todo is to look at using the pom files in the repository to modify the javadocs so that they are interlinked. Thought I'd share. Hen I like multidoc. Why don't you link it on the wiki marked as experimental? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEdCepkv8rKBUE/T4RAut2AJwOfm6JtNGx+aMJRAM7jzR+jsKrsgCfbtSd kx0w7YZ3GbZjM0OE6l74uRc= =Mwoi -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [compress] Draft 6
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 will pugh wrote: Yeah. I agree valueOf would work just fine, but unless I'm missing something, the current implementation doesn't have this. The purpose of my comments was to say that I thought it should have something along those lines. The valueOf is on the TODO. Cheers, -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEZaMjkv8rKBUE/T4RAhidAJ9+bj2TDSwjYa38MeFn7POKhFY2cgCfUgu7 ar6ChVFXGvEGc3u2CygbDUI= =/zrx -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [compress] Draft 6
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ...so what's the benefit over the usual factory + constructor instantiation then? Archive arch = new TarArchive(new File(my.tar)); Archive arch = ArchiveFactory.newInstance(new File(my.tar); Archive arch = ArchiveFactory.newInstance(tar); i have read your suggestion but i was not sure why i should accept strings for choosing an archive. I like the idea ArchiveFactory identifys archives by it's header. So, thanks for making this clear to me. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEZaN4kv8rKBUE/T4RAiV3AJ9WcG4Sfl4b7Hlv1pj/DDbojqbV9gCeJaFd lZAWKvyFjba5F7LEVYQqKV4= =9Ojn -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[compress] Draft 6
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, here is a new draft: http://www.grobmeier.de/commons-compress-draft-6.zip I have changed a lot of things discussed with draft 5. The API is easier now. Everything what seems to be unnecessary has been deleted. Compress is working with Files and InputStreams only, no more String-params are allowed. New is also ArchiveEntry, which represents the entry of an archive ;-). For example, a zip file can be created like this: Archiver archiver = ArchiverFactory.ZIP.getInstance(); archiver.add( new File(C:\\Temp\\1.html)); archiver.add( new File(C:\\Temp\\1.html.bz2)); archiver.save( new File(C:\\Temp\\ZIPTEST.zip)); and unpacked like this: Archiver archiver = ArchiverFactory.ZIP.getInstance( new File(C:\\Temp\\ZIPTEST.zip)); archiver.unpack( new File(C:\\Temp\\unpacked\\)); There a lots TODO, like handling archive-manipulating, overwriting files, checking out the solaris issue or how to set special flags. But imho with this interface we have done a step into the right direction and now we can think about the more difficult things. Regards, Chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEZEDqkv8rKBUE/T4RAlP+AJ9wYDnXZoPK3/oAfutGSKfw690C6ACeNQHZ Qg9hnd0w6IqMLBV47pqzOXM= =zgEA -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [compress] New draft 5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Henri Yandell wrote: If you could fill out the software grant: http://www.apache.org/licenses/#grants and either fax or postal-mail it (see instructions in first paragraph of http://www.apache.org/licenses/icla.txt;). [x] done via fax Please come back to me if the fax doesn't arrive chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEWNvekv8rKBUE/T4RAnqGAJ9YQKz7KEebe2uQGvEkCgSVlxiSMwCcCSKD y8jvogkVakzI1PtEqOXENaw= =w/Xo -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [compress] New draft 5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Henri Yandell wrote: If you could fill out the software grant: http://www.apache.org/licenses/#grants and either fax or postal-mail it (see instructions in first paragraph of http://www.apache.org/licenses/icla.txt;). I will fill out the form and send it today. It's better to get the code in early and then have comments be patches than continually keep sending you back to the drawing board I think. I agree. Having a high level look at the discussions followed by my proposal, i will prepare a new draft. So please hold on before comitting :-) Regards, Chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEVydgkv8rKBUE/T4RAqWzAKCReSn/6vPAJk4W+wchxSAVTjLH7ACfQCoz BJKgL+JWWWI0eitr/VtB8yQ= =SbNP -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [compress] New draft 5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sandy McArthur wrote: On 4/30/06, C. Grobmeier [EMAIL PROTECTED] wrote: here is a new draft for the compress interface: * http://grobmeier.de/commons-compress-draft-5.zip Same as before, suggestions as a stream of consciousness, take the ones you like: Thanks again to all for your comments. I will think about em, create a new draft and come back here in a few days. Regards, Chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEVyfkkv8rKBUE/T4RAsarAJ0dWH03RbU8I1C8ib6Jl5V9RKLovwCeM2VM L5n+xE2rW5fXJkwmK+Y9Veo= =M4TW -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [compress] New draft 5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 My fault for only just joining in etc, but why have the underlying Tar/Zip classes become package scoped? Does the bridging API replace all need to dig into the lower-level APIs? I was not thinking enough about this. In my fault i was thinking its a good idea to lower visibility. But i didn't think about if the bridge has enough functionallity or not. If so, why are the bzip classes still public? Cause bzip still needs refactoring. There were compile errors on severeal points, and i didn't want to dig all up. Should there be ZipCompressor and GZipCompressor implementations? In my opinion, yes. Any reason for there not being an archiveToStream method? Especially in the case of the Tar implementation where you'd want to attach a TarArchiver to a GZipCompressor. I don't know any reason not to do so. I will remind this in Draft 6. Thanks, Chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEVymhkv8rKBUE/T4RAk0yAJ9Jx6+pfSRVvsuApFCbZpkKiO7AwQCeJPLx g3rJSBX+ovIEPZrW7JKJnLY= =YsaR -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [compress] New draft 5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 So my comments: o Don't like that compressor does both compression and decompression. I'm ambivalent on this one. If we would do so, we have 4 different interfaces. But i like the look. o Always use File not String +1. Only use 'String filename' when you're doing something to a filename - otherwise we bloat the APIs for the sake of a new File(xxx). It's not worth it. Agreed, i will delete that. Also, the setXxx stuff seems a bit unnecessary. For the interface, minimal and stateless seem like important goals. Having setXxx just means that the implementors have to worry about thread safety. OK, my new draft will remind that. I will keep it pure ;-) Chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEV50/kv8rKBUE/T4RAiYiAKCJEGc8eQ07MgenqF/BNBjr4rQ8UQCfRIhL 8K3+oBrOYvXuAGIyUuR/yQM= =UBTS -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[compress] New draft 5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello all, here is a new draft for the compress interface: * http://grobmeier.de/commons-compress-draft-5.zip I have improved a lot of things, based on the comments of Sandy (thanks for that). This draft is not perfect, as you can see in the todo list. But imho we have a quite good base for future work, everything compiles and works and is documented. So i would like to propose that someone is comitting this, except you have reasons not to do this. If you agree with me, i will open a bugzilla issue and add the link to the code. - - Chris. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEVKMikv8rKBUE/T4RAlxxAKCMYzova2roWDA/skRyoDvFcErE2gCfTjFw bT2VrGdR8Byt+VjsRo7Cyhw= =1GRF -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Jira?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 James Carman wrote: I'm +1. JIRA is much more user friendly and intuitive, IMHO. I like JIRA too. I have reported a lot of bugs for other OS projects using JIRA, cause it's intuitive. As i saw the commons bugzilla instance first time i was really afraid. Meanwhile i have learned how to find what i want, but i can't say i really like this ugly thing. For this religious things: there is a free license and commons could benefit from a switch (and if only if guys like me report more bugs ;-)). If they sell it expensive for enterprises- ok, i have sold commons components too (as part of my applications). As long as they do not decide to roll back this free license i don't care. Chris. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEUNHGkv8rKBUE/T4RAksKAJwPY74q4zGxefRKcQjukjtP5rvJLgCePt+C OKuk6YWBe2tPgb3R64Brd4I= =bow8 -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [compress] Moving forward...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brett said that it provides an archive bridging API, so I was wondering how that part of the Plexus one compared to your work Chris. I presume their one is tried and tested in Maven 2, so that's a pro for pulling it over into the Commons component and enhancing it. The archiver bridging api isn't to complex and is quite similar to what i wrote, but there are some problems: Plexus isn't documented. The difference between archiver and compressor isn't clear enough, imho. There are some things i like, some i don't. I really would like to go ahead with what i wrote till now, and merge just single methods/functionallity we really need into compress. Enhancing plexus would mean, that i refactor plexus to what i wrote by now. That plexus is tested is really a plus, but after checking out the code brought up a lot of compile errors, missing references etc., so... I would like to keep a clean base. In short: i would like to keep the new, clean, documented build bridge, and enhance it with plexus features after it's stable. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFETzACkv8rKBUE/T4RArgwAJ0ZbjFUgioa+WbtNWUjC63N3aTvEgCgl3Kv hzBwt/87LfxRwkHWOHMDPiw= =trpy -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [compress] Moving forward...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Henri Yandell wrote: http://svn.plexus.codehaus.org/trunk/plexus-components/plexus-archiver/ btw. How does that compare to what you have Chris? It's quite similar to what we have. But i would prefer to build upon the old commons code, enhance it and the merge single features from plexus to commons. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFETc32kv8rKBUE/T4RAuVTAJ9sfPLvE+E+JKb51jcwEe9WskU1yQCfSr2R ESyzYb4kLjQyd27SG5ikSkw= =BwbI -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [compress] Moving forward...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * VFS release is held up by lack of a stable/promoted compress. Mario said so. * Maven (in plexus at codehaus) have a fork of compress with bugs fixed. True. Plexus has not factory, so it's not perfectly usable * Chris has an archive bridging API that would fit well at the top of compress True :-) * Will has zip updating available True * 4 issues in Bugzilla 1 is solved using my implementation, one is a wish for more performance. * I have an issue mailed to me privately that I need to put in bugzilla Don't know ;-) Anything I missed? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - -- Christian Grobmeier Possessed Management Hurlacher Str. 5 - 86853 Langerringen - Germany E-Mail: [EMAIL PROTECTED] Mobil: +(49)(0)175 57 66830 Fax: +(49) (0)8232 959119 Web: http://www.possessed.de -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFETc6Ckv8rKBUE/T4RAjA6AJ9Y4e+rQ9H2MERDnBnNkJTTWuGOiwCbBj/k 52CIWsa+qoveo8hAKGPa7Vg= =0Rif -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Contributing Code
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'd love to see your code, although I don't think we should merge until we get the code contributed. It looks like contributing code gets a bit harder when there are more than one person involved in writing it. It's easily possible to merge if you would implement the Archiver-Interface. You could just head off the older zip implementation and drop yours in. Please use: http://www.grobmeier.de/commons-compress-draft-4.zip But please notice, i have to do a lot of changes suggested by Sandy McArthur. Its under heavy construction. My factory is being updated next days. Further it was very difficult to easily browse your code, cause it's not documented. Can you tell me how you delete a file from the zip? Do you manipulate the bytes directly? cheers chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFETLZmkv8rKBUE/T4RAq7qAJ4gKdfdsqRPxUwSN4BOdx8q/Yjl+gCffoe0 tTBfkfbqMd1wMpltMZrCUdg= =l/d6 -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Contributing Code
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 will pugh wrote: I thought it made sense to go into compress, but I think that depends on how close compress is to releasing. As I mentioned before, this code has a number of things to finish before it's ready for primetime. I would estimate that I could get this ready in about a month. If this is too risky for compress, I would offer that we could start a new branch for the next version. The compress code needs a lot of time before it's beeing released imho. There are severeal things to do with tar, the interface must be extended and so on. It's the right time to drop a new zip implementation in, if this implementation fits all needs. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFETLzIkv8rKBUE/T4RAlpmAKCPGxchPNpcKKC2Zp8DCRMQMCz6AQCgkGh4 3eKUJ1j1OSTpKDbassa1muo= =8ig4 -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Id, Compress] question about status of the subproject 'Id' and 'Compress'
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, i wanted to ask what the status of the two subprojects 'Id' and Compress' currently are and what tasks will have to be solved to get them moved into the proper repository. for compress: at the moment there are 2,3 non-comitters out there writing code. The code is not in a stable state nor has it been checked in and approved by an comitter yet. After the compress factory is welldone and a comitter has time left to handle this component on a regular basis compress could possibly go to proper. imho this will need more time. At the moment, there is development at the factory (by me). Will pugh has written an modifiable zip implementation (which i haven't read yet). A modifiable tar-implementation would be great. For ID i cannot speak. Regards, Chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFETNqQkv8rKBUE/T4RAuFvAKCCXR/FLHUr848PTIQ09s3Uj/xKUgCfZ15L iSAv7BwykB9TJRxTG/BgVGQ= =nRhs -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Contributing Code
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I am interested in contributing code to commons. I wrote a ModifiableZip class, that basically implements all the methods on ZipFile, but provides new methods for adding, removing and modifying entries in an existing zip file. The basics work, but it is still a bit rough around the edges. I need to do a bit more work on 1) Getting the proper apis 2) Changing package names + general refactoring 3) Making sure there is less duplication between what I have and what is implemented in compress (there are common elements in org.apache.commons.compress.ZipOutputStream that I feel we could share) 4) Filling in some of the smaller bits like file attributes, etc. 5) There are some other known bugs I thought it made sense to contribute this now, and apply patches, since I figured this could be useful to the VFS folks, and thought it might be able to go into Compress, in which case being able to get feedback and requirements from the communities earlier (rather than later) will be useful. this is great. I am doing work on compress at the moment, if you like i send you the current code via email (i am not a comitter too). I will check out your code and will try to put it into my current implementation. It would be great if we could do this stuff together. The zip file is http://sandbox.sourcelabs.com/willpugh/myzip_contribution.zip I'm not an Apache committer. Should this be going through the incubator first? IMHO not- it's just a enhancement to a allready incubatet codebase. But i am not an expert on this stuff, so somebody please correct me if i am writing bullshit. Cheers, Chris. Thanks, --Will - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - -- Christian Grobmeier Possessed Management Hurlacher Str. 5 - 86853 Langerringen - Germany E-Mail: [EMAIL PROTECTED] Mobil: +(49)(0)175 57 66830 Fax: +(49) (0)8232 959119 Web: http://www.possessed.de -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFESMznkv8rKBUE/T4RAtmsAJ4kmHTv/9CjPT9/TtN9RwPHEmjSwwCeKxkE heEsaUZ6fSqVTr5su6yUsDk= =JBUM -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Contributing Code
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thanks for the info. I will keep this in mind. I have to fill out these forms too, so i will comment what has been written be will too seperate the code again, if necessary. Chris James Carman wrote: Be careful when putting code from an outside source into the ASF code base. You might want to check with the incubator folks (I cc'ed them on this message) about this. I would think that any code that is donated would need to have the appropriate accompanying forms filled out, even if it is just donated to an existing project. -Original Message- From: C. Grobmeier [mailto:[EMAIL PROTECTED] Sent: Friday, April 21, 2006 8:16 AM To: Jakarta Commons Developers List Subject: Re: Contributing Code Hi, I am interested in contributing code to commons. I wrote a ModifiableZip class, that basically implements all the methods on ZipFile, but provides new methods for adding, removing and modifying entries in an existing zip file. The basics work, but it is still a bit rough around the edges. I need to do a bit more work on 1) Getting the proper apis 2) Changing package names + general refactoring 3) Making sure there is less duplication between what I have and what is implemented in compress (there are common elements in org.apache.commons.compress.ZipOutputStream that I feel we could share) 4) Filling in some of the smaller bits like file attributes, etc. 5) There are some other known bugs I thought it made sense to contribute this now, and apply patches, since I figured this could be useful to the VFS folks, and thought it might be able to go into Compress, in which case being able to get feedback and requirements from the communities earlier (rather than later) will be useful. this is great. I am doing work on compress at the moment, if you like i send you the current code via email (i am not a comitter too). I will check out your code and will try to put it into my current implementation. It would be great if we could do this stuff together. The zip file is http://sandbox.sourcelabs.com/willpugh/myzip_contribution.zip I'm not an Apache committer. Should this be going through the incubator first? IMHO not- it's just a enhancement to a allready incubatet codebase. But i am not an expert on this stuff, so somebody please correct me if i am writing bullshit. Cheers, Chris. Thanks, --Will - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Christian Grobmeier Possessed Management Hurlacher Str. 5 - 86853 Langerringen - Germany E-Mail: [EMAIL PROTECTED] Mobil: +(49)(0)175 57 66830 Fax: +(49) (0)8232 959119 Web: http://www.possessed.de - - 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] - -- Christian Grobmeier Possessed Management Hurlacher Str. 5 - 86853 Langerringen - Germany E-Mail: [EMAIL PROTECTED] Mobil: +(49)(0)175 57 66830 Fax: +(49) (0)8232 959119 Web: http://www.possessed.de -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFESNnckv8rKBUE/T4RAoZ+AJ9ONTgI8qBcwreyCOh+cgpCTRrExACfZ5eS eCsp0IbqfT+G5zhwOyMfN0o= =6FdO -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Unsubscribe me please, thanks.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have read lists in which the admins have sent (automatically) a simple user guide for the list, with unsubsribe information, about do's and dont's etc. Sending such an email could be quite cool- thinking on the [tag]-issue :-) Chris. Boris Unckel wrote: Hello Brian, at the bottom of EACH mail of this list can you read how to unsubscribe: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Additionally this on the page where you might have found the subscribe info: http://jakarta.apache.org/site/mail2.html#Commons Regards Boris Brian Elfers wrote: Unsubscribe me please, thanks. Brian C. Elfers Application Specialist Greenbrier Russel, Inc. Phone: 414.973.7000 Fax: 414.973.7010 11270 West Park Place Suite 1000 Milwaukee, WI 53224 www.gr.com - 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] - -- Christian Grobmeier Possessed Management Hurlacher Str. 5 - 86853 Langerringen - Germany E-Mail: [EMAIL PROTECTED] Mobil: +(49)(0)175 57 66830 Fax: +(49) (0)8232 959119 Web: http://www.possessed.de -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEOoTQkv8rKBUE/T4RApRvAJsEwfOmQqlrEo8a0Wbu3Lk4xUAfAACeKj1y v0Kl74pQOROL5lbwCIuV1ak= =NBF2 -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [compress] Interface is ready
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, The only information that I was able to find that said anything useful about the difference is found in this page. http://java.sun.com/products/archive/j2se/1.2.2_017/install-docs.html Snippet from this page (you'll find it at the bottom of the page) : Background: The original tar format supports a maximum path size of 99 characters. If you use Solaris tar, you will not see a problem, because Solaris tar extends this format beyond 99 characters but in a Solaris-only way. GNU tar has a different way of extending the format, so is incompatible with the Solaris tar. WinZip and Cygnus GNU tar 1.11.8 do not support the Solaris way. We recommended that you use Solaris tar to extract the archive, or use the jar tool or WinZip to extract the zip version. Note : WinRAR seems to work properly with Solaris tar archives, though.. I am trying to get docs on the tar implementation in Solaris. I will get back once I get more information. What's happening is that for files with long path size , they get extracted as if they were present in the root directory. Sounds interesting. I am quite sure this is allready implemented. I am very much interested in a version that works on Solaris. I dont know if I'll have time to work right now on a Solaris tar implementation, but if someone gets around to writing one I'll surely be able to help test it. You could also try installing Solaris on x86 for testing, since it is free. it would be great if you could help me a bit cause i have no solaris installation at the moment and i am not able to get on ein appropriate time. If you would like to take a look at the code, start with the old tartest case. There are two different tars and i am quite sure this is what you want. Could you simply try out with this example? Regards and thx for the information, Chris Thanks, Hari. On 4/6/06, C. Grobmeier [EMAIL PROTECTED] wrote: Hi, Does this work with Solaris tar, since Solaris tar is different from GNU tar ? If not , is there a plan to do so ? Won't making TarEntry an interface with Solaris/GNU implementations be a good idea ? This is just an idea off the top of my head.. I've not delved too much into the code.. i have just used the old APIs which have been implemented bevor ages. In the old testcases [1] i see that there seem to be a difference between Posix Tar and GNU Tar. Is this what you meant? It seems there is work to do left. I am sorry that i am not to deep into tar yet. If you have documents for me to read just send me the urls. Thanks, Christian [1] org.apache.commons.compress.TarTestCase.java - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFENL9+kv8rKBUE/T4RAp++AKCVZawrBruhpTaIpZM4Od9QBHR4MgCeLngq C2tpjqBwovipl1ePWRmz4Bc= =6bJE -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [compress] Interface is ready
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Does this work with Solaris tar, since Solaris tar is different from GNU tar ? If not , is there a plan to do so ? Won't making TarEntry an interface with Solaris/GNU implementations be a good idea ? This is just an idea off the top of my head.. I've not delved too much into the code.. i have just used the old APIs which have been implemented bevor ages. In the old testcases [1] i see that there seem to be a difference between Posix Tar and GNU Tar. Is this what you meant? It seems there is work to do left. I am sorry that i am not to deep into tar yet. If you have documents for me to read just send me the urls. Thanks, Christian [1] org.apache.commons.compress.TarTestCase.java -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFENC85kv8rKBUE/T4RAvepAJ9UhbEJ/L1CfQnz42Z3zyMgBQXFOwCfXDxV BHUXlp3lDBNsE4bgTUFOfMU= =oVNZ -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [compress] Interface is ready
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Sandy, thousand thanks for your comments and the time you have spent for this. I will work through this all and prepare another draft soon. Thank you very much, Chris The following is a stream of things I don't think are right in the order I observe them while skimming the code. I've never used the compress code so excuse any suggestions that miss the point. * Archiver: too many overloaded methods. Especially with setters. Having setFoo(File) and setFoo(String) will breaks the JavaBean property conventions and could cause problems with scripting tools. If you're going to do something like this then use different names eg: setDestinationFile(File) and setDestinationFilename(String) and let the latter be a virtual property that really just creates a new File and calls setDestinationFile(File). * Archive: doesn't do much, only contains one static method: getInstnace(ArchiverType). Because it's static you cannot subclass it so there is no way to extend it's behavior for when someone else want to implement CabArchiver. The type-safe enum example I gave in the other email makes this class unnecessary. * ArchiveType/CompressorType: make them type safe enums. Actually I think it's a mistake to distinguish between Archive types and Compression types. Making them separate you have one library that does two things and I think you should treat them as one thing and do that one thing well or have two libs that each do one thing. * TarConstants: is package scoped and, with the exception of one line in TarOutputStream, is only used by TarEntry. It looks to me the logic in TarOutputStream that uses TarConstansts could be easily pushed into TarEnrty and then the constants in TarConstants should be moved to where they are used. * TarInputStream: skimming it I don't it. It looks like it's taking the InputStream concept and corrupting it with the notion of many separate streams for each file in one stream. This is confusing because it doesn't fit the expectations of an InputStream. IMO it should be it's something similar to an Iterator that takes a raw InputStream and provides a way to get at metadata sequentially from the raw InputStream. From the meta data you should be able to get an InputStream which is just for that file in the archive. * TarOutputStream: Same problem as TarInputStream but with an OutputStream. Because TarOutputStream subclasses OutputStream it makes write methods available. But using these methods are dangerous because if you write a different number of bytes than what was passed when putNextEntry(TarEntry) was called you corrupt the archive. A good API doesn't let the programmer make mistakes. I'd change this to be it's own object type that accepts TarEntrys with all the needed to add a file in one step that either succeeds or fails. * TarInputStream/TarOutputStream: I don't see why these classes should be public. Making them package private would make me care less what they are because they aren't part of the public API and can be changed at will. * ZipLong, ZipShort: these are both public, and I don't see why they need to be. They are only used inside the package with the exception of 3 places ZipShort is used as a parameter type in a public method. I don't see why those ZipShorts cannot be converted to shorts for the public API and both of them made package private. * ZipOutputStream: has the same problems as TarOutputStream. * compress.archivers.zip: every class in this package is public, I don't think they all need to be. * compress.compressors.bzip2: This package seems fine. I don't get why CBZip2InputStream and CBZip2OutputStream start with the letter C though. * compress.exceptions: I don't get why the exceptions are segregated to their own package. Javadoc already keeps them separated so there isn't a need to put them in their own package. I'd put them in the compress package or a package closer to where they are used. -- Sandy McArthur He who dares not offend cannot be honest. - Thomas Paine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEMi31kv8rKBUE/T4RAhe3AJ9HCrNQf8dvHAyJnW20dWoF4tpnxwCgi7U8 Hu/4efxAre76d8mbK/mqPrw= =4wUL -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [compress] Interface is ready
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephen Colebourne wrote: I haven't been following this thread closely. However I just took a quick look at the zip. Thanks for that. The ArchiverType/CompressorType interfaces will be a problem. They indicate that they must be changed when a new type is added to [compress]. But commons has pretty strict rules about not changing interfaces. I will change this and use constants instead. Is there a website regarding the mentioned rules? Personally, I was also unclear as to the reason why there is a split between archiver and compressor, but then I don't know the low level of these APIs that well. Archiving and compressing are two different things; while you can add more files to a tar-archive, you can't do that to bzip2/gunzip etc. I didn't want methods in one single interface which work for this format but not sometimes not for other operations. I think it's more easy to recognize that you have to use Archiver for archiving and Compressor for compressing instead to know what the methods do exactly. Cheers + Thanks, Chris Stephen C. Grobmeier wrote: Hey all, i have just uploaded this: http://www.grobmeier.de/commons-compress-draft-4.zip Tar, Zip and BZip2 is now implemented by the 2 new interfaces. Please check it out, and tell me, if something more i have to do before it can be comitted to the compress-code. If this looks ok, i will create a bug in bugzilla and add this zip as attachment. Looking forward to read your comments- Cheers Chris. - - 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] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEL5Dzkv8rKBUE/T4RAiYBAJ9ZIck108krrbQihjmqjT9MNyJtigCfef9y s9z0WtbwF7JSarfJ8E1Jt9Q= =XNia -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[compress] Interface is ready
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hey all, i have just uploaded this: http://www.grobmeier.de/commons-compress-draft-4.zip Tar, Zip and BZip2 is now implemented by the 2 new interfaces. Please check it out, and tell me, if something more i have to do before it can be comitted to the compress-code. If this looks ok, i will create a bug in bugzilla and add this zip as attachment. Looking forward to read your comments- Cheers Chris. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFELTxCkv8rKBUE/T4RAhJxAJ9btr7wN5IZWg4PxAYxLUv71iu0IACfUqts CoNlikABCZ6SG3yzWUEggQM= =Vrml -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [compress] Introducing the Compress-Interface
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It appears to target the compress goals, is an active project(?) with releases, and most importantly uses a sane license (ASL). I'm not sure how much of a one-man show it is; but maybe we could be helping out there rather than trying to create something out of [compress]. Compress is stable code that just needs to be made easily reusable. I need to do a review of the last couple of messages, but there are at least 2 or 3 keen people involved. I think it's got promise. [compress] is beeing used for vfs as far as i understood Mario correct. He has special wishes for compress for a better integration in vfs and i think it would be great if could support the development of vfs with providing an more evolved compress. In my opinion, compress should be renamed in archive/compress (or a better name ;-)) to avoid confusion. The idea of having implementations for archivers like .iso is a good one, but at the moment i would like to wrap the give implementation. Of course, if we would stop as a wrapper of classes provided by the JDK, we could think about stopping this component here. But i think it's possible to write an implementation for (f.e.) a delete/add-operation. This is very useful and i do not know an API with a similiar implementation. The user feedback on the commons-user list is rare. But, hey, it's simply uncomfortable to use [compress] at the moment. Let's see again what happens when compress has some more lines of code and a nice interface. Thanks for your comments. Chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEDqgPkv8rKBUE/T4RAuWkAJ0TuTU/6DnJmWvia+kvKknYhGUIGwCeN3OS d1xmKT7znjMz332Qvv6dSWU= =MmIS -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: commons-vfs release
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 You've got my time if you need it. Push on with getting each one of these moving, and whenever you hit a karma issue, just hit me and I'll deal with patches etc. I'll try to find time to dig into the issues themselves, but far more realistic to have those interested driving things (yourself, vfs, others?). Thank you. Yesterday evening i checked out plexus-archiver, the issues and so on. I see that the issues are not to hard to solve, in fact, 3 issues have a working patch included, 1 must be solved when the API has been cleaned up. So these issues are not a matter by now. The plexus thing is interesting. We can only use few parts of the code. A lot of it is allready in our code, some parts are nice to have, like f.e. war-archiver. A complete merge will need time, but i think we will check out some features and take it over. I looks like we will have a bit other architecture then they have now. Next step (IMHO): - - having the interface working for unpack/pack operations (as simple as possible) - - having examples running Step two: - - having interface for Input/Output Streams I will try to have the first step as soon as possible. Cheers, Chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEDUd4kv8rKBUE/T4RAtPhAJ98aFWyGNmFmN3tnwhzI3z4Cnb4BwCeKU5s r+JJnIsZbEr0zYNkZ/YxuH4= =HBFj -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [compress] Discussing compress
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have updated: http://grobmeier.de/commons-compress-draft-2.zip + input/output streams are all in finally-blocks + Examples for the old tar/bzip2 way included + Patch in Bug 30494 included: fixes these examples :-) Cheers, Chris C. Grobmeier wrote: 1) Please take care to always close your input/output streams. ie. do this in a finally() block so that in any case (excpetion) the streams were closed OK, i will check this tonight or tomorrow evening :-) 2) you cant handle directories now, maybe something you have on your todo list? Yes, it's on my TODO, this package should only introduce the direction. 2) The archiver uses java.io.File in its public interface. PLEASE provide Streams too. Internally you can create temp-files or whatever you would like to. So you might have something like OutputStream os = Archiver.createEntry(String pathname); Why? From the view of VFS its simply easier to handle ;-) It would be great if you could handle this in your abstract archiver. I think this should be no problem. I have it on my TODO by now. Regards, Chris - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEDUhOkv8rKBUE/T4RAsTBAJ0ReEDicWq80b4GG+l+RUcUGWenKACfdXkh dQ7XcOGowMslJyNPUx1w+6Y= =mbN/ -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[compress] Introducing the Compress-Interface
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, after thinking a lot about the difference of archivers and compressors, i am not sure how to proceed with it. At the moment [1], we have an Archiv Interface. This fits fine for Tar and Zip. If we imagine gunzip or bzip2 as an archive for an single file, we would be fine aswell. For the compression portion, we could have an Archiv::setCompression( new TarCompressor()); method. For Zip we could have Archiv::setCompression( new ZipCompressor()); (just an example, we will not have static methods here!) We could implement a default Compressor for every Component, for example, ZipArchiver would have ZipCompressor as a default, so it's not a must to care about it. A compressor could be used standalone. In case of bzip2 it would be not problem, but how would a zipcompressor act? Archiving simply in zipformat? Having said this i am afraid my thoughts could make everything to complex. On the other hand, this sounds like a good idea for [compress]. Every comment on this important question is welcome. Regards, Chris [1] http://grobmeier.de/commons-compress-draft-2.zip -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEDZ7Nkv8rKBUE/T4RAnbcAJ9pAEFWFUkaRc5y1HzEMLdTMKDPBgCaAidw nJ6OCUMKp8rm3UeK/rp/KUI= =mx3B -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [compress] Discussing compress
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 hi, I actually think commons-archiver is a better name (the library I have used is plexus-archiver [1], which is derived from the same code and I want to merge them here). Note that there is also the unpack/decompress portion as well. +1 to the archiver thing. In my draft, i renamed all what is Compress to Archiver. I think this is the right way to start. I think investigating more performant methods for large archives might be a good idea later too, though. Yes, i agree with you and mario. Having this in mind, i will try to write some simple files as a basis at the weekend. I don't recall seeing anything come in. Is this still happening? If not, can we kick it off again? I have done something and uploaded a draft: http://grobmeier.de/commons-compress-draft.zip Please check it out. Every comments are welcome. Please notice, this is a draft. It provides the function to zip and unzip an archive. There is a source folder with an example. Thanks, Chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEDFzdkv8rKBUE/T4RApQZAJ9N4x5oyiqITIEOyTdvygJC7MJ5XQCfUEHG cHOhiQ2sx7TnCIgcE7+SDRI= =Iu3M -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [compress] Discussing compress
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 1) Please take care to always close your input/output streams. ie. do this in a finally() block so that in any case (excpetion) the streams were closed OK, i will check this tonight or tomorrow evening :-) 2) you cant handle directories now, maybe something you have on your todo list? Yes, it's on my TODO, this package should only introduce the direction. 2) The archiver uses java.io.File in its public interface. PLEASE provide Streams too. Internally you can create temp-files or whatever you would like to. So you might have something like OutputStream os = Archiver.createEntry(String pathname); Why? From the view of VFS its simply easier to handle ;-) It would be great if you could handle this in your abstract archiver. I think this should be no problem. I have it on my TODO by now. Regards, Chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEDGi4kv8rKBUE/T4RAuuOAJ9xrVSwtnBbVcpPD6OXNk08D+h5RQCfeKTJ 9gsb05rxKIUydG4SW7dwo1w= =Yebv -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: commons-vfs release
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 What would be the work involved in getting compress released? Any idea? - - fixing the 3 (or 4) Bugs - - preparing an commonly used interface - - having functions for deleting files from a compressed file (optional, i think) - - clean up of the old code - - possibly merging with codehaus-code (from Brett Porter) - - preparing functions to work with Output/Inputstreams (necessary for VFS) I have something done and put a draft-compress online (see thread [compress] Discussing compress) Nothing special, but needs a bit of time. This would be a core release, with just the most simple features. - - Chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEDH3Okv8rKBUE/T4RApbFAJ9AND6e4WRu7hB1x3cd+k7OL7HrdQCgjEeX eOQOG04okgQyRwuSabmSlo8= =u7xW -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [email] ant dist fails / dependencies not found
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dion Gillard wrote: The javamail jars cannot be distributed by themselves as they are licensed under the Sun Binary Code License. How about building against the Geronimo versions? http://www.ibiblio.org/maven/geronimo-spec/jars/geronimo-spec-activation-1.0.2-rc4.jar http://www.ibiblio.org/maven/geronimo-spec/jars/geronimo-spec-javamail-1.3.1-rc5.jar sorry for my asking again, but why is it a problem to keep javamail-jars for Commons Mail but not for having jars for geronimo? Couldn't we have something like: commons-javamail-1.3.1.jar? - - Chris. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEBsOlkv8rKBUE/T4RAlhzAJ4iVPd226qY34lUhFP4VGB+XIWlNwCfRars zOuAadap5XT5xNoHpAkGXY4= =1izm -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [email] ant dist fails / dependencies not found
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thank you. I think i will document this in the build-file and sent it to you soon for a possible patch. I really don't like build-files with comments :-) - - Chris Dennis Lundberg wrote: matthew.hawthorne wrote: C. Grobmeier wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dion Gillard wrote: If you define a property (in build.properties) javamail.jar=c:/myjars/javamail-1.3.3.ar AFAIK, the build.xml will notice this and copy it into ./lib No, this doesn't work as expected. Cause the build-file works with get, i get: BUILD FAILED C:\Data\Projects\commons-email\build.xml:211: java.net.MalformedURLException: no protocol: /Data/java-repository/javamail-1.3.3_01/mail.jar when i use slashes, backslashes, double-backslashes, C:, c: and so on. You may want to try the 'file' protocol, like this: file:///Data/java-repository/javamail-1.3.3_01/mail.jar Matthew is correct, you need to use a correctly formated URL. Here's an example for a Windows machine: activation.jar=file://C:/myjars/activation.jar javamail.jar=file://C:/myjars/mail.jar -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEBWfwkv8rKBUE/T4RAmzsAJ9oofxjkPYNiGXEVmZcNnxwXZ1URwCggl0D DI+QDjtSbcXLrdod9HUV/4I= =i4Xc -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[email] ant dist fails / dependencies not found
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, ant dist fails, cause the dependencies cannot be found. http://www.ibiblio.org/maven/javamail/jars/javamail-1.3.3.jar http://www.ibiblio.org/maven/javamail/jars/javamail-1.3.3.jar ... brought an I/O Exception, trying to download this from a browser show a 404. Are there any other archives or who does maintain this ibiblio.org site? An apache-depencies-host would be great, i guess... Regards, Chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEBB3Bkv8rKBUE/T4RAp9+AJsEL8PS+t/tY2sWS8A6GTJ5ZNq1kQCfSf/E rMgf/hCLYoaFEMpvW0ZrlNs= =cEZa -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [email] ant dist fails / dependencies not found
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dion Gillard wrote: The javamail jars cannot be distributed by themselves as they are licensed under the Sun Binary Code License. I thought the generated ant build.xml would allow you to specify an alternate location of javamail.jar as a a property? is this not working? I got Dumbster, but not these two: * http://www.ibiblio.org/maven/javamail/jars/javamail-1.3.3.jar * http://www.ibiblio.org/maven/activation/jars/activation-1.0.2.jar The location is hard-coded in the get/ Tag. Problem is before downloading you have to accept the terms. I think it would be better to kick off these get/ Tags and tell the user he has to download these apis manually. How is this solved with maven? I guess this will result in an error too. Regards, Chris On 2/28/06, C. Grobmeier [EMAIL PROTECTED] wrote: Hello, ant dist fails, cause the dependencies cannot be found. http://www.ibiblio.org/maven/javamail/jars/javamail-1.3.3.jar http://www.ibiblio.org/maven/javamail/jars/javamail-1.3.3.jar ... brought an I/O Exception, trying to download this from a browser show a 404. Are there any other archives or who does maintain this ibiblio.org site? An apache-depencies-host would be great, i guess... Regards, Chris - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://www.multitask.com.au/people/dion/ Chuck Norris sleeps with a night light. Not because Chuck Norris is afraid of the dark, but because the dark is afraid of Chuck Norris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEBDHukv8rKBUE/T4RApQIAJ9D4h0gNoV3nOrhkE+SFFcbXlcl+gCfbq3I zNU5CSsxE6fxg1TDI6NXRoo= =ziSf -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [email] ant dist fails / dependencies not found
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dion Gillard wrote: If you define a property (in build.properties) javamail.jar=c:/myjars/javamail-1.3.3.ar AFAIK, the build.xml will notice this and copy it into ./lib No, this doesn't work as expected. Cause the build-file works with get, i get: BUILD FAILED C:\Data\Projects\commons-email\build.xml:211: java.net.MalformedURLException: no protocol: /Data/java-repository/javamail-1.3.3_01/mail.jar when i use slashes, backslashes, double-backslashes, C:, c: and so on. I downloaded the distributions manually and will copy it to the place it have to be, but this is not comfortable. Does maven work with this? Chris. On 2/28/06, C. Grobmeier [EMAIL PROTECTED] wrote: Dion Gillard wrote: The javamail jars cannot be distributed by themselves as they are licensed under the Sun Binary Code License. I thought the generated ant build.xml would allow you to specify an alternate location of javamail.jar as a a property? is this not working? I got Dumbster, but not these two: * http://www.ibiblio.org/maven/javamail/jars/javamail-1.3.3.jar * http://www.ibiblio.org/maven/activation/jars/activation-1.0.2.jar The location is hard-coded in the get/ Tag. Problem is before downloading you have to accept the terms. I think it would be better to kick off these get/ Tags and tell the user he has to download these apis manually. How is this solved with maven? I guess this will result in an error too. Regards, Chris On 2/28/06, C. Grobmeier [EMAIL PROTECTED] wrote: Hello, ant dist fails, cause the dependencies cannot be found. http://www.ibiblio.org/maven/javamail/jars/javamail-1.3.3.jar http://www.ibiblio.org/maven/javamail/jars/javamail-1.3.3.jar ... brought an I/O Exception, trying to download this from a browser show a 404. Are there any other archives or who does maintain this ibiblio.org site? An apache-depencies-host would be great, i guess... Regards, Chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://www.multitask.com.au/people/dion/ Chuck Norris sleeps with a night light. Not because Chuck Norris is afraid of the dark, but because the dark is afraid of Chuck Norris - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://www.multitask.com.au/people/dion/ Chuck Norris sleeps with a night light. Not because Chuck Norris is afraid of the dark, but because the dark is afraid of Chuck Norris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEBEdmkv8rKBUE/T4RAtmKAJ0RQbTpSA2FgZyR1cfrethb6a1o4ACgiSCb LC3oBaGCZDTKWWlB3JIMBLg= =0b7x -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[compress] Discussing compress
Hello, not knowing how to start best, i would like to kick off an discussion about the goals of [compress]. As i wrote in an email before ages, i have allready started to check out the existing lib and want to see this component working. I noticed, that compress ist divided into three different APIs, one for every compression algorithm: Zip, BZip2, Tar. Every implementation is not complete and cool features are not ready yet (f.e. no possibility to delete single files from a zipfile). Next problem is the lack of a commonly used interface: it seems one have to learn everything about the 3 components to use it. This is quite uncomfortable. I think it would be very best to have one interface, say Compress.class. This could organize the Compression itself. Here are the keypoints. Compress should be used to: - load or create an existing compressed file, - add files to compressed file, - compress a file, - return a list of stored files - delete a single file from the compressed file - in a later release: set special fields, like zip-fields For these actions, Compress uses one of the 3 Compressors, ZipCompressor, TarCompressor or BZip2Compressor which are beeing loaded lazily. This is, how i would like to see the compress package. I think before fixing and extending the old apis, it makes sense to discuss the direction in general. Ok, as a newbie to apache contributing all your comments and tips are welcome. Cheers, Chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [compress] Discussing compress
I was thinking that something like Compress.getInstance(String compressorType); like Crypto would be nice. This way you can get a unique entry point for every compression algorithm that can provide its own methods to compress/decompress/add files etc etc. you are speaking of a factory method. I allready thought about it. Besides: Compress.getInstance(String compressorType); there could be also a Compress.getInstance(File compressedFile); which loads a compressed file with the correct Compressor. Returntype of getInstance could be Compressor, which is the interface of an concrete algorithm implementation. Thx, - Chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [compress] Discussing compress
Mario Ivankovits wrote: Hi! Compress.getInstance(String compressorType); +1 or even better Compress.getInstance(CompressorType compressorType); Yes, better. Thanks So, from my point of view compress should avoid having a configuration at all and should concentrate to be a compact library. Sounds good to me. Having this in mind, i will try to write some simple files as a basis at the weekend. How do i proceed then? Sending it to this list? Creating an bugzilla issue? Regards, Chris --- Mario - 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: [compress] Discussing compress
but be sure to only work with streams in your public API. So you might have to decompress and recompress the archive in a local temp folder to make those operations work. I think in your local temp directory you should NOT use the original filenames of the archive as they might contain invalid characters for the current filesystem. So it might be best to generate dummy names and maintain a map of those to their real names. I was thinking about that problem before a while. Can you explain a bit more, why i should use streams only in public instead of a byte-manipulation like with RandomAccessFile. Any link or comment here is appreciated. I found out that i possibly can use RandomAccessFile and read byte for byte and write in back to the same file at the same time. This may lead to a corruption of the source file when the operation is interrupted, but is fastest. I could read the file as a stream and write the needed bytes as output-stream in another temp-file which has to be mv'd to the source after finished. That would be fast and quite secure. But i need a tempfolder where something can get wrong. The issue with decompressing to a temp-folder and compressing it again: I think it would be faster if i could manipulate the bytes directly. And what if the temp-folder is beeing manipulated while the operation runs? What if the zipfile is huge so space in the temp-folder runs out? Regards and thanks, Chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [compress] Discussing compress
Hello again :-) How do you change a file? Replacement would be not so good. I think a modify is a: delete and add operation. How do you delete a file and shrink the archive? I thought about reading the zip spec and cutting out the bytes i don't need. And all this heavily depends on the used compression type. So you might have to implement this for zip/jar/tar - ok - I know tar is not a compressed archive - but its a archive where it might be nice to have write support for. Yes, of course i would have to read the spec of tar, bzip2 etc. Hope i didn't miss your point. I found out that i possibly can use RandomAccessFile and read byte for byte and write in back to the same file at the same time. Sure, but you have to write a compressed stream. Does that matter? Byte is a Byte is a Byte, i would daresay. At the moment i don't want to reimplement the compressing algorithms but want to extend the Zip-API. This may lead to a corruption of the source file when the operation is interrupted, but is fastest. This is bad, isnt it? haha ok, ok you are right this is bad. Don't know why i was thinking about it seriously :) I could read the file as a stream and write the needed bytes as output-stream in another temp-file which has to be mv'd to the source after finished. That would be fast and quite secure. But i need a tempfolder where something can get wrong. The issue with decompressing to a temp-folder and compressing it again: I think it would be faster if i could manipulate the bytes directly. And what if the temp-folder is beeing manipulated while the operation runs? What if the zipfile is huge so space in the temp-folder runs out? throw new IOException() ;-) Ok, lets make it easy ;-) Thanks for your help, this is very motivating. Christian Ciao, Mario - 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: [compress] Discussing compress
How do you delete a file and shrink the archive? I thought about reading the zip spec and cutting out the bytes i don't need. I am not aware of a file operation which allows you to cut out a number of bytes from a file. I think there exists a cut from end, but AFAIK this is not available in java, nor is it available with filesystems like webdav, ftp or cifs. I hoped compress will be able to write to files on those filesystems too (with the help of VFS for sure :-) ) My mistake: with cutting off i meant: reading (in a loop) the bytes and writing only the necessary bytes in a temp-file. There is a skip function. CUtting out is not possible, you are right. I found out that i possibly can use RandomAccessFile and read byte for byte and write in back to the same file at the same time. Sure, but you have to write a compressed stream. Does that matter? Byte is a Byte is a Byte, i would daresay. At the moment i don't want to reimplement the compressing algorithms but want to extend the Zip-API. Your RandomAccessFile directly manipulates the archive, no? So when you change bytes they have to follow the spec. so if you archive looks like: asldkjg which represents the text compress is super duper your RandomAccessFile only sees the bytes asldkjg now if you change compress is super duper to compress is duper super the bytes might look like asuriz This is very simplified, you have to manage a directory structure too. I will think about it. RandomAccessFile is not my first choice, after we figured out that we need a temp-file. My first choice is FileIn/OutStream, see above. If you manage to do that, than I'll salut you ;-) I'll remind that and try it out ;-) Cheers Chris --- Mario - 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: commons-email needs care
Cheers, recommended readings: * http://jakarta.apache.org/site/getinvolved.html * http://jakarta.apache.org/commons/patches.html Regards, Chris Piero Ottuzzi wrote: Hi there, yesterday I used commons-email 1.0 and I found it is quite buggy (for the jakarta quality meter). I found many bugs fixed in bugzilla (not yet ported in SVN) and some more I fixed by myself. How can I help to improve this situation? It really seems that commons-email needs care to fix at least simple bugs. Thanks Bye Piero - 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: [lang] StringUtils.interrupt
No,
it's exactly the same as WordUtils.wrap( String, int, String, boolean).
Well, forget interrupt then. Thank you for the tip. I didn't know
WordUtils till now.
Chris.
Stephen Colebourne wrote:
This looks vaguely similar to the methods in WordUtils. Possibly it
could be done as an adjustment to one of those, although I don't know
how common a case it is.
Stephen
C. Grobmeier wrote:
Hello all,
building my websites guestbook, i figured out that somebody entered a
big string (exactly: an URL). This blew up my complete layout. HTML
doesn't give any solution on this, you simply can't break up this
stupid long string.
Looking at commons lang i found a lot of join/split-operations, but it
seems that never anybody needed something of a separate after 20
characters with a blank-function. Well, i am not sure if ever
somebody REALLY needs this besides me, but you'll never know. So i
decided to let take you a look at my method (attached).
OK, i know it's not the very best method in the world (at least it
midnight and i was at a whiskey tasting this evening), but if somebody
thinks it could be useful to be included in
org.apache.commons.lang.StringUtils i will improve it and would be
glad to contribute interrupt() to you. If somebody has a better idea
than this, your comments are welcome.
Let me know.
Having said this, good night.
- Chris
/**
* Interrupts the string text after the max number of characters *
with the given seperator. Before this operation is beeing done, a split
* operation with the seperator is beeing fullfilled. This means that
seperator
* is beeing trimmed from the beginning and the end of the string.
* * @param text - the String which has to be interrupted
* @param seperator - the seperator to interrupt with
* @param max - maximal occurencies of other characters before the
string is beeing interrupted
* @return the interrupted string, null if the text is null
*/
public static String interrupt(String text, String seperator, int max) {
if(text==null) {
return null;
}
if(seperator == null) {
seperator = ;
}
String[] array = StringUtils.split(text, seperator);
StringBuffer result = new StringBuffer();
for(int i=0; i array.length; i++) {
String value = array[i];
if(i 0) {
result.append(seperator);
}
int length = value.length();
if(length max ) {
int pieces = length / max;
float mod = length % max;
if(mod0) {
pieces++;
}
int c = 0;
while( c pieces ) {
if(c0) {
result.append(seperator);
}
result.append(StringUtils.mid(value, c*max, max));
c++;
}
} else {
result.append(value);
}
}
return result.toString();
}
-
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]
[lang] StringUtils.interrupt
Hello all,
building my websites guestbook, i figured out that somebody entered a
big string (exactly: an URL). This blew up my complete layout. HTML
doesn't give any solution on this, you simply can't break up this stupid
long string.
Looking at commons lang i found a lot of join/split-operations, but it
seems that never anybody needed something of a separate after 20
characters with a blank-function. Well, i am not sure if ever somebody
REALLY needs this besides me, but you'll never know. So i decided to let
take you a look at my method (attached).
OK, i know it's not the very best method in the world (at least it
midnight and i was at a whiskey tasting this evening), but if somebody
thinks it could be useful to be included in
org.apache.commons.lang.StringUtils i will improve it and would be glad
to contribute interrupt() to you. If somebody has a better idea than
this, your comments are welcome.
Let me know.
Having said this, good night.
- Chris
/**
* Interrupts the string text after the max number of characters
* with the given seperator. Before this operation is beeing done, a split
* operation with the seperator is beeing fullfilled. This means that seperator
* is beeing trimmed from the beginning and the end of the string.
*
* @param text - the String which has to be interrupted
* @param seperator - the seperator to interrupt with
* @param max - maximal occurencies of other characters before the string is
beeing interrupted
* @return the interrupted string, null if the text is null
*/
public static String interrupt(String text, String seperator, int max) {
if(text==null) {
return null;
}
if(seperator == null) {
seperator = ;
}
String[] array = StringUtils.split(text, seperator);
StringBuffer result = new StringBuffer();
for(int i=0; i array.length; i++) {
String value = array[i];
if(i 0) {
result.append(seperator);
}
int length = value.length();
if(length max ) {
int pieces = length / max;
float mod = length % max;
if(mod0) {
pieces++;
}
int c = 0;
while( c pieces ) {
if(c0) {
result.append(seperator);
}
result.append(StringUtils.mid(value, c*max,
max));
c++;
}
} else {
result.append(value);
}
}
return result.toString();
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [compress] what to do with?
Is there anything in particular you are interested in Chris? I would like to add stuff to the zip-implementation, for example deleting files from a zipfile. I would like to see this component released and so i am also interested to discuss the api or to check the Ant implementation Stefan mentioned. I have time to do work end of next week. Chris. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [compress] what to do with?
Hi, I am interested in help with compress. I already read the code and checked out the zip-spec, but couldn't code something till now. Imaging an simple standalone compression helper makes me feel good. Chris Brett Porter wrote: I intend to resuscitate compress, but I wouldn't want to have to maintain the existing API (though not far off). Might be best to svn cp them into your own tree. - Brett Mario Ivankovits wrote: Hi! What to do with [compress]? There is no development on the compress package, but VFS depends on it. As you know, this is a show stopper for VFS to release. The question now is if we should promote compress to proper and cut a release or if I should import the required classes into the VFS codebase. The latter might mean that compress will get dormant at all. Personally I would like to keep compress as I hope sometimes in the future we well see new compression algos too. Might It be an option to move compress to [codec]? With some good will ;-) we can argue that it fits not that bad. Ciao, Mario - 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: [cli][patch 0/2] Some minor fixes
... please, do us a favour and put them into Bugzilla, so they do not get lost. Any effort by the maintainers is on a voluntary basis and you don't know, when they have the time to look. A mailing list is not the proper archive for proposed changes, bugfixes and patches. Hi, i agree with you. This should be changed if this is the common opinion: * http://jakarta.apache.org/commons/patches.html There are two ways to submit a patch: [...] - By mailing the patch as an attachment to the appropriate dev mailing list [...] But which way is better? They are both equally acceptable! Regards, Chris. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump VM
So what can we do? I read about timers in the book killer game programming in java :-), where this things are important. Maybe this is a direction for you. Use the following instead of System.currentTimeMillis(): 1) Suns undocumented Class (Java2): sun.misc.Perf 2) Java 5: System.nanoTime() This two have a higher resolution than currentTimeMillis() and could help. Chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [test] Awake dormant component
Alex Karasulu once created the test component and I had already at that time a special interest in this. I would like to awake this dormant component, maintain and add stuff. just for info, what did this component? can't find any information about this. Thanks Chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [compress] playing around
i will take a look on the mentioned projects, but i am quite sure i will start with compress, cause i am having the zip-problem all the time. thanks for your answers, links etc! i will let you know i have some patches someday :-) Chris James Carman wrote: I thought he was saying that there were no examples for compress. Upon further inspection though (I'm not that familiar with that project), it's not that there are no examples, but the links to the examples are broken. I've noticed quite a few broken links on the apache site in the past couple of days. For example, the links to download the velocity releases on this page (http://jakarta.apache.org/site/downloads/downloads_velocity.html) are broken also. Anyway, if you would still like to see the examples, they're available here: http://svn.apache.org/repos/asf/jakarta/commons/sandbox/compress/trunk/src/t est/org/apache/commons/compress/bzip2/example/Bzip2Compress.java and here: http://svn.apache.org/repos/asf/jakarta/commons/sandbox/compress/trunk/src/t est/org/apache/commons/compress/bzip2/example/Bzip2Uncompress.java I was merely suggesting the more popular ones, since they would most likely be better documented and there should be many examples readily available. But, as Rahul said, if compress is what you're interested in, by all means check it out. Just make sure you check out proxy next! ;-) James -Original Message- From: Rahul Akolkar [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 06, 2005 4:50 PM To: Jakarta Commons Developers List Subject: Re: [compress] playing around On 12/6/05, James Carman [EMAIL PROTECTED] wrote: Chris, I probably wouldn't choose a component in the sandbox to start off with. If I were you, I'd start with one of the more popular commons components from the proper. You might try Collections, Lang, BeanUtils, or Digester. Those are the ones that I've found most useful on the typical project. snip/ True, OTOH, Chris, if [compress] has taken your fancy, please go for it. All Commons components are looking for volunteers. While picking up one that is less popular might mean longer response times on mailing lists or in Bugzilla, if you take up spreading the word as a challenge, I'm sure you'll find much joy along the way as well. -Rahul James -Original Message- From: C. Grobmeier [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 06, 2005 12:58 PM To: Jakarta Commons Developers List Subject: [compress] playing around Hi, i want to play around with some commons components to get a deeper understanding. I would like to start with compress. The examples are not online at the moment. I wanted to ask if somebody has a link with examples for me or other information about the roadmap or todo. Cheers + Thx, Chris - 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: [compress] playing around
Whats the zip-problem? You want to create a simple zipfile and always have to google and try to figure out what this and that means instead of simple writing: ZipFile zip = new ZipFile(/home/Cy/yourzip.zip); zip.add(/home/Cy/yourfile1.zip); zip.add(/home/Cy/yourfile2.zip); zip.create(); No problem at all, but after 5 projects i have 5 different interfaces for the same problem. Looking at commons i found compress, so i thought this would be a great place to start. Chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [compress] playing around
In other words, if your solution also allows to change/update zip files (or even more abstract jar/tar too), chances are good to have this integrated in commons-vfs too ;-) sounds like one should play around with compress :-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[compress] playing around
Hi, i want to play around with some commons components to get a deeper understanding. I would like to start with compress. The examples are not online at the moment. I wanted to ask if somebody has a link with examples for me or other information about the roadmap or todo. Cheers + Thx, Chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[compress] playing around
Sorry for the double-post. For your comfort i sent my message again. -- Hi, i want to play around with some commons components to get a deeper understanding. I would like to start with compress. The examples are not online at the moment. I wanted to ask if somebody has a link with examples for me or other information about the roadmap or todo. Cheers + Thx, Chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Commons Manual
Maybe this is of interest: * Programming guidelines: do's and don'ts Chris Phil Steitz wrote: I am +1 (in the sense of will help :-) for anything involving improving docs. My one request would be that we start with the docs that already exist and target the main commons web site to house this stuff, rather than creating ever more scattered and incomplete Wiki pages. The following items are already covered on the commons and apache/dev pages: * Subversion information. How to check code out. * Maven information. How to build. * Site information. How to generate the site. How to upload your changes. * Releasing. How to release. If the existing pages are not complete or clear enough, then we should start by updating them. Phil - 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] Together, and bricks apart
At least one of you release checkers ;-) should setup a wiki to describe every step to do, this helps the release manager and those checking it. Especially if you are a newbie in the release cycle it might be a great start AND it defines standards. I like Marios idea. Very new to commons-dev i would like to get more involved. I guess i will start with bugfixing, submitting patches all this stuff. Checking out a potentiel release is work everyone can do- if there is a concrete description what to do. I really have a problem with:hey do you support this release?- ok, i have no idea if this is all ok cause i don't know what i should check. In this case it's better to shut up :-) If somebody could provide a wiki page it would be a good start for a noob like i am to help out with some things. Namely: gimme a checklist. Cheers, Chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
