TBH I am not such super big fan of adding and maintaining a high level API at this stage. You will never find the right abstraction that everyone is happy with. If you would - well, then that should be the real API afterall.
Honestly - I would just add example code for now. Maybe that can turn into a helper class in the long run. But for now we would not introduce something we may no longer break. Maybe we need to look at the various users of the API and take that as the basis for the next step. My 2 cents. Torsten On Mon, Apr 23, 2018 at 8:57 PM, Stefan Bodewig <bode...@apache.org> wrote: > Hi all > > I've started to work on COMPRESS-118 and added Archiver and Expander > classes - without any tests for now. As I'm trying to cover a bunch of > possible use cases there are lots of inputs or outputs that can > represent archives. When expanding archives you may want to use > auto-detect the format or specify it explicitly. You may want to filter > the files to add/entries to expand. All this leads to an explosion of > overloads that I'm not comfortable with. > > One idea that I came up with is using a fluent interface like > > Expander.forFile(someFile).filtering(someFilter).expandTo(someDirectory); > > or similar. But before I delve deeper into it, I'd like to collect > feedback. > > And then I'd like to collect additional features that might be > needed. What I can easily imaging is > > * When expanding, don't overwrite existing files when expanding an > archive (or only if the archive entries are newer. > > * Add an API for updating archives - of course this boils down to > writing a completely new archive with entries taken from two sources. > > * we may want to provide a utility class that makes dealing with the > subclasses of ArchiveEntry easier. Many of them provide a userid, but > there is no common interface. I'm thinking about something like > > https://github.com/apache/ant-antlibs-compress/blob/master/src/main/org/apache/ant/compress/util/EntryHelper.java > > Any feedback is very much appreciated. > > Stefan > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
