On 19/03/2009, Stephen Connolly <[email protected]> wrote: > 2009/3/19 sebb <[email protected]> > > > On 19/03/2009, Stephen Connolly <[email protected]> wrote: > > > 2009/3/19 sebb <[email protected]> > > > > > > > > > > On 19/03/2009, Rusty Wright <[email protected]> wrote: > > > > > Do the imports only have an effect at compile time? For example, if > > you > > > > > have > > > > > > > > > > package impl.zzz; > > > > > > > > > > import api.yyy.Yyy; > > > > > > > > > > public class Xyz implements Yyy { > > > > > } > > > > > > > > > > When you run the app the jvm won't need to have the yyy.Yyy class > > > > > available? > > > > > > > > Yes, that's what I wrote. > > > > > > > > At runtime: > > > > - annotation jars are not needed > > > > > > > > > > > > Only if they have a retention of compile.... if they are retained at > > runtime > > > you'll need them on the classpath > > > > > > > > > > > > > > > > > - code jars are needed, but they may be different from the ones used > > to > > > > compile. > > > > > > > > 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 > > separately, which is a pain. > > > > > Nope....
I think you meant "Yep..." as you seem to be agreeing with me. > provided just says that somebody will provide it for you and that maven does > not need to worry about it. > Yes, I know. Maven maybe does not have to worry about it, but the user does, which is what I want to avoid. 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. > > > > > > > > > > > > > > > Even if that's true it seems dubious to me because it seems to me > > that > > > > that > > > > > means your code is always referring to the concrete class Xyz when > > it > > > > should > > > > > be using the interface Yyy. For example, how could you do > > > > > > > > > > Yyy y = new Xyz(); > > > > > > > > > > Would that run without the interface class on the classpath? > > > > > > > > > > > > > > > sebb wrote: > > > > > > > > > > > > > > > > > On 18/03/2009, sebb <[email protected]> wrote: > > > > > > > > > > > > > AIUI, "compile" scope means compile, test and run, and generates > > a > > > > > > > transitive dependency. > > > > > > > > > > > > > > There are some dependencies that are compile-time only, for > > example > > > > > > > annotations, and Java specification jars - i.e. API-only jars > > that > > > > > > > have no implementation. > > > > > > > > > > > > > > What is the best way to define such a dependency? > > > > > > > > > > > > > > The Maven site suggests using "provided", but this does not > > solve > > > > the > > > > > problem. > > > > > > > > > > > > > > Maybe there should be a"compile-only" scope? > > > > > > > > > > > > > > > > > > > > > > > > > > Note that in the case of annotation jars, these are not needed at > > > > > run-time. > > > > > > > > > > > > In the case of API-only jars, at run-time one would use a > > different > > > > > > jar which has the full implementation. This is useful for public > > specs > > > > > > which might not have open source implementations. The API-only > > jars > > > > > > allow one to compile. > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > 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] > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > 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] > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
