[
https://jira.codehaus.org/browse/MNG-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=335883#comment-335883
]
Tibor Digana edited comment on MNG-2205 at 11/17/13 9:11 AM:
-------------------------------------------------------------
I do not know if the bug is definitely in Maven core or maven-war-plugin 2.2 or
2.4.
The efective-pom correctly resolves the modules DAO(jar) and Services(jar).
For sure I will rollback to Maven 2.2.1 because there the profiles in DAO-BOM
and Services-BOM work as expected.
{code
reactor's parent(pom)
^
+---------------------+
| ^
| |
DAO(jar) -> DAO-BOM(pom)
^ ^
| |
Services(jar) -> Services-BOM(pom)
^
|
webapp(war)}
The development profile has dependencies in DAO(jar):
<groupId>org.hibernate</groupId>
<artifactId>hibernate-core</artifactId>
<version>4.2.6.Final</version>
Th production profile has dependencies in DAO(jar):
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-core</artifactId>
<version>4.2.6.Final</version>
<exclusions>
<exclusion>
<groupId>org.jboss.spec.javax.transaction</groupId>
<artifactId>jboss-transaction-api_1.1_spec</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.jboss.spec.javax.transaction</groupId>
<artifactId>jboss-transaction-api_1.1_spec</artifactId>
<version>1.0.1.Final</version>
<scope>provided</scope>
</dependency>
was (Author: tibor17):
I do not know if the bug is definitely in Maven core or maven-war-plugin
2.2 or 2.4.
The efective-pom correctly resolves the modules DAO(jar) and Services(jar).
For sure I will rollback to Maven 2.2.1 because there the profiles in DAO-BOM
and Services-BOM work as expected.
reactor's parent(pom)
^
+---------------------+
| ^
| |
DAO(jar) -> DAO-BOM(pom)
^ ^
| |
Services(jar) -> Services-BOM(pom)
^
|
webapp(war)
The development profile has dependencies in DAO(jar):
<groupId>org.hibernate</groupId>
<artifactId>hibernate-core</artifactId>
<version>4.2.6.Final</version>
Th production profile has dependencies in DAO(jar):
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-core</artifactId>
<version>4.2.6.Final</version>
<exclusions>
<exclusion>
<groupId>org.jboss.spec.javax.transaction</groupId>
<artifactId>jboss-transaction-api_1.1_spec</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.jboss.spec.javax.transaction</groupId>
<artifactId>jboss-transaction-api_1.1_spec</artifactId>
<version>1.0.1.Final</version>
<scope>provided</scope>
</dependency>
> "provided" scope dependencies must be transitive
> ------------------------------------------------
>
> Key: MNG-2205
> URL: https://jira.codehaus.org/browse/MNG-2205
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies
> Reporter: David Boden
> Priority: Critical
> Fix For: 3.x / Backlog
>
> Attachments: transitivetest.zip
>
>
> A provided scope dependency can also be thought of as "compile-only".
> Project A requires Sybase JConnect on the runtime classpath. Project A
> declares a "provided" dependency on Sybase JConnect.
> Project B depends upon Project A. Project B declares a "compile" dependency
> on Project A.
> Project C depends upon Project B. Project C declares a "compile" dependency
> on Project B.
> {noformat}
> C
> | - compile dependency
> B
> | - compile dependency
> A
> | - provided dependency
> Sybase JConnect
> {noformat}
> So, does Project C transitively depend on Sybase JConnect. Yes, of course!
> The "provided" dependency needs to be transitive.
> Ultimately, when Project C gets deployed, Sybase JConnect needs to be
> somewhere on the runtime classpath in order for the application to function.
> It's valid for Project C to assume that Sybase JConnect is available and use
> JDBC all over the Project C code. Project C is safe to do this because it can
> happily deduce that Sybase JConnect will be there in the runtime environment
> because Project A NEEDS IT.
> I've got Use Cases all over my aggregated build which make it absolutely
> critical and common sense that provided scope dependencies are transitive.
> For the (very rare) odd case where you don't want to inherit provided
> dependencies, you can <exclude/> them.
--
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
