5:25 a.m.
[
https://issues.jboss.org/browse/SHRINKWRAP-360?page=com.atlassian.jira.pl...
]
Dan Allen commented on SHRINKWRAP-360:
--------------------------------------
I'll layout the scenario in more detail for clarity.
h2. Proposed artifact library set
*BOM:* (defines the versions in use for this library)
org.jboss.shrinkwrap.resolver:shrinkwrap-resolver-bom:pom
*APIs:*
org.jboss.shrinkwrap.resolver:shrinkwrap-resolver-api:jar (should be compile)
org.jboss.shrinkwrap.resolver:shrinkwrap-resolver-api-maven:jar (should be compile)
*Impls:*
org.jboss.shrinkwrap.resolver:shrinkwrap-resolver-impl-maven:jar (likely runtime)
*Library:* (declares usage of this library, brings in deps transitively)
org.jboss.shrinkwrap.resolver:shrinkwrap-resolver-maven:pom
h2. User experience
{code}
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.jboss.shrinkwrap.resolver</groupId>
<artifactId>shrinkwrap-resolver-bom</artifactId>
<version>x.y.z</version>
<type>pom</type>
<scope>import</scope>
</dependency>
<dependencies>
</dependencyManagement>
<dependencies>
<dependency>
<groupId>org.jboss.shrinkwrap.resolver</groupId>
<artifactId>shrinkwrap-resolver-maven</artifactId>
<type>pom</type>
</dependency>
</dependencies>
{code}
This will resolve:
- org.jboss.shrinkwrap.resolver:shrinkwrap-resolver-api:x.y.z:jar (compile)
- org.jboss.shrinkwrap.resolver:shrinkwrap-resolver-api-maven:x.y.z:jar (compile)
- org.jboss.shrinkwrap.resolver:shrinkwrap-resolver-impl-maven:x.y.z:jar (runtime)
- (any transitive deps of resolvers)
Now, if the user wanted to change the default scope of the impl from runtime to provided
(just assume it is defined as runtime for the example), they can change the dependency to
this: (parallel for test scope)
{code}
<dependencies>
<dependency>
<groupId>org.jboss.shrinkwrap.resolver</groupId>
<artifactId>shrinkwrap-resolver-maven</artifactId>
<type>pom</type>
<scope>provided</scope>
</dependency>
</dependencies>
{code}
(May need to override scope of api artifacts, but not sure. Either way, never have to
refer to impl artifact).
As a summary, the benefit of this library set is:
- dependency versions move together (don't get one version of api, another of impl
when using it w/ other libraries that depend on them)
- can import the library as a grouping, not worrying about how many or the names of the
artifacts
- scopes are setup correctly by the bom and the user doesn't have to worry about
getting them right, but can override
Create "Library Dependency" module
----------------------------------
Key: SHRINKWRAP-360
URL: https://issues.jboss.org/browse/SHRINKWRAP-360
Project: ShrinkWrap
Issue Type: Feature Request
Components: ext-resolver
Reporter: Andrew Rubinger
Also called a "A-BOM" in EAP, or "depchain" in AS, this POM
aggregates dependencies for a project, in the right scope, in one view:
For instance:
{code}foo-api
foo-impl
foo
dep:
foo-api (compile)
foo-impl (runtime){code}
In this case, "foo" would be the module we're looking to create. A user
then makes a dependency upon this POM in coordination with a dep on the BOM in
"import" scope in depMgt (in order to honor exclusions).
An example of this in use is:
https://github.com/ALRubinger/jboss-as-test-example/blob/master/pom.xml#L128
https://github.com/ALRubinger/jboss-as-test-example/blob/master/pom.xml#L156
In the example above we have the dep on the AS7 API in two places as required; in turn
the AS7 API POM exports out transitives as we need. In that case the AS7 API is both BOM
and Library POM.
--
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