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 :-) Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
