Hi all,
with the fix of COMPRESS-58 the magic BZ is not longer written to the stream.
Its assumed the stream caller has written this. Compress-69 is a bug
which claims about inconsistency.
However, I would like to comment in those two lines again which writes
BZ to the stream.
Anything speaking
Hi,
I don't think that TarArchiveInputStream should have that method:
copyEntryContents(OutputStream out) throws IOException
I copies the current read entry directly to an output stream which
mixes up reading and writing.
The method is never called in the workspace and I will remove it now.
If
bode...@apache.org wrote:
Christian Grobmeier has been elected as a new Commons committer about
two weeks ago and this has been his first commit
On 2009-04-07, grobme...@apache.org wrote:
Author: grobmeier
Date: Tue Apr 7 16:56:00 2009
New Revision: 762849
Welcome!
Stefan
Hi,
TarArchiveOutputStream, TarArchiveInputStream and TarBuffer contain a
variable named debug. In the first class it does nothing.
If it is set in TarBuffer the flag produces some weird output on System.err.
Like this:
if (numBytes != blockSize) {
if (debug) {
Hi,
looking at:
http://people.apache.org/builds/commons/nightly/commons-compress/
shows me just some md5 hashes,
but:
http://people.apache.org/builds/commons/nightly/commons-vfs/
has some builds. Can I do something to change this?
Thanks,
Christian
Hi,
Sebb allready took a look at all the classs and annotated them
carefully. Conclusion is, Compress is not (completly) threadsafe.
Looking round the code I think we have documented it quite complete.
The tags proposed by Sebb can be found in the site by now. Everybody
should know why and how we
I think all proposed changes are good.
Tar looks quite complex for my taste and everything which makes this
part of compress more easy is highly appreciated.
Cheers
On Thu, Apr 2, 2009 at 4:09 PM, sebb seb...@gmail.com wrote:
I find it confusing to have get() as the inverse to parse() -
OK, I'll remove them.
What about the corresponding getNextxxxEntry() methods?
I suppose they do avoid a cast.
Correct.
I'll don't need them so specific stuff. For ChangeSet its all enough
to have ArchiveEntry aswell.
-
To
Hi,
The current ChangeSet API allows for:
+ deletion of entries by name
+ addition of entries by ArchiveEntry and InputStream.
This is fine as far as it goes, but I think it would be useful to add:
+ addition of entries by File
+ replacement of an existing named entry by File or
As you assumed,
getSize returns the size of file data for this entry (to be clear, no
header data).
I will write some javadoc for this class when I have my account ready.
Cheers,
Christian
On Fri, Mar 27, 2009 at 6:25 PM, sebb seb...@gmail.com wrote:
The interface ArchiveEntry does not have any
I think the only requirement was to give credit ...somehow somewhere.
This is true for CPIO.
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Cool!
On Thu, Mar 26, 2009 at 12:09 PM, Jukka Zitting jukka.zitt...@gmail.com wrote:
Hi,
I just made a patch (see TIKA-204 [1]) to Apache Tika where I replaced
our custom copies of the Ant classes with a proper dependency to
commons-compress 1.0-SNAPSHOT. Everything works fine and I was even
Hi,
shouldn't credits of:
https://issues.apache.org/jira/browse/COMPRESS-23
go to Adrian Pronk?
Cheers,
Ch
On Tue, Mar 24, 2009 at 9:41 PM, mben...@apache.org wrote:
Author: mbenson
Date: Tue Mar 24 20:41:45 2009
New Revision: 758009
URL: http://svn.apache.org/viewvc?rev=758009view=rev
Is that because of the checkstyle tool, or because of the rules that
have been chosen?
Not because of these rules. It's the approach.
I've seen people wasting too much time on this. Builds breaking
because of wrong coding styles. Terrible!
I thought checkstyle.xml is a commons convention.
On 2009-03-24, Torsten Curdt tcu...@apache.org wrote:
Personally I am not a big fan of checkstyle enforcement at all.
I can perfectly well live without it as well.
OK, I will add a patch to the cs issue whcih deletes the checkstyle.xml
from the pom file (its currently commented out).
Cheers
!
Christian
Sitting next to Stefan Bodewig,
Siegfried Goeschl
Christian Grobmeier wrote:
On 2009-03-24, Torsten Curdt tcu...@apache.org wrote:
Personally I am not a big fan of checkstyle enforcement at all.
I can perfectly well live without it as well.
OK, I will add a patch to the cs
Hi
Christian, you could have a go at doing this yourself. I added you
specifically to the COMPRESS project in JIRA, so you should have the
privileges to do that. Let me know if it doesn't work for you, and I'll
have another look at it.
it seems to work, thank you very much!
Christian
Hi,
i just added a patch to:
https://issues.apache.org/jira/browse/COMPRESS-28
This should make sure that CPIO classes work like all the other classes.
Testcases are more better and now I feel more comfortable with this new stuff.
Cheers,
Christian
It looks to me as though Adrian's report/patch actually came after (this)
Christian's... no?
True. :-)
Christian
-Matt
--- On Wed, 3/25/09, Christian Grobmeier grobme...@gmail.com wrote:
From: Christian Grobmeier grobme...@gmail.com
Subject: Re: svn commit: r758009 - /commons/proper
Hi all,
I just try to figure out how to include a checkstyle.xml in compress.
I have stolen the configuration file
from [email] and put it in the root directory. For testing I enabled
it within eclipse and found out that
I need to set the following properties, which seem to come out from
can help me :-)
Mostly I have taken the same options then [email] has, except that I
prefer to have my braces { on the same level as my method name is (sun
standard).
Any comments?
Best,
Christian
On Tue, Mar 24, 2009 at 8:00 AM, Christian Grobmeier
grobme...@gmail.com wrote:
Hi all,
I just
I need to set the following properties, which seem to come out from
commons-parent. I checked that out and searched, but couldn't find the
setting of this properties.
I think you're mistaken - AFAIK commons-parent doesn't have anything
configured for checkstyle.
oh... thanks! OK I will
Hi,
first patch for:
https://issues.apache.org/jira/browse/SANDBOX-305
just contains some java doc, but this was necessary for understanding
CPIO and resolving
the bug. Can you please apply?
Thanks,
Christian
-
To unsubscribe,
Hi,
the checkstyle.xml is missing - I create an issue and add a patch.
If need to do that now comment out the pom
Cheers + Thanks for the hint,
Christian
On Mon, Mar 23, 2009 at 1:25 PM, Stefan Bodewig bode...@apache.org wrote:
On 2009-03-23, Siegfried Goeschl siegfried.goes...@it20one.at
Hi,
however, I am worrying about I don`t have 'commit authority' when
it goes to sandbox.
So, I`d like to know how to obtain 'commit authority' when it goes to
sandbox. Is it possible?
here are two interesting links for you:
http://www.apache.org/foundation/getinvolved.html
A long road, but I am so glad compress finally made it :-)
On Fri, Mar 20, 2009 at 7:29 AM, Henri Yandell flame...@gmail.com wrote:
*cheer*
My +0 not withstanding, this is great :)
On Thu, Mar 19, 2009 at 10:26 PM, Stefan Bodewig bode...@apache.org wrote:
Hi all,
I'm happy to announce
I added a patch for CPIO to SANDBOX-294
Cheers
On Wed, Mar 18, 2009 at 11:22 AM, sebb seb...@gmail.com wrote:
On 18/03/2009, Stefan Bodewig bode...@apache.org wrote:
On 2009-03-18, Stefan Bodewig bode...@apache.org wrote:
I'd like to remove some fields, make them private or final and maybe
Hi,
a patch for SANDBOX-298 is available. Nothing special here.
Thanks for applying!
Cheers
Christian
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Hi,
diving into the open issues, I would like prio them.
* SANDBOX-282 TAR formaT unspecified
https://issues.apache.org/jira/browse/SANDBOX-282
I would do this in version 1.1. Its an important thing, but will need
its time, at least, if I work on this :-)
* SANDBOX-286 BZip2CompressorInputStream
Thanks Stefan and Sebb,
I reorganized the wiki page on that basis.
http://wiki.apache.org/commons/CompressRoadmap
Christian
On Fri, Mar 20, 2009 at 6:19 AM, Stefan Bodewig bode...@apache.org wrote:
On 2009-03-19, Christian Grobmeier grobme...@gmail.com wrote:
* SANDBOX-293 Make
Hi,
as far as I know you have to apply a DOAP file. I created one, see this issue:
https://issues.apache.org/jira/browse/SANDBOX-304
I guess pathes will be correct, but better review please.
Cheers
Christian
On Fri, Mar 20, 2009 at 6:31 AM, Stefan Bodewig bode...@apache.org wrote:
Hi,
the
Additionally,
can you pleaes tag the component after the move?
http://wiki.apache.org/commons/MovingComponents
Thanks
Christian
On Fri, Mar 20, 2009 at 6:47 AM, Christian Grobmeier
grobme...@gmail.com wrote:
Hi,
as far as I know you have to apply a DOAP file. I created one, see this issue
Hi,
I think restrict visibility whereever possible would be a good idea
too. You can loosen later if one wants to.
I just checked out CPIO, AR and JAR. The latter two contain so less
code, everything looks good. But CPIO needs some work...
However, I guess you want to:
CpioArchiveInputStream
-
to test this special scenario or not.
Cheers
Christian
On Tue, Mar 17, 2009 at 4:14 PM, Stefan Bodewig bode...@apache.org wrote:
On 2009-03-17, Christian Grobmeier grobme...@gmail.com wrote:
Hi
I could not test it with a general working testcase, since this is a
platform problem and i have
Does only proper components need a doapfile?
If yes, then proper-trunk, except if a proper component can go dormant.
Then doap_files in SVN.
Christian
On Wed, Mar 18, 2009 at 5:11 AM, sebb seb...@gmail.com wrote:
On 23/05/2008, sebb seb...@gmail.com wrote:
At present the doap files are in each
Hi,
So we don't have a continues
integration test for exactly that problem.
IMO it does not matter not having a continuous integration test so
long as the OS-specific stuff is tested from time to time by someone,
and particularly before release.
Might be a good idea to make a note in the
Sorry, I still don't understand why refactoring would be needed in
order for the code to be tested using CI?
I must be missing something - can you explain?
I'm curious to know what the problem is that requires refactoring for CI.
Sorry for beeing unclear. Refactoring is big term for
Yes, understood now, thanks.
In which case maybe it is worth refactoring into two package-protected
methods so Unit tests can exercise them easily. It would be useful for
a Windows developer to be able to test the Unix code too.
Also consider doing this for any other bits of code that
Hi all,
just made a quick fix for SANDBOX-284:
https://issues.apache.org/jira/browse/SANDBOX-284
I could not test it with a general working testcase, since this is a
platform problem and i have only OSX.
However, GUMP will not run on windows too, i guess. I think here is
some refactoring
Hi,
it looks like all the world is meeting at the conference except myself :-)
However, I think developing at the hackathon is a quick development,
and I would like to kindly ask you to take make some edits at the wiki
and let me know which tasks has been done. It would be frustrating to
think on
Its SANDBOX-302 now: https://issues.apache.org/jira/browse/SANDBOX-302
Medium isnt in the system, I tagged it minor now.
Major is the new Medium :) It's the default, so everyone treats it as medium.
Aaaah ok :-) I updated the prio now.
Thanks
Christian
Btw - I've had a success organizing this kind of thing on a wiki page.
That worked very well for me with both Quartz work and Taglibs.
Thanks Hen, this is a good idea. I have added an wiki page too:
http://wiki.apache.org/commons/CompressRoadmap
Christian
favours already for maven-related help
Cheers,
Siegfried Goeschl
Christian Grobmeier wrote:
Hi all,
since everybody seems to agree to promoting compress I collected several
todos.
I would like to discuss what is necessary for release 1 and what is not.
* Of course administrative stuff
* Gump: I don't see compress here:
http://vmgump.apache.org/gump/public/apache-commons/index.html
Because you are looking at the wrong place 8-)
http://vmgump.apache.org/gump/public/commons-sandbox/index.html
thanks, that helped :-)
* Stefan wrote: I'd love to work on Zip64 support
Hi all,
since everybody seems to agree to promoting compress I collected several todos.
I would like to discuss what is necessary for release 1 and what is not.
* Of course administrative stuff: vote compress to proper etc. I don't
have a clue of that currently. Who of you feels responsible for
Patch for this is now attached to Jira. If somebody has some time left.. :-)
Cheers,
Christian
On Wed, Mar 4, 2009 at 2:45 PM, Sebb (JIRA) j...@apache.org wrote:
AbstractTestCase.createArchive method appears to use incorrect file size -
cut and paste error?
Hi,
I added a patch to Jira.
The attached patch fixes the following:
* ArchiveStreamFactory and CompressStreamFactory throw an
Exception now if no fitting Archiver/Compressor cand be found
* If the name of the impl. or the stream is null, an
IllegalArgumentException will be thrown
*
Hi
All committers have write access to Gump data files.
I can add it.
It can go into Compress JIRA issue if you want to track it, but AFAIK
Gump is not required.
not necessary if you keep an eye on it :-)
* ChangeSet Support (SANDBOX-183): testcases and such are running. Its
..
Yep. We'll probably start using the component in Tika as soon as a
release is available, and through Tika the code will soon find it's
way to wider use in projects like Solr and Jackrabbit. I wouldn't be
surprised if these uses resulted in at least a few contributions
trickling back to here.
Could anybody using Eclipse please check whether the appended trivial
patch causes problems there?
Your patch works for me with Eclipse Ganymede and Mac OSX 10.5.
The addUrl Method looks like not used anymore, it can be removed imho.
It has appeared cause of the getClass.getResource approach.
Its now know as:
https://issues.apache.org/jira/browse/SANDBOX-296
I will create a patch fo a testcase quite soon
Best,
Christian
On Mon, Mar 2, 2009 at 6:16 AM, Stefan Bodewig bode...@apache.org wrote:
On 2009-02-28, Christian Grobmeier grobme...@gmail.com wrote:
Torsten (or any other) if you
I have improved ChangeSet stuff a bit. It now supports most common
usecases as described in the testcase.
The re-enabled tests pass for me, great.
svn revision 749332.
Thanks for applying!
Christian
-
To unsubscribe,
Thanks Stefan.
I allready thought that you can identify the problem within a short time.
Note that the method (or better the input stream) is still broken in a
more general sense since it will not detect self extracting ZIP files
which do have a tiny native bootstrapper tacked to the front of
My status: I started with implementing on that this morning and
figured out that its not a very easy task. Even when I have it
finished in a good time, there should be a good amount of testing
imho.
we could label that part of the API unstable/experimental - or leave
it out of the release
Hi,
I recently figured out that a compress created zip file doesn't
necessary match the signature of
ZipArchiveInputStream.matches(...)
For example:
AbstractTestCase.createArchive creates a zip archive with several files in it.
The resulting zip archive cannot be matched in
I put everything concerning the magic number issue into this jira issue:
https://issues.apache.org/jira/browse/SANDBOX-285
Is this sufficient?
I am still investigating the second issue, reading from the stream
directly works fine, but it fails if it is wrapped into a InputStreamReader.
Perhaps someone could add the source/target properties?
No idea how to do that and the POM reference didn't tell me either.
Please forgive the mvn neophyte.
Here it is:
https://issues.apache.org/jira/browse/SANDBOX-288
You have to check the compiler-plugin for the information:
The svn merges were more or less painless, the only conflict I got was
in UnknownExtraField because the commons-compress version uses m_foo
fields where Ant uses foo (likely because of Avalon/Peter Donald
coding style).
If you could do that - yes, thats cool then.
I suggest we add the
6) delete dir1 + add dir1/bla.txt
Like in every shell, I would think that this would delete all dir1/*
files first, and then adds a new file bla.txt in dir1.
Tthe question is whether it is missing an
add dir1/
Do we create directories implicit?
In my opinion, yes. If you look into a Tar
Hi,
i have added the CPIO patch to JIRA.
https://issues.apache.org/jira/secure/ManageAttachments.jspa?id=12398489
Please review esspecially the license stuff which we discussed
recently before applying.
Cheers
-
To unsubscribe,
I have it applied here locally and are ready for a commit.
Cool!
I did change a few things though. I've removed the attribution from
the class files as we don't do author tags either. I would think the
attribution in the NOTICE file should be enough. Or we add something
more along the lines
+ Thanks
cheers
--
Torsten
On Fri, Jan 9, 2009 at 08:20, Christian Grobmeier grobme...@gmail.com wrote:
Hi,
i made a patch of a first idea of the ChangeSet design which has been
proposed by Torsten.
https://issues.apache.org/jira/browse/SANDBOX-183
The testcase fails
Could we maybe ask the jrpm project whether upgrading the license to
ASL 2.0 would be an option? Would make things a little cleaner IMO.
I just wrote the guys an email and begged for a License change.
Great news:
The jRPM project has updated it License to AS 2.0.
For example:
Hi,
please apply the patch provided here:
https://issues.apache.org/jira/browse/SANDBOX-273
It updates old and evil stenching TAR compress code with fresh, soft
coated ant code.
This is a must have, cause the newer implementations are fixing many bugs which
make it impossible to use compress, if
Maybe we should really leave out the ChangeSet support for a 1.0 and
add that later.
I have a basic ChangeSet support nearly finished :-) I can propably
send a Delete- and a Add-Operation tomorrow morning. Maybe you'll have
some refactoring issues, but since this just a few lines of code, this
The software grant *donates* the code to the foundation, so all the
rights become of Apache itself, not of the owners.
The previous owners of the right will be mentioned only in the IP
(intellectual property) clearance form.
In your case I suggest to:
1. add the code in your software;
2.
Hi all,
compress issue 241 [1] proposes to implement CPIO archives. Since the
jRPM project allready
has implemented the streaming code, it should be really
straightforward to include it in compress.
I know I am bit early since there are many other open issues with
compress, but I would like
to
Contacting him surely can't hurt - no matter what ;-)
me neither :-)
..but this does raise an interesting question. Surely the safest would
be to get a software grant from him. But that frankly speaking that
feels a bit over the top. Other opinions?
How many classes are we talking about?
On Wed, Jan 7, 2009 at 3:18 PM, James Carman ja...@carmanconsulting.com wrote:
If you could create a JIRA and ask the author to attach their code as
a patch, that might be sufficient.
OK. I wrote the authors of the project. If they respond, I'll create a
issue and ask them for a patch.
exactly mean you have the
right to license the code at all (perhaps your employer owns
anything you write?). I'd feel safer with some a more formal code
grant, but that's just me.
On Wed, Jan 7, 2009 at 12:42 PM, Mark Thomas ma...@apache.org wrote:
Christian Grobmeier wrote:
Hi all,
compress
Hi,
https://issues.apache.org/jira/browse/SANDBOX-195
describes a problem, which occurs in the Ant-BZIP2-Classes and in in
our implementation (which is an old version of the ant stuff).
I created a patch which updates our codebase to the current codebase
of ant which should fix a few problems,
Hi,
sorry for beeing late :-)
I guess we could also just get rid of the reflection. What do you think?
I think this is good. I have attached a patch to:
https://issues.apache.org/jira/browse/SANDBOX-262
which eliminates the reflection usage in both factories.
Can sombody (Torsten? :-)) please
Hi all,
the redesigned compress-codebase fixes this issue:
https://issues.apache.org/jira/browse/SANDBOX-245
It can be closed. Can somebody please do this?
Thanks!
Chris
-
To unsubscribe, e-mail:
Hi,
i just added a patch to Sandbox-30:
https://issues.apache.org/jira/browse/SANDBOX-30
Can somebody please review and comment or patch the codebase?
Thanks,
Christian
-
To unsubscribe, e-mail:
Hi,
Yeah, I don't have access to a MAC, so have been reluctant to commit
MAC-specific changes. As a non-PMC committer to commons, Mark has my
(non-binding) +1 to becoming a commons commiter.
if you give me detailled instructions, I can test the issue on my Mac
with 10.4.x installed. I can do
On Mon, Nov 10, 2008 at 8:51 AM, Viraj Turakhia [EMAIL PROTECTED]wrote:
If I have read it right, I do agree with the point that we need to give
committers access to people more freely.
Definitly.Primetime developing for Commons is no fun. It's a bit frustrating.
Maybe there should be some
that would be wonderful.
Cheers
On Sun, Oct 5, 2008 at 4:10 PM, Torsten Curdt [EMAIL PROTECTED] wrote:
Any objections to move trunk over to an old design branch and then switch
the new design branch to be trunk?
This has already caused some confusion.
We need finally need to make some
Hi there,
I've recently been working with zip files and saw that commons IO did not
support them.
May I suggest that a ZipUtils class is added to commons IO, perhaps with my
meagre contribution
which has one simple function: expand a zip file from an input stream to a
directory. (and a support
Hi Stefan,
compress is a component of the commons-sandbox project:
https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truemode=hidepid=12310491sorter/order=DESCsorter/field=priorityresolution=-1component=12311183
@Torsten: i will prepare a patch for the redesign branch.
On Wed, Jul
thanks for that hint.
@Torsten: can I fix that in my GIT branch without disturbing the git-svn
commit?
Or should I wait till the commit has been finished?
On Thu, Jul 10, 2008 at 12:36 PM, sebb [EMAIL PROTECTED] wrote:
Just had a quick look at the compress redesign branch.
There are some
suggest we fix this in svn first and then you can start from a clean
git-svn clone if you want.
cheers
--
Torsten
On Jul 10, 2008, at 12:46, Christian Grobmeier wrote:
thanks for that hint.
@Torsten: can I fix that in my GIT branch without disturbing the
git-svn
The compress codebase is full of tabs. If I go ahead and detab things,
will that map happily over to your git tree? I don't want to make it
too painful for you to produce a patch that can come back.
I just reckoned that we didn't start to work against the svn codebase.
Instead of that we
Hi Martin,
we would like to have an own apache component,
cause several people here do not like the api.
As stated in the board report of september 07,
they is less community behind truezip, which is another -.
However, if interested, check these discussions here:
= tcurdt
merge = refs/heads/master
Pull in the commits:
git pull --rebase tcurdt master
Rewrite the log messages:
git filter-branch -f --msg-filter 'cat; if [ $GIT_AUTHOR_NAME = Chris
]; then echo; echo Author: Christian Grobmeier ([EMAIL PROTECTED]);
fi;'
git filter-branch -f --msg
Hi Samuel,
* I see that the
Archive
http://commons.apache.org/sandbox/compress/apidocs/org/apache/commons/compress/Archive.html
interface and the
ArchiverFactory
http://commons.apache.org/sandbox/compress/apidocs/org/apache/commons/compress/ArchiverFactory.html
deal a lot with files.
Torsten Curdt a écrit :
- the exceptions could extend IOException
Could - but why restrict it that way? (composition over inheritance)
I don't see this as a restriction.
Well, it means all ArchiveException necessarily need to be IOExceptions.
That's restricts their type.
I don't see
OK, we've never been consistent with our notation and some
committers liked HN You probably don't find any in the zip package.
* @author a href=[EMAIL PROTECTED]Stefan Bodewig/a
If anybody could remove that, I'd be grateful. That email address
died many years ago (not exaggerating)
I agree with Torsten. There may occur other exceptions than plain
input/output errors.
For example ?
hm, maybe those?
- putting the same file twice under same name in an archive
- putting different files twice under same name in an archive
- try to set unix permissions in an special
input/output errors.
I agree with Torsten. There may occur other exceptions than plain
I looked at the code, indeed the exceptions in the refactored compress are
always related to configuration issue, whereas in the current svn code
errors are often created on IO issues (path not writable,
+1 that would not be the place to throw a NPE IMO
You are right sorry, thought it was a method parameter.
No worries :-) Glad you jumped in and give so much feedback! That is
motivating!
On Wed, Jun 18, 2008 at 11:53 PM, Matt Benson [EMAIL PROTECTED] wrote:
--- Emmanuel Bourg [EMAIL PROTECTED] wrote:
That looks interesting, this kind of structure can
still be found today
in ar and cpio archives used for deb and rpm
packages. I also used this
style of file in inter
Hi Emmanuel,
thanks for your comments below. They all make sense.
However, Thorsten and I currently develop a new and (hopefully) better
implementation
than that which is currently available. That implementation fixes some of
the issues you mentioned.
If you want to take a look at it, please
Hi
Git is problematic for Windows. I tried to clone the repository with
msysgit but it failed with the following error :
fatal: Couldn't find remote ref HEAD
I use cygwin and could check out with:
$ git clone http://projects.grobmeier.de/compress-redesign.gitcompress-redesign
I created
I'll give it a look. I wanted to see how the Ar classes from jdeb could fit
into commons compress.
Cool!
Thorsten allready included some ArArchivers code, you may want to .take a
look into:
src\main\java\org\apache\commons\compress\archivers\ar
Hi
A higher level API to manipulate the archives would be nice, but I believe
an initial release could be made with just the stream classes.
Hm ...indeed. But IMO the changeset stuff is where it actually gets
interesting :)
changeset is great :-) however an initial release with the stream
Hi,
payload - self-extracting jar builder. Useful as an agile install tool.
gj-scrape - HTML scraping API. Scrapes as a String walker rather than
trying to tidy up into nice XML and doing DOM.
xmlwriter - output XML. Very simple API and I think still valuable. I
know there are alternatives
401 - 496 of 496 matches
Mail list logo
