[jira] [Updated] (MJAVADOC-794) Taglet autodetection fails when taglets JAR includes a module-info.class
[
https://issues.apache.org/jira/browse/MJAVADOC-794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Curtis Rueden updated MJAVADOC-794:
---
Description:
Due to a bug in the maven-javadoc-plugin, the following warning gets emitted
when a JPMS-modularized artifact containing taglets is included in the javadoc
build via a `` tag:
{{ [WARNING] Unable to auto-detect Taglet class names from}}
{{ '/path/to/jar.jar'. Try to specify them with .}}
Running with `mvn -X` shows the underlying cause:
{{ NoClassDefFoundError: module-info is not a}}
{{ class because access_flag ACC_MODULE is set}}
Removing the {{module-info.java}} from the component avoids the problem.
The following patch fixes the problem as of {{{}ded56a90{}}}:
{{diff --git a/src/main/java/org/apache/maven/plugins/javadoc/JavadocUtil.java
b/src/main/java/org/apache/maven/plugins/ja>}}
{{index 835d6332..6e29eadf 100644}}
{{--- a/src/main/java/org/apache/maven/plugins/javadoc/JavadocUtil.java}}
{{+++ b/src/main/java/org/apache/maven/plugins/javadoc/JavadocUtil.java}}
{{@@ -904,6 +904,9 @@ public class JavadocUtil {}}
{{ for (JarEntry jarEntry = jarStream.getNextJarEntry();}}
{{ jarEntry != null;}}
{{ jarEntry = jarStream.getNextJarEntry()) {}}
{{+ if ("module-info.class".equals(jarEntry.getName())) {}}
{{+ continue;}}
{{+ }}}
{{ Matcher matcher = pattern.matcher(jarEntry.getName());}}
{{ if (matcher.matches()) {}}
{{ String version = matcher.group("v");}}
was:
Due to a bug in the maven-javadoc-plugin, the following warning gets emitted
with a JPMS-modularized artifact containing taglets is included in the javadoc
build via a `` tag:
{{ [WARNING] Unable to auto-detect Taglet class names from}}
{{ '/path/to/jar.jar'. Try to specify them with .}}
Running with `mvn -X` shows the underlying cause:
{{ NoClassDefFoundError: module-info is not a}}
{{ class because access_flag ACC_MODULE is set}}
Removing the {{module-info.java}} from the component avoids the problem.
The following patch fixes the problem as of {{{}ded56a90{}}}:
{{diff --git a/src/main/java/org/apache/maven/plugins/javadoc/JavadocUtil.java
b/src/main/java/org/apache/maven/plugins/ja>}}
{{index 835d6332..6e29eadf 100644}}
{{--- a/src/main/java/org/apache/maven/plugins/javadoc/JavadocUtil.java}}
{{+++ b/src/main/java/org/apache/maven/plugins/javadoc/JavadocUtil.java}}
{{@@ -904,6 +904,9 @@ public class JavadocUtil {}}
{{ for (JarEntry jarEntry = jarStream.getNextJarEntry();}}
{{ jarEntry != null;}}
{{ jarEntry = jarStream.getNextJarEntry()) {}}
{{+ if ("module-info.class".equals(jarEntry.getName())) {}}
{{+ continue;}}
{{+ }}}
{{ Matcher matcher = pattern.matcher(jarEntry.getName());}}
{{ if (matcher.matches()) {}}
{{ String version = matcher.group("v");}}
> Taglet autodetection fails when taglets JAR includes a module-info.class
>
>
> Key: MJAVADOC-794
> URL: https://issues.apache.org/jira/browse/MJAVADOC-794
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 3.6.3
>Reporter: Curtis Rueden
>Priority: Major
>
> Due to a bug in the maven-javadoc-plugin, the following warning gets emitted
> when a JPMS-modularized artifact containing taglets is included in the
> javadoc build via a `` tag:
> {{ [WARNING] Unable to auto-detect Taglet class names from}}
> {{ '/path/to/jar.jar'. Try to specify them with .}}
> Running with `mvn -X` shows the underlying cause:
> {{ NoClassDefFoundError: module-info is not a}}
> {{ class because access_flag ACC_MODULE is set}}
> Removing the {{module-info.java}} from the component avoids the problem.
> The following patch fixes the problem as of {{{}ded56a90{}}}:
> {{diff --git
> a/src/main/java/org/apache/maven/plugins/javadoc/JavadocUtil.java
> b/src/main/java/org/apache/maven/plugins/ja>}}
> {{index 835d6332..6e29eadf 100644}}
> {{--- a/src/main/java/org/apache/maven/plugins/javadoc/JavadocUtil.java}}
> {{+++ b/src/main/java/org/apache/maven/plugins/javadoc/JavadocUtil.java}}
> {{@@ -904,6 +904,9 @@ public class JavadocUtil {}}
> {{ for (JarEntry jarEntry = jarStream.getNextJarEntry();}}
> {{ jarEntry != null;}}
> {{ jarEntry = jarStream.getNextJarEntry()) {}}
> {{+ if ("module-info.class".equals(jarEntry.getName())) {}}
> {{+ continue;}}
> {{+ }}}
> {{ Matcher matcher = pattern.matcher(jarEntry.getName());}}
> {{ if (matcher.matches()) {}}
> {{
[jira] [Updated] (MJAVADOC-794) Taglet autodetection fails when taglets JAR includes a module-info.class
[
https://issues.apache.org/jira/browse/MJAVADOC-794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Curtis Rueden updated MJAVADOC-794:
---
Description:
Due to a bug in the maven-javadoc-plugin, the following warning gets emitted
when a JPMS-modularized artifact containing taglets is included in the javadoc
build via a `` tag:
{{ [WARNING] Unable to auto-detect Taglet class names from}}
{{ '/path/to/jar.jar'. Try to specify them with .}}
Running with {{mvn -X}} shows the underlying cause:
{{ NoClassDefFoundError: module-info is not a}}
{{ class because access_flag ACC_MODULE is set}}
Removing the {{module-info.java}} from the component avoids the problem.
The following patch fixes the problem as of {{{}ded56a90{}}}:
{{diff --git a/src/main/java/org/apache/maven/plugins/javadoc/JavadocUtil.java
b/src/main/java/org/apache/maven/plugins/ja>}}
{{index 835d6332..6e29eadf 100644}}
{{--- a/src/main/java/org/apache/maven/plugins/javadoc/JavadocUtil.java}}
{{+++ b/src/main/java/org/apache/maven/plugins/javadoc/JavadocUtil.java}}
{{@@ -904,6 +904,9 @@ public class JavadocUtil {}}
{{ for (JarEntry jarEntry = jarStream.getNextJarEntry();}}
{{ jarEntry != null;}}
{{ jarEntry = jarStream.getNextJarEntry()) {}}
{{+ if ("module-info.class".equals(jarEntry.getName())) {}}
{{+ continue;}}
{{+ }}}
{{ Matcher matcher = pattern.matcher(jarEntry.getName());}}
{{ if (matcher.matches()) {}}
{{ String version = matcher.group("v");}}
was:
Due to a bug in the maven-javadoc-plugin, the following warning gets emitted
when a JPMS-modularized artifact containing taglets is included in the javadoc
build via a `` tag:
{{ [WARNING] Unable to auto-detect Taglet class names from}}
{{ '/path/to/jar.jar'. Try to specify them with .}}
Running with `mvn -X` shows the underlying cause:
{{ NoClassDefFoundError: module-info is not a}}
{{ class because access_flag ACC_MODULE is set}}
Removing the {{module-info.java}} from the component avoids the problem.
The following patch fixes the problem as of {{{}ded56a90{}}}:
{{diff --git a/src/main/java/org/apache/maven/plugins/javadoc/JavadocUtil.java
b/src/main/java/org/apache/maven/plugins/ja>}}
{{index 835d6332..6e29eadf 100644}}
{{--- a/src/main/java/org/apache/maven/plugins/javadoc/JavadocUtil.java}}
{{+++ b/src/main/java/org/apache/maven/plugins/javadoc/JavadocUtil.java}}
{{@@ -904,6 +904,9 @@ public class JavadocUtil {}}
{{ for (JarEntry jarEntry = jarStream.getNextJarEntry();}}
{{ jarEntry != null;}}
{{ jarEntry = jarStream.getNextJarEntry()) {}}
{{+ if ("module-info.class".equals(jarEntry.getName())) {}}
{{+ continue;}}
{{+ }}}
{{ Matcher matcher = pattern.matcher(jarEntry.getName());}}
{{ if (matcher.matches()) {}}
{{ String version = matcher.group("v");}}
> Taglet autodetection fails when taglets JAR includes a module-info.class
>
>
> Key: MJAVADOC-794
> URL: https://issues.apache.org/jira/browse/MJAVADOC-794
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 3.6.3
>Reporter: Curtis Rueden
>Priority: Major
>
> Due to a bug in the maven-javadoc-plugin, the following warning gets emitted
> when a JPMS-modularized artifact containing taglets is included in the
> javadoc build via a `` tag:
> {{ [WARNING] Unable to auto-detect Taglet class names from}}
> {{ '/path/to/jar.jar'. Try to specify them with .}}
> Running with {{mvn -X}} shows the underlying cause:
> {{ NoClassDefFoundError: module-info is not a}}
> {{ class because access_flag ACC_MODULE is set}}
> Removing the {{module-info.java}} from the component avoids the problem.
> The following patch fixes the problem as of {{{}ded56a90{}}}:
> {{diff --git
> a/src/main/java/org/apache/maven/plugins/javadoc/JavadocUtil.java
> b/src/main/java/org/apache/maven/plugins/ja>}}
> {{index 835d6332..6e29eadf 100644}}
> {{--- a/src/main/java/org/apache/maven/plugins/javadoc/JavadocUtil.java}}
> {{+++ b/src/main/java/org/apache/maven/plugins/javadoc/JavadocUtil.java}}
> {{@@ -904,6 +904,9 @@ public class JavadocUtil {}}
> {{ for (JarEntry jarEntry = jarStream.getNextJarEntry();}}
> {{ jarEntry != null;}}
> {{ jarEntry = jarStream.getNextJarEntry()) {}}
> {{+ if ("module-info.class".equals(jarEntry.getName())) {}}
> {{+ continue;}}
> {{+ }}}
> {{ Matcher matcher = pattern.matcher(jarEntry.getName());}}
> {{ if (matcher.matches()) {}}
> {{
[jira] [Updated] (MJAVADOC-794) Taglet autodetection fails when taglets JAR includes a module-info.class
[
https://issues.apache.org/jira/browse/MJAVADOC-794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Curtis Rueden updated MJAVADOC-794:
---
Description:
Due to a bug in the maven-javadoc-plugin, the following warning gets emitted
with a JPMS-modularized artifact containing taglets is included in the javadoc
build via a `` tag:
{{ [WARNING] Unable to auto-detect Taglet class names from}}
{{ '/path/to/jar.jar'. Try to specify them with .}}
Running with `mvn -X` shows the underlying cause:
{{ NoClassDefFoundError: module-info is not a}}
{{ class because access_flag ACC_MODULE is set}}
Removing the {{module-info.java}} from the component avoids the problem.
The following patch fixes the problem as of {{{}ded56a90{}}}:
{{diff --git a/src/main/java/org/apache/maven/plugins/javadoc/JavadocUtil.java
b/src/main/java/org/apache/maven/plugins/ja>}}
{{index 835d6332..6e29eadf 100644}}
{{--- a/src/main/java/org/apache/maven/plugins/javadoc/JavadocUtil.java}}
{{+++ b/src/main/java/org/apache/maven/plugins/javadoc/JavadocUtil.java}}
{{@@ -904,6 +904,9 @@ public class JavadocUtil {}}
{{ for (JarEntry jarEntry = jarStream.getNextJarEntry();}}
{{ jarEntry != null;}}
{{ jarEntry = jarStream.getNextJarEntry()) {}}
{{+ if ("module-info.class".equals(jarEntry.getName())) {}}
{{+ continue;}}
{{+ }}}
{{ Matcher matcher = pattern.matcher(jarEntry.getName());}}
{{ if (matcher.matches()) {}}
{{ String version = matcher.group("v");}}
was:
Due to a bug in the maven-javadoc-plugin, the following warning gets
emitted with the scijava-taglets artifact included in the javadoc build:
[WARNING] Unable to auto-detect Taglet class names from
'/path/to/jar.jar'. Try to specify them with .
Running with `mvn -X` shows the underlying cause:
NoClassDefFoundError: module-info is not a
class because access_flag ACC_MODULE is set
Removing scijava-taglets's module-info.java avoids the problem.
> Taglet autodetection fails when taglets JAR includes a module-info.class
>
>
> Key: MJAVADOC-794
> URL: https://issues.apache.org/jira/browse/MJAVADOC-794
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 3.6.3
>Reporter: Curtis Rueden
>Priority: Major
>
> Due to a bug in the maven-javadoc-plugin, the following warning gets emitted
> with a JPMS-modularized artifact containing taglets is included in the
> javadoc build via a `` tag:
> {{ [WARNING] Unable to auto-detect Taglet class names from}}
> {{ '/path/to/jar.jar'. Try to specify them with .}}
> Running with `mvn -X` shows the underlying cause:
> {{ NoClassDefFoundError: module-info is not a}}
> {{ class because access_flag ACC_MODULE is set}}
> Removing the {{module-info.java}} from the component avoids the problem.
> The following patch fixes the problem as of {{{}ded56a90{}}}:
> {{diff --git
> a/src/main/java/org/apache/maven/plugins/javadoc/JavadocUtil.java
> b/src/main/java/org/apache/maven/plugins/ja>}}
> {{index 835d6332..6e29eadf 100644}}
> {{--- a/src/main/java/org/apache/maven/plugins/javadoc/JavadocUtil.java}}
> {{+++ b/src/main/java/org/apache/maven/plugins/javadoc/JavadocUtil.java}}
> {{@@ -904,6 +904,9 @@ public class JavadocUtil {}}
> {{ for (JarEntry jarEntry = jarStream.getNextJarEntry();}}
> {{ jarEntry != null;}}
> {{ jarEntry = jarStream.getNextJarEntry()) {}}
> {{+ if ("module-info.class".equals(jarEntry.getName())) {}}
> {{+ continue;}}
> {{+ }}}
> {{ Matcher matcher = pattern.matcher(jarEntry.getName());}}
> {{ if (matcher.matches()) {}}
> {{ String version = matcher.group("v");}}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MJAVADOC-794) Taglet autodetection fails when taglets JAR includes a module-info.class
[ https://issues.apache.org/jira/browse/MJAVADOC-794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Curtis Rueden updated MJAVADOC-794: --- Affects Version/s: 3.6.3 > Taglet autodetection fails when taglets JAR includes a module-info.class > > > Key: MJAVADOC-794 > URL: https://issues.apache.org/jira/browse/MJAVADOC-794 > Project: Maven Javadoc Plugin > Issue Type: Bug >Affects Versions: 3.6.3 >Reporter: Curtis Rueden >Priority: Major > > Due to a bug in the maven-javadoc-plugin, the following warning gets > emitted with the scijava-taglets artifact included in the javadoc build: > [WARNING] Unable to auto-detect Taglet class names from > '/path/to/jar.jar'. Try to specify them with . > Running with `mvn -X` shows the underlying cause: > NoClassDefFoundError: module-info is not a > class because access_flag ACC_MODULE is set > Removing scijava-taglets's module-info.java avoids the problem. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MJAVADOC-794) Taglet autodetection fails when taglets JAR includes a module-info.class
[ https://issues.apache.org/jira/browse/MJAVADOC-794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Curtis Rueden updated MJAVADOC-794: --- Description: Due to a bug in the maven-javadoc-plugin, the following warning gets emitted with the scijava-taglets artifact included in the javadoc build: [WARNING] Unable to auto-detect Taglet class names from '/path/to/jar.jar'. Try to specify them with . Running with `mvn -X` shows the underlying cause: NoClassDefFoundError: module-info is not a class because access_flag ACC_MODULE is set Removing scijava-taglets's module-info.java avoids the problem. > Taglet autodetection fails when taglets JAR includes a module-info.class > > > Key: MJAVADOC-794 > URL: https://issues.apache.org/jira/browse/MJAVADOC-794 > Project: Maven Javadoc Plugin > Issue Type: Bug >Reporter: Curtis Rueden >Priority: Major > > Due to a bug in the maven-javadoc-plugin, the following warning gets > emitted with the scijava-taglets artifact included in the javadoc build: > [WARNING] Unable to auto-detect Taglet class names from > '/path/to/jar.jar'. Try to specify them with . > Running with `mvn -X` shows the underlying cause: > NoClassDefFoundError: module-info is not a > class because access_flag ACC_MODULE is set > Removing scijava-taglets's module-info.java avoids the problem. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MJAVADOC-794) Taglet autodetection fails when taglets JAR includes a module-info.class
Curtis Rueden created MJAVADOC-794: -- Summary: Taglet autodetection fails when taglets JAR includes a module-info.class Key: MJAVADOC-794 URL: https://issues.apache.org/jira/browse/MJAVADOC-794 Project: Maven Javadoc Plugin Issue Type: Bug Reporter: Curtis Rueden -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MDEP-390) org.apache.maven.plugins:maven-dependency-plugin:unpack to support remoteRepositories
[
https://issues.apache.org/jira/browse/MDEP-390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17624770#comment-17624770
]
Curtis Rueden commented on MDEP-390:
This is still an issue:
{noformat}
$ mvn -v
Maven home: /usr/local/Cellar/maven/3.8.6/libexec
Java version: 1.8.0_322, vendor: Azul Systems, Inc., runtime:
/Users/curtis/Java/macos/zulu-fx-8u322/zulu-8.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "10.16", arch: "x86_64", family: "mac"
$ mvn dependency:get \
-DremoteRepositories=scijava.publichttps://maven.scijava.org/content/groups/public
\
-Dartifact="org.scijava:scijava-cache:0.1.2"
[INFO] Scanning for projects...
[INFO]
[INFO] --< org.apache.maven:standalone-pom >---
[INFO] Building Maven Stub Project (No POM) 1
[INFO] [ pom ]-
[INFO]
[INFO] --- maven-dependency-plugin:2.8:get (default-cli) @ standalone-pom ---
[INFO] Resolving org.scijava:scijava-cache:jar:0.1.2 with transitive
dependencies
Downloading from central:
https://repo.maven.apache.org/maven2/org/scijava/scijava-cache/0.1.2/scijava-cache-0.1.2.pom
Downloading from scijava.public:
https://maven.scijava.org/content/groups/public/org/scijava/scijava-cache/0.1.2/scijava-cache-0.1.2.pom
Downloaded from scijava.public:
https://maven.scijava.org/content/groups/public/org/scijava/scijava-cache/0.1.2/scijava-cache-0.1.2.pom
(3.1 kB at 8.6 kB/s)
Downloading from central:
https://repo.maven.apache.org/maven2/org/scijava/scijava-cache/0.1.2/scijava-cache-0.1.2.jar
Downloading from scijava.public:
https://maven.scijava.org/content/groups/public/org/scijava/scijava-cache/0.1.2/scijava-cache-0.1.2.jar
Downloaded from scijava.public:
https://maven.scijava.org/content/groups/public/org/scijava/scijava-cache/0.1.2/scijava-cache-0.1.2.jar
(4.1 kB at 255 kB/s)
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 1.590 s
[INFO] Finished at: 2022-10-26T16:40:42-05:00
[INFO]
$ rm -rf ~/.m2/repository/org/scijava/scijava-cache
$ mvn dependency:unpack \
-DremoteRepositories=scijava.publichttps://maven.scijava.org/content/groups/public
\
-Dartifact="org.scijava:scijava-cache:0.1.2" \
-DoutputDirectory=.
[INFO] Scanning for projects...
[INFO]
[INFO] --< org.apache.maven:standalone-pom >---
[INFO] Building Maven Stub Project (No POM) 1
[INFO] [ pom ]-
[INFO]
[INFO] --- maven-dependency-plugin:2.8:unpack (default-cli) @ standalone-pom ---
[INFO] Configured Artifact: org.scijava:scijava-cache:0.1.2:jar
Downloading from central:
https://repo.maven.apache.org/maven2/org/scijava/scijava-cache/0.1.2/scijava-cache-0.1.2.jar
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 1.130 s
[INFO] Finished at: 2022-10-26T16:40:21-05:00
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-dependency-plugin:2.8:unpack (default-cli) on
project standalone-pom: Unable to find artifact.: Could not find artifact
org.scijava:scijava-cache:jar:0.1.2 in central
(https://repo.maven.apache.org/maven2)
...
{noformat}
Happens also with the {{copy}} mojo.
> org.apache.maven.plugins:maven-dependency-plugin:unpack to support
> remoteRepositories
> -
>
> Key: MDEP-390
> URL: https://issues.apache.org/jira/browse/MDEP-390
> Project: Maven Dependency Plugin
> Issue Type: Improvement
> Components: unpack
>Affects Versions: 2.5.1
>Reporter: Mickael Istria
>Priority: Major
>
> As a user, I'd like to download a Maven artifact from command-line and get it
> unzipped.
> In order to use the maven-depdenceny-plugin:goal as the ultimate command-line
> client to download a maven artifact (not necessarly in the context of a
> project), it would be useful to add to it an "unpack" parameter that would
> allow to unpack the just-downloaded stuff.
> When in comes to automating download+unzip of an artifact in CI:
> Currently, one has to add a Shell or Ant or Groovy script to unzip, after
> using "mvn org.apache.maven.plugins:maven-dependency-plugin:2.5.1:get
> -Dartifact=blah:blah:1.0 -DremoteRepositories=http://somewhere;. It's not
> very convenient as this requires usage of another Ant or Groovy file, or
> usage
[jira] [Commented] (WAGON-616) Deprecate Wagon SSH Provider
[
https://issues.apache.org/jira/browse/WAGON-616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522858#comment-17522858
]
Curtis Rueden commented on WAGON-616:
-
Ah, thank you, I understand now that sshexe and scpexe mean wagon-ssh-external,
as explained in the [Deployment of artifacts in an external SSH
command|https://maven.apache.org/plugins/maven-deploy-plugin/examples/deploy-ssh-external.html]
guide. Thank you for your patience, and the helpful links!
I have now updated [my SO answer|https://stackoverflow.com/a/14404990/1207769]
to explain the current situation, as well as mentioning Apache Mina SSHD as a
potential way forward in the future. Please feel free to edit the answer if I
got anything wrong, and/or correct me here on this comment thread.
> Deprecate Wagon SSH Provider
>
>
> Key: WAGON-616
> URL: https://issues.apache.org/jira/browse/WAGON-616
> Project: Maven Wagon
> Issue Type: Task
> Components: wagon-ssh
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.5.0
>
>
> This provider has serious implications and implementation issues:
> - JSch http://www.jcraft.com/jsch/ failed to provide a source repository,
> accept contributions and address issues.
> - Too complex and low level.
> - It is disputed whether this is open source at all.
> The sshexe ({{scp}}) provider remains until someone wants to write something
> on top of Apache MINA SSHD.
> We are deprecating this provider to be removed in 4.0.0.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (WAGON-616) Deprecate Wagon SSH Provider
[
https://issues.apache.org/jira/browse/WAGON-616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17515446#comment-17515446
]
Curtis Rueden commented on WAGON-616:
-
[~michael-o] Thank you very much for your reply! I deeply sympathize with the
burdens of maintainership, and I thank you from the bottom of my heart for your
service to the open source community. I hope my message did not come across as
accusatory or critical. I just honestly do not understand what the currently
recommended approach is for using wagon with SSH/SCP right now. What is "the
sshexe (scp) provider"? I tried to find it, but failed. Sorry if I'm being dumb
here, but I am trying to maintain [my SO answer about
wagon+SCP|https://stackoverflow.com/a/14404990/1207769], and I do not know what
to try next. Given Maven's sparse documentation, I think SO ends up helping a
lot of people figure out how to actually do stuff with it in practice, and I'm
trying to be part of that solution. I just need a little guidance: a pointer to
documentation or example somewhere?
> Deprecate Wagon SSH Provider
>
>
> Key: WAGON-616
> URL: https://issues.apache.org/jira/browse/WAGON-616
> Project: Maven Wagon
> Issue Type: Task
> Components: wagon-ssh
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.5.0
>
>
> This provider has serious implications and implementation issues:
> - JSch http://www.jcraft.com/jsch/ failed to provide a source repository,
> accept contributions and address issues.
> - Too complex and low level.
> - It is disputed whether this is open source at all.
> The sshexe ({{scp}}) provider remains until someone wants to write something
> on top of Apache MINA SSHD.
> We are deprecating this provider to be removed in 4.0.0.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (WAGON-616) Deprecate Wagon SSH Provider
[
https://issues.apache.org/jira/browse/WAGON-616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17495080#comment-17495080
]
Curtis Rueden commented on WAGON-616:
-
The current status leaves the community rather lost in how to proceed. Comments
from the maintainers would be appreciated regarding:
* What the current recommended best practice is for transferring Maven
artifacts via SSH/SCP. For example: what is "the sshexe (scp) provider"? I
couldn't find it after a few web searches. Is there a guide anywhere on how to
use it?
* What about the JSch fork described in WAGON-613? Can this wagon provider not
simply switch to the fork, if the upstream JSch is concerning?
* Can you post links to discussions, e.g. mailing list threads in archives,
cluing us into the rationale behind this decision, and hopefully more details
on how to better move forward?
> Deprecate Wagon SSH Provider
>
>
> Key: WAGON-616
> URL: https://issues.apache.org/jira/browse/WAGON-616
> Project: Maven Wagon
> Issue Type: Task
> Components: wagon-ssh
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.5.0
>
>
> This provider has serious implications and implementation issues:
> - JSch http://www.jcraft.com/jsch/ failed to provide a source repository,
> accept contributions and address issues.
> - Too complex and low level.
> - It is disputed whether this is open source at all.
> The sshexe ({{scp}}) provider remains until someone wants to write something
> on top of Apache MINA SSHD.
> We are deprecating this provider to be removed in 4.0.0.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (MNG-7343) Document a working migration path away from LATEST and RELEASE metaversions
[
https://issues.apache.org/jira/browse/MNG-7343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17466593#comment-17466593
]
Curtis Rueden edited comment on MNG-7343 at 12/29/21, 8:57 PM:
---
> Can you share concrete other examples, please?
Sure! Here is one use case:
[https://github.com/scijava/jgo#readme]
The jgo tool lets you launch Java code from remote Maven artifacts. For
example, you can run:
jgo org.python:jython-standalone
to launch the latest release version of the Jython REPL. Or:
jgo ome:bio-formats-tools:loci.formats.tools.ImageConverter
to launch the latest release version of the
[Bio-Formats|https://www.openmicroscopy.org/bio-formats/] image conversion
tool. Or:
jgo com.github.kwart.jd:jd-cli
for the latest release version of the
[jd-cli|https://github.com/intoolswetrust/jd-cli] decompiler. Or:
jgo sc.fiji:fiji
for the latest release version of [Fiji|https://fiji.sc/].
All of the above examples implicitly use the RELEASE metaversion. While the
user can also specify an explicit version, often what they want is the latest
release, and jgo using RELEASE by default is very convenient. It would be
possible to replicate this behavior by digging through remote
maven-metadata.xml files, or using MojoHaus's versions-maven-plugin, but this
would add extra code and complexity, extra remote negotiation with every jgo
execution, and corresponding potential for extra bugs.
> And wan you precise which Jira issue is causing you that reaction?
I'm sorry, I don't understand the question. Are you asking if there is a Jira
issue corresponding to my statement: "in my tests, specifying a version range
like {{[0,)}} causes Maven to download POMs at a bunch of (maybe all?) versions
of an artifact, whereas {{LATEST}} and {{RELEASE}} do not trigger en masse
downloading."? Unfortunately, there is not a corresponding issue, as far as I
know. I could file one if it would be helpful.
was (Author: ctrueden):
> Can you share concrete other examples, please?
Sure! Here is one use case:
[https://github.com/scijava/jgo#readme]
The jgo tool lets you launch Java code from remote Maven artifacts. For
example, you can run:
jgo org.python:jython-standalone
to launch the latest release version of the Jython REPL. Or:
jgo ome:bio-formats-tools:loci.formats.tools.ImageConverter
to launch the latest release version of the
[Bio-Formats|https://www.openmicroscopy.org/bio-formats/] image conversion
tool. Or:
jgo com.github.kwart.jd:jd-cli
for the latest release version of the
[jd-cli|https://github.com/intoolswetrust/jd-cli] decompiler. Or:
jgo sc.fiji:fiji
for the latest release version of [Fiji|https://fiji.sc/].
All of the above examples implicitly use the `RELEASE` metaversion. While the
user can also specify an explicit version, often what they want is the latest
release, and jgo using `RELEASE` by default is very convenient. It would be
possible to replicate this behavior by digging through remote
`maven-metadata.xml` files, or using MojoHaus's versions-maven-plugin, but this
would add extra code and complexity, extra remote negotiation with every jgo
execution, and corresponding potential for extra bugs.
> And wan you precise which Jira issue is causing you that reaction?
I'm sorry, I don't understand the question. Are you asking if there is a Jira
issue corresponding to my statement: "in my tests, specifying a version range
like {{[0,)}} causes Maven to download POMs at a bunch of (maybe all?) versions
of an artifact, whereas {{LATEST}} and {{RELEASE}} do not trigger en masse
downloading."? Unfortunately, there is not a corresponding issue, as far as I
know. I could file one if it would be helpful.
> Document a working migration path away from LATEST and RELEASE metaversions
> ---
>
> Key: MNG-7343
> URL: https://issues.apache.org/jira/browse/MNG-7343
> Project: Maven
> Issue Type: Bug
>Reporter: Curtis Rueden
>Priority: Major
>
> I use LATEST and RELEASE a lot for various purposes, such as CLI tooling that
> automatically synthesizes POMs to perform various tasks. I personally feel
> deprecating these metaversions was a mistake—I find them incredibly useful,
> with the understanding that I would never use them for production
> reproducible builds. But I do understand the rationale: we don't want to
> encourage anyone to use these in a way that harms the stability of dependency
> resolution, reproducibility-wise. So I'm OK with it, as long as there is a
> migration path forward for these sorts of use cases.
> But what is that path? I cannot find a way to replicate either of the
> metaversion behaviors using version ranges. There are problems with version
> ranges (MNG-3092, MNG-6049)
[jira] [Commented] (MNG-7343) Document a working migration path away from LATEST and RELEASE metaversions
[
https://issues.apache.org/jira/browse/MNG-7343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17466593#comment-17466593
]
Curtis Rueden commented on MNG-7343:
> Can you share concrete other examples, please?
Sure! Here is one use case:
[https://github.com/scijava/jgo#readme]
The jgo tool lets you launch Java code from remote Maven artifacts. For
example, you can run:
jgo org.python:jython-standalone
to launch the latest release version of the Jython REPL. Or:
jgo ome:bio-formats-tools:loci.formats.tools.ImageConverter
to launch the latest release version of the
[Bio-Formats|https://www.openmicroscopy.org/bio-formats/] image conversion
tool. Or:
jgo com.github.kwart.jd:jd-cli
for the latest release version of the
[jd-cli|https://github.com/intoolswetrust/jd-cli] decompiler. Or:
jgo sc.fiji:fiji
for the latest release version of [Fiji|https://fiji.sc/].
All of the above examples implicitly use the `RELEASE` metaversion. While the
user can also specify an explicit version, often what they want is the latest
release, and jgo using `RELEASE` by default is very convenient. It would be
possible to replicate this behavior by digging through remote
`maven-metadata.xml` files, or using MojoHaus's versions-maven-plugin, but this
would add extra code and complexity, extra remote negotiation with every jgo
execution, and corresponding potential for extra bugs.
> And wan you precise which Jira issue is causing you that reaction?
I'm sorry, I don't understand the question. Are you asking if there is a Jira
issue corresponding to my statement: "in my tests, specifying a version range
like {{[0,)}} causes Maven to download POMs at a bunch of (maybe all?) versions
of an artifact, whereas {{LATEST}} and {{RELEASE}} do not trigger en masse
downloading."? Unfortunately, there is not a corresponding issue, as far as I
know. I could file one if it would be helpful.
> Document a working migration path away from LATEST and RELEASE metaversions
> ---
>
> Key: MNG-7343
> URL: https://issues.apache.org/jira/browse/MNG-7343
> Project: Maven
> Issue Type: Bug
>Reporter: Curtis Rueden
>Priority: Major
>
> I use LATEST and RELEASE a lot for various purposes, such as CLI tooling that
> automatically synthesizes POMs to perform various tasks. I personally feel
> deprecating these metaversions was a mistake—I find them incredibly useful,
> with the understanding that I would never use them for production
> reproducible builds. But I do understand the rationale: we don't want to
> encourage anyone to use these in a way that harms the stability of dependency
> resolution, reproducibility-wise. So I'm OK with it, as long as there is a
> migration path forward for these sorts of use cases.
> But what is that path? I cannot find a way to replicate either of the
> metaversion behaviors using version ranges. There are problems with version
> ranges (MNG-3092, MNG-6049) preventing them from being used as a replacement
> for LATEST or RELEASE. Furthermore, in my tests, specifying a version range
> like {{[0,)}} causes Maven to download POMs at a bunch of (maybe all?)
> versions of an artifact, whereas {{LATEST}} and {{RELEASE}} do not trigger en
> masse downloading.l
> Is there a non-deprecated syntax that has equivalent behavior? As things
> stand, I am concerned that support for these metaversions is going to
> disappear in a future version of Maven without a feasible migration path
> forward.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (MNG-7343) Document a working migration path away from LATEST and RELEASE metaversions
[
https://issues.apache.org/jira/browse/MNG-7343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Curtis Rueden updated MNG-7343:
---
Description:
I use LATEST and RELEASE a lot for various purposes, such as CLI tooling that
automatically synthesizes POMs to perform various tasks. I personally feel
deprecating these metaversions was a mistake—I find them incredibly useful,
with the understanding that I would never use them for production reproducible
builds. But I do understand the rationale: we don't want to encourage anyone to
use these in a way that harms the stability of dependency resolution,
reproducibility-wise. So I'm OK with it, as long as there is a migration path
forward for these sorts of use cases.
But what is that path? I cannot find a way to replicate either of the
metaversion behaviors using version ranges. There are problems with version
ranges (MNG-3092, MNG-6049) preventing them from being used as a replacement
for LATEST or RELEASE. Furthermore, in my tests, specifying a version range
like {{[0,)}} causes Maven to download POMs at a bunch of (maybe all?) versions
of an artifact, whereas {{LATEST}} and {{RELEASE}} do not trigger en masse
downloading.l
Is there a non-deprecated syntax that has equivalent behavior? As things stand,
I am concerned that support for these metaversions is going to disappear in a
future version of Maven without a feasible migration path forward.
> Document a working migration path away from LATEST and RELEASE metaversions
> ---
>
> Key: MNG-7343
> URL: https://issues.apache.org/jira/browse/MNG-7343
> Project: Maven
> Issue Type: Bug
>Reporter: Curtis Rueden
>Priority: Major
>
> I use LATEST and RELEASE a lot for various purposes, such as CLI tooling that
> automatically synthesizes POMs to perform various tasks. I personally feel
> deprecating these metaversions was a mistake—I find them incredibly useful,
> with the understanding that I would never use them for production
> reproducible builds. But I do understand the rationale: we don't want to
> encourage anyone to use these in a way that harms the stability of dependency
> resolution, reproducibility-wise. So I'm OK with it, as long as there is a
> migration path forward for these sorts of use cases.
> But what is that path? I cannot find a way to replicate either of the
> metaversion behaviors using version ranges. There are problems with version
> ranges (MNG-3092, MNG-6049) preventing them from being used as a replacement
> for LATEST or RELEASE. Furthermore, in my tests, specifying a version range
> like {{[0,)}} causes Maven to download POMs at a bunch of (maybe all?)
> versions of an artifact, whereas {{LATEST}} and {{RELEASE}} do not trigger en
> masse downloading.l
> Is there a non-deprecated syntax that has equivalent behavior? As things
> stand, I am concerned that support for these metaversions is going to
> disappear in a future version of Maven without a feasible migration path
> forward.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (MNG-7343) Document a working migration path away from LATEST and RELEASE metaversions
Curtis Rueden created MNG-7343: -- Summary: Document a working migration path away from LATEST and RELEASE metaversions Key: MNG-7343 URL: https://issues.apache.org/jira/browse/MNG-7343 Project: Maven Issue Type: Bug Reporter: Curtis Rueden -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (MJAVADOC-595) javadoc not found using java.home
[
https://issues.apache.org/jira/browse/MJAVADOC-595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17249923#comment-17249923
]
Curtis Rueden edited comment on MJAVADOC-595 at 12/15/20, 8:40 PM:
---
It looks like this bug was fixed by:
[https://github.com/apache/maven-javadoc-plugin/commit/4bf64b02]
So now we just need a 3.2.1 release, no?
Relatedly: this bug and MJAVADOC-650 are the same problem, right?
was (Author: ctrueden):
It looks like this bug was fixed by:
https://github.com/apache/maven-javadoc-plugin/commit/4bf64b02
So now we just need a 3.2.1 release, no?
> javadoc not found using java.home
> --
>
> Key: MJAVADOC-595
> URL: https://issues.apache.org/jira/browse/MJAVADOC-595
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Oliver Lüttin
>Priority: Major
>
> When searching for the javadoc executable the plugin looks in
> java.home/../bin.
> This doesn't work with ubuntu 18.10 and java-11-openjdk.
> Instead it should look at java.hom/bin where the javadoc executable is
> located.
> Here's the code snippet from AbstactJavadocMojo:
> {code:java}
> 3720 private String getJavadocExecutable()
> 3721 throws IOException
> 3722 {
> ...
> 3768 else
> 3769 {
> 3770 javadocExe =
> 3771 new File( SystemUtils.getJavaHome() + File.separator + ".." +
> File.separator + "bin", javadocCommand );
> 3772 }
> {code}
>
> As workaround one could configure the executable in the pom.xml:
>
> {code:java}
>
> ${java.home}/bin/javadoc
>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MJAVADOC-595) javadoc not found using java.home
[
https://issues.apache.org/jira/browse/MJAVADOC-595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17249923#comment-17249923
]
Curtis Rueden commented on MJAVADOC-595:
It looks like this bug was fixed by:
https://github.com/apache/maven-javadoc-plugin/commit/4bf64b02
So now we just need a 3.2.1 release, no?
> javadoc not found using java.home
> --
>
> Key: MJAVADOC-595
> URL: https://issues.apache.org/jira/browse/MJAVADOC-595
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Oliver Lüttin
>Priority: Major
>
> When searching for the javadoc executable the plugin looks in
> java.home/../bin.
> This doesn't work with ubuntu 18.10 and java-11-openjdk.
> Instead it should look at java.hom/bin where the javadoc executable is
> located.
> Here's the code snippet from AbstactJavadocMojo:
> {code:java}
> 3720 private String getJavadocExecutable()
> 3721 throws IOException
> 3722 {
> ...
> 3768 else
> 3769 {
> 3770 javadocExe =
> 3771 new File( SystemUtils.getJavaHome() + File.separator + ".." +
> File.separator + "bin", javadocCommand );
> 3772 }
> {code}
>
> As workaround one could configure the executable in the pom.xml:
>
> {code:java}
>
> ${java.home}/bin/javadoc
>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6141) Dependency management overrides are not transitive and should be considered an anti-pattern.
[
https://issues.apache.org/jira/browse/MNG-6141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16267225#comment-16267225
]
Curtis Rueden commented on MNG-6141:
It would be a shame indeed for that work to be lost. But my understanding is
that these patches were going to be cherry-picked into future releases, no?
> Dependency management overrides are not transitive and should be considered
> an anti-pattern.
>
>
> Key: MNG-6141
> URL: https://issues.apache.org/jira/browse/MNG-6141
> Project: Maven
> Issue Type: Bug
>Reporter: Christian Schulte
>Priority: Critical
> Attachments: MNG-6141-3.zip, MNG-6141.zip
>
>
> Overriding the dependency management in a module's {{}}
> section, the overridden value will not be preserved transitively. It makes no
> sense to be able to override the dependency management in a module if that is
> only effective in that module and nowhere else. Overriding the dependency
> management from inside a {{}} element should be considered an
> anti-pattern. Maven should provide a warning when it is used. During the
> development of Maven 3.4, there have been quite a few discussions on dev@
> about build issues which were all caused by overriding the dependency
> management that way without noticing this is not supported transitively.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (MNG-6141) Dependency management overrides are not transitive and should be considered an anti-pattern.
[
https://issues.apache.org/jira/browse/MNG-6141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16267225#comment-16267225
]
Curtis Rueden edited comment on MNG-6141 at 11/27/17 6:41 PM:
--
It would be a shame indeed for that work to be lost. But my understanding was
that these patches were going to be cherry-picked into future releases, no?
was (Author: ctrueden):
It would be a shame indeed for that work to be lost. But my understanding is
that these patches were going to be cherry-picked into future releases, no?
> Dependency management overrides are not transitive and should be considered
> an anti-pattern.
>
>
> Key: MNG-6141
> URL: https://issues.apache.org/jira/browse/MNG-6141
> Project: Maven
> Issue Type: Bug
>Reporter: Christian Schulte
>Priority: Critical
> Attachments: MNG-6141-3.zip, MNG-6141.zip
>
>
> Overriding the dependency management in a module's {{}}
> section, the overridden value will not be preserved transitively. It makes no
> sense to be able to override the dependency management in a module if that is
> only effective in that module and nowhere else. Overriding the dependency
> management from inside a {{}} element should be considered an
> anti-pattern. Maven should provide a warning when it is used. During the
> development of Maven 3.4, there have been quite a few discussions on dev@
> about build issues which were all caused by overriding the dependency
> management that way without noticing this is not supported transitively.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-6141) Dependency management overrides are not transitive and should be considered an anti-pattern.
[
https://issues.apache.org/jira/browse/MNG-6141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16214185#comment-16214185
]
Curtis Rueden commented on MNG-6141:
Hmm, I guess the issue I stumbled over is something different then? Sorry for
the noise.
> Dependency management overrides are not transitive and should be considered
> an anti-pattern.
>
>
> Key: MNG-6141
> URL: https://issues.apache.org/jira/browse/MNG-6141
> Project: Maven
> Issue Type: Bug
>Reporter: Christian Schulte
>Priority: Critical
> Attachments: MNG-6141.zip
>
>
> Overriding the dependency management in a module's {{}}
> section, the overridden value will not be preserved transitively. It makes no
> sense to be able to override the dependency management in a module if that is
> only effective in that module and nowhere else. Overriding the dependency
> management from inside a {{}} element should be considered an
> anti-pattern. Maven should provide a warning when it is used. During the
> development of Maven 3.4, there have been quite a few discussions on dev@
> about build issues which were all caused by overriding the dependency
> management that way without noticing this is not supported transitively.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (MNG-5761) Dependency management is not transitive.
[ https://issues.apache.org/jira/browse/MNG-5761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16107492#comment-16107492 ] Curtis Rueden edited comment on MNG-5761 at 7/31/17 4:01 PM: - I also ran into this issue, and posted [an MCVE gist|https://gist.github.com/ctrueden/d058330c8a3687317806ce8cc18332c3] illustrating it. In my view, if a library L believes it depends on component X at a particular version, projects depending on L should also inherit component X at that same version. See also [this SO post|https://stackoverflow.com/q/45041888/1207769]. was (Author: ctrueden): I also ran into this issue, and posted [an MCVE gist|https://gist.github.com/ctrueden/d058330c8a3687317806ce8cc18332c3] illustrating it. In my view, if a library L believes it depends on component X at a particular version, project depending on L should also inherit component X at that same version. See also [this SO post|https://stackoverflow.com/q/45041888/1207769]. > Dependency management is not transitive. > > > Key: MNG-5761 > URL: https://issues.apache.org/jira/browse/MNG-5761 > Project: Maven > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.2.5 >Reporter: Jeff Schnitzer >Priority: Critical > Fix For: 3.6.0-candidate > > Attachments: MNG-5761.zip > > > A detailed description of the issue is here: > http://stackoverflow.com/questions/28312975/maven-dependencymanagement-version-ignored-in-transitive-dependencies > The short of it is that maven appears to be using the wrong > version in a transitive dependency. There are two > relevant sections in the build, one pulled in by guice > and one pulled in by gwizard-parent. These are the dependency paths from the > top: > gwizard-example -> gwizard-config -> gwizard-parent > gwizard-example -> gwizard-config -> guice -> guice-parent > gwizard-parent's dependencyManagement specifies guava 18 > guice-parent's dependencyManagement specifies guava 16 > Guava 16 is winning. This seems highly undesirable, and in fact it breaks our > build. I would expect that in a version # fight, "closest to the top" should > win. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MNG-6141) Dependency management overrides are not transitive and should be considered an anti-pattern.
[ https://issues.apache.org/jira/browse/MNG-6141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16107495#comment-16107495 ] Curtis Rueden commented on MNG-6141: I also ran into this issue, and posted [an MCVE gist|https://gist.github.com/ctrueden/d058330c8a3687317806ce8cc18332c3] illustrating it. In my view, if a library L believes it depends on component X at a particular version, projects depending on L should also inherit component X at that same version. See also [this SO post|https://stackoverflow.com/q/45041888/1207769]. > Dependency management overrides are not transitive and should be considered > an anti-pattern. > > > Key: MNG-6141 > URL: https://issues.apache.org/jira/browse/MNG-6141 > Project: Maven > Issue Type: Bug >Reporter: Christian Schulte >Priority: Critical > Attachments: MNG-6141.zip > > > Overriding the dependency management in a module, the overridden value will > not be preserved transitively. It makes no sense to be able to override the > dependency management in a module if that is only effective in that module > and nowhere else. Overriding the dependency management should be considered > an anti-pattern. Maven should provide a warning when it is used. During the > development of Maven 3.4, there have been quite a few discussions on dev@ > about build issues which were all caused by overriding the dependency > management without noticing this is not supported transitively. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MNG-5761) Dependency management is not transitive.
[ https://issues.apache.org/jira/browse/MNG-5761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16107492#comment-16107492 ] Curtis Rueden commented on MNG-5761: I also ran into this issue, and posted [an MCVE gist|https://gist.github.com/ctrueden/d058330c8a3687317806ce8cc18332c3] illustrating it. In my view, if a library L believes it depends on component X at a particular version, project depending on L should also inherit component X at that same version. See also [this SO post|https://stackoverflow.com/q/45041888/1207769]. > Dependency management is not transitive. > > > Key: MNG-5761 > URL: https://issues.apache.org/jira/browse/MNG-5761 > Project: Maven > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.2.5 >Reporter: Jeff Schnitzer >Priority: Critical > Fix For: 3.6.0-candidate > > Attachments: MNG-5761.zip > > > A detailed description of the issue is here: > http://stackoverflow.com/questions/28312975/maven-dependencymanagement-version-ignored-in-transitive-dependencies > The short of it is that maven appears to be using the wrong > version in a transitive dependency. There are two > relevant sections in the build, one pulled in by guice > and one pulled in by gwizard-parent. These are the dependency paths from the > top: > gwizard-example -> gwizard-config -> gwizard-parent > gwizard-example -> gwizard-config -> guice -> guice-parent > gwizard-parent's dependencyManagement specifies guava 18 > guice-parent's dependencyManagement specifies guava 16 > Guava 16 is winning. This seems highly undesirable, and in fact it breaks our > build. I would expect that in a version # fight, "closest to the top" should > win. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MNG-5971) Imported dependencies should be available to inheritance processing
[
https://issues.apache.org/jira/browse/MNG-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15419236#comment-15419236
]
Curtis Rueden commented on MNG-5971:
This change breaks backwards compatibility, and IMHO should be reverted.
h1. REAL-WORLD EXAMPLE
Consider the following project:
*
https://github.com/fiji/fiji/blob/ced9faee1c4fba9997a3d614759fb6e78e359d4f/pom.xml
Amongst many other dependencies, this project has:
{code:xml}
ca.mcgill
Sholl_Analysis
runtime
{code}
This is defined in the parent sc.fiji:pom-fiji:24.1.0 here:
* https://github.com/fiji/pom-fiji/blob/pom-fiji-24.1.0/pom.xml#L830-L835
* https://github.com/fiji/pom-fiji/blob/pom-fiji-24.1.0/pom.xml#L255-L256
{code:xml}
3.6.2
...
ca.mcgill
Sholl_Analysis
${Sholl_Analysis.version}
{code}
With Maven 3.3.9, we have:
{code}
$ mvn dependency:list|grep Sholl
[INFO]ca.mcgill:Sholl_Analysis:jar:3.6.2:runtime
{code}
But with Maven 3.4.0-20160806.181437-172, we get:
{code}
$ mvn dependency:list|grep Sholl
[INFO]ca.mcgill:Sholl_Analysis:jar:3.6.1:runtime
{code}
!!!
I believe this surprising behavior is caused by the fact that the toplevel fiji
POM needs to also include other BOMs via import scope:
*
https://github.com/fiji/fiji/blob/ced9faee1c4fba9997a3d614759fb6e78e359d4f/pom.xml#L49-L68
{code:xml}
sc.fiji
pom-bigdataviewer
${pom-bigdataviewer.version}
pom
import
sc.fiji
pom-trakem2
${pom-trakem2.version}
pom
import
{code}
The version of pom-bigdataviewer is 3.2.0:
* https://github.com/fiji/pom-fiji/blob/pom-fiji-24.1.0/pom.xml#L135-L136
Which extends pom-fiji version 22.3.0 instead of 24.1.0:
*
https://github.com/bigdataviewer/pom-bigdataviewer/blob/pom-bigdataviewer-3.2.0/pom.xml#L5-L9
And that version of pom-fiji defines Sholl_Analysis at 3.6.1 instead:
* https://github.com/fiji/pom-fiji/blob/pom-fiji-22.3.0/pom.xml#L261-L262
h1. GIST OF THE PROBLEM
So, with Maven 3.4.0, dependency management brought in from import scope is now
trumping that brought in from the parent POM itself. This is problematic
because:
* IMHO, it violates the Principle of Least Astonishment.
* It is now more complicated to compose together multiple "subtrees" of
components into a final application which needs to inherit multiple BOMs from
these subtrees.
* It is now not possible to override version properties _in the POM itself_ to
trump the dependencyManagement versions.
* But strangely, you _can_ still override the version property on the CLI via
-DSholl_Analysis.version=x.y.z. This seems inconsistent.
I understand and appreciate that I am naive of the deepest nuances of the Maven
project model and how it gets synthesized. But:
# The above behavior will break all of my projects.
# I do not know how to restructure my components for Maven 3.4.0 to avoid this
problem.
My vote would be to revert to the old behavior, which seems better to me.
However, if this behavior really must be changed, I would suggest pushing it
till Maven 4, since it will surely break a lot of existing builds.
If this change really goes through, then all previous releases of all of my
projects will no longer build reproducibly with Maven 3.4.0+, since they will
produce different dependency graphs.
Rather than breaking backwards compatibility of import scope by default,
perhaps there could be a setting, or a different scope as Christian Schulte
previously suggested.
See also this thread on the maven-users list:
*
http://mail-archives.apache.org/mod_mbox/maven-users/201608.mbox/%3CCADN69yn-ffoEV6_Q24VXAcSKbdXrT6CL263ih-LvvEdoYmL4CA%40mail.gmail.com%3E
> Imported dependencies should be available to inheritance processing
> ---
>
> Key: MNG-5971
> URL: https://issues.apache.org/jira/browse/MNG-5971
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.3.3
>Reporter: Stephane Nicoll
>Assignee: Christian Schulte
>Priority: Trivial
>
[jira] [Comment Edited] (MNG-6079) 3.4 regression: cannot override version of a dependencyManagement in a submodule any more
[
https://issues.apache.org/jira/browse/MNG-6079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15419191#comment-15419191
]
Curtis Rueden edited comment on MNG-6079 at 8/12/16 6:09 PM:
-
This change breaks backwards compatibility, and IMHO should be reverted.
h1. REAL-WORLD EXAMPLE
Consider the following project:
*
https://github.com/fiji/fiji/blob/ced9faee1c4fba9997a3d614759fb6e78e359d4f/pom.xml
Amongst many other dependencies, this project has:
{code:xml}
ca.mcgill
Sholl_Analysis
runtime
{code}
This is defined in the parent sc.fiji:pom-fiji:24.1.0 here:
* https://github.com/fiji/pom-fiji/blob/pom-fiji-24.1.0/pom.xml#L830-L835
* https://github.com/fiji/pom-fiji/blob/pom-fiji-24.1.0/pom.xml#L255-L256
{code:xml}
3.6.2
...
ca.mcgill
Sholl_Analysis
${Sholl_Analysis.version}
{code}
With Maven 3.3.9, we have:
{code}
$ mvn dependency:list|grep Sholl
[INFO]ca.mcgill:Sholl_Analysis:jar:3.6.2:runtime
{code}
But with Maven 3.4.0-20160806.181437-172, we get:
{code}
$ mvn dependency:list|grep Sholl
[INFO]ca.mcgill:Sholl_Analysis:jar:3.6.1:runtime
{code}
!!!
I believe this surprising behavior is caused by the fact that the toplevel fiji
POM needs to also include other BOMs via import scope:
*
https://github.com/fiji/fiji/blob/ced9faee1c4fba9997a3d614759fb6e78e359d4f/pom.xml#L49-L68
{code:xml}
sc.fiji
pom-bigdataviewer
${pom-bigdataviewer.version}
pom
import
sc.fiji
pom-trakem2
${pom-trakem2.version}
pom
import
{code}
The version of pom-bigdataviewer is 3.2.0:
* https://github.com/fiji/pom-fiji/blob/pom-fiji-24.1.0/pom.xml#L135-L136
Which extends pom-fiji version 22.3.0 instead of 24.1.0:
*
https://github.com/bigdataviewer/pom-bigdataviewer/blob/pom-bigdataviewer-3.2.0/pom.xml#L5-L9
And that version of pom-fiji defines Sholl_Analysis at 3.6.1 instead:
* https://github.com/fiji/pom-fiji/blob/pom-fiji-22.3.0/pom.xml#L261-L262
h1. GIST OF THE PROBLEM
So, with Maven 3.4.0, dependency management brought in from import scope is now
trumping that brought in from the parent POM itself. This is problematic
because:
* IMHO, it violates the Principle of Least Astonishment.
* It is now more complicated to compose together multiple "subtrees" of
components into a final application which needs to inherit multiple BOMs from
these subtrees.
* It is now not possible to override version properties _in the POM itself_ to
trump the dependencyManagement versions.
* But strangely, you _can_ still override the version property on the CLI via
-DSholl_Analysis.version=x.y.z. This seems inconsistent.
I understand and appreciate that I am naive of the deepest nuances of the Maven
project model and how it gets synthesized. But:
# The above behavior will break all of my projects.
# I do not know how to restructure my components for Maven 3.4.0 to avoid this
problem.
My vote would be to revert to the old behavior, which seems better to me.
However, if this behavior really must be changed, I would suggest pushing it
till Maven 4, since it will surely break a lot of existing builds.
If this change really goes through, then all previous releases of all of my
projects will no longer build reproducibly with Maven 3.4.0+, since they will
produce different dependency graphs.
Rather than breaking backwards compatibility of import scope by default,
perhaps there could be a setting, or a different scope as Christian Schulte
previously suggested.
See also this thread on the maven-users list:
*
http://mail-archives.apache.org/mod_mbox/maven-users/201608.mbox/%3CCADN69yn-ffoEV6_Q24VXAcSKbdXrT6CL263ih-LvvEdoYmL4CA%40mail.gmail.com%3E
was (Author: ctrueden):
This change breaks backwards compatibility, and IMHO should be reverted.
h1. REAL-WORLD EXAMPLE
Consider the following project:
*
https://github.com/fiji/fiji/blob/ced9faee1c4fba9997a3d614759fb6e78e359d4f/pom.xml
Amongst many other dependencies, this project has:
{code:xml}
ca.mcgill
Sholl_Analysis
runtime
{code}
This is defined in the
[jira] [Comment Edited] (MNG-6079) 3.4 regression: cannot override version of a dependencyManagement in a submodule any more
[
https://issues.apache.org/jira/browse/MNG-6079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15419191#comment-15419191
]
Curtis Rueden edited comment on MNG-6079 at 8/12/16 5:47 PM:
-
This change breaks backwards compatibility, and IMHO should be reverted.
h1. REAL-WORLD EXAMPLE
Consider the following project:
*
https://github.com/fiji/fiji/blob/ced9faee1c4fba9997a3d614759fb6e78e359d4f/pom.xml
Amongst many other dependencies, this project has:
{code:xml}
ca.mcgill
Sholl_Analysis
runtime
{code}
This is defined in the parent sc.fiji:pom-fiji:24.1.0 here:
* https://github.com/fiji/pom-fiji/blob/pom-fiji-24.1.0/pom.xml#L830-L835
* https://github.com/fiji/pom-fiji/blob/pom-fiji-24.1.0/pom.xml#L255-L256
{code:xml}
3.6.2
...
ca.mcgill
Sholl_Analysis
${Sholl_Analysis.version}
{code}
With Maven 3.3.9, we have:
{code}
$ mvn dependency:list|grep Sholl
[INFO]ca.mcgill:Sholl_Analysis:jar:3.6.2:runtime
{code}
But with Maven 3.4.0-20160806.181437-172, we get:
{code}
$ mvn dependency:list|grep Sholl
[INFO]ca.mcgill:Sholl_Analysis:jar:3.6.1:runtime
{code}
!!!
I believe this surprising behavior is caused by the fact that the toplevel fiji
POM needs to also include other BOMs via import scope:
*
https://github.com/fiji/fiji/blob/ced9faee1c4fba9997a3d614759fb6e78e359d4f/pom.xml#L49-L68
{code:xml}
sc.fiji
pom-bigdataviewer
${pom-bigdataviewer.version}
pom
import
sc.fiji
pom-trakem2
${pom-trakem2.version}
pom
import
{code}
The version of pom-bigdataviewer is 3.2.0:
* https://github.com/fiji/pom-fiji/blob/pom-fiji-24.1.0/pom.xml#L135-L136
Which extends pom-fiji version 22.3.0 instead of 24.1.0:
*
https://github.com/bigdataviewer/pom-bigdataviewer/blob/pom-bigdataviewer-3.2.0/pom.xml#L5-L9
And that version of pom-fiji defines Sholl_Analysis at 3.6.1 instead:
* https://github.com/fiji/pom-fiji/blob/pom-fiji-22.3.0/pom.xml#L261-L262
h1. GIST OF THE PROBLEM
So, with Maven 3.4.0, dependency management brought in from import scope is now
trumping that brought in from the parent POM itself. This is problematic
because:
* IMHO, it violates the Principle of Least Astonishment.
* It is now more complicated to compose together multiple "subtrees" of
components into a final application which needs to inherit multiple BOMs from
these subtrees.
* It is now not possible to override version properties _in the POM itself_ to
trump the dependencyManagement versions.
* But strangely, you _can_ still override the version property on the CLI via
-DSholl_Analysis.version=x.y.z. This seems inconsistent.
I understand and appreciate that I am naive of the deepest nuances of the Maven
project model and how it gets synthesized. But:
# The above behavior will break all of my projects.
# I do not know how to restructure my components for Maven 3.4.0 to avoid this
problem.
My vote would be to revert to the old behavior, which seems better to me.
However, if this behavior really must be changed, I would suggest pushing it
till Maven 4, since it will surely break a lot of existing builds.
If this change really goes through, then all previous releases of all of my
projects will no longer build reproducibly with Maven 3.4.0+, since they will
produce different dependency graphs.
Rather than breaking backwards compatibility of import scope by default,
perhaps there could be a setting, or a different scope as Christian Schulte
previously suggested.
was (Author: ctrueden):
This change breaks backwards compatibility, and IMHO should be reverted.
h1. REAL-WORLD EXAMPLE
Consider the following project:
*
https://github.com/fiji/fiji/blob/ced9faee1c4fba9997a3d614759fb6e78e359d4f/pom.xml
Amongst many other dependencies, this project has:
{code:xml}
ca.mcgill
Sholl_Analysis
runtime
{code}
This is defined in the parent sc.fiji:pom-fiji:24.1.0 here:
* https://github.com/fiji/pom-fiji/blob/pom-fiji-24.1.0/pom.xml#L830-L835
* https://github.com/fiji/pom-fiji/blob/pom-fiji-24.1.0/pom.xml#L255-L256
[jira] [Comment Edited] (MNG-6079) 3.4 regression: cannot override version of a dependencyManagement in a submodule any more
[
https://issues.apache.org/jira/browse/MNG-6079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15419191#comment-15419191
]
Curtis Rueden edited comment on MNG-6079 at 8/12/16 5:47 PM:
-
This change breaks backwards compatibility, and IMHO should be reverted.
h1. REAL-WORLD EXAMPLE
Consider the following project:
*
https://github.com/fiji/fiji/blob/ced9faee1c4fba9997a3d614759fb6e78e359d4f/pom.xml
Amongst many other dependencies, this project has:
{code:xml}
ca.mcgill
Sholl_Analysis
runtime
{code}
This is defined in the parent sc.fiji:pom-fiji:24.1.0 here:
* https://github.com/fiji/pom-fiji/blob/pom-fiji-24.1.0/pom.xml#L830-L835
* https://github.com/fiji/pom-fiji/blob/pom-fiji-24.1.0/pom.xml#L255-L256
{code:xml}
3.6.2
...
ca.mcgill
Sholl_Analysis
${Sholl_Analysis.version}
{code}
With Maven 3.3.9, we have:
{code}
$ mvn dependency:list|grep Sholl
[INFO]ca.mcgill:Sholl_Analysis:jar:3.6.2:runtime
{code}
But with Maven 3.4.0-20160806.181437-172, we get:
{code}
$ mvn dependency:list|grep Sholl
[INFO]ca.mcgill:Sholl_Analysis:jar:3.6.1:runtime
{code}
!!!
I believe this surprising behavior is caused by the fact that the toplevel fiji
POM needs to also include other BOMs via import scope:
*
https://github.com/fiji/fiji/blob/ced9faee1c4fba9997a3d614759fb6e78e359d4f/pom.xml#L49-L68
{code:xml}
sc.fiji
pom-bigdataviewer
${pom-bigdataviewer.version}
pom
import
sc.fiji
pom-trakem2
${pom-trakem2.version}
pom
import
{code}
The version of pom-bigdataviewer is 3.2.0:
* https://github.com/fiji/pom-fiji/blob/pom-fiji-24.1.0/pom.xml#L135-L136
Which extends pom-fiji version 22.3.0 instead of 24.1.0:
*
https://github.com/bigdataviewer/pom-bigdataviewer/blob/pom-bigdataviewer-3.2.0/pom.xml#L5-L9
And that version of pom-fiji defines Sholl_Analysis at 3.6.1 instead:
* https://github.com/fiji/pom-fiji/blob/pom-fiji-22.3.0/pom.xml#L261-L262
h1. GIST OF THE PROBLEM
So, with Maven 3.4.0, dependency management brought in from import scope is now
trumping that brought in from the parent POM itself. This is problematic
because:
* IMHO, it violates the Principle of Least Astonishment.
* It is now more complicated to compose together multiple "subtrees" of
components into a final application which needs to inherit multiple BOMs from
these subtrees.
* It is now not possible to override version properties _in the POM itself_ to
trump the dependencyManagement versions.
* But strangely, you _can_ still override the version property on the CLI via
-DSholl_Analysis.version=x.y.z. This seems inconsistent.
I understand and appreciate that I am naive of the deepest nuances of the Maven
project model and how it gets synthesized. But:
# The above behavior will break all of my projects.
# I do not know how to restructure my components for Maven 3.4.0 to avoid this
problem.
My vote would be to revert to the old behavior, which seems better to me.
However, if this behavior really must be changed, I would suggest pushing it
till Maven 4, since it will surely break a lot of existing builds.
If this change really goes through, then all previous releases of all of my
projects will no longer build reproducibly with Maven 3.4.0+, since they will
produce different dependency graphs.
Rather than breaking backwards compatibility of import scope by default,
perhaps there could be a setting, or a different scope as Christian Schulte
like suggested.
was (Author: ctrueden):
This change breaks backwards compatibility, and IMHO should be reverted.
h1. REAL-WORLD EXAMPLE
Consider the following project:
*
https://github.com/fiji/fiji/blob/ced9faee1c4fba9997a3d614759fb6e78e359d4f/pom.xml
Amongst many other dependencies, this project has:
{code:xml}
ca.mcgill
Sholl_Analysis
runtime
{code}
This is defined in the parent sc.fiji:pom-fiji:24.1.0 here:
* https://github.com/fiji/pom-fiji/blob/pom-fiji-24.1.0/pom.xml#L830-L835
* https://github.com/fiji/pom-fiji/blob/pom-fiji-24.1.0/pom.xml#L255-L256
{code:xml}
[jira] [Comment Edited] (MNG-6079) 3.4 regression: cannot override version of a dependencyManagement in a submodule any more
[
https://issues.apache.org/jira/browse/MNG-6079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15419191#comment-15419191
]
Curtis Rueden edited comment on MNG-6079 at 8/12/16 5:46 PM:
-
This change breaks backwards compatibility, and IMHO should be reverted.
h1. REAL-WORLD EXAMPLE
Consider the following project:
*
https://github.com/fiji/fiji/blob/ced9faee1c4fba9997a3d614759fb6e78e359d4f/pom.xml
Amongst many other dependencies, this project has:
{code:xml}
ca.mcgill
Sholl_Analysis
runtime
{code}
This is defined in the parent sc.fiji:pom-fiji:24.1.0 here:
* https://github.com/fiji/pom-fiji/blob/pom-fiji-24.1.0/pom.xml#L830-L835
* https://github.com/fiji/pom-fiji/blob/pom-fiji-24.1.0/pom.xml#L255-L256
{code:xml}
3.6.2
...
ca.mcgill
Sholl_Analysis
${Sholl_Analysis.version}
{code}
With Maven 3.3.9, we have:
{code}
$ mvn dependency:list|grep Sholl
[INFO]ca.mcgill:Sholl_Analysis:jar:3.6.2:runtime
{code}
But with Maven 3.4.0-20160806.181437-172, we get:
{code}
$ mvn dependency:list|grep Sholl
[INFO]ca.mcgill:Sholl_Analysis:jar:3.6.1:runtime
{code}
!!!
I believe this surprising behavior is caused by the fact that the toplevel fiji
POM needs to also include other BOMs via import scope:
*
https://github.com/fiji/fiji/blob/ced9faee1c4fba9997a3d614759fb6e78e359d4f/pom.xml#L49-L68
{code:xml}
sc.fiji
pom-bigdataviewer
${pom-bigdataviewer.version}
pom
import
sc.fiji
pom-trakem2
${pom-trakem2.version}
pom
import
{code}
The version of pom-bigdataviewer is 3.2.0:
* https://github.com/fiji/pom-fiji/blob/pom-fiji-24.1.0/pom.xml#L135-L136
Which extends pom-fiji version 22.3.0 instead of 24.1.0:
*
https://github.com/bigdataviewer/pom-bigdataviewer/blob/pom-bigdataviewer-3.2.0/pom.xml#L5-L9
And that version of pom-fiji defines Sholl_Analysis at 3.6.1 instead:
* https://github.com/fiji/pom-fiji/blob/pom-fiji-22.3.0/pom.xml#L261-L262
h1. GIST OF THE PROBLEM
So, with Maven 3.4.0, dependency management brought in from import scope is now
trumping that brought in from the parent POM itself. This is problematic
because:
* IMHO, it violates the Principle of Least Astonishment.
* It is now more complicated to compose together multiple "subtrees" of
components into a final application which needs to inherit multiple BOMs from
these subtrees.
* It is now not possible to override version properties _in the POM itself_ to
trump the dependencyManagement versions.
* But strangely, you _can_ still override the version property on the CLI via
-DSholl_Analysis.version=x.y.z. This seems inconsistent.
I understand and appreciate that I am naive of the deepest nuances of the Maven
project model and how it gets synthesized. But:
# The above behavior will break all of my projects.
# I do not know how to restructure my components for Maven 3.4.0 to avoid this
problem.
My vote would be to revert to the old behavior, which seems better to me.
However, if this behavior really must be changed, I would suggest pushing it
till Maven 4, since it will surely break a lot of existing builds.
If this change really goes through, then all previous releases of all of my
projects will no longer build reproducibly with Maven 3.4.0+, since they will
produce different dependency graphs.
Rather than breaking backwards compatibility of import scope by default,
perhaps there could be a setting, or a different scope as Christian Schulte
like suggested.
was (Author: ctrueden):
This change breaks backwards compatibility, and IMHO should be reverted.
h1. REAL-WORLD EXAMPLE
Consider the following project:
*
https://github.com/fiji/fiji/blob/ced9faee1c4fba9997a3d614759fb6e78e359d4f/pom.xml
Amongst many other dependencies, this project has:
{code:xml}
ca.mcgill
Sholl_Analysis
runtime
{code}
This is defined in the parent sc.fiji:pom-fiji:24.1.0 here:
* https://github.com/fiji/pom-fiji/blob/pom-fiji-24.1.0/pom.xml#L830-L835
* https://github.com/fiji/pom-fiji/blob/pom-fiji-24.1.0/pom.xml#L255-L256
{code:xml}
[jira] [Comment Edited] (MNG-6079) 3.4 regression: cannot override version of a dependencyManagement in a submodule any more
[
https://issues.apache.org/jira/browse/MNG-6079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15419191#comment-15419191
]
Curtis Rueden edited comment on MNG-6079 at 8/12/16 5:46 PM:
-
This change breaks backwards compatibility, and IMHO should be reverted.
h1. REAL-WORLD EXAMPLE
Consider the following project:
*
https://github.com/fiji/fiji/blob/ced9faee1c4fba9997a3d614759fb6e78e359d4f/pom.xml
Amongst many other dependencies, this project has:
{code:xml}
ca.mcgill
Sholl_Analysis
runtime
{code}
This is defined in the parent sc.fiji:pom-fiji:24.1.0 here:
* https://github.com/fiji/pom-fiji/blob/pom-fiji-24.1.0/pom.xml#L830-L835
* https://github.com/fiji/pom-fiji/blob/pom-fiji-24.1.0/pom.xml#L255-L256
{code:xml}
3.6.2
...
ca.mcgill
Sholl_Analysis
${Sholl_Analysis.version}
{code:shell}
With Maven 3.3.9, we have:
{code}
$ mvn dependency:list|grep Sholl
[INFO]ca.mcgill:Sholl_Analysis:jar:3.6.2:runtime
{code}
But with Maven 3.4.0-20160806.181437-172, we get:
{code:shell}
$ mvn dependency:list|grep Sholl
[INFO]ca.mcgill:Sholl_Analysis:jar:3.6.1:runtime
{code}
!!!
I believe this surprising behavior is caused by the fact that the toplevel fiji
POM needs to also include other BOMs via import scope:
*
https://github.com/fiji/fiji/blob/ced9faee1c4fba9997a3d614759fb6e78e359d4f/pom.xml#L49-L68
{code:xml}
sc.fiji
pom-bigdataviewer
${pom-bigdataviewer.version}
pom
import
sc.fiji
pom-trakem2
${pom-trakem2.version}
pom
import
{code}
The version of pom-bigdataviewer is 3.2.0:
* https://github.com/fiji/pom-fiji/blob/pom-fiji-24.1.0/pom.xml#L135-L136
Which extends pom-fiji version 22.3.0 instead of 24.1.0:
*
https://github.com/bigdataviewer/pom-bigdataviewer/blob/pom-bigdataviewer-3.2.0/pom.xml#L5-L9
And that version of pom-fiji defines Sholl_Analysis at 3.6.1 instead:
* https://github.com/fiji/pom-fiji/blob/pom-fiji-22.3.0/pom.xml#L261-L262
h1. GIST OF THE PROBLEM
So, with Maven 3.4.0, dependency management brought in from import scope is now
trumping that brought in from the parent POM itself. This is problematic
because:
* IMHO, it violates the Principle of Least Astonishment.
* It is now more complicated to compose together multiple "subtrees" of
components into a final application which needs to inherit multiple BOMs from
these subtrees.
* It is now not possible to override version properties _in the POM itself_ to
trump the dependencyManagement versions.
* But strangely, you _can_ still override the version property on the CLI via
-DSholl_Analysis.version=x.y.z. This seems inconsistent.
I understand and appreciate that I am naive of the deepest nuances of the Maven
project model and how it gets synthesized. But:
# The above behavior will break all of my projects.
# I do not know how to restructure my components for Maven 3.4.0 to avoid this
problem.
My vote would be to revert to the old behavior, which seems better to me.
However, if this behavior really must be changed, I would suggest pushing it
till Maven 4, since it will surely break a lot of existing builds.
If this change really goes through, then all previous releases of all of my
projects will no longer build reproducibly with Maven 3.4.0+, since they will
produce different dependency graphs.
Rather than breaking backwards compatibility of import scope by default,
perhaps there could be a setting, or a different scope as Christian Schulte
like suggested.
was (Author: ctrueden):
This change breaks backwards compatibility, and IMHO should be reverted.
## REAL-WORLD EXAMPLE
Consider the following project:
*
https://github.com/fiji/fiji/blob/ced9faee1c4fba9997a3d614759fb6e78e359d4f/pom.xml
Amongst many other dependencies, this project has:
{{
ca.mcgill
Sholl_Analysis
runtime
}}
This is defined in the parent sc.fiji:pom-fiji:24.1.0 here:
* https://github.com/fiji/pom-fiji/blob/pom-fiji-24.1.0/pom.xml#L830-L835
* https://github.com/fiji/pom-fiji/blob/pom-fiji-24.1.0/pom.xml#L255-L256
[jira] [Comment Edited] (MNG-6079) 3.4 regression: cannot override version of a dependencyManagement in a submodule any more
[
https://issues.apache.org/jira/browse/MNG-6079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15419191#comment-15419191
]
Curtis Rueden edited comment on MNG-6079 at 8/12/16 5:43 PM:
-
This change breaks backwards compatibility, and IMHO should be reverted.
## REAL-WORLD EXAMPLE
Consider the following project:
*
https://github.com/fiji/fiji/blob/ced9faee1c4fba9997a3d614759fb6e78e359d4f/pom.xml
Amongst many other dependencies, this project has:
{{
ca.mcgill
Sholl_Analysis
runtime
}}
This is defined in the parent sc.fiji:pom-fiji:24.1.0 here:
* https://github.com/fiji/pom-fiji/blob/pom-fiji-24.1.0/pom.xml#L830-L835
* https://github.com/fiji/pom-fiji/blob/pom-fiji-24.1.0/pom.xml#L255-L256
3.6.2
...
ca.mcgill
Sholl_Analysis
${Sholl_Analysis.version}
With Maven 3.3.9, we have:
$ mvn dependency:list|grep Sholl
[INFO]ca.mcgill:Sholl_Analysis:jar:3.6.2:runtime
But with Maven 3.4.0-20160806.181437-172, we get:
$ mvn dependency:list|grep Sholl
[INFO]ca.mcgill:Sholl_Analysis:jar:3.6.1:runtime
!!!
I believe this surprising behavior is caused by the fact that the toplevel fiji
POM needs to also include other BOMs via import scope:
*
https://github.com/fiji/fiji/blob/ced9faee1c4fba9997a3d614759fb6e78e359d4f/pom.xml#L49-L68
sc.fiji
pom-bigdataviewer
${pom-bigdataviewer.version}
pom
import
sc.fiji
pom-trakem2
${pom-trakem2.version}
pom
import
The version of pom-bigdataviewer is 3.2.0:
* https://github.com/fiji/pom-fiji/blob/pom-fiji-24.1.0/pom.xml#L135-L136
Which extends pom-fiji version 22.3.0 instead of 24.1.0:
*
https://github.com/bigdataviewer/pom-bigdataviewer/blob/pom-bigdataviewer-3.2.0/pom.xml#L5-L9
And that version of pom-fiji defines Sholl_Analysis at 3.6.1 instead:
* https://github.com/fiji/pom-fiji/blob/pom-fiji-22.3.0/pom.xml#L261-L262
== GIST OF THE PROBLEM ==
So, with Maven 3.4.0, dependency management brought in from import scope is now
trumping that brought in from the parent POM itself. This is problematic
because:
- IMHO, it violates the Principle of Least Astonishment.
- It is now more complicated to compose together multiple "subtrees" of
components into a final application which needs to inherit multiple BOMs from
these subtrees.
- It is now not possible to override version properties _in the POM itself_ to
trump the dependencyManagement versions.
But strangely, you _can_ still override the version property on the CLI via
-DSholl_Analysis.version=x.y.z.
I understand and appreciate that I am naive of the deepest nuances of the Maven
project model and how it gets synthesized. But:
1) The above behavior will break all of my projects.
2) I do not know how to restructure my components for Maven 3.4.0 to avoid this
problem.
My vote would be to revert to the old behavior, which seems better to me.
However, if this behavior really must be changed, I would suggest pushing it
till Maven 4, since it will surely break a lot of existing builds.
If this change really goes through, then all previous releases of all of my
projects will no longer build reproducibly with Maven 3.4.0+, since they will
produce different dependency graphs.
Rather than breaking backwards compatibility of import scope by default,
perhaps there could be a setting, or a different scope as Christian Schulte
like suggested.
was (Author: ctrueden):
This change breaks backwards compatibility, and IMHO should be reverted.
## REAL-WORLD EXAMPLE
Consider the following project:
*
https://github.com/fiji/fiji/blob/ced9faee1c4fba9997a3d614759fb6e78e359d4f/pom.xml
Amongst many other dependencies, this project has:
ca.mcgill
Sholl_Analysis
runtime
This is defined in the parent sc.fiji:pom-fiji:24.1.0 here:
* https://github.com/fiji/pom-fiji/blob/pom-fiji-24.1.0/pom.xml#L830-L835
* https://github.com/fiji/pom-fiji/blob/pom-fiji-24.1.0/pom.xml#L255-L256
3.6.2
...
[jira] [Comment Edited] (MNG-6079) 3.4 regression: cannot override version of a dependencyManagement in a submodule any more
[
https://issues.apache.org/jira/browse/MNG-6079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15419191#comment-15419191
]
Curtis Rueden edited comment on MNG-6079 at 8/12/16 5:42 PM:
-
This change breaks backwards compatibility, and IMHO should be reverted.
## REAL-WORLD EXAMPLE
Consider the following project:
*
https://github.com/fiji/fiji/blob/ced9faee1c4fba9997a3d614759fb6e78e359d4f/pom.xml
Amongst many other dependencies, this project has:
ca.mcgill
Sholl_Analysis
runtime
This is defined in the parent sc.fiji:pom-fiji:24.1.0 here:
* https://github.com/fiji/pom-fiji/blob/pom-fiji-24.1.0/pom.xml#L830-L835
* https://github.com/fiji/pom-fiji/blob/pom-fiji-24.1.0/pom.xml#L255-L256
3.6.2
...
ca.mcgill
Sholl_Analysis
${Sholl_Analysis.version}
With Maven 3.3.9, we have:
$ mvn dependency:list|grep Sholl
[INFO]ca.mcgill:Sholl_Analysis:jar:3.6.2:runtime
But with Maven 3.4.0-20160806.181437-172, we get:
$ mvn dependency:list|grep Sholl
[INFO]ca.mcgill:Sholl_Analysis:jar:3.6.1:runtime
!!!
I believe this surprising behavior is caused by the fact that the toplevel fiji
POM needs to also include other BOMs via import scope:
*
https://github.com/fiji/fiji/blob/ced9faee1c4fba9997a3d614759fb6e78e359d4f/pom.xml#L49-L68
sc.fiji
pom-bigdataviewer
${pom-bigdataviewer.version}
pom
import
sc.fiji
pom-trakem2
${pom-trakem2.version}
pom
import
The version of pom-bigdataviewer is 3.2.0:
* https://github.com/fiji/pom-fiji/blob/pom-fiji-24.1.0/pom.xml#L135-L136
Which extends pom-fiji version 22.3.0 instead of 24.1.0:
*
https://github.com/bigdataviewer/pom-bigdataviewer/blob/pom-bigdataviewer-3.2.0/pom.xml#L5-L9
And that version of pom-fiji defines Sholl_Analysis at 3.6.1 instead:
* https://github.com/fiji/pom-fiji/blob/pom-fiji-22.3.0/pom.xml#L261-L262
== GIST OF THE PROBLEM ==
So, with Maven 3.4.0, dependency management brought in from import scope is now
trumping that brought in from the parent POM itself. This is problematic
because:
- IMHO, it violates the Principle of Least Astonishment.
- It is now more complicated to compose together multiple "subtrees" of
components into a final application which needs to inherit multiple BOMs from
these subtrees.
- It is now not possible to override version properties _in the POM itself_ to
trump the dependencyManagement versions.
But strangely, you _can_ still override the version property on the CLI via
-DSholl_Analysis.version=x.y.z.
I understand and appreciate that I am naive of the deepest nuances of the Maven
project model and how it gets synthesized. But:
1) The above behavior will break all of my projects.
2) I do not know how to restructure my components for Maven 3.4.0 to avoid this
problem.
My vote would be to revert to the old behavior, which seems better to me.
However, if this behavior really must be changed, I would suggest pushing it
till Maven 4, since it will surely break a lot of existing builds.
If this change really goes through, then all previous releases of all of my
projects will no longer build reproducibly with Maven 3.4.0+, since they will
produce different dependency graphs.
Rather than breaking backwards compatibility of import scope by default,
perhaps there could be a setting, or a different scope as Christian Schulte
like suggested.
was (Author: ctrueden):
This change breaks backwards compatibility, and IMHO should be reverted.
== REAL-WORLD EXAMPLE ==
Consider the following project:
https://github.com/fiji/fiji/blob/ced9faee1c4fba9997a3d614759fb6e78e359d4f/pom.xml
Amongst many other dependencies, this project has:
ca.mcgill
Sholl_Analysis
runtime
This is defined in the parent sc.fiji:pom-fiji:24.1.0 here:
* https://github.com/fiji/pom-fiji/blob/pom-fiji-24.1.0/pom.xml#L830-L835
* https://github.com/fiji/pom-fiji/blob/pom-fiji-24.1.0/pom.xml#L255-L256
3.6.2
...
[jira] [Commented] (MNG-6079) 3.4 regression: cannot override version of a dependencyManagement in a submodule any more
[
https://issues.apache.org/jira/browse/MNG-6079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15419191#comment-15419191
]
Curtis Rueden commented on MNG-6079:
This change breaks backwards compatibility, and IMHO should be reverted.
== REAL-WORLD EXAMPLE ==
Consider the following project:
https://github.com/fiji/fiji/blob/ced9faee1c4fba9997a3d614759fb6e78e359d4f/pom.xml
Amongst many other dependencies, this project has:
ca.mcgill
Sholl_Analysis
runtime
This is defined in the parent sc.fiji:pom-fiji:24.1.0 here:
* https://github.com/fiji/pom-fiji/blob/pom-fiji-24.1.0/pom.xml#L830-L835
* https://github.com/fiji/pom-fiji/blob/pom-fiji-24.1.0/pom.xml#L255-L256
3.6.2
...
ca.mcgill
Sholl_Analysis
${Sholl_Analysis.version}
With Maven 3.3.9, we have:
$ mvn dependency:list|grep Sholl
[INFO]ca.mcgill:Sholl_Analysis:jar:3.6.2:runtime
But with Maven 3.4.0-20160806.181437-172, we get:
$ mvn dependency:list|grep Sholl
[INFO]ca.mcgill:Sholl_Analysis:jar:3.6.1:runtime
!!!
I believe this surprising behavior is caused by the fact that the toplevel fiji
POM needs to also include other BOMs via import scope:
*
https://github.com/fiji/fiji/blob/ced9faee1c4fba9997a3d614759fb6e78e359d4f/pom.xml#L49-L68
sc.fiji
pom-bigdataviewer
${pom-bigdataviewer.version}
pom
import
sc.fiji
pom-trakem2
${pom-trakem2.version}
pom
import
The version of pom-bigdataviewer is 3.2.0:
* https://github.com/fiji/pom-fiji/blob/pom-fiji-24.1.0/pom.xml#L135-L136
Which extends pom-fiji version 22.3.0 instead of 24.1.0:
*
https://github.com/bigdataviewer/pom-bigdataviewer/blob/pom-bigdataviewer-3.2.0/pom.xml#L5-L9
And that version of pom-fiji defines Sholl_Analysis at 3.6.1 instead:
* https://github.com/fiji/pom-fiji/blob/pom-fiji-22.3.0/pom.xml#L261-L262
== GIST OF THE PROBLEM ==
So, with Maven 3.4.0, dependency management brought in from import scope is now
trumping that brought in from the parent POM itself. This is problematic
because:
- IMHO, it violates the Principle of Least Astonishment.
- It is now more complicated to compose together multiple "subtrees" of
components into a final application which needs to inherit multiple BOMs from
these subtrees.
- It is now not possible to override version properties _in the POM itself_ to
trump the dependencyManagement versions.
But strangely, you _can_ still override the version property on the CLI via
-DSholl_Analysis.version=x.y.z.
I understand and appreciate that I am naive of the deepest nuances of the Maven
project model and how it gets synthesized. But:
1) The above behavior will break all of my projects.
2) I do not know how to restructure my components for Maven 3.4.0 to avoid this
problem.
My vote would be to revert to the old behavior, which seems better to me.
However, if this behavior really must be changed, I would suggest pushing it
till Maven 4, since it will surely break a lot of existing builds.
If this change really goes through, then all previous releases of all of my
projects will no longer build reproducibly with Maven 3.4.0+, since they will
produce different dependency graphs.
Rather than breaking backwards compatibility of import scope by default,
perhaps there could be a setting, or a different scope as Christian Schulte
like suggested.
> 3.4 regression: cannot override version of a dependencyManagement in a
> submodule any more
> -
>
> Key: MNG-6079
> URL: https://issues.apache.org/jira/browse/MNG-6079
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.4.0
>Reporter: Samuel Langlois
>Assignee: Christian Schulte
> Attachments: parent-pom.xml, pom.xml
>
>
> When you import a {{}} section from another pom, you
> can use a property for the version:
> {code}
>
>
>
> org.apache.maven.surefire
> surefire
>
[jira] (MENFORCER-185) Require Release Dependencies ignorant about aggregator build
[ https://jira.codehaus.org/browse/MENFORCER-185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Curtis Rueden updated MENFORCER-185: Attachment: seuss.zip mvn validate [INFO] Scanning for projects... [INFO] [INFO] Reactor Build Order: [INFO] [INFO] pom [INFO] green-eggs [INFO] ham [INFO] [INFO] [INFO] Building pom 0.0.0-SNAPSHOT [INFO] [INFO] [INFO] --- maven-enforcer-plugin:1.3.1:enforce (enforce-rules) @ pom --- [INFO] [INFO] [INFO] Building green-eggs 0.0.0-SNAPSHOT [INFO] [INFO] [INFO] --- maven-enforcer-plugin:1.3.1:enforce (enforce-rules) @ green-eggs --- [WARNING] Rule 0: org.apache.maven.plugins.enforcer.RequireReleaseDeps failed with message: Parent Cannot be a snapshot: seuss:pom:pom:0.0.0-SNAPSHOT [INFO] [INFO] Reactor Summary: [INFO] [INFO] pom SUCCESS [ 0.462 s] [INFO] green-eggs . FAILURE [ 0.003 s] [INFO] ham SKIPPED [INFO] [INFO] BUILD FAILURE [INFO] Require Release Dependencies ignorant about aggregator build Key: MENFORCER-185 URL: https://jira.codehaus.org/browse/MENFORCER-185 Project: Maven Enforcer Plugin Issue Type: Bug Components: Standard Rules Affects Versions: 1.3.1 Reporter: Thomas Diesler Attachments: seuss.zip If A depends on B it is ok for A-1.0.0-SNAPSHOT to have snapshot dependency on B-1.0.0-SNAPSHOT if B was build before A during the same reactor build. Using the requireReleaseDeps rule it seems that SNAPSHOTS are generally not allowed even when they belong to the same project and were built during the same reactor build. We have a complex project with 100+ modules. I want to enforce that no module has dependencies on project SNAPSHOTS that were not included in the build. In such case A would use a stale version of B that happened to be available in the local/remote maven repository. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MENFORCER-185) Require Release Dependencies ignorant about aggregator build
[ https://jira.codehaus.org/browse/MENFORCER-185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=358949#comment-358949 ] Curtis Rueden commented on MENFORCER-185: - +1. My group's projects also use requireReleaseDeps, which works great for single-module projects. I attached a nearly MCVE for illustration. Require Release Dependencies ignorant about aggregator build Key: MENFORCER-185 URL: https://jira.codehaus.org/browse/MENFORCER-185 Project: Maven Enforcer Plugin Issue Type: Bug Components: Standard Rules Affects Versions: 1.3.1 Reporter: Thomas Diesler Attachments: seuss.zip If A depends on B it is ok for A-1.0.0-SNAPSHOT to have snapshot dependency on B-1.0.0-SNAPSHOT if B was build before A during the same reactor build. Using the requireReleaseDeps rule it seems that SNAPSHOTS are generally not allowed even when they belong to the same project and were built during the same reactor build. We have a complex project with 100+ modules. I want to enforce that no module has dependencies on project SNAPSHOTS that were not included in the build. In such case A would use a stale version of B that happened to be available in the local/remote maven repository. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MENFORCER-185) Require Release Dependencies ignorant about aggregator build
[ https://jira.codehaus.org/browse/MENFORCER-185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=358949#comment-358949 ] Curtis Rueden edited comment on MENFORCER-185 at 12/11/14 1:29 PM: --- +1. My group's projects also use requireReleaseDeps, which works great for single-module projects, but not multi-module ones without hacky exclusions. I attached a nearly MCVE for illustration. was (Author: ctrueden): +1. My group's projects also use requireReleaseDeps, which works great for single-module projects. I attached a nearly MCVE for illustration. Require Release Dependencies ignorant about aggregator build Key: MENFORCER-185 URL: https://jira.codehaus.org/browse/MENFORCER-185 Project: Maven Enforcer Plugin Issue Type: Bug Components: Standard Rules Affects Versions: 1.3.1 Reporter: Thomas Diesler Attachments: seuss.zip If A depends on B it is ok for A-1.0.0-SNAPSHOT to have snapshot dependency on B-1.0.0-SNAPSHOT if B was build before A during the same reactor build. Using the requireReleaseDeps rule it seems that SNAPSHOTS are generally not allowed even when they belong to the same project and were built during the same reactor build. We have a complex project with 100+ modules. I want to enforce that no module has dependencies on project SNAPSHOTS that were not included in the build. In such case A would use a stale version of B that happened to be available in the local/remote maven repository. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MENFORCER-185) Require Release Dependencies ignorant about aggregator build
[
https://jira.codehaus.org/browse/MENFORCER-185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=358960#comment-358960
]
Curtis Rueden commented on MENFORCER-185:
-
Thanks for the quick reply, Karl. I want to clarify that this is a fringe issue
for my group's projects, since we have switched almost completely to
single-module projects in separate Git repositories. We have only a couple of
multi-module projects left that get bitten. That said, I agree with the OP that
if you have a 100-module build, and it is important that it have only release
dependencies outside the reactor, it would be awesome if this rule could
support that use case. My personal tack would be to add another boolean
property {{allowSnapshotsInReactor}} which defaults to {{false}} for backwards
compatibility, but can be set to {{true}} to get the desired behavior.
Looking at the source, I wouldn't think a full rewrite is required, but rather
some case logic carefully injected in a couple of places. For example, in
{{RequireReleaseDeps.java}}, in the {{if ( failWhenParentIsSnapshot )}} block,
do not throw the exception if {{allowSnapshotsInReactor}} is set and the parent
is part of the multi-module build. And in the {{checkDependencies}} method, do
not add the artifact to the {{foundSnapshots}} structure if the artifact is
part of the multi-module build.
I'm certainly no expert on the codebase though, so perhaps it is more
complicated than that.
Require Release Dependencies ignorant about aggregator build
Key: MENFORCER-185
URL: https://jira.codehaus.org/browse/MENFORCER-185
Project: Maven Enforcer Plugin
Issue Type: Bug
Components: Standard Rules
Affects Versions: 1.3.1
Reporter: Thomas Diesler
Attachments: seuss.zip
If A depends on B it is ok for A-1.0.0-SNAPSHOT to have snapshot dependency
on B-1.0.0-SNAPSHOT if B was build before A during the same reactor build.
Using the requireReleaseDeps rule it seems that SNAPSHOTS are generally not
allowed even when they belong to the same project and were built during the
same reactor build.
We have a complex project with 100+ modules. I want to enforce that no module
has dependencies on project SNAPSHOTS that were not included in the build. In
such case A would use a stale version of B that happened to be available in
the local/remote maven repository.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-4687) Maven should not warn about incorrect parent path when no relativePath is specified
[
https://jira.codehaus.org/browse/MNG-4687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=314415#comment-314415
]
Curtis Rueden commented on MNG-4687:
Another relevant recent thread from maven-users:
http://mail-archives.apache.org/mod_mbox/maven-users/201211.mbox/%3CCABbdPEaJPFahp8uAWmUYYkjKQQ3XdMWb6eeos9Qbx=h2bdp...@mail.gmail.com%3E
Maven should not warn about incorrect parent path when no relativePath is
specified
---
Key: MNG-4687
URL: https://jira.codehaus.org/browse/MNG-4687
Project: Maven 2 3
Issue Type: Improvement
Components: Logging
Affects Versions: 3.0-beta-1
Reporter: Paul Gier
Priority: Minor
Attachments: MNG-relativePath.zip
If a module pom uses a parent other than the one in the parent directory,
maven logs a warning. In some cases it is necessary that a module pom has an
external parent pom, and there is no way to refer to this external pom in the
relativePath. If nothing is specified in the relativePath, Maven should not
log the warning.
{noformat}
[WARNING] 'parent.relativePath' of POM
org.maven.test:relative-path-parent:0.0.1-SNAPSHOT
(/home/pgier/projects/MNG-relativePath/module-1/pom.xml) points at
org.maven.test:relative-path-test instead of org.apache.maven:maven-parent,
please verify your project structure @
{noformat}
The attached zip reproduces the warning.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-4687) Maven should not warn about incorrect parent path when no relativePath is specified
[
https://jira.codehaus.org/browse/MNG-4687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=307580#comment-307580
]
Curtis Rueden commented on MNG-4687:
I agree with Scott that automatic local resolution would be ideal. To respond
to Laird's concern, without loss of generality, there are six cases for the
behavior:
|| ||no relativePath given in child
POM||relativePath/||relativePath../relativePath||
|*POM in parent dir _is_ the parent*|automatically use local POM in parent
dir|force lookup in repo|force use of local POM in parent|
|*POM in parent dir is _not_ the parent (or there is no POM
there)*|automatically do lookup in repo|force lookup in repo|force use of local
POM in parent (will fail)|
So to avoid the case where the parent directory contains an out-of-date version
of the parent POM, you could add relativePath/ to your child POMs to always
force a repository lookup. Personally I think this is a less common case than
having a multi-module build and desiring it to use the local version of the POM
in the parent directory when present.
This could be implemented easily by adding support for a special token (e.g.,
AUTOMATIC) for the relativePath value, and changing the super POM's default
value from .. as it is now to AUTOMATIC.
Maven should not warn about incorrect parent path when no relativePath is
specified
---
Key: MNG-4687
URL: https://jira.codehaus.org/browse/MNG-4687
Project: Maven 2 3
Issue Type: Improvement
Components: Logging
Affects Versions: 3.0-beta-1
Reporter: Paul Gier
Priority: Minor
Attachments: MNG-relativePath.zip
If a module pom uses a parent other than the one in the parent directory,
maven logs a warning. In some cases it is necessary that a module pom has an
external parent pom, and there is no way to refer to this external pom in the
relativePath. If nothing is specified in the relativePath, Maven should not
log the warning.
{noformat}
[WARNING] 'parent.relativePath' of POM
org.maven.test:relative-path-parent:0.0.1-SNAPSHOT
(/home/pgier/projects/MNG-relativePath/module-1/pom.xml) points at
org.maven.test:relative-path-test instead of org.apache.maven:maven-parent,
please verify your project structure @
{noformat}
The attached zip reproduces the warning.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-623) Assembly documentation does not list all supported formats
Curtis Rueden created MASSEMBLY-623: --- Summary: Assembly documentation does not list all supported formats Key: MASSEMBLY-623 URL: https://jira.codehaus.org/browse/MASSEMBLY-623 Project: Maven 2.x Assembly Plugin Issue Type: Improvement Affects Versions: 2.3 Environment: Website Reporter: Curtis Rueden The assembly plugin supports several different assembly formats. However, the supported formats are enumerated in two different places: * On the [front page|http://maven.apache.org/plugins/maven-assembly-plugin/] * On the [formats/format element of the assembly descriptor page|http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html#assembly]. These two lists do not match; each has at least one item missing from the other. These lists should be reconciled such that either: A) each is a complete listing of all supported formats; or B) one says something like etc. with a link to the other, as a canonical complete listing. I would argue that the formats/format section should list all supported types, since the assembly descriptor page is supposed to be a complete technical description of the descriptor format. The listing on the front page could either link to the descriptor page, or else fully recapitulate the listing, as long as new formats supported in the future continue to get added to both. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-91) Currently the assembly plugin renames SNAPSHOT dependencies to a date stamp ex. api-authorisation-4.00-20060502.150651-20.jar
[
https://jira.codehaus.org/browse/MASSEMBLY-91?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=291558#comment-291558
]
Curtis Rueden commented on MASSEMBLY-91:
David: You can avoid using two separate configurations with the
${dashClassifier?} syntax:
outputFileNameMapping${artifact.artifactId}-${artifact.baseVersion}${dashClassifier?}.${artifact.extension}/outputFileNameMapping
Currently the assembly plugin renames SNAPSHOT dependencies to a date stamp
ex. api-authorisation-4.00-20060502.150651-20.jar
-
Key: MASSEMBLY-91
URL: https://jira.codehaus.org/browse/MASSEMBLY-91
Project: Maven 2.x Assembly Plugin
Issue Type: New Feature
Affects Versions: 2.0.1
Environment: Win XP, Java 1.5
Reporter: Chris Stevenson
Assignee: John Casey
Fix For: 2.2-beta-1
Currently the assembly plugin renames SNAPSHOT dependencies to a date stamp
ex. api-authorisation-4.00-20060502.150651-20.jar. Would it be possible to
offer a flag on the plugin so that this behaviour could be turned off and the
file could remain as api-authorisation-SNAPSHOT.jar?
The renaming of the files causes the files to become invalid when compiling
native or CSharp binaries inside of maven.
Thanks,
Chris Stevenson
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
