Re: Transitive dependency question
I think that is a bug that is in scope for 3.5.1 or 3.6.0 On 31 May 2017 at 22:30, Laird Nelson wrote: > (I've been working with Maven since at least 2004 and I think I *still* > don't > get transitive dependencies.) > > I have a pom.xml file of type pom that has some compile-scoped dependencies > in it. (P1 -> A(compile), B(compile)) > > I have another project that depends on this pom in provided scope (I'm just > playing around for now). The intention is that I will "get" all the > transitive compile-scoped dependencies of the pom artifact I'm depending > on, but in provided scope. (P2 -> P1(provided); result is effectively: P2 > -> P1(provided) -> A(provided), B(provided)) > > If that's all I have, then indeed, that's the result I observe: when I run > the maven-dependency-plugin's dependency-tree goal, I see these transitive > dependencies and they are all marked as being in provided scope, not > compile. I see, in other words, the tree representation of P2 -> > P1(provided) -> A(provided), B(provided). So far so good. > > Now I pull in another (jar) dependency in runtime scope. It has some > transitive dependencies in compile scope. Fine. They don't include any of > the dependencies mentioned in my second paragraph. (P2 -> (P1(provided) -> > A(provided),B(provided)), (P3(runtime) -> C(compile),D(compile))) Note > that this pseudo-language is what I *expect* to see. > > When I run dependency:tree on this hairy mess, it does *not* show the > representation of my pseudo-language above. Instead, it shows the > transitive dependencies from my third paragraph as direct "children" of the > pom-type artifact I'm pulling in in provided scope (P1), but they all have > a scope of runtime. So, for just this part of the tree: P2 -> P1(provided) > -> A(runtime(!)), B(runtime(!)) > > What the…? In other words, somebody in the tree is "promoting" my A and B > dependencies to runtime scope. But I can't tell from the tree output who > it is, because A and B (that are now apparently runtime-scoped > dependencies) are still showing as children of my pom artifact (P1, > mentioned in my second paragraph). > > Is this all according to plan? I'm using version 3.0.0 of the > maven-dependency-plugin and version 3.5.0 of Maven itself. > > Best, > Laird >
Transitive dependency question
(I've been working with Maven since at least 2004 and I think I *still* don't get transitive dependencies.) I have a pom.xml file of type pom that has some compile-scoped dependencies in it. (P1 -> A(compile), B(compile)) I have another project that depends on this pom in provided scope (I'm just playing around for now). The intention is that I will "get" all the transitive compile-scoped dependencies of the pom artifact I'm depending on, but in provided scope. (P2 -> P1(provided); result is effectively: P2 -> P1(provided) -> A(provided), B(provided)) If that's all I have, then indeed, that's the result I observe: when I run the maven-dependency-plugin's dependency-tree goal, I see these transitive dependencies and they are all marked as being in provided scope, not compile. I see, in other words, the tree representation of P2 -> P1(provided) -> A(provided), B(provided). So far so good. Now I pull in another (jar) dependency in runtime scope. It has some transitive dependencies in compile scope. Fine. They don't include any of the dependencies mentioned in my second paragraph. (P2 -> (P1(provided) -> A(provided),B(provided)), (P3(runtime) -> C(compile),D(compile))) Note that this pseudo-language is what I *expect* to see. When I run dependency:tree on this hairy mess, it does *not* show the representation of my pseudo-language above. Instead, it shows the transitive dependencies from my third paragraph as direct "children" of the pom-type artifact I'm pulling in in provided scope (P1), but they all have a scope of runtime. So, for just this part of the tree: P2 -> P1(provided) -> A(runtime(!)), B(runtime(!)) What the…? In other words, somebody in the tree is "promoting" my A and B dependencies to runtime scope. But I can't tell from the tree output who it is, because A and B (that are now apparently runtime-scoped dependencies) are still showing as children of my pom artifact (P1, mentioned in my second paragraph). Is this all according to plan? I'm using version 3.0.0 of the maven-dependency-plugin and version 3.5.0 of Maven itself. Best, Laird
Re: Transitive Dependency Question
Hi Jamal, Jamal B wrote: > Interesting > > Taking your suggestion, it looks like it is coming in from another compile > dependency, and was "promoted" to compile. > > [INFO] +- org.apache.maven.shared:maven-shared-jar:jar:1.1:compile > [INFO] | +- org.codehaus.plexus:plexus-digest:jar:1.0:compile > [INFO] | | \- > org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-8:compile > [INFO] | | +- junit:junit:jar:3.8.1:compile > > Is there a way to prevent this from happening without having to add > exclude stanzas across projects where this is happening? You can control this with a dependencyManagement section of a shared parent. Just define there junit:junit: and the scope. The annoying part is nevertheless that the situation is no longer obvious in M3. Try this in M2 and you'll see that the dependency makes much more sense. Since the same plugin produces different output, I blame the new Aether backend here which favors now the "nearest" occurrence without taking the inherited scope into account. While this behavior has no impact on the resulting class path, it hides dependency problems like the one, you have encountered here. - Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Transitive Dependency Question
Interesting
Taking your suggestion, it looks like it is coming in from another compile
dependency, and was "promoted" to compile.
[INFO] +- org.apache.maven.shared:maven-shared-jar:jar:1.1:compile
[INFO] | +- org.codehaus.plexus:plexus-digest:jar:1.0:compile
[INFO] | | \-
org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-8:compile
[INFO] | | +- junit:junit:jar:3.8.1:compile
Is there a way to prevent this from happening without having to add exclude
stanzas across projects where this is happening?
On Mon, Jun 3, 2013 at 7:56 PM, Jörg Schaible wrote:
> Hi Jamal,
>
> Jamal B wrote:
>
> > Hello, I have a question about transitive dependencies. According to the
> > pom documentation here: http://maven.apache.org/pom.html#Dependencies
> >
> > project dependencies marked with test scope are not transitive. I
> assumed
> > that this also applied to it's dependencies, so my question is if I
> > declare a dependency on a project at test scope, that project's
> > dependencies should
> > all be included at test scope. For example, given the following
> > project(s)
> >
> > Project test-utils defines a junit dependency like such:
> >
> >
> > junit
> > junit
> >
> >
> > Project application defines a dependency on test-utils with a scope of
> > test like such
> >
> > ${project.groupId}
> > test-utils
> > ${project.version}
> > test
> >
> >
> > Now running mvn clean dependency:tree shows that the junit dependency is
> > being passed to the application project at compile scope which is not
> > expected.
> >
> > [INFO] --- maven-dependency-plugin:2.7:tree (default-cli) @ application
> > [--- INFO] org.sandbox:application:war:1.0.0-SNAPSHOT
> >
> > [INFO] \- org.sandbox:test-utils:jar:1.0.0-SNAPSHOT:test
> > [INFO]+- junit:junit:jar:4.8.2:compile
> > [INFO]+- org.mockito:mockito-all:jar:1.8.5:test
> > [INFO]+- com.h2database:h2:jar:1.3.165:test
> > [INFO]\- log4j:log4j:jar:1.2.16:test
> >
> >
> > Is this a bug or was my interpretation of the transitive dependency logic
> > incorrect?
> >
> > Thank you for your time.
>
> Actually I was fooled by such an output with M3 in one of my projects at
> first sight also.
>
> So, please make a test: Comment out the org.sandbox:test-utils in your POM
> and print the tree again. I am quite sure that you will see that
> junit:junit
> is now introduced by a different dependency that is not of test scope. What
> you see above is only the result of the dependency resolver. It detected
> that it already has a junit:junit in its transitive deps in compile scope
> (maybe even in a different version), but the "nearest" path to junit was as
> direct child of org.sandbox:test-utils. Therefor it was "promoted" to
> compile scope in this place, but the overall result of the compilation
> classpath is still OK, it is only the displayed tree that is somewhat
> inconsistent (compared to M2).
>
> - Jörg
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>
Re: Transitive Dependency Question
Hi Jamal,
Jamal B wrote:
> Hello, I have a question about transitive dependencies. According to the
> pom documentation here: http://maven.apache.org/pom.html#Dependencies
>
> project dependencies marked with test scope are not transitive. I assumed
> that this also applied to it's dependencies, so my question is if I
> declare a dependency on a project at test scope, that project's
> dependencies should
> all be included at test scope. For example, given the following
> project(s)
>
> Project test-utils defines a junit dependency like such:
>
>
> junit
> junit
>
>
> Project application defines a dependency on test-utils with a scope of
> test like such
>
> ${project.groupId}
> test-utils
> ${project.version}
> test
>
>
> Now running mvn clean dependency:tree shows that the junit dependency is
> being passed to the application project at compile scope which is not
> expected.
>
> [INFO] --- maven-dependency-plugin:2.7:tree (default-cli) @ application
> [--- INFO] org.sandbox:application:war:1.0.0-SNAPSHOT
>
> [INFO] \- org.sandbox:test-utils:jar:1.0.0-SNAPSHOT:test
> [INFO]+- junit:junit:jar:4.8.2:compile
> [INFO]+- org.mockito:mockito-all:jar:1.8.5:test
> [INFO]+- com.h2database:h2:jar:1.3.165:test
> [INFO]\- log4j:log4j:jar:1.2.16:test
>
>
> Is this a bug or was my interpretation of the transitive dependency logic
> incorrect?
>
> Thank you for your time.
Actually I was fooled by such an output with M3 in one of my projects at
first sight also.
So, please make a test: Comment out the org.sandbox:test-utils in your POM
and print the tree again. I am quite sure that you will see that junit:junit
is now introduced by a different dependency that is not of test scope. What
you see above is only the result of the dependency resolver. It detected
that it already has a junit:junit in its transitive deps in compile scope
(maybe even in a different version), but the "nearest" path to junit was as
direct child of org.sandbox:test-utils. Therefor it was "promoted" to
compile scope in this place, but the overall result of the compilation
classpath is still OK, it is only the displayed tree that is somewhat
inconsistent (compared to M2).
- Jörg
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Transitive Dependency Question
Hi, thanks for your response.
Running dependency:list shows also shows that junit is at compile scope
which I expected to be at test scope.
[INFO] --- maven-dependency-plugin:2.7:list (default-cli) @ application ---
[INFO]
[INFO] The following files have been resolved:
[INFO]junit:junit:jar:4.8.2:compile
So is it a correct statement that the base scope of a dependency is fixed
regardless of the declared scope of the outer dependency? This appears to
be the behavior, but I am not sure that this is correct.
On Mon, Jun 3, 2013 at 1:53 PM, Baptiste MATHUS wrote:
> Hi,
> Tree is showing the tree. So it seems correct at first sight. Its showing
> you the dependency beetween your test-utils of the project and junit which
> is in fact scope compile.
>
> What you seem to actually want to have is the resolved list of dependencies
> for your application project.
> That goal is called dependency:list.
>
> Hope this helps.
>
> Cheers
>
> -- Baptiste
> Le 3 juin 2013 19:21, "Jamal B" a écrit :
>
> > Hello, I have a question about transitive dependencies. According to the
> > pom documentation here: http://maven.apache.org/pom.html#Dependencies
> >
> > project dependencies marked with test scope are not transitive. I
> assumed
> > that this also applied to it's dependencies, so my question is if I
> declare
> > a dependency on a project at test scope, that project's dependencies
> should
> > all be included at test scope. For example, given the following
> project(s)
> >
> > Project test-utils defines a junit dependency like such:
> >
> >
> > junit
> > junit
> >
> >
> > Project application defines a dependency on test-utils with a scope of
> test
> > like such
> >
> > ${project.groupId}
> > test-utils
> > ${project.version}
> > test
> >
> >
> > Now running mvn clean dependency:tree shows that the junit dependency is
> > being passed to the application project at compile scope which is not
> > expected.
> >
> > [INFO] --- maven-dependency-plugin:2.7:tree (default-cli) @ application
> ---
> > [INFO] org.sandbox:application:war:1.0.0-SNAPSHOT
> >
> > [INFO] \- org.sandbox:test-utils:jar:1.0.0-SNAPSHOT:test
> > [INFO]+- junit:junit:jar:4.8.2:compile
> > [INFO]+- org.mockito:mockito-all:jar:1.8.5:test
> > [INFO]+- com.h2database:h2:jar:1.3.165:test
> > [INFO]\- log4j:log4j:jar:1.2.16:test
> >
> >
> > Is this a bug or was my interpretation of the transitive dependency logic
> > incorrect?
> >
> > Thank you for your time.
> >
>
Re: Transitive Dependency Question
Hi,
Tree is showing the tree. So it seems correct at first sight. Its showing
you the dependency beetween your test-utils of the project and junit which
is in fact scope compile.
What you seem to actually want to have is the resolved list of dependencies
for your application project.
That goal is called dependency:list.
Hope this helps.
Cheers
-- Baptiste
Le 3 juin 2013 19:21, "Jamal B" a écrit :
> Hello, I have a question about transitive dependencies. According to the
> pom documentation here: http://maven.apache.org/pom.html#Dependencies
>
> project dependencies marked with test scope are not transitive. I assumed
> that this also applied to it's dependencies, so my question is if I declare
> a dependency on a project at test scope, that project's dependencies should
> all be included at test scope. For example, given the following project(s)
>
> Project test-utils defines a junit dependency like such:
>
>
> junit
> junit
>
>
> Project application defines a dependency on test-utils with a scope of test
> like such
>
> ${project.groupId}
> test-utils
> ${project.version}
> test
>
>
> Now running mvn clean dependency:tree shows that the junit dependency is
> being passed to the application project at compile scope which is not
> expected.
>
> [INFO] --- maven-dependency-plugin:2.7:tree (default-cli) @ application ---
> [INFO] org.sandbox:application:war:1.0.0-SNAPSHOT
>
> [INFO] \- org.sandbox:test-utils:jar:1.0.0-SNAPSHOT:test
> [INFO]+- junit:junit:jar:4.8.2:compile
> [INFO]+- org.mockito:mockito-all:jar:1.8.5:test
> [INFO]+- com.h2database:h2:jar:1.3.165:test
> [INFO]\- log4j:log4j:jar:1.2.16:test
>
>
> Is this a bug or was my interpretation of the transitive dependency logic
> incorrect?
>
> Thank you for your time.
>
Transitive Dependency Question
Hello, I have a question about transitive dependencies. According to the
pom documentation here: http://maven.apache.org/pom.html#Dependencies
project dependencies marked with test scope are not transitive. I assumed
that this also applied to it's dependencies, so my question is if I declare
a dependency on a project at test scope, that project's dependencies should
all be included at test scope. For example, given the following project(s)
Project test-utils defines a junit dependency like such:
junit
junit
Project application defines a dependency on test-utils with a scope of test
like such
${project.groupId}
test-utils
${project.version}
test
Now running mvn clean dependency:tree shows that the junit dependency is
being passed to the application project at compile scope which is not
expected.
[INFO] --- maven-dependency-plugin:2.7:tree (default-cli) @ application ---
[INFO] org.sandbox:application:war:1.0.0-SNAPSHOT
[INFO] \- org.sandbox:test-utils:jar:1.0.0-SNAPSHOT:test
[INFO]+- junit:junit:jar:4.8.2:compile
[INFO]+- org.mockito:mockito-all:jar:1.8.5:test
[INFO]+- com.h2database:h2:jar:1.3.165:test
[INFO]\- log4j:log4j:jar:1.2.16:test
Is this a bug or was my interpretation of the transitive dependency logic
incorrect?
Thank you for your time.
RE: [m2] Transitive Dependency Question
Is it a bug in the javadoc (not using the compile path) or the compiler (using a dependency it shouldn't)? The portal server we use already puts log4j into the app server's classpath, so we aren't actually adding that. I have not seen any docs regarding not putting log4j into a container. Looking at the link Jason sent, it would appear that what I am doing fits. I am completely hiding the use of log4j behind the API of the logging project; no other components of our code should have any interest in exactly how the logging is performed. Is "Monitor" a standard pattern I can find somewhere or is that an IoC artifact? -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 17, 2005 22:18 To: Maven Users List Subject: Re: [m2] Transitive Dependency Question On 8/18/05, Allison, Bob <[EMAIL PROTECTED]> wrote: > What is the correct scope to make this > work (or do I need to explicitly state the dependency on log4j in the > logging project)? Sounds more like a bug in the javadoc plugin. Redeclaring will work as a workaround, but please file a JIRA issue. > > Is this configured properly so that the log4j and log4jext jars won't > get packaged into the war file? You'd need to redeclare the ext jar in the WAR's POM with scope "provided". But also, you should read the docs on the log4j site about why putting log4j into the container is a bad idea (and even better, read the info Jason sent here). Cheers, Brett - 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]
Re: [m2] Transitive Dependency Question
On 8/18/05, Allison, Bob <[EMAIL PROTECTED]> wrote: > What is the correct scope to make this > work (or do I need to explicitly state the dependency on log4j in the > logging project)? Sounds more like a bug in the javadoc plugin. Redeclaring will work as a workaround, but please file a JIRA issue. > > Is this configured properly so that the log4j and log4jext jars won't > get packaged into the war file? You'd need to redeclare the ext jar in the WAR's POM with scope "provided". But also, you should read the docs on the log4j site about why putting log4j into the container is a bad idea (and even better, read the info Jason sent here). Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] Transitive Dependency Question
On Wed, 2005-08-17 at 19:43 -0500, Allison, Bob wrote: > I am working on a multi-project which looks like this: > > Project log4jext is an extension for log4j for our environment. Because > of the nature of extending log4j, I was unable to completely remove all > log4j classes from this project's API. Its dependencies look like: > > > log4j > log4j > > Just thought I would point you at Paul Hammant's blog entry on using Monitors instead of things like log4j or clogging: http://paulhammant.com/blog/000241.html -- jvz. Jason van Zyl jason at maven.org http://maven.apache.org A party which is not afraid of letting culture, business, and welfare go to ruin completely can be omnipotent for a while. -- Jakob Burckhardt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[m2] Transitive Dependency Question
I am working on a multi-project which looks like this: Project log4jext is an extension for log4j for our environment. Because of the nature of extending log4j, I was unable to completely remove all log4j classes from this project's API. Its dependencies look like: log4j log4j Project logging is a front-end for logging which has no reference to log4j in its API (the intent is to be able to change to another logging framework in the future and not have to change every bit of our code). Its dependencies look like: qaccess log4jext Project war is a servlet I am going to build which will use the logging environment. It should depend only on the logging project's artifact. The top-level project has the following in its POM: qaccess log4jext 3.0-SNAPSHOT jar provided log4j log4j 1.2.6 jar provided Since there are going to be several servlets which use this logging environment, I am going to place the log4j, log4jext, and logging jars in the app server's system classpath so that they are available to all servlets without requiring them to be packaged into the war file. With things as they are configured now, the logging project compiles successfully, even though it does not list a dependency for the required log4j library (I assume that is because the compile-time scope is inherited from the log4jext project). When I try to build the JavaDocs, though, I get a large number of errors since the log4j library is not made available at that time. What is the correct scope to make this work (or do I need to explicitly state the dependency on log4j in the logging project)? Is this configured properly so that the log4j and log4jext jars won't get packaged into the war file? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
