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: [email protected] > For additional commands, e-mail: [email protected] > > > -- 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: [email protected] For additional commands, e-mail: [email protected]
