[
https://issues.apache.org/jira/browse/MNG-2496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17902196#comment-17902196
]
Jörg Hohwiller edited comment on MNG-2496 at 12/2/24 8:39 AM:
--------------------------------------------------------------
{quote}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?
{quote}
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...
# not intuitive?
# not consistent?
# not backward compatbile?
# 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]
was (Author: hohwille):
{quote}
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?
{quote}
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...
# not intuitive?
# not consistent?
# not backward compatbile?
# 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: Unsers 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
> dependencyManagement not used for dependencies in plugin section.
> -----------------------------------------------------------------
>
> Key: MNG-2496
> URL: https://issues.apache.org/jira/browse/MNG-2496
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
> Affects Versions: 2.0.4
> Reporter: Brian E Fox
> Priority: Major
>
> 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)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
