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, Rusty Wright <rusty.wri...@gmail.com> 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 <seb...@gmail.com> 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:
> > > > > users-unsubscr...@maven.apache.org
> > > > > > For additional commands, e-mail: users-h...@maven.apache.org
> > > > > >
> > > > > >
> > > > >
> > > > >
> > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > > > > For additional commands, e-mail: users-h...@maven.apache.org
> > > > >
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > > > For additional commands, e-mail: users-h...@maven.apache.org
> > > >
> > > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
