Mailing-List: contact users-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Maven Users List" <users@maven.apache.org>
Received-SPF: pass (athena.apache.org: domain of
 gcjtmu-turbine-maven-user-846@m.gmane.org designates 80.91.229.3 as permitted
 sender)
To: users@maven.apache.org
From: =?UTF-8?B?SsO2cmc=?= Schaible <joerg.schaible@gmx.de>
Subject: Re: Provided scope dependencies
Date: Thu, 14 Mar 2013 18:57:58 +0100
Lines: 44
Message-ID: <kht333$6j1$1@ger.gmane.org>
References: 
 <OFDFAE6E69.F56BB4BF-ONC1257B2E.0054B84D-C1257B2E.005AA0E5@kisters.de>
Reply-To: joerg.schaible@gmx.de
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8Bit
User-Agent: KNode/4.9.5

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