https://github.com/apache/commons-compress/blob/master/ src/main/java/org/apache/commons/compress/archivers/Archiver.java
Is tiny compared the whole lots of https://github.com/apache/commons-compress/tree/master/ src/main/java/org/apache/commons/compress/archivers/examples and while the later is not a bad approach it's also a whole lot of belts and whistles. I also noticed when re-reading the snippet try (Sink<File> sink = ArchiveSinks.forFile(args[1], new File(args[2]))) { Archive.directory(new File(args[0])) .to(sink); } that "forFile" is not very descriptive for a high level API. With jdeb being one of the compress users I am still on the fence whether (if released some day) I would want to switch to a Sink API or not. Internally jdeb also uses producer-consumer abstraction - so it could maybe make sense to try that route. And with jdeb needing a major overhaul anyway it is a possibility. But I also have the feeling I might want to have the producer-consumer code closer to home. Either way I'd need to find the time to sketch out the plans for jdeb 2.x first. Bottom line: Given that you are currently the main person working on Compress I'd say - whatever you are OK with. But you don't really sound super confident/happy about the API - otherwise you might not have written this email :) I personally would keep both approaches for now - but somewhere outside of the official jar. And just give everyone some time to play with it. cheers, Torsten
