Wendy is right. Provided scope is not the solution.
/Anders
On Mon, Jan 17, 2011 at 14:46, Wendy Smoak wrote:
> On Mon, Jan 17, 2011 at 7:59 AM, Jesse Farinacci wrote:
>
> > The scope=provided instructs Maven to not actually bring that
> > dependency into the classpath, thus, it behaves as a g
I have described innumerable times how aggregator POMs fix many problems
and this is one of them.
I exclude dependencies in the aggregated library and the module POMs
never have to worry about this.
This saves a lot of grief in our case where we have about 60 deliverable
modules that make up the
On Mon, Jan 17, 2011 at 7:59 AM, Jesse Farinacci wrote:
> The scope=provided instructs Maven to not actually bring that
> dependency into the classpath, thus, it behaves as a global exclude.
My understanding of 'provided' is that it *does* go on the classpath
for compilation, but it is not trans
I wouldn't recommended using provided scope as you or your fellow
developers may unintentionally in development/compile time make use of
some resource or type from dependency in provided scope, but then get
a nasty surprise at runtime.
Typically I'd use dependencyManagement at parent level, and ex
Hi,
On Mon, Jan 17, 2011 at 4:49 AM, wrote:
> is it possible to exclude a dependency without specifying from which other
> dependency it might come from ?
> Like "wherever depA is coming from, exclude it" ?
Until MNG-1977 is resolved, you can perform a simple work around. E.g.
http://jira.codehaus.org/browse/MNG-1977
On Mon, Jan 17, 2011 at 10:49 AM, wrote:
> Hi,
>
> is it possible to exclude a dependency without specifying from which other
> dependency it might come from ?
>
> Like "wherever depA is coming from, exclude it" ?
>
> Thanks
>
>
>
>
>
>
>
--
Hi,
is it possible to exclude a dependency without specifying from which other
dependency it might come from ?
Like "wherever depA is coming from, exclude it" ?
Thanks
