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