[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [compress] High Level API for Archives

On 2018-04-26, Matt Sicker wrote:

> If it helps in design, the most promising approach I found was to integrate
> with the java.nio.file API. However, that turns into a sort of hybrid
> library between VFS and Compress.

The current compress-2.0 branch - which is something that I haven't fully
given up on but is dormant right now - at least uses the file views for
permissions and stuff.

I must admit I was underwhelmed by the java.nio.file implementation when
I tried it for real in Ant's setpermissions task (even though Windows
file system can provide POSIX attributes for everything it won't provide
a PosixFileAttributes view and you are restricted to set a DOS read-only
flag). But losing focus here. :-)

> However, they are rather strongly related (if the two libraries were
> modular, then it wouldn't be such a problem to combine them).

I'm not sure what you mean by modular in this context.

Splitting Compress into an API-only library and separate libs for the
different formats? This might be doable in a 2.0 version because
everything else would not be backwards compatible. But we'd end up with
a double digit number of jars which I'm not sure will be easy to
maintain. You likely would want to release them independently (why would
I release the commons-compress-pack200 component if there only is a
change in commons-compress-tar?) and end up with a strange mix of
versions inside of a single reactor build. I'm a bit scared by the idea,
I must admit :-)


To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxx