On 12/1/06, Alexander Sack <[EMAIL PROTECTED]> wrote:

And in fact, one can actually remove the transitive dependencies that are
unwanted during the build classpath by declaring them in the POM as
"provided."  I believe that fits his scenario where he is building against
a
library that has a transitive dependency that he does not want on his
build
classpath for whatever reason (packaging, etc.).


My understanding is the "provided" is essentially the opposite of "runtime"
... it leaves the dependency on the compile classpath but does not include
it in the output.   Whereas, "runtime" leaves it off the compile classpath
but does include it in the output.

In a web app, I'll want to declare the servlet API as a "provided" API so
that I can use it in my own code.  The servlet container will make it
available to me at runtime, so I don't want to include it in the war.  But,
if I'm also using something like the MyFaces JSF implementation, which has
both an API jar and an implementation JAR, I'll want the API jar declared as
"compile" scope (so its on the classpath and included in the war), but the
impl JAR declared "runtime" scope (so it is *not* possible for me to
accidentally compile against classes in the MyFaces implementation, where I
should be programming solely to JSF APIs), but is included so that the
runtime app will work.

Craig


-aps


Craig


On 12/1/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:
>
> On 12/1/06, Alexander Sack <[EMAIL PROTECTED]> wrote:
> >
> > This maybe an artifact of the fact that many plugins use the classpath
> for
> > runtime constraints as well.
>
>
> It's also possible to avoid this behavior, by declaring a scope of
> <runtime>
> on the dependency.  That way, the module is *not* included on the
compile
> time classpath (unless it's declared with compile scope by someone else
> you
> depend on), but *is* included for runtime (for example, in a webapp it'd
> be
> included in WEB-INF/lib).
>
> -aps
>
>
> Craig
>
>


--
"What lies behind us and what lies in front of us is of little concern to
what lies within us." -Ralph Waldo Emerson


Reply via email to