[ https://issues.jboss.org/browse/SHRINKWRAP-360?page=com.atlassian.jira.pl... ] Andrew Rubinger updated SHRINKWRAP-360: --------------------------------------- Description: 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. was: 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 two places: one as a standard dependency, and once as "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. -- 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

[ https://issues.jboss.org/browse/SHRINKWRAP-360?page=com.atlassian.jira.pl... ] Dan Allen edited comment on SHRINKWRAP-360 at 11/15/11 6:25 AM: ---------------------------------------------------------------- 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 logical group, 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 was (Author: dan.j.allen): 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 -- 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

[ https://issues.jboss.org/browse/SHRINKWRAP-360?page=com.atlassian.jira.pl... ] Andrew Rubinger updated SHRINKWRAP-360: --------------------------------------- Status: Resolved (was: Pull Request Sent) Assignee: Andrew Rubinger Resolution: Done Upstream: https://github.com/shrinkwrap/shrinkwrap/commit/91961ecf90e82cf569240b55b... -- 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