On 19/03/2009, Stephen Connolly <stephen.alan.conno...@gmail.com> wrote: > 2009/3/19 sebb <seb...@gmail.com> > > > On 19/03/2009, Stephen Connolly <stephen.alan.conno...@gmail.com> wrote: > > > 2009/3/19 sebb <seb...@gmail.com> > > > > > > > On 19/03/2009, Stephen Connolly <stephen.alan.conno...@gmail.com> > > wrote: > > > > > 2009/3/19 sebb <seb...@gmail.com> > > > > > > > > > > > > > > > > > Can I get back to my original question, which is: > > > > > > > > > > > > How does one express a dependency on a jar which is only needed > > at > > > > > > compile time, such that the dependency is not propagated? > > > > > > > > > > > > > > > > > > > > > scope provided will do what you need afaik > > > > > > > > > > > > > Yes, but then AFAIK the user has to download and install the jar
This was an incorrect assumption, see below. > > > > separately, which is a pain. > > > > > > > > > > > > > Nope.... > > > > I think you meant "Yep..." as you seem to be agreeing with me. > > > > > I meant Nope... as I was disagreeing with you > > > > > > > provided just says that somebody will provide it for you and that maven > > does > > > not need to worry about it. > > > I understood that to mean that Maven would *not* resolve the dependency from the repo at build time - which is why I thought you agreed with me. But see below - that was a misunderstanding. > > > > > provided says that the final deployment location of the jar will have > whatever classes are needed at runtime to fullfil this jar's requirements. > > The classes in the jar with provided scope should be on maven's compile and > test classpaths for this module... this jar is not needed for any transitive > dependencies. That use of "should" confused me, see below. > > > > > Yes, I know. > > > > Maven maybe does not have to worry about it, but the user does, which > > is what I want to avoid. > > Again, this is because I thought Maven did not resolve provided jars from the repo at build time. > > > IF you are certain that annotations with runtime retention do not break > classloading, then you are fine. Use scope "provided" problem solved. My bad. I misunderstood the "provided" scope to mean that something outside Maven - i.e. the user in this case - has to provide the jar at build time. That view appeared to be confirmed by what you wrote (and the Maven docs), but I see now that I can read it differently. I've now know that Maven resolves "provided" dependencies from the repository. Sorry for the noise. > > > > > AIUI "provided" is mainly intended for jars that are not available via > > the repository, e.g. they may be commercial jars that have to be paid > > for separately. > > > > > Nope, provided is for artifacts that are either provided in another form by > the container in which the jar will run, or are not actually needed. This is true only of run-time. See above, I thought it applied to Maven compilations as well. > (Note: <optional>true</optional> should have the same effect but I have > never quite got that to work the way it should) > I'm told it doesn't, because the dpendency still ends up in OSGI bundles. > > -Stephen > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
