[
http://jira.codehaus.org/browse/MNG-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162058#action_162058
]
Timothy Twelves commented on MNG-2205:
--------------------------------------
Hi,
In the context of a "war" a dependency that is "provided" can mean 1 of two
things:
1. It is provided within the application ear
OR
2. It is provided by the environment.
The solution for (1) is easy because we could have "provided" being transitive
and have the ear-plugin package the "provided" dependencies.
The solution for (2) is tricky because (as in the servlets example) we need it
for compilation and we do NOT want it packaged by the ear-plugin since it is
provided by the appserver or jvm path. I considered "runtime" but this would
make it unavailable during compilation and with the servlet -api example we
need those dependencies during compilation. "optional" for (2) works fine
however the reasons why it works are not obvious to the layman.
The solution is to introduce a new state called "environmental" and duplicate
functionality around "optional".
Make a "provided" transitive and have all class-packaging plugins
(maven-ear-plugin, maven-war-plugin) support the correct packaging of
"provided" dependencies.
>From my understanding of the maven code base (i've been digging) this is
>relatively do-able and the semantic changes are not going to be too bad
>considering the way people work around the problem of creating wars. I have
>only one problem which is the need to rewrite the manifest within jar/war/etc
>to support bundled libraries with different jar locations and signed jar/wars
>but again i believe this can be managed in the context of how people work
>around skinny jars at the moment.
-Tim
> "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: 3.x
>
>
> 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
