Thanks, this is exactly what I was getting at. As this higher-level project does not reference javax.mail:mail in any way, it should not have to specify a direct dependency on it imho. Yet in the current state of things it needs to, but only in the special case that the provided scope is used by the primordial project.
While this might all sound a bit abstract, we actually run into these problems when working with OSGi bundles (which is mentioned as an affected use case in the JIRA as well). The provided scope fits pretty nicely for bundles, since we do not want to package these dependencies but need to compile against them. I guess I just don't see why it would be a good thing to not provide compile-time dependencies transitively. I thought that was one of the core ideas of Maven? Best regards, Patrick From: Laird Nelson <[email protected]> To: Maven Users List <[email protected]>, [email protected], Date: 14.03.2013 19:42 Subject: Re: Provided scope dependencies 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 -------------------------------------------------------------------------------------------------------------------------------------------- Patrick Schlebusch - KISTERS AG - Charlottenburger Allee 5 - 52068 Aachen - Germany Handelsregister Aachen, HRB-Nr. 7838 | Vorstand: Klaus Kisters, Hanns Kisters | Aufsichtsratsvorsitzender: Dr. Thomas Klevers Tel.: +49 241 9671 -466 | Fax: +49 241 9671 -555 | E-Mail: [email protected] | WWW: http://www.kisters.de -------------------------------------------------------------------------------------------------------------------------------------------- Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
