[JBoss JIRA] (SHRINKRES-136) System scoped dependencies shouldn't be added to WAR
by Karel Piwko (JIRA)
[ https://issues.jboss.org/browse/SHRINKRES-136?page=com.atlassian.jira.plu... ]
Karel Piwko updated SHRINKRES-136:
----------------------------------
Fix Version/s: 2.0.0-beta-4
Assignee: Karel Piwko (was: Andrew Rubinger)
> System scoped dependencies shouldn't be added to WAR
> ----------------------------------------------------
>
> Key: SHRINKRES-136
> URL: https://issues.jboss.org/browse/SHRINKRES-136
> Project: ShrinkWrap Resolvers
> Issue Type: Bug
> Components: impl-maven
> Affects Versions: 2.0.0-beta-3
> Reporter: Ron Šmeral
> Assignee: Karel Piwko
> Fix For: 2.0.0-beta-4
>
>
> When resolving dependencies with {{importRuntimeDependencies}} and adding them to an archive as in
> {code}
> File[] libs = Maven.resolver().loadPomFromFile("pom.xml").importRuntimeDependencies().asFile();
> ShrinkWrap.create(WebArchive.class, "seam-blog.war").addAsLibraries(libs);
> {code}
> system-scoped dependencies are resolved and added to the archive as well.
> This should not happen and should be aligned with the behaviour of the maven war plugin, as described in this issue: https://jira.codehaus.org/browse/MWAR-23.
--
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, 4 months
[JBoss JIRA] (SHRINKRES-136) System scoped dependencies shouldn't be added to WAR
by Ron Šmeral (JIRA)
Ron Šmeral created SHRINKRES-136:
------------------------------------
Summary: System scoped dependencies shouldn't be added to WAR
Key: SHRINKRES-136
URL: https://issues.jboss.org/browse/SHRINKRES-136
Project: ShrinkWrap Resolvers
Issue Type: Bug
Components: impl-maven
Affects Versions: 2.0.0-beta-3
Reporter: Ron Šmeral
Assignee: Andrew Rubinger
When resolving dependencies with {{importRuntimeDependencies}} and adding them to an archive as in
{code}
File[] libs = Maven.resolver().loadPomFromFile("pom.xml").importRuntimeDependencies().asFile();
ShrinkWrap.create(WebArchive.class, "seam-blog.war").addAsLibraries(libs);
{code}
system-scoped dependencies are resolved and added to the archive as well.
This should not happen and should be aligned with the behaviour of the maven war plugin, as described in this issue: https://jira.codehaus.org/browse/MWAR-23.
--
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, 4 months
[JBoss JIRA] (SHRINKRES-133) RejectDependenciesFilter and strategy should be able to work in both recursive and nonrecursive way
by Karel Piwko (JIRA)
Karel Piwko created SHRINKRES-133:
-------------------------------------
Summary: RejectDependenciesFilter and strategy should be able to work in both recursive and nonrecursive way
Key: SHRINKRES-133
URL: https://issues.jboss.org/browse/SHRINKRES-133
Project: ShrinkWrap Resolvers
Issue Type: Enhancement
Reporter: Karel Piwko
Assignee: Andrew Rubinger
It is unclear what should happen if you use RejectDependencies Filter/Strategy.
Currently, it does:
1/ Reject in preResolution -> that means dependency is removed including all possible transtives
2/ Reject in resolution -> removed during resolution, not including transitives
We need to cover both use cases especially with SHRINKRES-112 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
11 years, 4 months
[JBoss JIRA] (SHRINKRES-30) ShrinkWrap should be able to exclude its own and Arquillian's -impl archives
by Karel Piwko (JIRA)
[ https://issues.jboss.org/browse/SHRINKRES-30?page=com.atlassian.jira.plug... ]
Karel Piwko commented on SHRINKRES-30:
--------------------------------------
Maybe is it enough to exclude test scoped dependencies?
> ShrinkWrap should be able to exclude its own and Arquillian's -impl archives
> ----------------------------------------------------------------------------
>
> Key: SHRINKRES-30
> URL: https://issues.jboss.org/browse/SHRINKRES-30
> Project: ShrinkWrap Resolvers
> Issue Type: Feature Request
> Environment: Linux wallace 3.0.0-14-generic-pae #23-Ubuntu SMP Mon Nov 21 22:07:10 UTC 2011 i686 i686 i386 GNU/Linux
> java version "1.7.0"
> Java(TM) SE Runtime Environment (build 1.7.0-b147)
> Java HotSpot(TM) Server VM (build 21.0-b17, mixed mode)
> JBoss AS 7.1.1.Final
> Arquillian 1.0.0.Final
> Reporter: Craig Ringer
> Labels: arquillian, dependency, maven, resolver, shrinkwrap
>
> I'm using ShrinkWrap via Arquillian 1.0.0.Final.
> When the Maven Dependency Resolver extension is used to load dependencies from a project pom, the ShrinkWrap and Arquillian dependencies are automatically included in produced ShrinkWrap archives. There doesn't appear to be any easy way to tell ShrinkWrap to leave its own -impl archives out, so a trivial test archive bloats to 31MB or more of Arquilian and ShrinkWrap archives
> and dependencies. Some of the transitive dependencies could cause conflicts with app server libraries, too.
> What I'd like to see is a very quick and easy way to tell the Maven resolver to exclude
> anything from ShrinkWrap or Arquillian when loading dependencies from a pom.xml, eg:
> {code}
> MavenDependencyResolver resolver = DependencyResolvers.use(MavenDependencyResolver.class)
> .includeDependenciesFromPom("pom.xml");
> .excludeShrinkWrap().excludeArquillian(); // Imaginary for now
> {code}
> Currently one should be able to do something like:
> {code}
> MavenDependencyResolver resolver = DependencyResolvers.use(MavenDependencyResolver.class)
> .includeDependenciesFromPom("pom.xml")
> .exclusions("org.jboss.shrinkwrap.descriptors:shrinkwrap-descriptors-impl-javaee",
> "org.jboss.shrinkwrap.resolver:shrinkwrap-resolver-impl-maven",
> "org.jboss.arquillian.junit:arquillian-junit-container",
> "org.jboss.as:jboss-as-arquillian-container-remote");
> {code}
> ... but in my quick tests these exclusions appeared to have no effect.
--
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, 4 months