[prev in list] [next in list] [prev in thread] [next in thread] 

List:       maven-user
Subject:    Re: Grandparent classes not found at compile time
From:       Trinition <trin+nabble.com () trinition ! org>
Date:       2009-03-30 23:33:49
Message-ID: 22795415.post () talk ! nabble ! com
[Download RAW message or body]


My point is about transitive support for provided dependencies.  The middle
artifact here does declare a dependency to the third-party jar.  But its
declared as *provided*, not *compile*.

Now I understand the intent of provided.  It's to say "I expect this to be
provided in the runtime environment, so don't package it into anything --
but since you're compiling outside of said runtime environment, include it
for compile purposes."  Is this correct?

On the other hand, a *compile* dependency is something you need tom compile
against and include in any subsequent packaging, true?

So then a project's own dependencies...

*compile*
  Used at compile: TRUE
  Used in package: TRUE
*provided*
  Used at compile: TRUE
  Used in package: FALSE

So compiling against a direct "provided" dependency works fine.  But if I
put a layer in there, it breaks down according to Maven's own rules:

transitive *compile*
  Used at compile: TRUE
  Used in package: TRUE
transitive *provided*
  Used at compile: FALSE
  Used in package: FALSE

A transitive *provided* dependency is not included at runtime.  But I'm
still in a compile phase, trying to compile against the same jars all of my
dependencies had available to them when they compiled.  I can certainly see
times when you wouldn't want this, but in the case of a class hierarchy, you
must  have them.

So my option is to go into the middle artifact's pom and change the
dependency to the third party from *provided* to *compile* or explicitly
include the third party *provided* jar directly form my application's pom
(which mean's I'm duplicating information already in the middle component's
pom).  For the time being, I'm doing the latter, but it doesn't feel right.

I feel like there's a certain degree of freedom missing here where I want
something to NOT be packaged because it'll be included but still make it a
compile time dependency since I'm not in the container at runtime.  I have
that for direct dependencies but not transitive dependencies.

Regards,
Brian.


Wayne Fay wrote:
> 
> > But if I must do manual dependency analysis every time I update a third
> > party jar -- just in case it now incurs a new dependency for me -- then
> > what
> > value are transitive dependencies in Maven at all?
> 
> You are expected to know what Jars your project (specifically) depends
> on. I've followed this thread and still don't understand why you don't
> know this.
> 
> If artifacts you depend on have dependencies themselves (which is what
> should happen when one class extends another), they should be declared
> in the pom files of those projects. If those artifacts do not properly
> declare the scope of all of their dependencies, such that a needed
> class is not being found during compilation/testing/runtime, then you
> need to talk to the owner of the "bad" artifact. If those artifacts do
> not have pom files at all (you're using mvn install:install-file or
> deploy:deploy-file on them), then that is another issue.
> 
> Maven's (transitive) dependency management works extremely well for a
> lot of people. I still don't know why you're having such troubles with
> it, and I can only blame the artifacts you're working with and not the
> system itself at this point.
> 
> Wayne
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
> 
> 
> 

-- 
View this message in context: \
http://www.nabble.com/Grandparent-classes-not-found-at-compile-time-tp22733894p22795415.html
 Sent from the Maven - Users mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


[prev in list] [next in list] [prev in thread] [next in thread]