commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Bodewig (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (COMPRESS-118) Simple high-level api to do with one line what you can do with one command in a command shell
Date Sun, 22 Apr 2018 12:25:00 GMT

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

Stefan Bodewig edited comment on COMPRESS-118 at 4/22/18 12:24 PM:
-------------------------------------------------------------------

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?


was (Author: bodewig):
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)

Mime
View raw message