[MNG-2496] dependencyManagement not used for dependencies in plugin section.

[jira-importer]

Brian E Fox opened MNG-2496 and commented

In my parent, I have a dependencyManagement set with this jar:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>com.stchome.build.maven</groupId>
<artifactId>testng-initializer</artifactId>
<version>1.0</version>
<scope>test</scope>
</dependency>

I have a plugin specified that had a dependency like this:
<plugin>
<artifactId>maven-antrun-plugin</artifactId>
<executions>
<execution>
<id>run-testng</id>
<phase>test</phase>
<configuration>
<tasks>
<java classname="com.stchome.testng.initializer.PackageInitializer">
<arg path="${project.build.testOutputDirectory}"/>
<arg path="${project.build.testSourceDirectory}"/>
</java>
<ant antfile="run-testng.xml" inheritRefs="true" inheritAll="true">
<property name="target.dir" value="${project.build.directory}"/>
<property name="test-classes.dir" value="${project.build.testOutputDirectory}"/>
<property name="test-source.dir" value="${project.build.testSourceDirectory}"/>
</ant>
</tasks>
</configuration>
<goals>
<goal>run</goal>
</goals>
</execution>
</executions>
<dependencies>
<dependency>
<groupId>com.stchome.build.maven</groupId>
<artifactId>testng-initializer</artifactId>
</dependency>
</dependencies>
</plugin>

When I build, it doesn't seem to resolve this dependency version from dependencyManagement

[INFO] An invalid artifact was detected.

This artifact might be in your project's POM, or it might have been included transitively du
information we do have for this artifact:

o GroupID:     com.stchome.build.maven
o ArtifactID:  testng-initializer
o Version:     <<< MISSING >>>
o Type:        jar

