optional scope for dependencies

[Brett Porter <br...@apache.org>]

Hi,

I'd like to add an optional scope to dependencies as a way to not pass
them on to projects depending on your library. This would allow fixing
things like dom4j that pull in extra dependencies.

If we don't do this, I believe scope=provided will be abused as using
that will do it, and prevent us from changing that behaviour in future
if desired.

Thoughts? Anyone disagreeing has to provide a viable way to deal with
dom4j and friends :)

- Brett

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: optional scope for dependencies

[Brett Porter <br...@apache.org>]

Kenney Westerhof wrote:

>scope=provided currently does not do this (but I like it to :))
>
>  
>
I thought that was the point - provided doesn't pass along the
dependency, hence can be abused as an optional scope. I'm porposing we
actually have an optional scope that does that. This would effectively
be the same as removing them from the repository POM, though allows us
to warn on it at least, and perhaps factor them into the version
resolution if the dependency is present elsewhere in the tree.

BTW, I've responded to that email - we should discuss that further there.

>Well, the excludes mechanism can deal with this.
>  
>
Yes, but that pushes the work to the client, which we are hearing
regular complaints about. It's very verbose.

>I believe there was an idea about specifying api's as dependencies
>and a default implementation for that. If a nearer project specifies
>another implementation, that should be used. Although I don't know
>how this should (and can?) be implemented. For instance, a war
>project can be considered final, but then you could also package
>it into an ear, which might override the implementation specified
>in the war's pom.
>  
>
This is different to this - I'm not sure what you mean.

>Btw, the dependencies brought along with dom4j are needed to use that
>project, right? Unless the project uses that project with dom4j specifies
>those dependencies, it'll break at runtime. Isn't it the job of the
>'nearest' conflict resolution to override versions brought in by
>dependencies? But i guess this is not a version issue, but an
>'implementation provider' issue?
>  
>
Again, not sure what you mean about implementation provider in relation
to this.

>Could you elaborate more on the exact problem? :)
>  
>
Yeah, probably didn't go through it enough as I thought it was well known.

dom4j introduces a bunch of dependencies it needs to compile, but you
most likely aren't using because they are optional. You are only using
them if you use the piece of dom4j code that uses them. This is the same
as velocity having a JDBC dependency for its JDBC resource loader that a
lot of people don't use.

The best solution is for dom4j to split up into a bunch of libraries
that have smaller sets of individual dependencies, and you only depend
on the pieces you use. As much as we can encourage that we can't enforce
it. Letting them designate some dependencies as optional would mean that
those are only used by specific functions not essential to the operation
of the library, and Maven would skip them in the transitive dependency
calculations.

- Brett



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: optional scope for dependencies

[Kenney Westerhof <fo...@neonics.com>]

On Mon, 19 Sep 2005, Brett Porter wrote:

Hi,

> Hi,
>
> I'd like to add an optional scope to dependencies as a way to not pass
> them on to projects depending on your library. This would allow fixing
> things like dom4j that pull in extra dependencies.
>
> If we don't do this, I believe scope=provided will be abused as using
> that will do it, and prevent us from changing that behaviour in future
> if desired.

scope=provided currently does not do this (but I like it to :))

If that change is committed, we might need something like that new scope.

> Thoughts? Anyone disagreeing has to provide a viable way to deal with
> dom4j and friends :)

Well, the excludes mechanism can deal with this.
I believe there was an idea about specifying api's as dependencies
and a default implementation for that. If a nearer project specifies
another implementation, that should be used. Although I don't know
how this should (and can?) be implemented. For instance, a war
project can be considered final, but then you could also package
it into an ear, which might override the implementation specified
in the war's pom.

Btw, the dependencies brought along with dom4j are needed to use that
project, right? Unless the project uses that project with dom4j specifies
those dependencies, it'll break at runtime. Isn't it the job of the
'nearest' conflict resolution to override versions brought in by
dependencies? But i guess this is not a version issue, but an
'implementation provider' issue?

Could you elaborate more on the exact problem? :)

-- Kenney

>
> - Brett
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>

--
Kenney Westerhof
http://www.neonics.com
GPG public key: http://www.gods.nl/~forge/kenneyw.key

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org