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-sc
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
A
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
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
signature.asc
Description: This is a digitally signed message part.
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
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 impl
