12:54 a.m.
Andrew Rubinger created SHRINKWRAP-389:
------------------------------------------
Summary: 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
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:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12:56 a.m.
[
https://issues.jboss.org/browse/SHRINKWRAP-389?page=com.atlassian.jira.pl...
]
Andrew Rubinger updated SHRINKWRAP-389:
---------------------------------------
Fix Version/s: 1.1.0-alpha-X
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
Fix For: 1.1.0-alpha-X
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:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:51 p.m.
[
https://issues.jboss.org/browse/SHRINKWRAP-389?page=com.atlassian.jira.pl...
]
Andrew Rubinger updated SHRINKWRAP-389:
---------------------------------------
Fix Version/s: (was: 1.1.0-alpha-1)
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
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:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
11:28 p.m.
[
https://issues.jboss.org/browse/SHRINKWRAP-389?page=com.atlassian.jira.pl...
]
Andrew Rubinger updated SHRINKWRAP-389:
---------------------------------------
Labels: starter (was: )
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
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:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:09 p.m.
[
https://issues.jboss.org/browse/SHRINKWRAP-389?page=com.atlassian.jira.pl...
]
Aslak Knutsen commented on SHRINKWRAP-389:
------------------------------------------
the new IllegalOverwriteException is causing some issues for Arquillian.
* The user adds a Package to the Deployment, Arquillian then fail to add the TestClass
because it already exist in the user added Package. There is no
ClassContainer.contains(Class), so Arquillian has to construct a possible ArchivePath from
the Class and check if it exists already before adding. The ArchivePath change depending
on Archive Type of course. (Another option is of course a try catch)
* Packaging JUnit is a bit odd. JUnit include parts of hamcrest, but if you add the full
hamcrest lib to classpath as well, you now get some of the hamcrest classes twice. A
Filter alla this is a possible workaround for multi includes
{code}
new Filter<ArchivePath>() {
@Override
public boolean include(ArchivePath path) {
return !archive.contains(path);
}
}
{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
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:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:09 p.m.
[
https://issues.jboss.org/browse/SHRINKWRAP-389?page=com.atlassian.jira.pl...
]
Aslak Knutsen edited comment on SHRINKWRAP-389 at 5/30/12 5:09 PM:
-------------------------------------------------------------------
fyi: the new IllegalOverwriteException is causing some issues for Arquillian.
* The user adds a Package to the Deployment, Arquillian then fail to add the TestClass
because it already exist in the user added Package. There is no
ClassContainer.contains(Class), so Arquillian has to construct a possible ArchivePath from
the Class and check if it exists already before adding. The ArchivePath change depending
on Archive Type of course. (Another option is of course a try catch)
* Packaging JUnit is a bit odd. JUnit include parts of hamcrest, but if you add the full
hamcrest lib to classpath as well, you now get some of the hamcrest classes twice. A
Filter alla this is a possible workaround for multi includes
{code}
new Filter<ArchivePath>() {
@Override
public boolean include(ArchivePath path) {
return !archive.contains(path);
}
}
{code}
* The AS7 JMX Packager.. It merges all AuxiliaryArchives into a new archive, but reads the
RemoteLoableExtension SPI content in the loop, but fail the merge due to multiple
RemoteLoadableExtension SPI files.
was (Author: aslak):
the new IllegalOverwriteException is causing some issues for Arquillian.
* The user adds a Package to the Deployment, Arquillian then fail to add the TestClass
because it already exist in the user added Package. There is no
ClassContainer.contains(Class), so Arquillian has to construct a possible ArchivePath from
the Class and check if it exists already before adding. The ArchivePath change depending
on Archive Type of course. (Another option is of course a try catch)
* Packaging JUnit is a bit odd. JUnit include parts of hamcrest, but if you add the full
hamcrest lib to classpath as well, you now get some of the hamcrest classes twice. A
Filter alla this is a possible workaround for multi includes
{code}
new Filter<ArchivePath>() {
@Override
public boolean include(ArchivePath path) {
return !archive.contains(path);
}
}
{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
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:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:23 p.m.
[
https://issues.jboss.org/browse/SHRINKWRAP-389?page=com.atlassian.jira.pl...
]
Michal Matloka reassigned SHRINKWRAP-389:
-----------------------------------------
Assignee: Michal Matloka
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
5:21 p.m.
[
https://issues.jboss.org/browse/SHRINKWRAP-389?page=com.atlassian.jira.pl...
]
Michal Matloka commented on SHRINKWRAP-389:
-------------------------------------------
"effectively a boolean flag for each of the archive "add" methods to allow
overwriting."
did you mean every possible addAsResource, addAsLibrary, addAsWebResource ~ double number
of methods in api?
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
6:36 a.m.
[
https://issues.jboss.org/browse/SHRINKWRAP-389?page=com.atlassian.jira.pl...
]
Andrew Rubinger commented on SHRINKWRAP-389:
--------------------------------------------
Yes, we probably would need to near-double the number of methods in the API. And on
further reflection, a flag would probably not be a good move given the existing parameter
order and varargs. So a better approach would be:
addAsResource(whatever) // We have this
addAsResourceWithOverwrite(whatever) // Make this. Or another naming approach?
"overwriteAsResource"?
Open to ideas.
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
6:42 a.m.
[
https://issues.jboss.org/browse/SHRINKWRAP-389?page=com.atlassian.jira.pl...
]
Aslak Knutsen commented on SHRINKWRAP-389:
------------------------------------------
How about getting the Archive instance in a overwrite enabled state.
e.g:
{code}
WebArchive war = ShrinkWrap.create(WebArchive.class):
war.add("x")
war.add("x") // throws Exception
war = war.enableOverwrite();
war.add("X")
war.add("X") // overwrites previous with no warning / exception
{code}
That would allow 'updated' code to hand of Overwrite enabled Archives to legacy
code that don't check for it. For instance Arquillian 1.x can hand of a overwrite
enabled archive to old container versions.
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
6:56 a.m.
[
https://issues.jboss.org/browse/SHRINKWRAP-389?page=com.atlassian.jira.pl...
]
Tommy Tynjä commented on SHRINKWRAP-389:
----------------------------------------
I like Aslak's suggestion above. As an API user I think that would be more feasible
than having additional addAsResourceWithOverwrite duplicates all over the API. A naming
suggestion for the latter option: addOverwritingResource(whatever)
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
7:32 a.m.
[
https://issues.jboss.org/browse/SHRINKWRAP-389?page=com.atlassian.jira.pl...
]
Andrew Rubinger commented on SHRINKWRAP-389:
--------------------------------------------
Each Archive has an associated Configuration; we *could* put the switch to enable
overwriting in there. For one-offs it's a heavy solution. For the
backwards-compatibility Aslak notes or for mass operations where overwriting is desired N
times, it's a great fit.
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
7:46 a.m.
[
https://issues.jboss.org/browse/SHRINKWRAP-389?page=com.atlassian.jira.pl...
]
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
9:21 a.m.
[
https://issues.jboss.org/browse/SHRINKWRAP-389?page=com.atlassian.jira.pl...
]
Aslak Knutsen commented on SHRINKWRAP-389:
------------------------------------------
[~kenfinni] In the 1.0 series it does nothing. In 1.1 it throws an
IllegalOverwriteException
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
9:25 a.m.
[
https://issues.jboss.org/browse/SHRINKWRAP-389?page=com.atlassian.jira.pl...
]
Andrew Rubinger commented on SHRINKWRAP-389:
--------------------------------------------
I'll also ask for potentially two solutions:
1) Given a clean slate, how would you implement ShrinkWrap to handle overwrites? Allow?
Separate method? Config? Hybird of both? This should be the basis for a possible SW 2.0
when we go to spec.
2) What would you do that *is* backwards-compatible in terms of API?
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
12:33 p.m.
[
https://issues.jboss.org/browse/SHRINKWRAP-389?page=com.atlassian.jira.pl...
]
Andrew Rubinger updated SHRINKWRAP-389:
---------------------------------------
Fix Version/s: 1.1.1
Priority: Blocker (was: Major)
Blocker for 1.1.1.
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
Priority: Blocker
Labels: starter
Fix For: 1.1.1
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
12:45 p.m.
[
https://issues.jboss.org/browse/SHRINKWRAP-389?page=com.atlassian.jira.pl...
]
Michal Matloka commented on SHRINKWRAP-389:
-------------------------------------------
Finally which approach we would like to have implemented? Aslak Knutsen proposition?
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
Priority: Blocker
Labels: starter
Fix For: 1.1.1
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
12:57 p.m.
[
https://issues.jboss.org/browse/SHRINKWRAP-389?page=com.atlassian.jira.pl...
]
Andrew Rubinger commented on SHRINKWRAP-389:
--------------------------------------------
We never published the use of IllegalOverwriteException in the API after they were
introduced in SHRINKWRAP-329. Overwrites can actually be supported without breaking the
API. I think we'll just keep IllegalOverwriteException for attempting to overwrite a
dir with a file.
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
Priority: Blocker
Labels: starter
Fix For: 1.1.1
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
1:34 p.m.
[
https://issues.jboss.org/browse/SHRINKWRAP-389?page=com.atlassian.jira.pl...
]
Andrew Rubinger reassigned SHRINKWRAP-389:
------------------------------------------
Assignee: Andrew Rubinger (was: Michal Matloka)
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: Andrew Rubinger
Priority: Blocker
Labels: starter
Fix For: 1.1.1
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
1:36 p.m.
[
https://issues.jboss.org/browse/SHRINKWRAP-389?page=com.atlassian.jira.pl...
]
Andrew Rubinger resolved SHRINKWRAP-389.
----------------------------------------
Labels: (was: starter)
Resolution: Done
Upstream:
https://github.com/shrinkwrap/shrinkwrap/commit/25f645d17ecb94fc021bcbdfb...
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: Andrew Rubinger
Priority: Blocker
Fix For: 1.1.1
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
1:44 p.m.
[
https://issues.jboss.org/browse/SHRINKWRAP-389?page=com.atlassian.jira.pl...
]
Andrew Rubinger updated SHRINKWRAP-389:
---------------------------------------
Comment: was deleted
(was: Upstream:
https://github.com/shrinkwrap/shrinkwrap/commit/25f645d17ecb94fc021bcbdfb...)
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: Andrew Rubinger
Priority: Blocker
Fix For: 1.1.1
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
1:44 p.m.
[
https://issues.jboss.org/browse/SHRINKWRAP-389?page=com.atlassian.jira.pl...
]
Andrew Rubinger commented on SHRINKWRAP-389:
--------------------------------------------
Upstream:
https://github.com/shrinkwrap/shrinkwrap/commit/4fd0419f494341357580f1ea5...
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: Andrew Rubinger
Priority: Blocker
Fix For: 1.1.1
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
4909
days inactive
5152
days old
shrinkwrap-issues@lists.jboss.org
21 comments
5 participants
participants (5)
-
Andrew Rubinger (JIRA) -
Aslak Knutsen (JIRA)
-
Ken Finnigan (JIRA)
-
Michal Matloka (JIRA)
-
Tommy Tynjä (JIRA)