[JBoss JIRA] (SHRINKRES-112) MavenImporter ignores AcceptScopesStrategy for dependency inclusion
by Karel Piwko (JIRA)
[ https://issues.jboss.org/browse/SHRINKRES-112?page=com.atlassian.jira.plu... ]
Karel Piwko edited comment on SHRINKRES-112 at 4/30/13 4:56 AM:
----------------------------------------------------------------
I pushed a few tests for Scopes in https://github.com/shrinkwrap/resolver/commit/4fbb087627fbd04e8fb078cf164....
When I tried to identify the problem, I realized that we use AcceptScopesStrategy for two different purposes:
*Handling transitive dependencies*::
Suppose you want to resolve test scoped dependencies of org.jboss.artifact:foobar:1. Then you do the following
{code}
Maven.resolver().resolve("org.jboss.artifact:foobar:1").using(new AcceptScopesStrategy(ScopeType.TEST)).asFiles()
{code}
This call will simply get a dependency, constructs it's tree and get only test scope.
This is default behavior for AcceptScopesStrategy - no preFiltering is done
Note, that it seems to me that it works only for the first level of dependency tree, might be a bug
*Handling scopes defined in pom*::
Suppose that you have a project and you want to resolve all scopes it defines as <scope>test</scope>
{code}
Maven.resolver().loadPomFromFile("pom.xml").importRuntimeAndTestDependencies(new AcceptScopesStrategy(ScopeType.TEST)).asFiles()
{code}
This call has completely different behavior! The purpose would be to get whole <dependencies> section and select only those that are defined as <scope>test</scope>.
So this is prefiltering. Then you obviously expect Maven to grab compile and runtime dependencie of the test dependencies and resolve those.
You don't really want to get all test scoped dependencies in the tree, as it happens now due to resolution filtering.
[~alrubinger], I was thinking of making the strategy context dependent, but it does not seem to solve the problem without bringing confusion, e.g. for PomLess calls it would filter graph, with PomIncluded calls it will filter <dependencies> defined so far.
The confusion will come from following calls:
{code}
// prefiltering will remove defined-in-pom:defined-in-pom as resolver call will put it into compile scope(no scope defined)
// will fail with no dependencies to be resolved
Maven.resolver().loadPomFromFile("pom.xml").resolve("defined-in-pom:defined-in-pom").using(new AcceptScopesStrategy(ScopeType.TEST)).asFiles();
// will grab test scoped dependencies if no pom, because no prefiltering will be applied
Maven.resolver().resolve("defined-in-pom:defined-in-pom:version-not-in-pom").using(new AcceptScopesStrategy(ScopeType.TEST)).asFiles();
{code}
Any other idea?
was (Author: kpiwko):
I pushed a few tests for Scopes in https://github.com/shrinkwrap/resolver/commit/4fbb087627fbd04e8fb078cf164....
When I tried to identify the problem, I realized that we use AcceptScopesStrategy for two different purposes:
*Handling transitive dependencies*::
Suppose you want to resolve test scoped dependencies of org.jboss.artifact:foobar:1. Then you do the following
{code}
Maven.resolver().resolve("org.jboss.artifact:foobar:1").using(new AcceptScopesStrategy(ScopeType.TEST)).asFiles()
{code}
This call will simply get a dependency, constructs it's tree and get only test scope.
This is default behavior for AcceptScopesStrategy - no preFiltering is done
Note, that it seems to me that it works only for the first level of dependency tree, might be a
*Handling scopes defined in pom*::
Suppose that you have a project and you want to resolve all scopes it defines as <scope>test</scope>
{code}
Maven.resolver().loadPomFromFile("pom.xml").importRuntimeAndTestDependencies(new AcceptScopesStrategy(ScopeType.TEST)).asFiles()
{code}
This call has completely different behavior! The purpose would be to get whole <dependencies> section and select only those that are defined as <scope>test</scope>.
So this is prefiltering. Then you obviously expect Maven to grab compile and runtime dependencie of the test dependencies and resolve those.
You don't really want to get all test scoped dependencies in the tree, as it happens now due to resolution filtering.
[~alrubinger], I was thinking of making the strategy context dependent, but it does not seem to solve the problem without bringing confusion, e.g. for PomLess calls it would filter graph, with PomIncluded calls it will filter <dependencies> defined so far.
The confusion will come from following calls:
{code}
// prefiltering will remove defined-in-pom:defined-in-pom as resolver call will put it into compile scope(no scope defined)
// will fail with no dependencies to be resolved
Maven.resolver().loadPomFromFile("pom.xml").resolve("defined-in-pom:defined-in-pom").using(new AcceptScopesStrategy(ScopeType.TEST)).asFiles();
// will grab test scoped dependencies if no pom, because no prefiltering will be applied
Maven.resolver().resolve("defined-in-pom:defined-in-pom:version-not-in-pom").using(new AcceptScopesStrategy(ScopeType.TEST)).asFiles();
{code}
Any other idea?
> MavenImporter ignores AcceptScopesStrategy for dependency inclusion
> -------------------------------------------------------------------
>
> Key: SHRINKRES-112
> URL: https://issues.jboss.org/browse/SHRINKRES-112
> Project: ShrinkWrap Resolvers
> Issue Type: Feature Request
> Components: impl-maven
> Affects Versions: 2.0.0-beta-2
> Reporter: Karel Piwko
> Priority: Blocker
>
> AcceptScopesStrategy is not correctly propagated:
> {code}
> @Deployment(testable = false)
> public static WebArchive createDeployment()
> {
> return ShrinkWrap.create(MavenImporter.class)
> .loadPomFromFile("pom.xml")
> .importBuildOutput(new AcceptScopesStrategy(ScopeType.COMPILE, ScopeType.RUNTIME))
> .as(WebArchive.class);
> }
> {code}
--
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
11 years
[JBoss JIRA] (SHRINKWRAP-455) ConcurrentModificationException during delete on imported archive
by Andrew Rubinger (JIRA)
[ https://issues.jboss.org/browse/SHRINKWRAP-455?page=com.atlassian.jira.pl... ]
Andrew Rubinger updated SHRINKWRAP-455:
---------------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 1.1.3
Resolution: Done
Upstream: https://github.com/shrinkwrap/shrinkwrap/commit/9883f240f5fe936d53b861e01...
> ConcurrentModificationException during delete on imported archive
> -----------------------------------------------------------------
>
> Key: SHRINKWRAP-455
> URL: https://issues.jboss.org/browse/SHRINKWRAP-455
> Project: ShrinkWrap
> Issue Type: Bug
> Reporter: Michal Matloka
> Assignee: Michal Matloka
> Fix For: 1.1.3
>
>
> Description from: https://community.jboss.org/message/808603#808603
> {noformat}
> I'm trying to use Shrinkwrap to delete a folder in a JavaArchive (jar). My jar is quite simple, it contains only one folder named resources and this folder contains two files :
>
> myJavaArchive.jar:
> /resources/
> /resources/bar.txt
> /resources/foo.txt
>
> So I create a JavaArchive from my JAR file and I call delete method on "/resources" folder (see below) but it causes a ConcurrentModifictionException.
>
> My code :
>
> package com.test;
>
> import java.io.File;
>
> import org.jboss.shrinkwrap.api.ShrinkWrap;
> import org.jboss.shrinkwrap.api.spec.JavaArchive;
>
> public class Main {
> public static void main(String[] args) {
> JavaArchive archive = ShrinkWrap.createFromZipFile(JavaArchive.class,
> new File(Main.class.getResource("/myJavaArchive.jar").getFile()));
> System.out.println(archive.toString(true));
> archive.delete("/resources");
> }
> }
>
>
> The stack trace :
>
> Exception in thread "main" java.util.ConcurrentModificationException
> at java.util.HashMap$HashIterator.nextEntry(HashMap.java:793)
> at java.util.HashMap$KeyIterator.next(HashMap.java:828)
> at java.util.Collections$UnmodifiableCollection$1.next(Collections.java:1010)
> at org.jboss.shrinkwrap.impl.base.MemoryMapArchiveBase.removeNodeRecursively(MemoryMapArchiveBase.java:309)
> at org.jboss.shrinkwrap.impl.base.MemoryMapArchiveBase.delete(MemoryMapArchiveBase.java:291)
> at org.jboss.shrinkwrap.impl.base.MemoryMapArchiveBase.delete(MemoryMapArchiveBase.java:325)
> at org.jboss.shrinkwrap.impl.base.container.ContainerBase.delete(ContainerBase.java:393)
> at com.test.Main.main(Main.java:13)
>
> {noformat}
> I was able to reproduce this issue.
--
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
11 years
[JBoss JIRA] (SHRINKWRAP-453) Paths in webarchives are not calculated correctly
by Stefan Hösel (JIRA)
[ https://issues.jboss.org/browse/SHRINKWRAP-453?page=com.atlassian.jira.pl... ]
Stefan Hösel commented on SHRINKWRAP-453:
-----------------------------------------
Sorry, it took a while, but here it is, Commit:
https://github.com/shoesel/shrinkwrap/commit/368f80f4f4da5209f4c34c16250e...
The second added test case works fine (just to verify and maybe clarify the problem).
Maybe your could just truncate the childpath by the length of the rootpath..
Hope that helps.
> Paths in webarchives are not calculated correctly
> -------------------------------------------------
>
> Key: SHRINKWRAP-453
> URL: https://issues.jboss.org/browse/SHRINKWRAP-453
> Project: ShrinkWrap
> Issue Type: Bug
> Components: api
> Affects Versions: 1.1.2
> Environment: Win7x64, JDK1.7.0_17x32, JBOSS 7.1.3.Final, Arquillian 1.0.3Final, JUnit 4.11
> Reporter: Stefan Hösel
>
> When creating a WebArchive via ShrinkWrap from a directory that is an exploded war file, paths inside this archive (generated with "arquillian.xml/arquillian/engine/property[deploymentExportPath]->target/deployments") generated invalid in some cases.
> When investigating the sources I found "org.jboss.shrinkwrap.impl.base.importer.ExplodedImporterImpl.calculatePath(File root, File child)" uses "String.replaceFirst" to replace the occurance of rootPath in childPath to create a local war file path. My path of the directory that needs compression contains *brackets*, which (as well as other path elements, e.g. ".") are interpreted as regular expression tokens and therefore don't match.
> The resulting archive can not be delpoyed in AS and tests can not be performed automatically.
> The code to create the WebArchive looks like this:
> {{ShrinkWrap._create_(WebArchive.{color:gray}*class*{color}, resultingWarFileNameAsString)}}
> {{.as(ExplodedImporter.{color:gray}*class*{color}).importDirectory(absolutePathToExplodedWarDirectoryAsFile)}}
> {{.as(WebArchive.{color:gray}*class*{color});}}
--
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
11 years
[JBoss JIRA] (SHRINKWRAP-455) ConcurrentModificationException during delete on imported archive
by Michal Matloka (JIRA)
[ https://issues.jboss.org/browse/SHRINKWRAP-455?page=com.atlassian.jira.pl... ]
Michal Matloka updated SHRINKWRAP-455:
--------------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/shrinkwrap/shrinkwrap/pull/74
> ConcurrentModificationException during delete on imported archive
> -----------------------------------------------------------------
>
> Key: SHRINKWRAP-455
> URL: https://issues.jboss.org/browse/SHRINKWRAP-455
> Project: ShrinkWrap
> Issue Type: Bug
> Reporter: Michal Matloka
> Assignee: Michal Matloka
>
> Description from: https://community.jboss.org/message/808603#808603
> {noformat}
> I'm trying to use Shrinkwrap to delete a folder in a JavaArchive (jar). My jar is quite simple, it contains only one folder named resources and this folder contains two files :
>
> myJavaArchive.jar:
> /resources/
> /resources/bar.txt
> /resources/foo.txt
>
> So I create a JavaArchive from my JAR file and I call delete method on "/resources" folder (see below) but it causes a ConcurrentModifictionException.
>
> My code :
>
> package com.test;
>
> import java.io.File;
>
> import org.jboss.shrinkwrap.api.ShrinkWrap;
> import org.jboss.shrinkwrap.api.spec.JavaArchive;
>
> public class Main {
> public static void main(String[] args) {
> JavaArchive archive = ShrinkWrap.createFromZipFile(JavaArchive.class,
> new File(Main.class.getResource("/myJavaArchive.jar").getFile()));
> System.out.println(archive.toString(true));
> archive.delete("/resources");
> }
> }
>
>
> The stack trace :
>
> Exception in thread "main" java.util.ConcurrentModificationException
> at java.util.HashMap$HashIterator.nextEntry(HashMap.java:793)
> at java.util.HashMap$KeyIterator.next(HashMap.java:828)
> at java.util.Collections$UnmodifiableCollection$1.next(Collections.java:1010)
> at org.jboss.shrinkwrap.impl.base.MemoryMapArchiveBase.removeNodeRecursively(MemoryMapArchiveBase.java:309)
> at org.jboss.shrinkwrap.impl.base.MemoryMapArchiveBase.delete(MemoryMapArchiveBase.java:291)
> at org.jboss.shrinkwrap.impl.base.MemoryMapArchiveBase.delete(MemoryMapArchiveBase.java:325)
> at org.jboss.shrinkwrap.impl.base.container.ContainerBase.delete(ContainerBase.java:393)
> at com.test.Main.main(Main.java:13)
>
> {noformat}
> I was able to reproduce this issue.
--
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
11 years
[JBoss JIRA] (SHRINKWRAP-455) ConcurrentModificationException during delete on imported archive
by Michal Matloka (JIRA)
Michal Matloka created SHRINKWRAP-455:
-----------------------------------------
Summary: ConcurrentModificationException during delete on imported archive
Key: SHRINKWRAP-455
URL: https://issues.jboss.org/browse/SHRINKWRAP-455
Project: ShrinkWrap
Issue Type: Bug
Reporter: Michal Matloka
Assignee: Michal Matloka
Description from: https://community.jboss.org/message/808603#808603
{noformat}
I'm trying to use Shrinkwrap to delete a folder in a JavaArchive (jar). My jar is quite simple, it contains only one folder named resources and this folder contains two files :
myJavaArchive.jar:
/resources/
/resources/bar.txt
/resources/foo.txt
So I create a JavaArchive from my JAR file and I call delete method on "/resources" folder (see below) but it causes a ConcurrentModifictionException.
My code :
package com.test;
import java.io.File;
import org.jboss.shrinkwrap.api.ShrinkWrap;
import org.jboss.shrinkwrap.api.spec.JavaArchive;
public class Main {
public static void main(String[] args) {
JavaArchive archive = ShrinkWrap.createFromZipFile(JavaArchive.class,
new File(Main.class.getResource("/myJavaArchive.jar").getFile()));
System.out.println(archive.toString(true));
archive.delete("/resources");
}
}
The stack trace :
Exception in thread "main" java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(HashMap.java:793)
at java.util.HashMap$KeyIterator.next(HashMap.java:828)
at java.util.Collections$UnmodifiableCollection$1.next(Collections.java:1010)
at org.jboss.shrinkwrap.impl.base.MemoryMapArchiveBase.removeNodeRecursively(MemoryMapArchiveBase.java:309)
at org.jboss.shrinkwrap.impl.base.MemoryMapArchiveBase.delete(MemoryMapArchiveBase.java:291)
at org.jboss.shrinkwrap.impl.base.MemoryMapArchiveBase.delete(MemoryMapArchiveBase.java:325)
at org.jboss.shrinkwrap.impl.base.container.ContainerBase.delete(ContainerBase.java:393)
at com.test.Main.main(Main.java:13)
{noformat}
I was able to reproduce this issue.
--
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
11 years
[JBoss JIRA] (SHRINKWRAP-453) Paths in webarchives are not calculated correctly
by Tommy Tynjä (JIRA)
[ https://issues.jboss.org/browse/SHRINKWRAP-453?page=com.atlassian.jira.pl... ]
Tommy Tynjä commented on SHRINKWRAP-453:
----------------------------------------
First of all, please notice that the greater than character is not supported in paths on all platforms. The problem in ExplodedImporterImpl in the calculatePath(File, File) method is that the replaceFirst method takes a regular expression as its first parameter. If the root path contains regular expression characters, the replaceFirst method call will most likely not behave as intended, in this case when brackets are present in the path. This could even cause a java.util.regex.PatternSyntaxException if e.g. only an opening bracket is present in the path, with no matching closing bracket for the regular expression evaluation.
I've created a reproducing failing test case as well as a test case causing a java.util.regex.PatternSyntaxException. The failing tests are accompanied by a test case which shows the intended behaviour. Commit: https://github.com/tommysdk/shrinkwrap/commit/e09da7845156d93ded6fab14091...
One solution would be to escape all regular expression characters so that the path never would be evaluated as an regular expression. Another solution is to not support such paths, clearly document this behaviour and throw an appropriate exception for such paths, such as an IllegalArgumentException.
> Paths in webarchives are not calculated correctly
> -------------------------------------------------
>
> Key: SHRINKWRAP-453
> URL: https://issues.jboss.org/browse/SHRINKWRAP-453
> Project: ShrinkWrap
> Issue Type: Bug
> Components: api
> Affects Versions: 1.1.2
> Environment: Win7x64, JDK1.7.0_17x32, JBOSS 7.1.3.Final, Arquillian 1.0.3Final, JUnit 4.11
> Reporter: Stefan Hösel
>
> When creating a WebArchive via ShrinkWrap from a directory that is an exploded war file, paths inside this archive (generated with "arquillian.xml/arquillian/engine/property[deploymentExportPath]->target/deployments") generated invalid in some cases.
> When investigating the sources I found "org.jboss.shrinkwrap.impl.base.importer.ExplodedImporterImpl.calculatePath(File root, File child)" uses "String.replaceFirst" to replace the occurance of rootPath in childPath to create a local war file path. My path of the directory that needs compression contains *brackets*, which (as well as other path elements, e.g. ".") are interpreted as regular expression tokens and therefore don't match.
> The resulting archive can not be delpoyed in AS and tests can not be performed automatically.
> The code to create the WebArchive looks like this:
> {{ShrinkWrap._create_(WebArchive.{color:gray}*class*{color}, resultingWarFileNameAsString)}}
> {{.as(ExplodedImporter.{color:gray}*class*{color}).importDirectory(absolutePathToExplodedWarDirectoryAsFile)}}
> {{.as(WebArchive.{color:gray}*class*{color});}}
--
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
11 years