[INFO] ------------------------------------------------------------------------
[INFO] Trace
org.apache.maven.artifact.InvalidArtifactRTException: For artifact {com.stchome.build.maven:
n cannot be empty.
at org.apache.maven.artifact.DefaultArtifact.validateIdentity(DefaultArtifact.java:1
at org.apache.maven.artifact.DefaultArtifact.<init>(DefaultArtifact.java:119)
at org.apache.maven.artifact.factory.DefaultArtifactFactory.createArtifact(DefaultAr
at org.apache.maven.artifact.factory.DefaultArtifactFactory.createDependencyArtifact
at org.apache.maven.project.artifact.MavenMetadataSource.createArtifacts(MavenMetada
at org.apache.maven.plugin.DefaultPluginManager.addPlugin(DefaultPluginManager.java:
at org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin(DefaultPluginM
at org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPluginManager.ja
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(DefaultLifecycle
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindPluginToLifecycle(Default
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycleMappings(De
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleE
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLi
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecu
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java
at java.lang.reflect.Method.invoke(Method.java:324)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)

---

Affects: 2.0.4

Issue Links:

• MNG-2172 <dependencyManagement><dependency><version>'s are not used when evaluating <plugin><dependencies><dependency>

Remote Links:

• GitHub Pull Request #500
  

0 votes, 8 watchers

[jira-importer]

Jason van Zyl commented

The depMan section should not be used for plugin or for extensions. You could pull in versions of dependencies that would cause plugins or extensions to fail.

Case in point is MNG-2934 where commons-httpclient was put in depMan and it pulled in an incompatible version which caused the webdav deployment to fail. The resolution for projects, extensions, and plugins should be fully partitioned.

[jira-importer]

Adam Gent commented

Jason van Zyl We are having an issue with plugins depending on Eclipse JDT: https://repo1.maven.org/maven2/org/eclipse/jdt/org.eclipse.jdt.core/3.13.102/org.eclipse.jdt.core-3.13.102.pom

which uses version ranges.

If the plugin authors do not declare all the dependencies for Eclipse JDT in the dependencyManagement section (in the plugin pom) then mvn \-U will fetch all of the maven-metadata.xml for the Eclipse dependencies every time even if the downstream non plugin projects declare all the dependencies in either the plugins dependencies section or dependencyManagement section.

Specific example is the maven eclipse formatter project. Here is the projects issue: revelc/formatter-maven-plugin#301 (comment)

[jira-importer]

Christopher Tubbs commented

To be fair, overriding the plugin's dependency versions within the plugin declaration itself does work.... it just downloads some unnecessary metadata to resolve version ranges first, before promptly ignoring all that it just downloaded and using the override version anyway.

[jira-importer]

Jörg Hohwiller commented

Sorry to come here late but IMHO the argument given by Jason van Zyl is not convincing or even valid:
The actual request is being able to omit the version of a dependency inside a plugin declarion. This is currently not supported and from a users PoV this seems like a natural feature request.
If that feature would be used the omitted dependency version would be taken from the dependencyManagement. Indeed when using this feature some projects may end up in situations where they have a version V configured for a dependency D in their dependencyManagement and then some child module M1 adds a dependency to D and another module M2 adds dependency to D in a plugin P and this combination would clash as maybe the plugin P is not compatible with D in version V. But to be fair one would have to see that the same problem can also happen in M2 if it uses D as a regular dependency so what should be plugin specific about this problem?

Could this be reconsidered for maven 4.x? There are some major changes in Maven 4.x anyway and still I do not see any incompatibility when introducing this feature since earlier versions would just fail if the version is omitted.

[jira-importer]

Tamas Cservenak commented

I am unsure what scenario would require "omit the version of dependency" from plugin... Could you provide some example?

I keep "plugin uses range" as invalid example, as plugins should not depend on range (or if something downstream does, should be fixed it in plugin project). But to fix it, one can declare in build/plugins/plugin/dependencies a direct dependency to fixed version, that would simply "push" the deeper one to become loser and not used.

[jira-importer]

Jörg Hohwiller commented

I am unsure what scenario would require "omit the version of dependency" from plugin...

It is the same why dependencyManagement exists at all:
In complex multi-module projects you want to centralize dependencies/versions to establish some governance and simplify updates that can be made in a central place.
So the example would be that I use a cross-cutting library say "commons-lang3" and I need this as dependency in 3 different child POMs.
So instead of putting the version redundantly in those 3 places, I just want to have it in my top-level parent POM in the dependencyManagement what is exactly the idea why maven introduced this element to the POM model.

So either maven should argue that the dependencyManagement element should be dropped from the POM model or if it is present, then the behavior and feature should be available to all dependencies no matter if a plugin or a project dependency. Everything else is inconsistent and not intuitive.
Please be aware that nowadays developers are dealing with security updates daily due to tons of CVEs flooding us. So I need to make it as simple as possible to update from x.y.z to x.y.(z+1).

[jira-importer]

Tamas Cservenak commented

I am still with jvz that resolution of projects, extensions and plugins should be fully partitioned. They should not be mixed at all, a "project dependency" and a "plugin dependency", even if physically maybe some file (ie. slf4j-api JAR), are NOT to be mixed up across contexts.

dependencyManagement is for (project) dependencies, while plugins are not dependencies. I'd maybe argue that "we need a pluginDependencyManagement" instead?

For log4shell-like problems (where given artifact is BAD, and there is GOOD drop in replacement), things like this can be used MNG-7959 (naturally, in Maven4).

[jira-importer]

Jörg Hohwiller commented

I am still with jvz that resolution of projects, extensions and plugins should be fully partitioned. They should not be mixed at all, a "project dependency" and a "plugin dependency", even if physically maybe some file (ie. slf4j-api JAR), are NOT to be mixed up across contexts.

dependencyManagement is for (project) dependencies, while plugins are not dependencies. I'd maybe argue that "we need a pluginDependencyManagement" instead?

IMHO there is a miss-understanding in what different people are trying to argue.

My PoV is that if and only if I manually add a dependency to a plugin and I omit the version of that dependency in my project POM then the version of that dependency should come from the dependencyManagement and nothing else.

Nobody is saying that my dependencyManagement  is "magically" taking influence on the dependencies of any plugins or overriding dependency versions that a plugin author has defined for his plugin. If something is problematic then it is that projects can define dependencies for plugins from the outside in at all. However, this is giving flexibility and has established some reasonable use-cases in the maven ecosystem. With it comes some responsibility since obviously I can easily break things with it (and that has nothing to do with the demand discussed in this story).

As I write a dependency element into the plugin  element which argument should say that if I take the omitted version from the dependencyManagement that this is...

1. not intuitive?
2. not consistent?
3. not backward compatbile?
4. risky?

For 1 and 2: Whenever I have a dependency  anywhere in my POM and I omitt the version, I explicitly say that the version should be taken from {}dependencyManagement{}. This feature makes sense for any dependency no matter where in my POM I define it.

For 3: Currently inside a plugin I can't define a dependency without specifying a version. So nothing can break for existing projects if this new feature is introduced in Maven 4.x

For 4: Users have mutliple ways to manage dependency versisons: I can explicitly specify it, I can use a variable or I can entirely omit it using dependencyManagement. Already I can do things better or worse in maven and there is not always a silver bullet for everything.

Sorry, if it may sound frank but IMHO you are ignoring and blocking an intuitive and obvious demand of your users with no serious reason. To me this sounds like what Oracle did for decades to argue that no boolean datatype is needed: https://asktom.oracle.com/ords/asktom.search?tag=boolean-datatype

[jira-importer]

Christopher Tubbs commented

Jörg Hohwiller wrote:

Nobody is saying that my dependencyManagement is "magically" taking influence on the dependencies of any plugins or overriding dependency versions that a plugin author has defined for his plugin.

Currently, that is kind of how dependencyManagement works for regular dependencies, though. The managed version affects not only explicitly declared dependencies, but also implicit/transitive ones. I suppose it could be very strange for a managed dependency version to influence a transitive dependency of a plugin, when that was probably never intended.

One alternative would be to create a new dependencyManagement element under the pluginManagement element (and support import scope/BOM, etc.). This would allow plugin dependencies to be centrally managed, albeit with some redundancy when a managed plugin dependency is also a managed project dependency.

[jira-importer]

Tamas Cservenak commented

project deps and project plugin deps are two completely separate "classpaths". And as Christopher says, your project uses latest jackson, while a plugin you use wants older... that would lead to explosion.

[jira-importer]

Jörg Hohwiller commented

Christopher Tubbs thanks for clarification. I am using maven for 2 decades but never noticed this effect in detail.

Thanks for clarification. I guess after reading the discussions here that I was not the only one having this miss-understanding so great that this is now clear.

Now I fully understand the PoV why this feature is not planned as implied.

So an alternative could be to consider dependencyManagement only if version is omitted and then take that version from depMgmt and nothing else for plugins or as you suggested to define a new element for it if you prefer.

I personally would suggest to use existing dependencyManagement but only to fill in a potentially omitted version of a plugin dependnecy and nothing else (so dependencyManagement has not impact on plugins classworld by itself at all, nothing existing can break, etc.).

Would be simple, not require a big model change and make sense from most end-user perspective. But just my PoV.