[shrinkwrap-issues] [JBoss JIRA] (SHRINKWRAP-389) Allow ShrinkWrap to overwrite existing ArchivePaths

Ken Finnigan (JIRA) jira-events at lists.jboss.org
Thu Oct 18 08:46:01 EDT 2012


    [ https://issues.jboss.org/browse/SHRINKWRAP-389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12727668#comment-12727668 ] 

Ken Finnigan commented on SHRINKWRAP-389:
-----------------------------------------

In terms of overloaded methods, I think a good name would be:

replaceAsResource(whatever)

as it reads a bit cleaner to me than:

overwriteAsResource(whatever)

or

addAsResourceWithOverwrite(whatever)

I like Aslak's idea of setting an overwrite flag, but feel it could potentially be more confusing and error prone.  Particularly in situations where a projects' testsuite may build up the content of an archive for deployment through method calls in a class hierarchy or static calls, making it difficult to know from looking at an archive in a test whether that particular archive is in overwrite mode or not.

Also, I'm not sure I understand the need for backward compatibility because as I understand it today overwriting resources that exist in archive does nothing, hence this jira, so existing arquillian code that needs to "replace" existing paths from code I've seen removes the existing path before adding back an updated one.  Without changing existing code, whether the archive is overwritable or not, or if there are overwrite methods on the archive, doesn't impact the legacy code.
                
> Allow ShrinkWrap to overwrite existing ArchivePaths
> ---------------------------------------------------
>
>                 Key: SHRINKWRAP-389
>                 URL: https://issues.jboss.org/browse/SHRINKWRAP-389
>             Project: ShrinkWrap
>          Issue Type: Feature Request
>            Reporter: Andrew Rubinger
>            Assignee: Michal Matloka
>              Labels: starter
>
> SHRINKWRAP-329 created a fail-fast (as opposed to silent no-op) approach to encountering the following case:
> {code}        // Create the new archive
>         final Archive<?> archive = createNewArchive();
>         // Put in an asset
>         final ArchivePath path = ArchivePaths.create("testPath");
>         archive.add(EmptyAsset.INSTANCE, path);
>         // Now try again with a new asset, and this should fail
>         try {
>             archive.add(new StringAsset("failContent"), path);
>         } catch (final IllegalOverwriteException ioe) {
>             // Good
>             return;
>         }{code}
> We need a feature now to disable this, effectively a boolean flag for each of the archive "add" methods to allow overwriting.  Will encompass API changes.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


More information about the shrinkwrap-issues mailing list