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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
