On 29 April 2018 at 06:24, Stefan Bodewig <bode...@apache.org> 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 dependencies. 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 <boa...@gmail.com>
