You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Patrick Schlebusch <Pa...@kisters.de> on 2013/03/14 17:29:54 UTC
Provided scope dependencies
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.
Best regards,
Patrick
[1]
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html
[2] http://jira.codehaus.org/browse/MNG-2205
--------------------------------------------------------------------------------------------------------------------------------------------
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: Patrick.Schlebusch@kisters.de | 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.
Re: Provided scope dependencies
Posted by Patrick Schlebusch <Pa...@kisters.de>.
Jörg Schaible wrote at some time (sorry, I'm doing this manually now, as
my mail client is apparently incapable of doing this in a mailing-list
friendly way):
> in the end, you always control it yourself (that's what project parents
and
> dependencyManagement sections are for) and in combination with
properties
> you have absolute control.
Thanks for your suggestion, but the thing is that I actually need the
semantics of the "provided" scope (so managing it to "compile" doesn't
help me). Due to the nature of compile-time (not "compile" scope!)
dependencies, there are cases where "provided" are required transitively
for compilation.
I hope I'm getting through here at all, it is really hard to explain this
clearly.
The thing I just don't get is why this case of transitive dependencies for
compilation is considered in the "compile" scope, but not in the
"provided" scope. I get all the stuff about provision for runtime and I
agree 100% with that. It is just at compile-time where I believe the
current behaviour is at least inconsistent, if not wrong.
Best regards,
Patrick
--------------------------------------------------------------------------------------------------------------------------------------------
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: Patrick.Schlebusch@kisters.de | 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.
Re: Provided scope dependencies
Posted by Jörg Schaible <Jo...@scalaris.com>.
Hi Patrick,
Patrick Schlebusch wrote:
> 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?
in the end, you always control it yourself (that's what project parents and
dependencyManagement sections are for) and in combination with properties
you have absolute control.
Parent POM for a project:
============ %< =============
<groupId>our.company</groupId>
<artifactId>project-master</artifactId>
<version>1.x-SNASPHTO</version>
...
<dependencyManagement>
<dependencies>
<dependency>
<groupId>javax.mail</groupId>
<artifactId>mail</artifactId>
<version>1.4</version>
<scope>${scope.javax.mail}</scope>
<dependency>
</dependencies>
</dependencyManagement>
...
<properties>
<!-- scope defaults, even for transitive deps -->
<scope.javax.mail>compile</scope.javax.mail>
</properties>
============ %< =============
In an artifact of the project that should not include this dependency, e.g.
for an EAR or WAR:
============ %< =============
<parent>
<groupId>our.company</groupId>
<artifactId>project-master</artifactId>
<version>1.x-SNASPHTO</version>
<relativePath/> <!-- is not necessarily physical parent! -->
</parent>
...
<properties>
<scope.javax.mail>provided</scope.javax.mail>
</properties>
============ %< =============
Now, if all artifacts of a project refer the same parent (directly or
indirectly), you can overwite the scope (and version) of any dependency used
anywhere in this project with that single declaration in the depMgmt section
of the parent with own defaults that can be overwritten in the POMs of the
individual artifacts.
Cheers,
Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Provided scope dependencies
Posted by Patrick Schlebusch <Pa...@kisters.de>.
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 <lj...@gmail.com>
To:
Maven Users List <us...@maven.apache.org>, joerg.schaible@gmx.de,
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
<jo...@gmx.de>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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
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: Patrick.Schlebusch@kisters.de | 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.
Re: Provided scope dependencies
Posted by Laird Nelson <lj...@gmail.com>.
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 <jo...@gmx.de>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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
http://about.me/lairdnelson
Re: Provided scope dependencies
Posted by Stephen Connolly <st...@gmail.com>.
On Thursday, 14 March 2013, Jörg Schaible 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".
I would change this to "provided means 'provided by either the runtime
environment or a consumer of the project declaring the dependency'"
In other words the provision of the dependency is not the problem of this
projects transitive dependency tree...
You may have a downstream project that lists this project as a dependency
and also adds the provided dependencies as its own 'runtime' scope
dependencies, so it need not be the runtime environment that provides the
dependency, but the scope declares that *this* project does not care where
it comes from ;-)
> 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: users-unsubscribe@maven.apache.org <javascript:;>
> For additional commands, e-mail: users-help@maven.apache.org<javascript:;>
>
>
--
Sent from my phone
Re: Provided scope dependencies
Posted by Jörg Schaible <jo...@gmx.de>.
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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Provided scope dependencies
Posted by Patrick Schlebusch <Pa...@kisters.de>.
Thomas Broyer wrote:
> If the class from C is part of the API of B, then it's not an "internal
> detail".
But C isn't necessarily part of the API of B and might still be required.
(think inheriting protected methods for example)
I would also argue that even if it is part of the API of B this can be an
internal detail that I might want to legitimately hide: If C changes I
might want to keep the API of B stable and just adapt B to changes in C
internally. This is especially important if we're not talking about one
artifact A that depends on B, but several.
> But as I said, I don't know OSGI much, and don't know the
> maven-bundle-plugin and bundle packaging, but it looks more like an
> impedance mismatch between OSGI and Maven and/or a bad integration, and
> thus a bug in the maven-bundle-plugin rather than Maven itself.
Surely there is a bit of an impedance mismatch, but it would be much more
manageable if provided scope dependencies were transitive.
However my argument for this is not that it makes OSGi development easier,
but that any dependency required at compile-time should be transitive. The
examples I described seem to have been considered in the behaviour of the
compile scope (which is why I quoted the note from the table about
transitive dependencies [1] in my first post). To me it just seems
inconsistent and wrong to not consider those in provided scope
dependencies.
I fully understand that Maven has to keep compatibility with many, many
existing builds, but at least in my opinion this is an issue which should
be considered to be fixed in some way (be it the <transitive> property or
a new scope or anything else).
> But maybe the maven-bundle-plugin should
> just use a special scope (e.g. scope=bundle) for things that will be
> bundled, rather than scope=provided (the tomcat-maven-plugin uses a
> scope=tomcat for WARs you want to automatically deploy to the
test-server
> with tomcat7:run, so it's entirely possible to do something similar at
the
> maven-bundle-plugin)
This is an interesting idea. I think I will kick off a discussion over
there.
Best regards,
Patrick
[1]
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope
From:
Thomas Broyer <t....@gmail.com>
To:
Maven Users List <us...@maven.apache.org>,
Date:
15.03.2013 17:24
Subject:
Re: Provided scope dependencies
On Fri, Mar 15, 2013 at 11:14 AM, Patrick Schlebusch <
Patrick.Schlebusch@kisters.de> wrote:
> Thomas Broyer wrote at some time:
> > Because a class in A transitively depends on a class provided by C
then
> it
> > *has* to know about C. Class hierarchy is part of the API (which is
one
> > reason you should generally prefer composition over inheritance).
>
> The compiler needs to know about artifact C of course. But I as the
> consumer of artifact B should not need to know B's dependencies.
Actually
> I thought this was the reason for the whole automatic resolution of
> transitive dependencies. This is not for convenience, it hides internal
> details of B from A.
>
If the class from C is part of the API of B, then it's not an "internal
detail".
Otherwise that would mean I would need to first look at the POMs of all my
> dependencies and basically copy all provided scope dependencies to my
> project. Which kind of reminds me of software development without Maven.
>
I understand your concern; I'm just not sure this should be seen as a bug.
Also note that if scope=provided is redefined as being transitive at
compile-time (i.e. when resolving dependencies for the compile scope) but
not runtime (i.e. packaging time actually) –you'd probably want to also
make it transitive at test-time–, that means annotation processors would
have to live in some other scope: because I use JPA2 (e.g. Hibernate) or
JSR330 (e.g. Dagger) annotation processors in my project doesn't mean
downstream projects want to use them.
In other words, that'd be a breaking change.
Maybe adding a new <transitive>true</transitive> to <dependency> would
work… Either that or creating a new scope (but then how would you call it?
"provided" would be great, but it already means "compile-only").
Now maybe the issue is in the maven-bundle-plugin and how it integrates
with Maven when resolving dependencies through Maven rather than OSGI:
AIUI
(I don't do OSGI), scope=compile for a bundle means "bundle it in the JAR,
and possibly expose its classes/packages" which should thus not be
transitive, whereas you use scope=provided to mean "don't bundle it, it'll
be provided as an OSGI bundle at runtime" and you thus would like it to be
transitive when resolved by Maven. The problem seems to be that Maven has
the notion that a packaging type either "includesDependencies" or not,
whereas OSGI bundles can do both. But maybe the maven-bundle-plugin should
just use a special scope (e.g. scope=bundle) for things that will be
bundled, rather than scope=provided (the tomcat-maven-plugin uses a
scope=tomcat for WARs you want to automatically deploy to the test-server
with tomcat7:run, so it's entirely possible to do something similar at the
maven-bundle-plugin)
But as I said, I don't know OSGI much, and don't know the
maven-bundle-plugin and bundle packaging, but it looks more like an
impedance mismatch between OSGI and Maven and/or a bad integration, and
thus a bug in the maven-bundle-plugin rather than Maven itself.
--
Thomas Broyer
/tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/>
--------------------------------------------------------------------------------------------------------------------------------------------
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: Patrick.Schlebusch@kisters.de | 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.
Re: Provided scope dependencies
Posted by Thomas Broyer <t....@gmail.com>.
On Fri, Mar 15, 2013 at 11:14 AM, Patrick Schlebusch <
Patrick.Schlebusch@kisters.de> wrote:
> Thomas Broyer wrote at some time:
> > Because a class in A transitively depends on a class provided by C then
> it
> > *has* to know about C. Class hierarchy is part of the API (which is one
> > reason you should generally prefer composition over inheritance).
>
> The compiler needs to know about artifact C of course. But I as the
> consumer of artifact B should not need to know B's dependencies. Actually
> I thought this was the reason for the whole automatic resolution of
> transitive dependencies. This is not for convenience, it hides internal
> details of B from A.
>
If the class from C is part of the API of B, then it's not an "internal
detail".
Otherwise that would mean I would need to first look at the POMs of all my
> dependencies and basically copy all provided scope dependencies to my
> project. Which kind of reminds me of software development without Maven.
>
I understand your concern; I'm just not sure this should be seen as a bug.
Also note that if scope=provided is redefined as being transitive at
compile-time (i.e. when resolving dependencies for the compile scope) but
not runtime (i.e. packaging time actually) –you'd probably want to also
make it transitive at test-time–, that means annotation processors would
have to live in some other scope: because I use JPA2 (e.g. Hibernate) or
JSR330 (e.g. Dagger) annotation processors in my project doesn't mean
downstream projects want to use them.
In other words, that'd be a breaking change.
Maybe adding a new <transitive>true</transitive> to <dependency> would
work… Either that or creating a new scope (but then how would you call it?
"provided" would be great, but it already means "compile-only").
Now maybe the issue is in the maven-bundle-plugin and how it integrates
with Maven when resolving dependencies through Maven rather than OSGI: AIUI
(I don't do OSGI), scope=compile for a bundle means "bundle it in the JAR,
and possibly expose its classes/packages" which should thus not be
transitive, whereas you use scope=provided to mean "don't bundle it, it'll
be provided as an OSGI bundle at runtime" and you thus would like it to be
transitive when resolved by Maven. The problem seems to be that Maven has
the notion that a packaging type either "includesDependencies" or not,
whereas OSGI bundles can do both. But maybe the maven-bundle-plugin should
just use a special scope (e.g. scope=bundle) for things that will be
bundled, rather than scope=provided (the tomcat-maven-plugin uses a
scope=tomcat for WARs you want to automatically deploy to the test-server
with tomcat7:run, so it's entirely possible to do something similar at the
maven-bundle-plugin)
But as I said, I don't know OSGI much, and don't know the
maven-bundle-plugin and bundle packaging, but it looks more like an
impedance mismatch between OSGI and Maven and/or a bad integration, and
thus a bug in the maven-bundle-plugin rather than Maven itself.
--
Thomas Broyer
/tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/>
Re: Provided scope dependencies
Posted by Ron Wheeler <rw...@artifact-software.com>.
If I understand the situation
A depends on B with a provided scope
B depends on C with a provided scope.
B should clearly indicate this on the outside of the box right under the
"Consuming this over a long period will cause cancer or at least confusion"
in big red letters: "You need to provide a compatible C in order to get
the desired effect from B."
It should also tell you what sort of C you need to provide for each sort
of B you need to consume.
If B is not, or can not be, delivered as a fully functional unit (black
box) it has to tell the user.
I would make a maven artifact BC out of a working combination of B and C
and store that in my repo as "BC" and make my A's depend on BC rather
than including both B and C as provided in A. I would then provide BC
rather than B and C or I would make it compile scope and get Maven to
include BC in my build.
Ron
On 15/03/2013 6:14 AM, Patrick Schlebusch wrote:
> Thomas Broyer wrote at some time:
>> Because a class in A transitively depends on a class provided by C then
> it
>> *has* to know about C. Class hierarchy is part of the API (which is one
>> reason you should generally prefer composition over inheritance).
> The compiler needs to know about artifact C of course. But I as the
> consumer of artifact B should not need to know B's dependencies. Actually
> I thought this was the reason for the whole automatic resolution of
> transitive dependencies. This is not for convenience, it hides internal
> details of B from A.
>
> Otherwise that would mean I would need to first look at the POMs of all my
> dependencies and basically copy all provided scope dependencies to my
> project. Which kind of reminds me of software development without Maven.
>
> Best regards,
> Patrick
>
> --------------------------------------------------------------------------------------------------------------------------------------------
> 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: Patrick.Schlebusch@kisters.de | 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.
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Provided scope dependencies
Posted by Wayne Fay <wa...@gmail.com>.
> For compilation purposes, it absolutely should be the case that
> provided-scope dependencies should be placed automatically on the
> compilation classpath. There is no excuse for this to be otherwise IMHO.
...
> However, it's also not going to be fixed, it sounds like, since it can be
> explained away via a documentation hiccup (redefining "provided" scope to
> mean not provided by the runtime environment but the downstream consumer)
I don't know that I agree "it's not going to be fixed."
If a strong argument can be made that this is a bug/defect, I'd
support changing it. And I'd hope the rest of the Maven dev team could
be similarly convinced.
Wayne
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Provided scope dependencies
Posted by Laird Nelson <lj...@gmail.com>.
On Fri, Mar 15, 2013 at 3:14 AM, Patrick Schlebusch <
Patrick.Schlebusch@kisters.de> wrote:
> Otherwise that would mean I would need to first look at the POMs of all my
> dependencies and basically copy all provided scope dependencies to my
> project. Which kind of reminds me of software development without Maven.
>
Patrick, you are exactly right; don't feel like you are missing something.
For compilation purposes, it absolutely should be the case that
provided-scope dependencies should be placed automatically on the
compilation classpath. There is no excuse for this to be otherwise IMHO.
(At runtime obviously provided-scope dependencies should not be placed on
the classpath, and indeed they are not.)
However, it's also not going to be fixed, it sounds like, since it can be
explained away via a documentation hiccup (redefining "provided" scope to
mean not provided by the runtime environment but the downstream consumer)
so you should use Jorg's cute but necessarily clumsy workaround ("clumsy"
not because it's his fault but because it's the only solution).
Best,
Laird
Re: Provided scope dependencies
Posted by Patrick Schlebusch <Pa...@kisters.de>.
Thomas Broyer wrote at some time:
> Because a class in A transitively depends on a class provided by C then
it
> *has* to know about C. Class hierarchy is part of the API (which is one
> reason you should generally prefer composition over inheritance).
The compiler needs to know about artifact C of course. But I as the
consumer of artifact B should not need to know B's dependencies. Actually
I thought this was the reason for the whole automatic resolution of
transitive dependencies. This is not for convenience, it hides internal
details of B from A.
Otherwise that would mean I would need to first look at the POMs of all my
dependencies and basically copy all provided scope dependencies to my
project. Which kind of reminds me of software development without Maven.
Best regards,
Patrick
--------------------------------------------------------------------------------------------------------------------------------------------
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: Patrick.Schlebusch@kisters.de | 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.
Re: Provided scope dependencies
Posted by Thomas Broyer <t....@gmail.com>.
On Thu, Mar 14, 2013 at 5:29 PM, Patrick Schlebusch <
Patrick.Schlebusch@kisters.de> wrote:
> 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.
Because a class in A transitively depends on a class provided by C then it
*has* to know about C. Class hierarchy is part of the API (which is one
reason you should generally prefer composition over inheritance).
If B depends on C with scope=provided, then it's saying to anyone using B
"you have to provide C". A uses B (it depends on it), so it has to provide
C. There are cases where this wouldn't be necessary (if B uses C but
doesn't expose it in its API) but they should be seen as the exception
rather than the rule. Now A can decide how it provides C; if it only wants
to provide it a compile-time, then it'll have it in scope=provided too.
Because Maven resolves dependencies for you doesn't mean you shouldn't care
about what those transitive dependencies are. I see Maven as a tool that
makes it *easier* to get the dependencies right (rather than download JARs
manually), but they're still under your responsibility.
Another way to approach the problem would be to have B depends on C with
scope=compile, so A would have the dependency "for free" (transitively).
And it would be in the hand of A to decide whether C will be provided or
not. But that depends a lot on the packaging you're using. This approach
works well for packaging=jar, and you'll leave it to the "leaves" (roots?)
of your dependency tree (packaging=war for instance) to decide what is
provided and what is not. I don't know packaging=bundle much but maybe it'd
be better to use scope=compile and exclude the JAR from being bundled at
the maven-bundle-plugin level.
Note that I'm not saying Maven couldn't do better; it definitely could:
using scope=provided for annotation processors just seems wrong (there
should be a scope=compile-only), you might also want to compile against one
version and test against another, etc.
--
Thomas Broyer
/tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/>
Re: Provided scope dependencies
Posted by Patrick Schlebusch <Pa...@kisters.de>.
I think this last comment misses the point: I might have transitive
dependencies* at compile-time that are not referenced anywhere in my own
code.
And for exactly that reason I think any compile-time dependency should be
transitive.
Best regards,
Patrick
* not talking about Maven dependencies here, but dependencies in a literal
sense
From:
Wayne Fay <wa...@gmail.com>
To:
Maven Users List <us...@maven.apache.org>,
Date:
14.03.2013 18:25
Subject:
Re: Provided scope dependencies
> 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.
Personally I think David Boden's latest comment in that Jira sums
things up rather nicely:
David Boden added a comment - 08/Aug/12 9:39 AM
For what it's worth, I no longer agree with this issue that I started
6 years ago! I have a best-practice document which I apply to my
projects and have pasted here in this comment. Under this strategy, I
always declare compile-time dependencies in any project that has an
import; statement referring to the class. I don't rely on transitive
dependencies when I'm actually using a dependency for compilation. I
think this is what the Maven authors intended, which is why "provided"
has stayed like it is for such a long time.
Wayne
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
--------------------------------------------------------------------------------------------------------------------------------------------
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: Patrick.Schlebusch@kisters.de | 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.
Re: Provided scope dependencies
Posted by Wayne Fay <wa...@gmail.com>.
> 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.
Personally I think David Boden's latest comment in that Jira sums
things up rather nicely:
David Boden added a comment - 08/Aug/12 9:39 AM
For what it's worth, I no longer agree with this issue that I started
6 years ago! I have a best-practice document which I apply to my
projects and have pasted here in this comment. Under this strategy, I
always declare compile-time dependencies in any project that has an
import; statement referring to the class. I don't rely on transitive
dependencies when I'm actually using a dependency for compilation. I
think this is what the Maven authors intended, which is why "provided"
has stayed like it is for such a long time.
Wayne
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org