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] > >
