Mediating here; no position either way. I think the disconnect is:
If my primordial project depends on javax.mail:mail in provided scope... ...and my higher-level project depends on my primordial project in compile scope... ...then at COMPILE TIME for my higher-level project I shouldn't have to ALSO specify javax.mail:mail since my higher-level project might not even know that such a thing is being used. At RUNTIME obviously javax.mail:mail shouldn't be packaged. Best, Laird On Thu, Mar 14, 2013 at 10:57 AM, Jörg Schaible <[email protected]>wrote: > Patrick Schlebusch wrote: > > > Hi everyone, > > > > we're using Maven to build OSGi bundles among other types of artifacts. > In > > this context we have run into some problems related to provided scope > > dependencies. > > > > The documentation [1] about the provided scope says: "This is much like > > compile, but indicates you expect the JDK or a container to provide the > > dependency at runtime." > > There is also the following note about transitive compile dependencies: " > > it is intended that this should be runtime scope instead, so that all > > compile dependencies must be explicitly listed - however, there is the > > case where the library you depend on extends a class from another > library, > > forcing you to have available at compile time. For this reason, compile > > time dependencies remain as compile scope even when they are transitive." > > > > In the same way, Mavens current behaviour leads to problems if an > artifact > > extends a class of a provided scope dependency. I hope this little > example > > makes this clearer: > > > > Lets assume we have the artifacts A, B and C. B depends on C with scope > > provided. B contains a class that extends a class of C. If A wants to use > > this class of B, it should only need to add a dependency for B (lets > > assume compile scope here). However, since provided scopes are not > > resolved transitively A cannot be compiled without also specifying a > > dependency on C, an artifact it shouldn't have to know about. > > > > I know this is not a new issue in any way; there is a 7 year old Jira > [2], > > which has some discussion, but seems to have no conclusion in any way and > > is not scheduled to be fixed. > > > > Are there any workarounds for this except for maybe using a patched Maven > > version? Is there any 'official' opinion on this? I would also be > > interested in the reasoning behind making the provided scope > > non-transitive. > > Provided means "provided by the runtime environment". If I use > javax.mail:mail, I add it to my dependency list as provided, when I know > that my target platform is JEE. I should not have this jar in my war files, > because the classes are provided by the JEE environment. Clear? > > - Jörg > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- http://about.me/lairdnelson
