[jira] Commented: (MNG-2205) "provided" scope dependencies must be transitive

["Maarten Billemont (JIRA)" <ji...@codehaus.org>]

    [ http://jira.codehaus.org/browse/MNG-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=144387#action_144387 ] 

Maarten Billemont commented on MNG-2205:
----------------------------------------

What I'd like to do is create a POM-type artifact which is basically just a grouping of dependencies used by other artifacts.

    <dependencies>
        <!-- jboss/server/default/lib -->
        <dependency>
            <groupId>commons-codec</groupId>
            <artifactId>commons-codec</artifactId>
            <version>1.3</version>
            <scope>provided</scope>
        </dependency>
        ....

Then I would add this artifact as a provided dependency to all artifacts.
The desired result would be an inclusion of all dependencies from this container artifact in my other artifacts, marked as provided.

You may wonder why I'm not just marking them as compile-scoped in the container artifact; here's why:
I have an artifact that creates a ZIP file containing the JBoss AS.  This artifact basically just downloads JBoss, extracts it, messes around with its configuration, and packages it as a ZIP file.  Additionally, all artifacts from the container artifact above that are *not* marked as *provided* (because they are not already provided by JBoss) are *added* to the jboss/server/default/lib/ directory just before zipping it up.  That means I can specify two types of provided dependencies in the container POM above:
 - Dependencies provided by the JBoss AS default configuration (<scope>provided</scope> in the container POM).
 - Dependencies that I add to my JBoss' server/default/lib directory (<scope>compile</scope> in the container POM).

Every artifact that depends on the container POM and sets that dependency to a <scope>provided</scope> should have all dependencies in the container pom, be they provided or compile, added to the artifact as provided.  This is exactly as described by the documentation here:
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope
With one single exception:  I cannot yet mark provided dependencies in the container POM as transitive.

The table on the link above says "provided" in the intersection of "provided" on the left side and "provided" on the top.  Reading the text above the table you will see this implies that:
If a dependency is set to [provided], transitive dependencies of that dependency with the scope [provided] will result in a dependency in the main project with the scope [provided]. If no scope is listed, it means the dependency will be omitted.

I would've thought that the author would've just put a "-" at the intersection of provided with provided seeing as there currently is no such thing as transitive provided dependencies.  Or is there?

> "provided" scope dependencies must be transitive
> ------------------------------------------------
>
>                 Key: MNG-2205
>                 URL: http://jira.codehaus.org/browse/MNG-2205
>             Project: Maven 2
>          Issue Type: Bug
>          Components: Dependencies
>            Reporter: David Boden
>            Priority: Critical
>             Fix For: 2.1
>
>
> 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.
> C
> | - compile dependency
> B
> | - compile dependency
> A
> | - provided dependency
> Sybase JConnect
> 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 contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira