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

Re: [compress] High Level API for Archives

On 29 April 2018 at 06:24, Stefan Bodewig <bodewig@xxxxxxxxxx> wrote:

> 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.

Neat! I've experimented a bit locally in the past to see how big an effort
it would be to migrate vfs to this API, and I got frustrated by having to
implement Path in a completely different way than the existing path
abstraction in vfs (which only has absolute URLs as far as I could tell,
but maybe I'm wrong).

> 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. :-)

Yes, maybe that's why I've barely seen anyone implement this API. Perhaps
Commons needs to be that starting point for everyone else? :)

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

As in one module/jar per implementation. One module for a zipfs, one for an
sshfs, etc., instead of just "commons-vfs" as a monolith with optional

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 :-)

Depending if the modules are separated by git repo (like how maven handles
its individual plugins they maintain) or all in a single repo, that would
certainly determine how often each FS gets released. Based on the release
process, I'd suggest the all-in-one repo unless each FS has a couple people
to vote on releases individually.

Matt Sicker <boards@xxxxxxxxx>