A "provide" mecanism for poms?

[David Delbecq <de...@oma.be>]

Hello maven users,

I encountered a curiosity in our maven dependency graph, while trying to 
find out why our webapp was failing.

What is the suggested and most proper solution when a library X and a 
library Y are "providing" the same api.

Am using myfaces api and myfaces impl. Both are implementation 
respectively of the jsf-api and jsf-impl of sun. However, a few jsf 
based library are marked as depending on jsf-api and jsf-impl. Is there 
some way to tell maven that myfaces-api and myfaces-impl are the same as 
jsf-api and jsf-impl and, as such, that if it encounter jsf-api or 
jsf-impl in the dependencies transitivity, it should not take that into 
consideration cause myfaecs was used higher in the graph? I could use 
restriction, but since the dependency to jsf can go deep in the graph 
using several path, with pom will be bloated with <restriction> ...  
There are quite a good amount of sun tools that have an equivalent 
counter-part in apache project i think.

-- 
David Delbecq
Institut Royal Météorologique
Ext:557


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

Re: A "provide" mecanism for poms?

[David Delbecq <de...@oma.be>]

En l'instant précis du 19/03/08 11:45, Stephen Connolly s'exprimait en 
ces termes:
> well I would have
>
> jsf-api as scope=provided
>
> I would not depend on jsf-impl
>   
Indeed, i could add a provided rule at top of tree for both :) I bet i 
didn't think enough about it :D Note that it didn't explicitly add 
jst-api/impl to our tree, it's a transitive dependency that comes at 
least with richfaces ^^, maybe with some other jsf components
> You will be deploying this application to a container that provides the api
> and it's impl. You should not be depending on any of the impl classes, so
> that would be my logic.
>
> If you then have customers that want to deploy to a container that does not
> supply a JSF impl, you could have assembler produce two distributions for
> these customers:
> 1. with the JSF-api and JSF-impl
> 2. with the myfaces-api and myfaces-impl
>   
Generated artefact is for internal use only, and we need myfaces in it 
(tomcat does not provide it ;) ). However, am curious. How do you ask 
maven2 to produce several artefacts with different dependency 
tree/different resources. I'm interrested in being able to generate 
artefact for test and production at the same time (you send the war to 
test, if it's ok, you already have it's corresponding production war, 
which includes it's production configuration)

-- 
David Delbecq
Institut Royal Météorologique
Ext:557


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

Re: A "provide" mecanism for poms?

["simon.kitching@chello.at" <si...@chello.at>]

It looks to me like David's problem is that he needs to depend on other
artifacts that declare a compile-scope or runtime-scope dependency on
Sun's jsf-api and jsf-impl artifacts.

IMO that would be an error in the poms for those other artifacts; they
should declare such dependencies as provided-scope only, and then there
is no problem. These are artifacts that are expected to be deployed
inside a container that will already have one of these libs, so
"provided" is the correct scope.

However if there is no chance to fix the other poms then I think the
only solution is to use the exclusions mechanism to prevent those
dependencies being inherited (when David says "restrictions" below, I
presume this means "exclusions"?).

Note that a more common occurrence of this problem is the
commons-logging artifact. A lot of projects declare this as a
compile-time dependency - and in this case, using "provided" scope would
not be reasonable. But there are several other projects who provide an
artifact that exposes the same api (ie is a complete alternative to
commons-logging). However maven provides no way AFAIK to specify that
the transitive dependency should be remapped; instead excludes have to
be used all over the place. It *would* be really nice for maven to have
a "provides" or "relocate" functionality in this case.

Regards,
Simon

Stephen Connolly schrieb:
> well I would have
>
> jsf-api as scope=provided
>
> I would not depend on jsf-impl
>
> You will be deploying this application to a container that provides the api
> and it's impl. You should not be depending on any of the impl classes, so
> that would be my logic.
>
> If you then have customers that want to deploy to a container that does not
> supply a JSF impl, you could have assembler produce two distributions for
> these customers:
> 1. with the JSF-api and JSF-impl
> 2. with the myfaces-api and myfaces-impl
>
> On Wed, Mar 19, 2008 at 9:32 AM, David Delbecq <de...@oma.be> wrote:
>
>   
>> Hello maven users,
>>
>> I encountered a curiosity in our maven dependency graph, while trying to
>> find out why our webapp was failing.
>>
>> What is the suggested and most proper solution when a library X and a
>> library Y are "providing" the same api.
>>
>>     
>
> The suggested and most proper solution is to have only one api.jar and have
> multiple impl.jar's
>
> Depending on the container rules for your api you would either have the api
> as scope=compile or scope=provided.
>
> The impl.jar's should all have a scope=compile dependency on the standard
> api.jar
>
> I would not have any dependency on the impl.jar (unless I needed it for unit
> tests, in which case scope=test)
>
>
>   
>> Am using myfaces api and myfaces impl. Both are implementation
>> respectively of the jsf-api and jsf-impl of sun. However, a few jsf
>> based library are marked as depending on jsf-api and jsf-impl. Is there
>> some way to tell maven that myfaces-api and myfaces-impl are the same as
>> jsf-api and jsf-impl and, as such, that if it encounter jsf-api or
>> jsf-impl in the dependencies transitivity, it should not take that into
>> consideration cause myfaecs was used higher in the graph? I could use
>> restriction, but since the dependency to jsf can go deep in the graph
>> using several path, with pom will be bloated with <restriction> ...
>> There are quite a good amount of sun tools that have an equivalent
>> counter-part in apache project i think.
>>
>> --
>> David Delbecq
>> Institut Royal Météorologique
>> Ext:557
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>>     
>
>   


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

Re: A "provide" mecanism for poms?

[David Delbecq <de...@oma.be>]

En l'instant précis du 19/03/08 11:53, Martin Höller s'exprimait en ces 
termes:
> On Wednesday 19 March 2008 Stephen Connolly wrote:
>   
>> well I would have
>>
>> jsf-api as scope=provided
>>     
>
> That's not possible if you develop your own JSF component. You would need it 
> at compile time.
>
> - martin
>   
As far as i know, scope=provided are available at compile time but not 
bundled in final package

-- 
David Delbecq
Institut Royal Météorologique
Ext:557


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

Re: A "provide" mecanism for poms?

[Martin Höller <ma...@xss.co.at>]

On Wednesday 19 March 2008 Stephen Connolly wrote:
> well I would have
>
> jsf-api as scope=provided

That's not possible if you develop your own JSF component. You would need it 
at compile time.

- martin

Re: A "provide" mecanism for poms?

[Stephen Connolly <st...@gmail.com>]

well I would have

jsf-api as scope=provided

I would not depend on jsf-impl

You will be deploying this application to a container that provides the api
and it's impl. You should not be depending on any of the impl classes, so
that would be my logic.

If you then have customers that want to deploy to a container that does not
supply a JSF impl, you could have assembler produce two distributions for
these customers:
1. with the JSF-api and JSF-impl
2. with the myfaces-api and myfaces-impl

On Wed, Mar 19, 2008 at 9:32 AM, David Delbecq <de...@oma.be> wrote:

> Hello maven users,
>
> I encountered a curiosity in our maven dependency graph, while trying to
> find out why our webapp was failing.
>
> What is the suggested and most proper solution when a library X and a
> library Y are "providing" the same api.
>

The suggested and most proper solution is to have only one api.jar and have
multiple impl.jar's

Depending on the container rules for your api you would either have the api
as scope=compile or scope=provided.

The impl.jar's should all have a scope=compile dependency on the standard
api.jar

I would not have any dependency on the impl.jar (unless I needed it for unit
tests, in which case scope=test)


>
> Am using myfaces api and myfaces impl. Both are implementation
> respectively of the jsf-api and jsf-impl of sun. However, a few jsf
> based library are marked as depending on jsf-api and jsf-impl. Is there
> some way to tell maven that myfaces-api and myfaces-impl are the same as
> jsf-api and jsf-impl and, as such, that if it encounter jsf-api or
> jsf-impl in the dependencies transitivity, it should not take that into
> consideration cause myfaecs was used higher in the graph? I could use
> restriction, but since the dependency to jsf can go deep in the graph
> using several path, with pom will be bloated with <restriction> ...
> There are quite a good amount of sun tools that have an equivalent
> counter-part in apache project i think.
>
> --
> David Delbecq
> Institut Royal Météorologique
> Ext:557
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>