I would also be able to model my dependency structure more accurately if
I could <exclude/> a dependency from the runtime classpath only and keep
it in the compile classpath.
E.g.
<dependencies>
<dependency>
<groupId>SalesStation</groupId>
<artifactId>cds_ss_shared</artifactId>
<version>SNAPSHOT</version>
<exclusions>
<exclusion>
<groupId>SalesStation</groupId>
<artifactId>ss_base_shared</artifactId>
<!-- I want to be able to do this: -->
<scope>runtime</scope> <!-- Exclude from runtime
classpath only, not compile classpath -->
</exclusion>
</exclusions>
</dependency>
</dependencies>
-----Original Message-----
From: Boden, David
Sent: Tuesday, January 17, 2006 12:36 PM
To: '[email protected]'
Subject: provided - not transitive?
Extract from:
http://maven.apache.org/guides/introduction/introduction-to-dependency-m
echanism.html
provided - this is much like compile, but indicates you expect the JDK
or a container to provide it. It is only available on the compilation
classpath, and is not transitive.
Question: Why are provided scope dependencies not transitive?
I have several examples in my project where I need to declare a
dependency as on the compilation classpath but not on the runtime
classpath and I need it to be transitive. I don't want the dependency to
be packaged up in my deployment artifact but my entire multi-project
hierarchy relies on the dependency.
At the moment, I have to workaround the problem, mostly by declaring
duplicate provided scope dependencies in multiple projects.
If there's a well-known answer to this query then apologies, could it be
placed in the "Introduction to Dependency Mechanism" documentation?
------------------------------------------------------------------------------
This message is intended only for the personal and confidential use of the
designated recipient(s) named above. If you are not the intended recipient of
this message you are hereby notified that any review, dissemination,
distribution or copying of this message is strictly prohibited. This
communication is for information purposes only and should not be regarded as an
offer to sell or as a solicitation of an offer to buy any financial product, an
official confirmation of any transaction, or as an official statement of Lehman
Brothers. Email transmission cannot be guaranteed to be secure or error-free.
Therefore, we do not represent that this information is complete or accurate
and it should not be relied upon as such. All information is subject to change
without notice.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
