Skip to content

Handling empty archives #52

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
Tunaki opened this issue Nov 1, 2016 · 2 comments
Closed

Handling empty archives #52

Tunaki opened this issue Nov 1, 2016 · 2 comments

Comments

@Tunaki
Copy link

Tunaki commented Nov 1, 2016

There is an issue for the Maven Assembly Plugin (MASSEMBLY-833) asking for a way to skip the creation of empty archives, instead of failing.

This is a use-case that cannot really be solved at the plugin level: it is possible to check if any resources are present with archiver.getResources().hasNext(), but this doesn't tackle the possible finalizers adding real or virtual files to the archive when it is created. Archiver can add themselves finalizers, which the plugin is then unaware of. For example, the DotDirectiveArchiveFinalizer is added at the moment an attempt is made to create the archive.

If support for handling empty archives should be added, there seem to be 2 possible solutions:

  1. Add a method isEmpty() on the Archiver interface.
  2. Mandate archivers to throw an exception in the case of an empty archive.

With regard to 1. I don't see an easier way to determine whether an archive is going to be empty or not than the following: check whether there are any added resources, then check whether any finalizer adds virtual files, and finally run all the finalizers on a mock archiver to determine whether or not they would add any real files to the archive (since we don't know in advance if they would, and the archiver doesn't know what the finalizer does). Note that since a method is added on the interface, this would probably require a major version update.

With regard to 2. This isn't specified in the documentation (there is no Javadoc), and currently, all of the built-in archivers, except DirectoryArchiver, are raising an exception in this case, although it is not consistent: for example AbstractZipArchiver and TarArchiver throw an ArchiverException in case of an empty archive, but GZipArchiver and SnappyArchiver throw a NoSuchElementException.

First of all, would such an addition be welcomed for Plexus Archiver? And if so, what would be the most appropriate choice here? Solution 1 is preferable: it gives a direct and simple way to check for content and it would allow Plexus Archiver to be able to create empty archives in the future if there's a need for it (the current exceptions could be configurable, and left for the caller to decide what to do in this case). But if it doesn't make sense to try to create empty archive, solution 2 would be simpler.

As far as the Maven Assembly Plugin is concerned, there is no need to create empty archives (no demand for that use-case) and it would most likely represent an error in the configuration; but other projects could have the need for this.

@plamentotev
Copy link
Member

plamentotev commented Nov 3, 2016

I want to add one somewhat related question. Should the clients of Archiver be able to get a list with the files (virtual and real files) that will go into the final archive before creating the archive?

If the answer is 'yes', then the current implementation should be changed. Archiver#getResources does not do that. First it does not take into account the virtual files. And second, finalizers could (and in fact some of them do) add files when the createArchive is invoked - that is when it is too late for the client to get a list of files that will go into the final archive. While the first point is implicitly documented, I don't think the second is. In my opinion that makes the method confusing and I wonder if there is an use case where Archiver#getResources is useful as public method (if it's used only by the Archiver implementations it could be protected method in AbstractArchiver).

@plamentotev
Copy link
Member

This one is fixed with #51 so I'll close it. @michael-o as far I can remember you had some ideas about the creation of empty archives. Would you please add another issue with them as I'm afraid otherwise we'll forgot them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants