[jira] [Commented] (COMPRESS-118) Simple high-level api to do with one line what you can do with one command in a command shell

["Stefan Bodewig (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/COMPRESS-118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16447219#comment-16447219 ] 

Stefan Bodewig commented on COMPRESS-118:
-----------------------------------------

I'm not quite sure what kind of operations are needed and whether we want to provide all of them inside of a single class or break into into multiple classes. Collecting all of them in {{ArchiveUtils}} may be possible but I feel it might be better to provide separate more cohesive classes for the different tasks.

Right now I'd like to focus on creating and expanding archives. What do we need here? From the top of my head I'd see (focusing on the method signatures)

{code:java}
class Archiver {
    void create(String format, File target, File directory) throws IOException, ArchiveException;
    void create(String format, File target, File directory, FileFilter filter) throws IOException, ArchiveException;
    void create(String format, OutputStream target, File directory) throws IOException, ArchiveException;
    void create(String format, OutputStream target, File directory, FileFilter filter) throws IOException, ArchiveException;
    void create(String format, SeekableByteChannel target, File directory) throws IOException, ArchiveException;
    void create(String format, SeekableByteChannel target, File directory, FileFilter filter) throws IOException, ArchiveException;
}
{code}

we could add {{Path}} instead of/in addition to {{File}}, I'm not sure. I've explicitly added {{SeekableByteChannel}} as zip and 7z could take advantage of them (7z won't be able to create an archive for a non-seekable stream). The "format" would be a constant from {{ArchiveStreamFactory}}. Likewise

{code:java}
class Expander {
    void expand(File archive, File targetDirectory) throws IOException, ArchiveException;
    void expand(String format, File archive, File targetDirectory) throws IOException, ArchiveException;
    void expand(File archive, File targetDirectory, Filter<ArchiveEntry> filter) throws IOException, ArchiveException;
    void expand(String format, File archive, File targetDirectory, Filter<ArchiveEntry> filter) throws IOException, ArchiveException;
    void expand(InputStream archive, File targetDirectory) throws IOException, ArchiveException;
    void expand(String format, InputStream archive, File targetDirectory) throws IOException, ArchiveException;
    void expand(InputStream archive, File targetDirectory, Filter<ArchiveEntry> filter) throws IOException, ArchiveException;
    void expand(String format, InputStream archive, File targetDirectory, Filter<ArchiveEntry> filter) throws IOException, ArchiveException;
    void expand(SeekableByteChannel archive, File targetDirectory) throws IOException, ArchiveException;
    void expand(String format, SeekableByteChannel archive, File targetDirectory) throws IOException, ArchiveException;
    void expand(SeekableByteChannel archive, File targetDirectory, Filter<ArchiveEntry> filter) throws IOException, ArchiveException;
    void expand(String format, SeekableByteChannel archive, File targetDirectory, Filter<ArchiveEntry> filter) throws IOException, ArchiveException;
{code}

Here the methods withour "format" would try to auto-detect the format and throw an exception if they fail to.

Would this cover all use-cases for archive creation/extraction or do we need more than that?

> Simple high-level api to do with one line what you can do with one command in a command shell
> ---------------------------------------------------------------------------------------------
>
>                 Key: COMPRESS-118
>                 URL: https://issues.apache.org/jira/browse/COMPRESS-118
>             Project: Commons Compress
>          Issue Type: New Feature
>          Components: Archivers
>            Reporter: Eirik Maus
>            Priority: Major
>              Labels: API
>             Fix For: 1.17
>
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> There should be a high-level api for basic operations with archives in Java. This could be a place for it. There are a few apis for working with compression archives in java, but all of them are fairly low-level. The most basic operations therefore requires just as much code as more specific ones.  It is not possible to unzip an archive in less than 50 lines of code, can you believe it!  
> Performing basic operations on archives should be as easy in java as on the command line. I suggest adding something like:
>   HighLevelApi.extractAll(zipfile,destinationDirectory)
> or, even
>   new ZipFile(file).extractAllTo(directory)
> and
>   ZipFile archive = HighLevelApi.createFrom(directory, "*");
> or, even
>   ZipFile archive = ZipFile.from(directory);
> In general: one line in bash should be one line in java (plus try-catch...) for these kinds of operations. 
> See "zip --help" and "unzip --help" for further candidate methods in the high-level API. 
> One could also consider a coordinated effort with the VFS-project, in order to add such methods to all such hierarchies/storages. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)