[jira] [Commented] (MNG-7852) Use all the versions for dependency resolution rather than "nearest first" or "declared first"
[ https://issues.apache.org/jira/browse/MNG-7852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17749174#comment-17749174 ] Vladimir Sitnikov commented on MNG-7852: {quote} Best would be to move this discussion to ML instead{quote} Would you please clarify why do you think the issue belongs to ML rather than JIRA? I do not understand the reason, and I do not want to get a "file JIRA instead" response on the ML. {quote}Also, you mix runtime and compile time things ("nobody ensure that people can compile code") {quote} Correct me if I am wrong, but the full cite is "nobody ensures that people can compile code with the recent version {*}and supply an old version in the execution{*}". "and supply an old version in the execution" is important as otherwise, the bug won't trigger. Correct me if I am wrong, but Java requires compile code before one can proceed with the execution, and it does matter which third-party libraries were present on the compilation classpath as it affects the resulting bytecode. My example says that projects rarely ensure their jars can be safely downgraded. {quote} You should do your homework{quote} Sure thing. Would you please respond to https://issues.apache.org/jira/browse/MNG-7852?focusedCommentId=17748173&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17748173 or https://issues.apache.org/jira/browse/MNG-7852?focusedCommentId=17748217&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17748217 ? In my examples, the problematic transitive dependencies come from **other** dependencies, and I do not use the problematic ones directly. I do not understand which of them you suggest to "declare as direct". If you suggest declaring all the possible transitive dependencies (including transitives of transitives) as direct, then, well, the re-declaring dependencies approach is prone to errors I described in https://issues.apache.org/jira/browse/MNG-7852?focusedCommentId=17748677&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17748677. > Use all the versions for dependency resolution rather than "nearest first" or > "declared first" > -- > > Key: MNG-7852 > URL: https://issues.apache.org/jira/browse/MNG-7852 > Project: Maven > Issue Type: Improvement > Components: Dependencies >Reporter: Vladimir Sitnikov >Priority: Major > > Currently, Maven uses "nearest first", "declared first" rules for conflict > resolution: > https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html > I suggest those rules are removed since they produce hard to reason > resolutions for transitive dependencies. > Below I list reasons why both "nearest wins" and "declared first" yield > hard-to-predict behaviours, and they are likely to produce dependency > downgrades and the associated runtime errors. > Here are some examples: > 1) "Nearest first". Even though the rule sounds easy, it is not something the > users can control. For instance, if the project does not use Guava library, > some of the transitive dependencies could add a dependency on Guava. The user > has no control which dependency would be "the nearest" to declare Guava, so > user has literally no way to tell which Guava version will be used. > The only workaround I see for the users is to declare Guava dependency > explicitly even though the project does not need it directly. It sounds like > Maven requires users to re-declare all the possible dependencies, including > the runtime-only ones. > 2) "declared first". Of course, dependency order matters for classpath order, > however, it is not predictable in practice, and it might result in > downgrading dependencies. Imagine the project does not use Guice. However, > transitive dependencies might use Guice. At the same time, they might start > using Guice and stop using Guice, so the user can never tell which will be > the first project that uses Guice. Unfortunately, in Maven, the first project > that declares dependency wins, so it might easily be the case that the first > mention of Guice will reference outdated version that would be incompatible > with the newer one required in another dependency. > 3) Here's a real-life case: Maven downgrades protobuf-java dependency causing > something like NoSuchMethodError at the runtime. The step to reproduce is to > add dependency on dev.sigstore:sigstore-java:0.4.0. See [~hboutemy] analysis > in https://github.com/hboutemy/sigstore-maven-plugin/blob/import/analysis.md > Long story short, sigstore-java does not depend on protobuf-java directly, > however, sigstore-java depends on several third-party libraries that > eventually depend on pro
[jira] [Commented] (MNG-7852) Use all the versions for dependency resolution rather than "nearest first" or "declared first"
[ https://issues.apache.org/jira/browse/MNG-7852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17749133#comment-17749133 ] Vladimir Sitnikov commented on MNG-7852: {quote}There is no proper versions nevermind which version we choose during resolving transitive dependencies, alway we can have an incompatibilities between two versions. {quote} The current Maven's algorithm results in *{*}downgrading{*}* versions. Downgrading dependency versions is very often an incompatible change. On the other hand, upgrading a version is more likely to produce a workable classpath because many libraries maintain backward compatibility (== further versions are compatible with previous versions). Let us quantify this. Imagine lib-a with Guava 21 (see https://issues.apache.org/jira/browse/MNG-7852?focusedCommentId=17748217&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17748217) Imagine I use lib-a in my project. Imagine Maven selects Guava 19 for the runtime (e.g., another library introduced guava-19 a little bit earlier in the dependency tree). Of course, the thing will fail at the runtime because lib-a might easily depend on a method added in guava-21. Who will be to blame? Of course, {*}Maven would be to blame{*}, as it downgraded guava from 21 to 19. Imagine an alternative case. Imagine I use lib-a in my project. Imagine Maven selects Guava 30 for the runtime. Of course the thing might fail at the runtime (e.g. if Guava 30 accidentally fails to keep backward compatibility). Who will be to blame in such case? Of course, {*}it would be Guava to blame{*}, and it is unlikely to break as Guava team tests backward compatibility. In other words, almost no library tests for "forward compatibility". In other words, almost nobody ensures that people can compile code with the recent version and supply an old version in the execution. At the same time, many teams verify backward compatibility. That means, upgrading dependencies is much safer than downgrading them. The current Maven's algorithm seems to select semi-random transitive versions which are both unpredictable and might cause downgrades. > Use all the versions for dependency resolution rather than "nearest first" or > "declared first" > -- > > Key: MNG-7852 > URL: https://issues.apache.org/jira/browse/MNG-7852 > Project: Maven > Issue Type: Improvement > Components: Dependencies >Reporter: Vladimir Sitnikov >Priority: Major > > Currently, Maven uses "nearest first", "declared first" rules for conflict > resolution: > https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html > I suggest those rules are removed since they produce hard to reason > resolutions for transitive dependencies. > Below I list reasons why both "nearest wins" and "declared first" yield > hard-to-predict behaviours, and they are likely to produce dependency > downgrades and the associated runtime errors. > Here are some examples: > 1) "Nearest first". Even though the rule sounds easy, it is not something the > users can control. For instance, if the project does not use Guava library, > some of the transitive dependencies could add a dependency on Guava. The user > has no control which dependency would be "the nearest" to declare Guava, so > user has literally no way to tell which Guava version will be used. > The only workaround I see for the users is to declare Guava dependency > explicitly even though the project does not need it directly. It sounds like > Maven requires users to re-declare all the possible dependencies, including > the runtime-only ones. > 2) "declared first". Of course, dependency order matters for classpath order, > however, it is not predictable in practice, and it might result in > downgrading dependencies. Imagine the project does not use Guice. However, > transitive dependencies might use Guice. At the same time, they might start > using Guice and stop using Guice, so the user can never tell which will be > the first project that uses Guice. Unfortunately, in Maven, the first project > that declares dependency wins, so it might easily be the case that the first > mention of Guice will reference outdated version that would be incompatible > with the newer one required in another dependency. > 3) Here's a real-life case: Maven downgrades protobuf-java dependency causing > something like NoSuchMethodError at the runtime. The step to reproduce is to > add dependency on dev.sigstore:sigstore-java:0.4.0. See [~hboutemy] analysis > in https://github.com/hboutemy/sigstore-maven-plugin/blob/import/analysis.md > Long story short, sigstore-java does not depend on protobuf-java directly, > however, sigsto
[jira] [Commented] (MNG-7852) Use all the versions for dependency resolution rather than "nearest first" or "declared first"
[ https://issues.apache.org/jira/browse/MNG-7852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17748677#comment-17748677 ] Vladimir Sitnikov commented on MNG-7852: [~sjaranowski] , thanks for mentioning dependencyConvergence, however, I do not think it is a generally recommended solution unless you make the said enforcer rule enabled by default in all Maven installations. enforcer does not help users "resolve the conflicts properly". I agree enforcer might make the dependency resolution issue easier to spot, however, it does not treat the root cause. The idea behind the current issue is to tune Maven's behaviour so it resolves proper versions in the first place rather than perform silent downgrades. {quote}You need resolve conflicts in your project {quote} Could you please clarify what you mean by "resolve conflicts"? Correct me if I am wrong, but it means "re-declaring all (conflicting?) transitive dependencies" which is a bad idea because re-declared dependencies might get out of date (e.g. they might become stale, bad versions, and so on). > Use all the versions for dependency resolution rather than "nearest first" or > "declared first" > -- > > Key: MNG-7852 > URL: https://issues.apache.org/jira/browse/MNG-7852 > Project: Maven > Issue Type: Improvement > Components: Dependencies >Reporter: Vladimir Sitnikov >Priority: Major > > Currently, Maven uses "nearest first", "declared first" rules for conflict > resolution: > https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html > I suggest those rules are removed since they produce hard to reason > resolutions for transitive dependencies. > Below I list reasons why both "nearest wins" and "declared first" yield > hard-to-predict behaviours, and they are likely to produce dependency > downgrades and the associated runtime errors. > Here are some examples: > 1) "Nearest first". Even though the rule sounds easy, it is not something the > users can control. For instance, if the project does not use Guava library, > some of the transitive dependencies could add a dependency on Guava. The user > has no control which dependency would be "the nearest" to declare Guava, so > user has literally no way to tell which Guava version will be used. > The only workaround I see for the users is to declare Guava dependency > explicitly even though the project does not need it directly. It sounds like > Maven requires users to re-declare all the possible dependencies, including > the runtime-only ones. > 2) "declared first". Of course, dependency order matters for classpath order, > however, it is not predictable in practice, and it might result in > downgrading dependencies. Imagine the project does not use Guice. However, > transitive dependencies might use Guice. At the same time, they might start > using Guice and stop using Guice, so the user can never tell which will be > the first project that uses Guice. Unfortunately, in Maven, the first project > that declares dependency wins, so it might easily be the case that the first > mention of Guice will reference outdated version that would be incompatible > with the newer one required in another dependency. > 3) Here's a real-life case: Maven downgrades protobuf-java dependency causing > something like NoSuchMethodError at the runtime. The step to reproduce is to > add dependency on dev.sigstore:sigstore-java:0.4.0. See [~hboutemy] analysis > in https://github.com/hboutemy/sigstore-maven-plugin/blob/import/analysis.md > Long story short, sigstore-java does not depend on protobuf-java directly, > however, sigstore-java depends on several third-party libraries that > eventually depend on protobuf-java. Maven's "the first wins" behaviour > results in incoherent set of protobuf dependencies on the classpath. > 4) see "unexpected" in MNG-5988 > To my best understanding, when it comes to transitive dependencies, both > "nearest first" and "declared first" are random variables which user can't > control unless they re-declare all the dependencies in their local pom. I > suggest Maven should not use random variables like "dependency depth" or > "dependency order" to drive conflict resolution. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7852) Use all the versions for dependency resolution rather than "nearest first" or "declared first"
[ https://issues.apache.org/jira/browse/MNG-7852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17748323#comment-17748323 ] Vladimir Sitnikov commented on MNG-7852: Well, one of the workable algorithms is described at [https://docs.gradle.org/current/userguide/dependency_resolution.html#sub:resolution-strategy] Of course, it would require rich versions (which would be useful in Maven anyway). So it would make sense if Maven could consume and produce Gradle Module Metadata to resolve and use rich version declarations and dependency constraints. With the new algorithm, many projects would just work since users often re-declare dependencies to avoid downgrades. Of course, the ones who intentionally performed downgrade would need some treatment, however, I am sure there is a possibility to make the transition smooth. For instance, Maven could resolve the deps with two algorithms, and issue a warning when the results diverge > Use all the versions for dependency resolution rather than "nearest first" or > "declared first" > -- > > Key: MNG-7852 > URL: https://issues.apache.org/jira/browse/MNG-7852 > Project: Maven > Issue Type: Improvement > Components: Dependencies >Reporter: Vladimir Sitnikov >Priority: Major > > Currently, Maven uses "nearest first", "declared first" rules for conflict > resolution: > https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html > I suggest those rules are removed since they produce hard to reason > resolutions for transitive dependencies. > Below I list reasons why both "nearest wins" and "declared first" yield > hard-to-predict behaviours, and they are likely to produce dependency > downgrades and the associated runtime errors. > Here are some examples: > 1) "Nearest first". Even though the rule sounds easy, it is not something the > users can control. For instance, if the project does not use Guava library, > some of the transitive dependencies could add a dependency on Guava. The user > has no control which dependency would be "the nearest" to declare Guava, so > user has literally no way to tell which Guava version will be used. > The only workaround I see for the users is to declare Guava dependency > explicitly even though the project does not need it directly. It sounds like > Maven requires users to re-declare all the possible dependencies, including > the runtime-only ones. > 2) "declared first". Of course, dependency order matters for classpath order, > however, it is not predictable in practice, and it might result in > downgrading dependencies. Imagine the project does not use Guice. However, > transitive dependencies might use Guice. At the same time, they might start > using Guice and stop using Guice, so the user can never tell which will be > the first project that uses Guice. Unfortunately, in Maven, the first project > that declares dependency wins, so it might easily be the case that the first > mention of Guice will reference outdated version that would be incompatible > with the newer one required in another dependency. > 3) Here's a real-life case: Maven downgrades protobuf-java dependency causing > something like NoSuchMethodError at the runtime. The step to reproduce is to > add dependency on dev.sigstore:sigstore-java:0.4.0. See [~hboutemy] analysis > in https://github.com/hboutemy/sigstore-maven-plugin/blob/import/analysis.md > Long story short, sigstore-java does not depend on protobuf-java directly, > however, sigstore-java depends on several third-party libraries that > eventually depend on protobuf-java. Maven's "the first wins" behaviour > results in incoherent set of protobuf dependencies on the classpath. > 4) see "unexpected" in MNG-5988 > To my best understanding, when it comes to transitive dependencies, both > "nearest first" and "declared first" are random variables which user can't > control unless they re-declare all the dependencies in their local pom. I > suggest Maven should not use random variables like "dependency depth" or > "dependency order" to drive conflict resolution. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MNG-7852) Use all the versions for dependency resolution rather than "nearest first" or "declared first"
[ https://issues.apache.org/jira/browse/MNG-7852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17748217#comment-17748217 ] Vladimir Sitnikov edited comment on MNG-7852 at 7/27/23 4:02 PM: - One more case (5): * I'm the author of my-lib * my-lib does not use guava, and it does not use guice * my-lib uses both lib-a and lib-b which are third-party libraries, and I have no direct control over them * lib-a uses guava 21 (==it depends on classes added in guava 21) * lib-a uses guice 5 (==it depends on classes added in guice 5, and it would fail with guice 3 on the classpath) * lib-b uses guava 23 (== it depends on a class that was added in guava 23, and it would fail with guava 21) * lib-b uses guice 3 (== it depends on a class that was added in guice 3) In that case, Maven is doomed to resolve an incompatible configuration. It will not fail the build, but it would build an artifact that throws errors at the runtime (either guava or guice would resolve to an too old version). Once again, I understand that the workaround is to re-declare every possible version locally. However, well, what is the point of having "nearest first" strategy if it forces everybody to re-redeclare all the transitive versions? Of course, I understand, that re-declaration is not that needed when there are no conflicts. Unfortunately, I do not understand how Maven users figure out if they have conflicts or not. All these problems would just go away if Maven considered all versions instead of "the first mentioned" ones. was (Author: vladimirsitnikov): One more case (5): * I'm the author of my-lib * my-lib does not use guava, and it does not use guice * my-lib uses both lib-a and lib-b which are third-party libraries, and I have no direct control over them * lib-a uses guava 21 (==it depends on classes added in guava 21) * lib-a uses guice 5 (==it depends on classes added in guice 5, and it would fail with guice 3 on the classpath) * lib-b uses guava 23 (== it depends on a class that was added in guava 23, and it would fail with guava 21) * lib-b uses guice 3 (== it depends on a class that was added in guice 3) In that case, Maven is doomed to resolve an incompatible configuration. It will not fail the build, but it would build an artifact that is throws errors at the runtime (either guava or guice would resolve to an too old version). Once again, I understand that the workaround is to re-declare every possible version locally. However, well, what is the point of having "nearest first" strategy if it forces everybody to re-redeclare all the transitive versions? Of course, I understand, that re-declaration is not that needed when there are no conflicts. Unfortunately, I do not understand how Maven users figure out if they have conflicts or not. All these problems would just go away if Maven considered all versions instead of "the first mentioned" ones. > Use all the versions for dependency resolution rather than "nearest first" or > "declared first" > -- > > Key: MNG-7852 > URL: https://issues.apache.org/jira/browse/MNG-7852 > Project: Maven > Issue Type: Improvement > Components: Dependencies >Reporter: Vladimir Sitnikov >Priority: Major > > Currently, Maven uses "nearest first", "declared first" rules for conflict > resolution: > https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html > I suggest those rules are removed since they produce hard to reason > resolutions for transitive dependencies. > Below I list reasons why both "nearest wins" and "declared first" yield > hard-to-predict behaviours, and they are likely to produce dependency > downgrades and the associated runtime errors. > Here are some examples: > 1) "Nearest first". Even though the rule sounds easy, it is not something the > users can control. For instance, if the project does not use Guava library, > some of the transitive dependencies could add a dependency on Guava. The user > has no control which dependency would be "the nearest" to declare Guava, so > user has literally no way to tell which Guava version will be used. > The only workaround I see for the users is to declare Guava dependency > explicitly even though the project does not need it directly. It sounds like > Maven requires users to re-declare all the possible dependencies, including > the runtime-only ones. > 2) "declared first". Of course, dependency order matters for classpath order, > however, it is not predictable in practice, and it might result in > downgrading dependencies. Imagine the project does not use Guice. However, > transitive dependencies might use Guice. At the same time, they might start > using Guice and stop u
[jira] [Comment Edited] (MNG-7852) Use all the versions for dependency resolution rather than "nearest first" or "declared first"
[ https://issues.apache.org/jira/browse/MNG-7852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17748217#comment-17748217 ] Vladimir Sitnikov edited comment on MNG-7852 at 7/27/23 3:46 PM: - One more case (5): * I'm the author of my-lib * my-lib does not use guava, and it does not use guice * my-lib uses both lib-a and lib-b which are third-party libraries, and I have no direct control over them * lib-a uses guava 21 (==it depends on classes added in guava 21) * lib-a uses guice 5 (==it depends on classes added in guice 5, and it would fail with guice 3 on the classpath) * lib-b uses guava 23 (== it depends on a class that was added in guava 23, and it would fail with guava 21) * lib-b uses guice 3 (== it depends on a class that was added in guice 3) In that case, Maven is doomed to resolve an incompatible configuration. It will not fail the build, but it would build an artifact that is throws errors at the runtime (either guava or guice would resolve to an too old version). Once again, I understand that the workaround is to re-declare every possible version locally. However, well, what is the point of having "nearest first" strategy if it forces everybody to re-redeclare all the transitive versions? Of course, I understand, that re-declaration is not that needed when there are no conflicts. Unfortunately, I do not understand how Maven users figure out if they have conflicts or not. All these problems would just go away if Maven considered all versions instead of "the first mentioned" ones. was (Author: vladimirsitnikov): One more case (5): * I'm the author of my-lib * my-lib does not use guava, and it does not use guice * my-lib uses both lib-a and lib-b which are third-party libraries, and I have no direct control over them * lib-a uses guava 21 (==it depends on classes added in guava 21) * lib-a uses guice 5 (==it depends on classes added in guice 5, and it would fail with guice 3 on the classpath) * lib-b uses guava 23 (== it depends on a class that was added in guava 23, and it would fail with guava 21) * lib-b uses guice 3 (== it depends on a class that was added in guice 3) In that case, Maven is doomed to resolve an incompatible configuration. It will not fail the build, but it would build an artifact that is throws errors in the runtime (either guava or guice would resolve to an too old version). Once again, I understand that the workaround is to re-declare every possible version locally. However, well, what is the point of having "nearest first" strategy if it forces everybody to re-redeclare all the transitive versions? Of course, I understand, that re-declaration is not that needed when there are no conflicts. Unfortunately, I do not understand how Maven users figure out if they have conflicts or not. All these problems would just go away if Maven considered all versions instead of "the first mentioned" ones. > Use all the versions for dependency resolution rather than "nearest first" or > "declared first" > -- > > Key: MNG-7852 > URL: https://issues.apache.org/jira/browse/MNG-7852 > Project: Maven > Issue Type: Improvement > Components: Dependencies >Reporter: Vladimir Sitnikov >Priority: Major > > Currently, Maven uses "nearest first", "declared first" rules for conflict > resolution: > https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html > I suggest those rules are removed since they produce hard to reason > resolutions for transitive dependencies. > Below I list reasons why both "nearest wins" and "declared first" yield > hard-to-predict behaviours, and they are likely to produce dependency > downgrades and the associated runtime errors. > Here are some examples: > 1) "Nearest first". Even though the rule sounds easy, it is not something the > users can control. For instance, if the project does not use Guava library, > some of the transitive dependencies could add a dependency on Guava. The user > has no control which dependency would be "the nearest" to declare Guava, so > user has literally no way to tell which Guava version will be used. > The only workaround I see for the users is to declare Guava dependency > explicitly even though the project does not need it directly. It sounds like > Maven requires users to re-declare all the possible dependencies, including > the runtime-only ones. > 2) "declared first". Of course, dependency order matters for classpath order, > however, it is not predictable in practice, and it might result in > downgrading dependencies. Imagine the project does not use Guice. However, > transitive dependencies might use Guice. At the same time, they might start > using Guice and sto
[jira] [Commented] (MNG-7852) Use all the versions for dependency resolution rather than "nearest first" or "declared first"
[ https://issues.apache.org/jira/browse/MNG-7852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17748217#comment-17748217 ] Vladimir Sitnikov commented on MNG-7852: One more case (5): * I'm the author of my-lib * my-lib does not use guava, and it does not use guice * my-lib uses both lib-a and lib-b which are third-party libraries, and I have no direct control over them * lib-a uses guava 21 (==it depends on classes added in guava 21) * lib-a uses guice 5 (==it depends on classes added in guice 5, and it would fail with guice 3 on the classpath) * lib-b uses guava 23 (== it depends on a class that was added in guava 23, and it would fail with guava 21) * lib-b uses guice 3 (== it depends on a class that was added in guice 3) In that case, Maven is doomed to resolve an incompatible configuration. It will not fail the build, but it would build an artifact that is throws errors in the runtime (either guava or guice would resolve to an too old version). Once again, I understand that the workaround is to re-declare every possible version locally. However, well, what is the point of having "nearest first" strategy if it forces everybody to re-redeclare all the transitive versions? Of course, I understand, that re-declaration is not that needed when there are no conflicts. Unfortunately, I do not understand how Maven users figure out if they have conflicts or not. All these problems would just go away if Maven considered all versions instead of "the first mentioned" ones. > Use all the versions for dependency resolution rather than "nearest first" or > "declared first" > -- > > Key: MNG-7852 > URL: https://issues.apache.org/jira/browse/MNG-7852 > Project: Maven > Issue Type: Improvement > Components: Dependencies >Reporter: Vladimir Sitnikov >Priority: Major > > Currently, Maven uses "nearest first", "declared first" rules for conflict > resolution: > https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html > I suggest those rules are removed since they produce hard to reason > resolutions for transitive dependencies. > Below I list reasons why both "nearest wins" and "declared first" yield > hard-to-predict behaviours, and they are likely to produce dependency > downgrades and the associated runtime errors. > Here are some examples: > 1) "Nearest first". Even though the rule sounds easy, it is not something the > users can control. For instance, if the project does not use Guava library, > some of the transitive dependencies could add a dependency on Guava. The user > has no control which dependency would be "the nearest" to declare Guava, so > user has literally no way to tell which Guava version will be used. > The only workaround I see for the users is to declare Guava dependency > explicitly even though the project does not need it directly. It sounds like > Maven requires users to re-declare all the possible dependencies, including > the runtime-only ones. > 2) "declared first". Of course, dependency order matters for classpath order, > however, it is not predictable in practice, and it might result in > downgrading dependencies. Imagine the project does not use Guice. However, > transitive dependencies might use Guice. At the same time, they might start > using Guice and stop using Guice, so the user can never tell which will be > the first project that uses Guice. Unfortunately, in Maven, the first project > that declares dependency wins, so it might easily be the case that the first > mention of Guice will reference outdated version that would be incompatible > with the newer one required in another dependency. > 3) Here's a real-life case: Maven downgrades protobuf-java dependency causing > something like NoSuchMethodError at the runtime. The step to reproduce is to > add dependency on dev.sigstore:sigstore-java:0.4.0. See [~hboutemy] analysis > in https://github.com/hboutemy/sigstore-maven-plugin/blob/import/analysis.md > Long story short, sigstore-java does not depend on protobuf-java directly, > however, sigstore-java depends on several third-party libraries that > eventually depend on protobuf-java. Maven's "the first wins" behaviour > results in incoherent set of protobuf dependencies on the classpath. > 4) see "unexpected" in MNG-5988 > To my best understanding, when it comes to transitive dependencies, both > "nearest first" and "declared first" are random variables which user can't > control unless they re-declare all the dependencies in their local pom. I > suggest Maven should not use random variables like "dependency depth" or > "dependency order" to drive conflict resolution. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7852) Use all the versions for dependency resolution rather than "nearest first" or "declared first"
[ https://issues.apache.org/jira/browse/MNG-7852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17748173#comment-17748173 ] Vladimir Sitnikov commented on MNG-7852: {quote}This "real life example" is totally along the lines of Maven specd behaviour {quote} Tamas, many thanks for your comments, however, I still struggle to figure out {*}{{*}}why{{*}}{*} Maven behaves like "nearest first". The behaviour produces hard-to-reason failures, and it is unclear what could be the benefits of such an algorithm except "dumb-easy to implement". {quote}As you (I guess) implied, this can be solved by multiple means, ideally by depMgmt. And yes, Maven makes you able to "not care", unlike Ant and others, where you need to enlist (and control) all the versions, with Maven you leave this to resolution. Or in other words, IF you care ("user has no control"), then use proper means like depMgt to sort out your issues. {quote} I am afraid I do not understand the suggestion here. Imagine * I'm the author of my-lib * my-lib does not use guava * my-lib uses both lib-a and lib-b which are third-party libraries, and I have no direct control over them * lib-a uses guava 21 (==it depends on classes added in guava 21, and it would work fine with guava 23) * lib-b uses guava 23 (== it depends on a class that was added in guava 23 only, and it would fail with guava 21) What is your exact suggestion? Do you suggest that I (as an author of my-lib) should explicitly mention "my-lib requires guava 23 on the runtime scope"? Of course, it would workaround the issue, however, it is exactly the duplication I do not like. As an author of my-lib, I do not really want to manually collect all the third-party transitive dependencies and figure out the compatible versions for them. I expect that dependency manager would do that. At the same time, if I just add both dependencies on lib-a and lib-b, then Maven would resolve a *{*}random{*}* guava version depending on which of lib-a or lib-b was first on the list and/or which of them listed guava "closer to the dependency root". Please, acknowledge that "dependency deepness" is random, and I don't control which of lib-a or lib-b would put guava deeper. In other words: * If I omit guava in my-lib, then Maven resolves random version, and I get crashes when Maven resolves guava 21 (e.g. lib-a was the first) * If I list guava in my-lib, then I would have to list every possible transitive dependency explicitly, and my list might easily get out of date. That is not much different from using wget and putting jars on the classpath. If Maven resolved all the versions no matter how deep they were declared, then Maven could figure out the latest version, and it would avoid runtime failures. {quote}Given this example is "oddly specific", I'd assume here some integration happens (DI container is expected at runtime), so yes, here you should either use "aligned libraries" (not always possible, especially if they are from multiple vendors) or then it is up to you to sort out the conflicts between them. Many many tools out there, ranging from Maven plugins to IDEs help you doing this. {quote} I am afraid I do not understand your suggestion here :( Imagine the case is: * I'm the author of my-lib * my-lib does not use guice * my-lib uses both lib-a and lib-b which are third-party libraries, and I have no direct control over them * lib-a does not use guice * lib-b uses guice 5 * Imagine my-lib declared dependencies in order of "lib-a, then lib-b", because, well, it was just fine So far, so good. Then: * lib-a started using guice 3 Maven would cause runtime failures, because it would resolve guice 3, while lib-b required guice 5. I do not understand why do you suggest resorting to third-party plugins and IDEs even for such a trivial case like library with a couple of transitive dependencies. I understand that I can workaround the case by declaring guice version explicitly, however, I do not understand why Maven requires duplicating dependency information. If Maven discovered all the versions (guice 3 and guice 5), then it could resolve the conflicts and come up with guice 5 on the classpath. {quote} you mention "no such method" with protobuf-java, so I assumed Maven "wildly mixed" versions (like major ones), but to me it seems you talk about this issue{quote} No. protobuf-java issue is not 11393, but it is like "Maven downgraded protobuf-java dependency, so the app failed". Here's the error message: https://youtu.be/2kooPqDguyw?t=7087 In other words: sigstore-java used protobuf compiler 3.22, however, Maven resolved protobuf-java 3.21 for the runtime. It failed with the dreaded emptyList error leaving maven users no clue on the way to fix it. {quote}Best would be to move this discussion to ML instead, preferably the users mailing list https://
[jira] [Commented] (MNG-7853) Support Gradle Module Metadata
[ https://issues.apache.org/jira/browse/MNG-7853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17748077#comment-17748077 ] Vladimir Sitnikov commented on MNG-7853: Module Metadata covers "capabilities" case as well: https://issues.apache.org/jira/browse/MNG-5652?focusedCommentId=17748076&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17748076 > Support Gradle Module Metadata > -- > > Key: MNG-7853 > URL: https://issues.apache.org/jira/browse/MNG-7853 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories, Dependencies, POM >Reporter: Vladimir Sitnikov >Priority: Major > > Currently, Maven lacks ability to describe and consume metadata for the > artifacts. > I suggest Maven should use Gradle Module Metadata format for both publication > and consumption. > Note: Gradle Module Metadata does not require Gradle, and it is a generic > format describing artifacts and attributes. > --- > For instance, if somebody publishes "artifact with classifier", then Maven > can't express what stands behind the artifact, and there's no way to add a > dependency without mentioning the classifier explicitly. > There are cases when hard-coding artifact names is not workable: > * jars targeted for different JDK versions: -jre8.jar > * jars targeted for different Operating Systems: -linux, -windows, -... > * test jars: -tests.jar > All of the above have no metadata, so the ones who consume the jars can't > just ask "I need a Java 11 compatible artifact for macOS ARM". With Maven the > only possibility is to hard-code the classifier name, and the classifiers are > different across projects. > Gradle Module Metadata enables publishers to describe the set of published > artifacts, so it is easier to consume. > > For instance, Guava uses versions like 28.1-android, 28.0-jre, and > 26.0-android. It is a workaround to overcome the lack of metadata handling in > Maven dependency resolution. > It would be way better for the end users to declare "guava version they need > like 28.1", and "target platform they need like java 11". Then Maven should > resolve all the dependencies according to the requested attributes, so Maven > could resolve the appropriate classifiers for the dependencies. Ideally, the > use of explicit classifiers in dependency declaration should be deprecated. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-5652) "supplies"/"provides"/"proffers" concept proposal
[ https://issues.apache.org/jira/browse/MNG-5652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17748076#comment-17748076 ] Vladimir Sitnikov commented on MNG-5652: Version ranges often create complexity issues. Would it be enough to use a fixed capability version rather than a range? For instance, Gradle supports single-version capabilities for quite some time now, and it is enough to describe many cases in JVM ecosystem. See * [https://docs.gradle.org/current/userguide/component_capabilities.html] * [https://github.com/gradlex-org/java-ecosystem-capabilities] At the same time, Gradle Module Metadata can already describe the capabilities (see [https://github.com/gradle/gradle/blob/48257a8256a089c426df1a787d1dec5b233cd77b/subprojects/docs/src/docs/design/gradle-module-metadata-latest-specification.md#capabilities-value] ) > "supplies"/"provides"/"proffers" concept proposal > - > > Key: MNG-5652 > URL: https://issues.apache.org/jira/browse/MNG-5652 > Project: Maven > Issue Type: New Feature > Components: FDPFC >Reporter: Stephen Connolly >Priority: Major > > The exact name is still undecided. Some candidate names are: "supplies", > "provides", and "proffers" > h2. "supplies" concept proposal > === > h3. Introduction > > The following is a proposal for Maven in a post-modelVersion-4.0.0 era. The > aim of this proposal is to simplify the management of dependency trees in the > decentralised era of artifact production that we find ourselves in. > The core issue is that different organisations can produce artifacts that may > overlap. The easiest example is the servlet-api. If we restrict ourselves to > version 2.5 of the servlet specification there are quite a few artifacts that > all deliver the exact same content: > * {{jetty:servlet-api:2.5-6.0.2}} > * {{org.daisy.libs:servlet-api:2.5.0}} > * {{org.mortbay.jetty:servlet-api-2.5:6.1.14}} > * {{org.jboss.spec.javax.servlet:jboss-servlet-api_2.5_spec:1.0.1.Final}} > * etc > **Note:** this is a generic problem that is not restricted to the > servlet-api, the servlet-api just provides the example that will be most > familiar to everyone. > So where these multiple artifacts supplying the equivalent content becomes a > problem is when the dependency tree is being calculated. If you have two > dependencies each declaring transitive dependencies on different artifacts > that supply equivalent content, then you end up with two copies of the same > JAR file in your classpath. > In the case of the servlet-api, the hack most people use is to declare the > servlet-api with scope `provided` thus preventing it from being transitive. > This is, however, a hack. In a more ideal world it would be better to let the > servlet-api be transitive and only when we get to the WAR module would we > declare that a specific servlet-api is to be provided in the containers that > the WAR is targets for deployment into. > We can take a second example that does not have the luxury of a *de facto* > hack. > * {{javax.faces:jsf-api:2.1}} > * {{org.jboss.spec.javax.faces:jboss-jsf-api_2.1_spec:2.1.28.Final}} > * {{org.apache.myfaces.core:myfaces-api:2.1.13}} > Now in the case of the JSF API, you are supposed to bundle the JSF API in > your WAR file. So if I use three JSF component libraries, I could very well > end up with three different but equivalent JSF API jars in my WAR file. > Ideally what we want is some way of telling Maven that these artifacts are > equivalent. > Proposal > > Introduce the concept of "supplies" to the project model. The concept needs > three changes to the project model: > 1. An explicit top level construct for a project to explicitly declare > up-front artifacts that it knows - at the time the project is being authored > - to contain equivalent content to at least a subset of the project's > content. Declarations could include a claim from: `subset`, `superset`, > `disjoint` and `equivalent` with the default being `disjoint`. > 2. An explicit sub-element of the `dependency` construct to allow consumers > to *post-facto* declare a specific dependency as supplying equivalent content > for other dependencies > 3. An extension to the `dependency/excludes/exclude` construct to allow > consumers to remove claims a dependency makes with respect to supplying > equivalent content > By way of illustration, here are some examples of these constructs mapped to > a Model Version 4.0.0 like XML schema. As the post-modelVersion-4.0.0 schema > is not yet known, this represents the best way to illustrate how the concept > will work, but note that this proposal does not suggest a schema for this > concept. > h3. Example 1 > This illustrates how we would want, say, th
[jira] [Created] (MNG-7853) Support Gradle Module Metadata
Vladimir Sitnikov created MNG-7853: -- Summary: Support Gradle Module Metadata Key: MNG-7853 URL: https://issues.apache.org/jira/browse/MNG-7853 Project: Maven Issue Type: Improvement Components: Artifacts and Repositories, Dependencies, POM Reporter: Vladimir Sitnikov Currently, Maven lacks ability to describe and consume metadata for the artifacts. I suggest Maven should use Gradle Module Metadata format for both publication and consumption. Note: Gradle Module Metadata does not require Gradle, and it is a generic format describing artifacts and attributes. --- For instance, if somebody publishes "artifact with classifier", then Maven can't express what stands behind the artifact, and there's no way to add a dependency without mentioning the classifier explicitly. There are cases when hard-coding artifact names is not workable: * jars targeted for different JDK versions: -jre8.jar * jars targeted for different Operating Systems: -linux, -windows, -... * test jars: -tests.jar All of the above have no metadata, so the ones who consume the jars can't just ask "I need a Java 11 compatible artifact for macOS ARM". With Maven the only possibility is to hard-code the classifier name, and the classifiers are different across projects. Gradle Module Metadata enables publishers to describe the set of published artifacts, so it is easier to consume. For instance, Guava uses versions like 28.1-android, 28.0-jre, and 26.0-android. It is a workaround to overcome the lack of metadata handling in Maven dependency resolution. It would be way better for the end users to declare "guava version they need like 28.1", and "target platform they need like java 11". Then Maven should resolve all the dependencies according to the requested attributes, so Maven could resolve the appropriate classifiers for the dependencies. Ideally, the use of explicit classifiers in dependency declaration should be deprecated. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MNG-7852) Use all the versions for dependency resolution rather than "nearest first" or "declared first"
[ https://issues.apache.org/jira/browse/MNG-7852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17747891#comment-17747891 ] Vladimir Sitnikov edited comment on MNG-7852 at 7/27/23 10:03 AM: -- {quote}Am really unsure what you want to see as solution here {quote} It would really help me if you could suggest how Maven solves the issues in the description: 1, 2, 3. The only workaround I can imagine for now is to re-declare all the dependencies manually, including the runtime dependencies of all the transitives. Of course, if dependencies are re-declared, they might get out of date, so it doesn't sound like a reasonable solution to me. I suggest that Maven expand the complete dependency (regular dependency, and dependencyManagement) tree, and then perform conflict resolution. When dealing with conflict resolution, "newest wins" makes more sense than "oldest wins". "newest wins unless there are other constraints" is even easier to describe to the end users, it does not suffer from "unexpected dependency downgrade", and it does not rely on semi-random (uncontrollable) variables like "dependency depth" or "dependency order". There's an option of "fail on conflict", however, it is not that practical. Of course, it would be nice if Maven supported rich version constraints like "requires", "prefers", "rejects", "strictly", however, it is a different story. was (Author: vladimirsitnikov): {quote}Am really unsure what you want to see as solution here {quote} It would really help me if you could suggest how Maven solves the issues in the description: 1, 2, 3. The only workaround I can imagine for now is to re-declare all the dependencies manually, including the runtime dependencies of all the transitives. Of course, if dependencies are re-declared, they might get out of date, so it doesn't sound like a reasonable solution to me. I suggest that Maven expand the complete dependency (regular dependency, and dependencyManagement) tree, and then perform conflict resolution. When dealing with conflict resolution, "newest wins" makes more sense than "oldest wins". There's an option of "fail on conflict", however, it is not that practical. Of course, it would be nice if Maven supported rich version constraints like "requires", "prefers", "rejects", "strictly", however, it is a different story. > Use all the versions for dependency resolution rather than "nearest first" or > "declared first" > -- > > Key: MNG-7852 > URL: https://issues.apache.org/jira/browse/MNG-7852 > Project: Maven > Issue Type: Improvement > Components: Dependencies >Reporter: Vladimir Sitnikov >Priority: Major > > Currently, Maven uses "nearest first", "declared first" rules for conflict > resolution: > https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html > I suggest those rules are removed since they produce hard to reason > resolutions for transitive dependencies. > Below I list reasons why both "nearest wins" and "declared first" yield > hard-to-predict behaviours, and they are likely to produce dependency > downgrades and the associated runtime errors. > Here are some examples: > 1) "Nearest first". Even though the rule sounds easy, it is not something the > users can control. For instance, if the project does not use Guava library, > some of the transitive dependencies could add a dependency on Guava. The user > has no control which dependency would be "the nearest" to declare Guava, so > user has literally no way to tell which Guava version will be used. > The only workaround I see for the users is to declare Guava dependency > explicitly even though the project does not need it directly. It sounds like > Maven requires users to re-declare all the possible dependencies, including > the runtime-only ones. > 2) "declared first". Of course, dependency order matters for classpath order, > however, it is not predictable in practice, and it might result in > downgrading dependencies. Imagine the project does not use Guice. However, > transitive dependencies might use Guice. At the same time, they might start > using Guice and stop using Guice, so the user can never tell which will be > the first project that uses Guice. Unfortunately, in Maven, the first project > that declares dependency wins, so it might easily be the case that the first > mention of Guice will reference outdated version that would be incompatible > with the newer one required in another dependency. > 3) Here's a real-life case: Maven downgrades protobuf-java dependency causing > something like NoSuchMethodError at the runtime. The step to reproduce is to > add dependency on dev.sigstore:sigstore-java:0.4.0. See [~hbout
[jira] [Commented] (MNG-7852) Use all the versions for dependency resolution rather than "nearest first" or "declared first"
[ https://issues.apache.org/jira/browse/MNG-7852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17747891#comment-17747891 ] Vladimir Sitnikov commented on MNG-7852: {quote}Am really unsure what you want to see as solution here {quote} It would really help me if you could suggest how Maven solves the issues in the description: 1, 2, 3. The only workaround I can imagine for now is to re-declare all the dependencies manually, including the runtime dependencies of all the transitives. Of course, if dependencies are re-declared, they might get out of date, so it doesn't sound like a reasonable solution to me. I suggest that Maven expand the complete dependency (regular dependency, and dependencyManagement) tree, and then perform conflict resolution. When dealing with conflict resolution, "newest wins" makes more sense than "oldest wins". There's an option of "fail on conflict", however, it is not that practical. Of course, it would be nice if Maven supported rich version constraints like "requires", "prefers", "rejects", "strictly", however, it is a different story. > Use all the versions for dependency resolution rather than "nearest first" or > "declared first" > -- > > Key: MNG-7852 > URL: https://issues.apache.org/jira/browse/MNG-7852 > Project: Maven > Issue Type: Improvement > Components: Dependencies >Reporter: Vladimir Sitnikov >Priority: Major > > Currently, Maven uses "nearest first", "declared first" rules for conflict > resolution: > https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html > I suggest those rules are removed since they produce hard to reason > resolutions for transitive dependencies. > Below I list reasons why both "nearest wins" and "declared first" yield > hard-to-predict behaviours, and they are likely to produce dependency > downgrades and the associated runtime errors. > Here are some examples: > 1) "Nearest first". Even though the rule sounds easy, it is not something the > users can control. For instance, if the project does not use Guava library, > some of the transitive dependencies could add a dependency on Guava. The user > has no control which dependency would be "the nearest" to declare Guava, so > user has literally no way to tell which Guava version will be used. > The only workaround I see for the users is to declare Guava dependency > explicitly even though the project does not need it directly. It sounds like > Maven requires users to re-declare all the possible dependencies, including > the runtime-only ones. > 2) "declared first". Of course, dependency order matters for classpath order, > however, it is not predictable in practice, and it might result in > downgrading dependencies. Imagine the project does not use Guice. However, > transitive dependencies might use Guice. At the same time, they might start > using Guice and stop using Guice, so the user can never tell which will be > the first project that uses Guice. Unfortunately, in Maven, the first project > that declares dependency wins, so it might easily be the case that the first > mention of Guice will reference outdated version that would be incompatible > with the newer one required in another dependency. > 3) Here's a real-life case: Maven downgrades protobuf-java dependency causing > something like NoSuchMethodError at the runtime. The step to reproduce is to > add dependency on dev.sigstore:sigstore-java:0.4.0. See [~hboutemy] analysis > in https://github.com/hboutemy/sigstore-maven-plugin/blob/import/analysis.md > Long story short, sigstore-java does not depend on protobuf-java directly, > however, sigstore-java depends on several third-party libraries that > eventually depend on protobuf-java. Maven's "the first wins" behaviour > results in incoherent set of protobuf dependencies on the classpath. > 4) see "unexpected" in MNG-5988 > To my best understanding, when it comes to transitive dependencies, both > "nearest first" and "declared first" are random variables which user can't > control unless they re-declare all the dependencies in their local pom. I > suggest Maven should not use random variables like "dependency depth" or > "dependency order" to drive conflict resolution. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7852) Use all the versions for dependency resolution rather than "nearest first" or "declared first"
[ https://issues.apache.org/jira/browse/MNG-7852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17747888#comment-17747888 ] Vladimir Sitnikov commented on MNG-7852: {quote}all the rest of issues were closed as "works as expected".{quote} Correct me if I am wrong, however, the only justification I saw was "works as expected since Maven uses nearest first algorithm". I suggest reconsidering "nearest first" as it is not really manageable from the end-user point of view. {quote} Maven never worked (unlike as npm) by "highest version" nor will.{quote} Can you clarify why "highest wins" is not an option for Maven? > Use all the versions for dependency resolution rather than "nearest first" or > "declared first" > -- > > Key: MNG-7852 > URL: https://issues.apache.org/jira/browse/MNG-7852 > Project: Maven > Issue Type: Improvement > Components: Dependencies >Reporter: Vladimir Sitnikov >Priority: Major > > Currently, Maven uses "nearest first", "declared first" rules for conflict > resolution: > https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html > I suggest those rules are removed since they produce hard to reason > resolutions for transitive dependencies. > Below I list reasons why both "nearest wins" and "declared first" yield > hard-to-predict behaviours, and they are likely to produce dependency > downgrades and the associated runtime errors. > Here are some examples: > 1) "Nearest first". Even though the rule sounds easy, it is not something the > users can control. For instance, if the project does not use Guava library, > some of the transitive dependencies could add a dependency on Guava. The user > has no control which dependency would be "the nearest" to declare Guava, so > user has literally no way to tell which Guava version will be used. > The only workaround I see for the users is to declare Guava dependency > explicitly even though the project does not need it directly. It sounds like > Maven requires users to re-declare all the possible dependencies, including > the runtime-only ones. > 2) "declared first". Of course, dependency order matters for classpath order, > however, it is not predictable in practice, and it might result in > downgrading dependencies. Imagine the project does not use Guice. However, > transitive dependencies might use Guice. At the same time, they might start > using Guice and stop using Guice, so the user can never tell which will be > the first project that uses Guice. Unfortunately, in Maven, the first project > that declares dependency wins, so it might easily be the case that the first > mention of Guice will reference outdated version that would be incompatible > with the newer one required in another dependency. > 3) Here's a real-life case: Maven downgrades protobuf-java dependency causing > something like NoSuchMethodError at the runtime. The step to reproduce is to > add dependency on dev.sigstore:sigstore-java:0.4.0. See [~hboutemy] analysis > in https://github.com/hboutemy/sigstore-maven-plugin/blob/import/analysis.md > Long story short, sigstore-java does not depend on protobuf-java directly, > however, sigstore-java depends on several third-party libraries that > eventually depend on protobuf-java. Maven's "the first wins" behaviour > results in incoherent set of protobuf dependencies on the classpath. > 4) see "unexpected" in MNG-5988 > To my best understanding, when it comes to transitive dependencies, both > "nearest first" and "declared first" are random variables which user can't > control unless they re-declare all the dependencies in their local pom. I > suggest Maven should not use random variables like "dependency depth" or > "dependency order" to drive conflict resolution. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-6357) Dependency order should be nearest first
[ https://issues.apache.org/jira/browse/MNG-6357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17747805#comment-17747805 ] Vladimir Sitnikov commented on MNG-6357: {quote}It would make more sense if direct dependencies are the first ones on the classpath, followed by the first level transitive dependencies, etc. This will make the explanation equal to version conflict resolution: nearest wins.{quote} I am afraid "nearest wins" is not reliable, and it is not predictable for the end users. See examples in MNG-7852. I suggest Maven should consider all the dependencies not just the nearest. > Dependency order should be nearest first > - > > Key: MNG-6357 > URL: https://issues.apache.org/jira/browse/MNG-6357 > Project: Maven > Issue Type: Improvement >Reporter: Robert Scholte >Priority: Major > Fix For: 4.0.x-candidate > > Time Spent: 20m > Remaining Estimate: 0h > > In case of version conflicts, the nearest wins. However, the dependency order > is simply based on tree walking. In the rare that a transitive dependency of > the first direct dependency contains the same class as a latter direct > dependency, the code is compiled against the first one, which is odd. > It would make more sense if direct dependencies are the first ones on the > classpath, followed by the first level transitive dependencies, etc. This > will make the explanation equal to version conflict resolution: nearest wins. > I don't expect real issues due to this change, otherwise we would have had > this issue much earlier. This should become the new default order, however > there should be a system property to get the original order, just in case > somebody needs it. > > Current workaround: make the critical dependency the first direct dependency. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-7852) Use all the versions for dependency resolution rather than "nearest first" or "declared first"
[ https://issues.apache.org/jira/browse/MNG-7852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Sitnikov updated MNG-7852: --- Description: Currently, Maven uses "nearest first", "declared first" rules for conflict resolution: https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html I suggest those rules are removed since they produce hard to reason resolutions for transitive dependencies. Below I list reasons why both "nearest wins" and "declared first" yield hard-to-predict behaviours, and they are likely to produce dependency downgrades and the associated runtime errors. Here are some examples: 1) "Nearest first". Even though the rule sounds easy, it is not something the users can control. For instance, if the project does not use Guava library, some of the transitive dependencies could add a dependency on Guava. The user has no control which dependency would be "the nearest" to declare Guava, so user has literally no way to tell which Guava version will be used. The only workaround I see for the users is to declare Guava dependency explicitly even though the project does not need it directly. It sounds like Maven requires users to re-declare all the possible dependencies, including the runtime-only ones. 2) "declared first". Of course, dependency order matters for classpath order, however, it is not predictable in practice, and it might result in downgrading dependencies. Imagine the project does not use Guice. However, transitive dependencies might use Guice. At the same time, they might start using Guice and stop using Guice, so the user can never tell which will be the first project that uses Guice. Unfortunately, in Maven, the first project that declares dependency wins, so it might easily be the case that the first mention of Guice will reference outdated version that would be incompatible with the newer one required in another dependency. 3) Here's a real-life case: Maven downgrades protobuf-java dependency causing something like NoSuchMethodError at the runtime. The step to reproduce is to add dependency on dev.sigstore:sigstore-java:0.4.0. See [~hboutemy] analysis in https://github.com/hboutemy/sigstore-maven-plugin/blob/import/analysis.md Long story short, sigstore-java does not depend on protobuf-java directly, however, sigstore-java depends on several third-party libraries that eventually depend on protobuf-java. Maven's "the first wins" behaviour results in incoherent set of protobuf dependencies on the classpath. 4) see "unexpected" in MNG-5988 To my best understanding, when it comes to transitive dependencies, both "nearest first" and "declared first" are random variables which user can't control unless they re-declare all the dependencies in their local pom. I suggest Maven should not use random variables like "dependency depth" or "dependency order" to drive conflict resolution. was: Currently, Maven uses "nearest first", "declared first" rules for conflict resolution: https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html I suggest those rules are removed since they produce hard to reason resolutions for transitive dependencies. Below I list reasons why both "nearest wins" and "declared first" yield hard-to-predict behaviours, and they are likely to produce dependency downgrades and the associated runtime errors. Here are some examples: 1) "Nearest first". Even though the rule sounds easy, it is not something the users can control. For instance, if the project does not use Guava library, some of the transitive dependencies could add a dependency on Guava. The user has no control which dependency would be "the nearest" to declare Guava, so user has literally no way to tell which Guava version will be used. The only workaround I see for the users is to declare Guava dependency explicitly even though the project does not need it directly. It sounds like Maven requires users to re-declare all the possible dependencies, including the runtime-only ones. 2) "declared first". Of course, dependency order matters for classpath order, however, it is not predictable in practice, and it might result in downgrading dependencies. Imagine the project does not use Guice. However, transitive dependencies might use Guice. At the same time, they might start using Guice and stop using Guice, so the user can never tell which will be the first project that uses Guice. Unfortunately, in Maven, the first project that declares dependency wins, so it might easily be the case that the first mention of Guice will reference outdated version that would be incompatible with the newer one required in another dependency. 3) Here's a real-life case: Maven downgrades protobuf-java dependency causing something like NoSuchMethodError at the runtime. The step to reproduce is to add dependency on dev.sigstore:sigstore-jav
[jira] [Updated] (MNG-7852) Use all the versions for dependency resolution rather than "nearest first" or "declared first"
[ https://issues.apache.org/jira/browse/MNG-7852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Sitnikov updated MNG-7852: --- Description: Currently, Maven uses "nearest first", "declared first" rules for conflict resolution: https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html I suggest those rules are removed since they produce hard to reason resolutions for transitive dependencies. Below I list reasons why both "nearest wins" and "declared first" yield hard-to-predict behaviours, and they are likely to produce dependency downgrades and the associated runtime errors. Here are some examples: 1) "Nearest first". Even though the rule sounds easy, it is not something the users can control. For instance, if the project does not use Guava library, some of the transitive dependencies could add a dependency on Guava. The user has no control which dependency would be "the nearest" to declare Guava, so user has literally no way to tell which Guava version will be used. The only workaround I see for the users is to declare Guava dependency explicitly even though the project does not need it directly. It sounds like Maven requires users to re-declare all the possible dependencies, including the runtime-only ones. 2) "declared first". Of course, dependency order matters for classpath order, however, it is not predictable in practice, and it might result in downgrading dependencies. Imagine the project does not use Guice. However, transitive dependencies might use Guice. At the same time, they might start using Guice and stop using Guice, so the user can never tell which will be the first project that uses Guice. Unfortunately, in Maven, the first project that declares dependency wins, so it might easily be the case that the first mention of Guice will reference outdated version that would be incompatible with the newer one required in another dependency. 3) Here's a real-life case: Maven downgrades protobuf-java dependency causing something like NoSuchMethodError at the runtime. The step to reproduce is to add dependency on dev.sigstore:sigstore-java:0.4.0. See [~hboutemy] analysis in https://github.com/hboutemy/sigstore-maven-plugin/blob/import/analysis.md Long story short, sigstore-java does not depend on protobuf-java directly, however, sigstore-java depends on several third-party libraries that eventually depend on protobuf-java. Maven's "the first wins" behaviour results in incoherent set of protobuf dependencies on the classpath. 4) see "unexpected" in To my best understanding, when it comes to transitive dependencies, both "nearest first" and "declared first" are random variables which user can't control unless they re-declare all the dependencies in their local pom. I suggest Maven should not use random variables like "dependency depth" or "dependency order" to drive conflict resolution. was: Currently, Maven uses "nearest first", "declared first" rules for conflict resolution: https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html I suggest those rules are removed since they produce hard to reason resolutions for transitive dependencies. Below I list reasons why both "nearest wins" and "declared first" yield hard-to-predict behaviours, and they are likely to produce dependency downgrades and the associated runtime errors. Here are some examples: 1) "Nearest first". Even though the rule sounds easy, it is not something the users can control. For instance, if the project does not use Guava library, some of the transitive dependencies could add a dependency on Guava. The user has no control which dependency would be "the nearest" to declare Guava, so user has literally no way to tell which Guava version will be used. The only workaround I see for the users is to declare Guava dependency explicitly even though the project does not need it directly. It sounds like Maven requires users to re-declare all the possible dependencies, including the runtime-only ones. 2) "declared first". Of course, dependency order matters for classpath order, however, it is not predictable in practice, and it might result in downgrading dependencies. Imagine the project does not use Guice. However, transitive dependencies might use Guice. At the same time, they might start using Guice and stop using Guice, so the user can never tell which will be the first project that uses Guice. Unfortunately, in Maven, the first project that declares dependency wins, so it might easily be the case that the first mention of Guice will reference outdated version that would be incompatible with the newer one required in another dependency. 3) Here's a real-life case: Maven downgrades protobuf-java dependency causing something like NoSuchMethodError at the runtime. The step to reproduce is to add dependency on dev.sigstore:sigstore-java:0.4.0.
[jira] [Updated] (MNG-7852) Use all the versions for dependency resolution rather than "nearest first" or "declared first"
[ https://issues.apache.org/jira/browse/MNG-7852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Sitnikov updated MNG-7852: --- Description: Currently, Maven uses "nearest first", "declared first" rules for conflict resolution: https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html I suggest those rules are removed since they produce hard to reason resolutions for transitive dependencies. Below I list reasons why both "nearest wins" and "declared first" yield hard-to-predict behaviours, and they are likely to produce dependency downgrades and the associated runtime errors. Here are some examples: 1) "Nearest first". Even though the rule sounds easy, it is not something the users can control. For instance, if the project does not use Guava library, some of the transitive dependencies could add a dependency on Guava. The user has no control which dependency would be "the nearest" to declare Guava, so user has literally no way to tell which Guava version will be used. The only workaround I see for the users is to declare Guava dependency explicitly even though the project does not need it directly. It sounds like Maven requires users to re-declare all the possible dependencies, including the runtime-only ones. 2) "declared first". Of course, dependency order matters for classpath order, however, it is not predictable in practice, and it might result in downgrading dependencies. Imagine the project does not use Guice. However, transitive dependencies might use Guice. At the same time, they might start using Guice and stop using Guice, so the user can never tell which will be the first project that uses Guice. Unfortunately, in Maven, the first project that declares dependency wins, so it might easily be the case that the first mention of Guice will reference outdated version that would be incompatible with the newer one required in another dependency. 3) Here's a real-life case: Maven downgrades protobuf-java dependency causing something like NoSuchMethodError at the runtime. The step to reproduce is to add dependency on dev.sigstore:sigstore-java:0.4.0. See [~hboutemy] analysis in https://github.com/hboutemy/sigstore-maven-plugin/blob/import/analysis.md Long story short, sigstore-java does not depend on protobuf-java directly, however, sigstore-java depends on several third-party libraries that eventually depend on protobuf-java. Maven's "the first wins" behaviour results in incoherent set of protobuf dependencies on the classpath. To my best understanding, when it comes to transitive dependencies, both "nearest first" and "declared first" are random variables which user can't control unless they re-declare all the dependencies in their local pom. I suggest Maven should not use random variables like "dependency depth" or "dependency order" to drive conflict resolution. was: Currently, Maven uses "nearest first", "declared first" rules for conflict resolution: https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html I suggest those rules are removed since they produce hard to reason resolutions for transitive dependencies. Below I list reasons why both "nearest wins" and "declared first" yield hard-to-predict behaviours, and they are likely to produce dependency downgrades and the associated runtime errors. Here are some examples: 1) "Nearest first". Even though the rule sounds easy, it is not something the users can control. For instance, if the project does not use Guava library, some of the transitive dependencies could add a dependency on Guava. The user has no control which dependency would be "the nearest" to declare Guava, so user has literally no way to tell which Guava version will be used. The only workaround I see for the users is to declare Guava dependency explicitly even though the project does not need it directly. It sounds like Maven requires users to re-declare all the possible dependencies, including the runtime-only ones. 2) "declared first". Of course, dependency order matters for classpath order, however, it is not predictable in practice, and it might result in downgrading dependencies. Imagine the project does not use Guice. However, transitive dependencies might use Guice. At the same time, they might start using Guice and stop using Guice, so the user can never tell which will be the first project that uses Guice. Unfortunately, in Maven, the first project that declares dependency wins, so it might easily be the case that the first mention of Guice will reference outdated version that would be incompatible with the newer one required in another dependency. 3) Here's a real-life case: Maven downgrades protobuf-java dependency causing something like NoSuchMethodError at the runtime. The step to reproduce is to add dependency on dev.sigstore:sigstore-java:0.4.0. See [~hboutemy] analysis
[jira] [Updated] (MNG-7852) Use all the versions for dependency resolution rather than "nearest first" or "declared first"
[ https://issues.apache.org/jira/browse/MNG-7852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Sitnikov updated MNG-7852: --- Description: Currently, Maven uses "nearest first", "declared first" rules for conflict resolution: https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html I suggest those rules are removed since they produce hard to reason resolutions for transitive dependencies. Below I list reasons why both "nearest wins" and "declared first" yield hard-to-predict behaviours, and they are likely to produce dependency downgrades and the associated runtime errors. Here are some examples: 1) "Nearest first". Even though the rule sounds easy, it is not something the users can control. For instance, if the project does not use Guava library, some of the transitive dependencies could add a dependency on Guava. The user has no control which dependency would be "the nearest" to declare Guava, so user has literally no way to tell which Guava version will be used. The only workaround I see for the users is to declare Guava dependency explicitly even though the project does not need it directly. It sounds like Maven requires users to re-declare all the possible dependencies, including the runtime-only ones. 2) "declared first". Of course, dependency order matters for classpath order, however, it is not predictable in practice, and it might result in downgrading dependencies. Imagine the project does not use Guice. However, transitive dependencies might use Guice. At the same time, they might start using Guice and stop using Guice, so the user can never tell which will be the first project that uses Guice. Unfortunately, in Maven, the first project that declares dependency wins, so it might easily be the case that the first mention of Guice will reference outdated version that would be incompatible with the newer one required in another dependency. 3) Here's a real-life case: Maven downgrades protobuf-java dependency causing something like NoSuchMethodError at the runtime. The step to reproduce is to add dependency on dev.sigstore:sigstore-java:0.4.0. See [~hboutemy] analysis in https://github.com/hboutemy/sigstore-maven-plugin/blob/import/analysis.md Long story short, sigstore-java does not depend on protobuf-java directly, however, sigstore-java depends on several third-party libraries that eventually depend on protobuf-java. Maven's "the first wins" behaviour results in incoherent set of protobuf dependencies on the classpath. was: Currently, Maven uses "nearest first", "declared first" rules for conflict resolution: https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html I suggest those rules are removed since they produce hard to reason resolutions for transitive dependencies. Here are some examples: 1) "Nearest first". Even though the rule sounds easy, it is not something the users can control. For instance, if the project does not use Guava library, some of the transitive dependencies could add a dependency on Guava. The user has no control which dependency would be "the nearest" to declare Guava, so user has literally no way to tell which Guava version will be used. The only workaround I see for the users is to declare Guava dependency explicitly even though the project does not need it directly. It sounds like Maven requires users to re-declare all the possible dependencies, including the runtime-only ones. 2) "declared first". Of course, dependency order matters for classpath order, however, it is not predictable in practice, and it might result in downgrading dependencies. Imagine the project does not use Guice. However, transitive dependencies might use Guice. At the same time, they might start using Guice and stop using Guice, so the user can never tell which will be the first project that uses Guice. Unfortunately, in Maven, the first project that declares dependency wins, so it might easily be the case that the first mention of Guice will reference outdated version that would be incompatible with the newer one required in another dependency. 3) Here's a real-life case: Maven downgrades protobuf-java dependency causing something like NoSuchMethodError at the runtime. The step to reproduce is to add dependency on dev.sigstore:sigstore-java:0.4.0. See [~hboutemy] analysis in https://github.com/hboutemy/sigstore-maven-plugin/blob/import/analysis.md Long story short, sigstore-java does not depend on protobuf-java directly, however, sigstore-java depends on several third-party libraries that eventually depend on protobuf-java. Maven's "the first wins" behaviour results in incoherent set of protobuf dependencies on the classpath. > Use all the versions for dependency resolution rather than "nearest first" or > "declared first" > --
[jira] [Updated] (MNG-7852) Use all the versions for dependency resolution rather than "nearest first" or "declared first"
[ https://issues.apache.org/jira/browse/MNG-7852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Sitnikov updated MNG-7852: --- Description: Currently, Maven uses "nearest first", "declared first" rules for conflict resolution: https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html I suggest those rules are removed since they produce hard to reason resolutions for transitive dependencies. Here are some examples: 1) "Nearest first". Even though the rule sounds easy, it is not something the users can control. For instance, if the project does not use Guava library, some of the transitive dependencies could add a dependency on Guava. The user has no control which dependency would be "the nearest" to declare Guava, so user has literally no way to tell which Guava version will be used. The only workaround I see for the users is to declare Guava dependency explicitly even though the project does not need it directly. It sounds like Maven requires users to re-declare all the possible dependencies, including the runtime-only ones. 2) "declared first". Of course, dependency order matters for classpath order, however, it is not predictable in practice, and it might result in downgrading dependencies. Imagine the project does not use Guice. However, transitive dependencies might use Guice. At the same time, they might start using Guice and stop using Guice, so the user can never tell which will be the first project that uses Guice. Unfortunately, in Maven, the first project that declares dependency wins, so it might easily be the case that the first mention of Guice will reference outdated version that would be incompatible with the newer one required in another dependency. 3) Here's a real-life case: Maven downgrades protobuf-java dependency causing something like NoSuchMethodError at the runtime. The step to reproduce is to add dependency on dev.sigstore:sigstore-java:0.4.0. See [~hboutemy] analysis in https://github.com/hboutemy/sigstore-maven-plugin/blob/import/analysis.md Long story short, sigstore-java does not depend on protobuf-java directly, however, sigstore-java depends on several third-party libraries that eventually depend on protobuf-java. Maven's "the first wins" behaviour results in incoherent set of protobuf dependencies on the classpath. was: Currently, Maven uses "nearest first", "declared first" rules for conflict resolution: https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html I suggest those rules are removed since they produce hard to reason resolutions for transitive dependencies. Here are some examples: 1) "Nearest first". Even though the rule sounds easy, it is not something the users can control. For instance, if the project does not use Guava library, some of the transitive dependencies could add a dependency on Guava. The user has no control which dependency would be "the nearest" to declare Guava, so user has literally no way to tell which Guava version will be used. The only workaround I see for the users is to declare Guava dependency explicitly even though the project does not need it directly. It sounds like Maven requires users to re-declare all the possible dependencies, including the runtime-only ones. 2) "declared first". Of course, dependency order matters for classpath order, however, it is not predictable in practice, and it might result in downgrading dependencies. Imagine the project does not use Guice. However, transitive dependencies might use Guice. At the same time, they might start using Guice and stop using Guice, so the user can never tell which will be the first project that uses Guice. Unfortunately, in Maven, the first project that declares dependency wins, so it might easily be the case that the first mention of Guice will reference outdated version that would be incompatible with the newer one required in another dependency. 3) Here's a real-life case: Maven downgrades protobuf-java dependency causing something like NoSuchMethodError at the runtime. The steps to reproduce is to add dependency on dev.sigstore:sigstore-java:0.4.0. See [~hboutemy] analysis in https://github.com/hboutemy/sigstore-maven-plugin/blob/import/analysis.md Long story short, sigstore-java does not depend on protobuf-java directly, however, sigstore-java depends on several third-party libraries that eventually depend on protobuf-java. Maven's "the first wins" behaviour results in incoherent set of protobuf dependencies on the classpath. > Use all the versions for dependency resolution rather than "nearest first" or > "declared first" > -- > > Key: MNG-7852 > URL: https://issues.apache.org/jira/browse/MNG-7852 > Project: Maven > Issue Type: Improvem
[jira] [Updated] (MNG-7852) Use all the versions for dependency resolution rather than "nearest first" or "declared first"
[ https://issues.apache.org/jira/browse/MNG-7852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Sitnikov updated MNG-7852: --- Summary: Use all the versions for dependency resolution rather than "nearest first" or "declared first" (was: Use all the versions for dependency resolution rather than "the first ones") > Use all the versions for dependency resolution rather than "nearest first" or > "declared first" > -- > > Key: MNG-7852 > URL: https://issues.apache.org/jira/browse/MNG-7852 > Project: Maven > Issue Type: Improvement > Components: Dependencies >Reporter: Vladimir Sitnikov >Priority: Major > > Currently, Maven uses "nearest first", "declared first" rules for conflict > resolution: > https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html > I suggest those rules are removed since they produce hard to reason > resolutions for transitive dependencies. > Here are some examples: > 1) "Nearest first". Even though the rule sounds easy, it is not something the > users can control. For instance, if the project does not use Guava library, > some of the transitive dependencies could add a dependency on Guava. The user > has no control which dependency would be "the nearest" to declare Guava, so > user has literally no way to tell which Guava version will be used. > The only workaround I see for the users is to declare Guava dependency > explicitly even though the project does not need it directly. It sounds like > Maven requires users to re-declare all the possible dependencies, including > the runtime-only ones. > 2) "declared first". Of course, dependency order matters for classpath order, > however, it is not predictable in practice, and it might result in > downgrading dependencies. Imagine the project does not use Guice. However, > transitive dependencies might use Guice. At the same time, they might start > using Guice and stop using Guice, so the user can never tell which will be > the first project that uses Guice. Unfortunately, in Maven, the first project > that declares dependency wins, so it might easily be the case that the first > mention of Guice will reference outdated version that would be incompatible > with the newer one required in another dependency. > 3) Here's a real-life case: Maven downgrades protobuf-java dependency causing > something like NoSuchMethodError at the runtime. The steps to reproduce is to > add dependency on dev.sigstore:sigstore-java:0.4.0. See [~hboutemy] analysis > in https://github.com/hboutemy/sigstore-maven-plugin/blob/import/analysis.md > Long story short, sigstore-java does not depend on protobuf-java directly, > however, sigstore-java depends on several third-party libraries that > eventually depend on protobuf-java. Maven's "the first wins" behaviour > results in incoherent set of protobuf dependencies on the classpath. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MNG-7852) Use all the versions for dependency resolution rather than "the first ones"
Vladimir Sitnikov created MNG-7852: -- Summary: Use all the versions for dependency resolution rather than "the first ones" Key: MNG-7852 URL: https://issues.apache.org/jira/browse/MNG-7852 Project: Maven Issue Type: Improvement Components: Dependencies Reporter: Vladimir Sitnikov Currently, Maven uses "nearest first", "declared first" rules for conflict resolution: https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html I suggest those rules are removed since they produce hard to reason resolutions for transitive dependencies. Here are some examples: 1) "Nearest first". Even though the rule sounds easy, it is not something the users can control. For instance, if the project does not use Guava library, some of the transitive dependencies could add a dependency on Guava. The user has no control which dependency would be "the nearest" to declare Guava, so user has literally no way to tell which Guava version will be used. The only workaround I see for the users is to declare Guava dependency explicitly even though the project does not need it directly. It sounds like Maven requires users to re-declare all the possible dependencies, including the runtime-only ones. 2) "declared first". Of course, dependency order matters for classpath order, however, it is not predictable in practice, and it might result in downgrading dependencies. Imagine the project does not use Guice. However, transitive dependencies might use Guice. At the same time, they might start using Guice and stop using Guice, so the user can never tell which will be the first project that uses Guice. Unfortunately, in Maven, the first project that declares dependency wins, so it might easily be the case that the first mention of Guice will reference outdated version that would be incompatible with the newer one required in another dependency. 3) Here's a real-life case: Maven downgrades protobuf-java dependency causing something like NoSuchMethodError at the runtime. The steps to reproduce is to add dependency on dev.sigstore:sigstore-java:0.4.0. See [~hboutemy] analysis in https://github.com/hboutemy/sigstore-maven-plugin/blob/import/analysis.md Long story short, sigstore-java does not depend on protobuf-java directly, however, sigstore-java depends on several third-party libraries that eventually depend on protobuf-java. Maven's "the first wins" behaviour results in incoherent set of protobuf dependencies on the classpath. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7842) Keep using transitive dependencies even if one of the declarations misses a version
[ https://issues.apache.org/jira/browse/MNG-7842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17747755#comment-17747755 ] Vladimir Sitnikov commented on MNG-7842: {quote}Maven does not consider "partial models", it considers "model" that is successfully built (and validated){quote} That is not true. Maven considers the partial models, and it discards the information. Cosider: A) User declares dependency without a version. Maven would fail the build with "Some problems were encountered while processing the POMs.." B) User declares dependency that references a dependency without a version. Maven happily performs a build ignoring **all** the dependencies in the pom that happens to contain "versionless" dependency. {quote} Also, to have depMgmt applied, you have to have Model to apply to{quote} Could you please rephrase so I could better understand what you suggest? What I say is that **even if I declare dependencyManagement** locally, Maven still ignores the pom that contains "versionless dependency". > Keep using transitive dependencies even if one of the declarations misses a > version > --- > > Key: MNG-7842 > URL: https://issues.apache.org/jira/browse/MNG-7842 > Project: Maven > Issue Type: Improvement > Components: Core, Dependencies >Reporter: Vladimir Sitnikov >Priority: Major > > I have a problem that Maven discards **all** transitive dependencies when a > single of them misses {{}}. It breaks workflows, and it is not clear > why Maven behaves like that. > I'm using Maven 3.8.6. > Sample: > {code:xml} > > http://maven.apache.org/POM/4.0.0"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 > http://maven.apache.org/xsd/maven-4.0.0.xsd";> > 4.0.0 > org.example > TestBugMaven > 1.0-SNAPSHOT > > 17 > 17 > UTF-8 > > > > org.apache.jmeter > ApacheJMeter_core > 5.6.1 > > > > {code} > Test: {{mvn dependency:tree}} > Output: > {noformat} > [WARNING] The POM for org.apache.jmeter:ApacheJMeter_core:jar:5.6.1 is > invalid, transitive dependencies (if any) will not be available, enable debug > logging for more details > [INFO] > [INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ TestBugMaven --- > [INFO] org.example:TestBugMaven:jar:1.0-SNAPSHOT > [INFO] \- org.apache.jmeter:ApacheJMeter_core:jar:5.6.1:compile > {noformat} > Frankly speaking, I do not understand why Maven discards ALL transitive > dependencies in case it observes a single one with "missing version". > Note: adding {{dependencyManagement}} does not seem to fix the case, so it is > even more confusing. > The following still discards transitive dependencies: > {code:xml} > > > > com.google.auto.service > auto-service-annotations > compile > 1.1.1 > > > > > > org.apache.jmeter > ApacheJMeter_core > 5.6.1 > > > {code} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-7842) Keep using transitive dependencies even if one of the declarations misses a version
[ https://issues.apache.org/jira/browse/MNG-7842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Sitnikov updated MNG-7842: --- Description: I have a problem that Maven discards **all** transitive dependencies when a single of them misses {{}}. It breaks workflows, and it is not clear why Maven behaves like that. I'm using Maven 3.8.6. Sample: {code:xml} http://maven.apache.org/POM/4.0.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd";> 4.0.0 org.example TestBugMaven 1.0-SNAPSHOT 17 17 UTF-8 org.apache.jmeter ApacheJMeter_core 5.6.1 {code} Test: {{mvn dependency:tree}} Output: {noformat} [WARNING] The POM for org.apache.jmeter:ApacheJMeter_core:jar:5.6.1 is invalid, transitive dependencies (if any) will not be available, enable debug logging for more details [INFO] [INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ TestBugMaven --- [INFO] org.example:TestBugMaven:jar:1.0-SNAPSHOT [INFO] \- org.apache.jmeter:ApacheJMeter_core:jar:5.6.1:compile {noformat} Frankly speaking, I do not understand why Maven discards ALL transitive dependencies in case it observes a single one with "missing version". Note: adding {{dependencyManagement}} does not seem to fix the case, so it is even more confusing. The following still discards transitive dependencies: {code:xml} com.google.auto.service auto-service-annotations compile 1.1.1 org.apache.jmeter ApacheJMeter_core 5.6.1 {code} was: I have a problem that Maven discards **all** transitive dependencies. I'm using Maven 3.8.6. Sample: {code:xml} http://maven.apache.org/POM/4.0.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd";> 4.0.0 org.example TestBugMaven 1.0-SNAPSHOT 17 17 UTF-8 org.apache.jmeter ApacheJMeter_core 5.6.1 {code} Test: {{mvn dependency:tree}} Output: {noformat} [WARNING] The POM for org.apache.jmeter:ApacheJMeter_core:jar:5.6.1 is invalid, transitive dependencies (if any) will not be available, enable debug logging for more details [INFO] [INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ TestBugMaven --- [INFO] org.example:TestBugMaven:jar:1.0-SNAPSHOT [INFO] \- org.apache.jmeter:ApacheJMeter_core:jar:5.6.1:compile {noformat} Frankly speaking, I do not understand why Maven discards ALL transitive dependencies in case it observes a single one with "missing version". Note: adding {{dependencyManagement}} does not seem to fix the case, so it is even more confusing. The following still discards transitive dependencies: {code:xml} com.google.auto.service auto-service-annotations compile 1.1.1 org.apache.jmeter ApacheJMeter_core 5.6.1 {code} > Keep using transitive dependencies even if one of the declarations misses a > version > --- > > Key: MNG-7842 > URL: https://issues.apache.org/jira/browse/MNG-7842 > Project: Maven > Issue Type: Improvement > Components: Core, Dependencies >Reporter: Vladimir Sitnikov >Priority: Major > > I have a problem that Maven discards **all** transitive dependencies when a > single of them misses {{}}. It breaks workflows, and it is not clear > why Maven behaves like that. > I'm using Maven 3.8.6. > Sample: > {code:xml} > > http://maven.apache.org/POM/4.0.0"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 > http://maven.apache.org/xsd/maven-4.0.0.xsd";> > 4.0.0 > org.example > TestBugMaven > 1.0-SNAPSHOT > > 17 > 17 > UTF-8 > > > > org.apache.jmeter > ApacheJMeter_core > 5.6.1 > > > > {code} > Test: {{mvn dependency:tree}} > Output: > {noformat} > [WARNING] The POM for org.apache.jmeter:ApacheJMeter_core:jar:5.6.1 is > invalid, transitive dependencies (if any) will not be available, enable debug > logging for more details > [INFO] > [INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ TestBugMaven --- > [INFO] org.example:TestBugMaven:jar:1.0-SNAPSHOT > [INFO] \- org.apache.jmeter:ApacheJMeter_core:jar:5.6.1:compile > {noformat} > Frankly sp
[jira] [Updated] (MNG-7842) Keep using transitive dependencies even if one of the declarations misses a version
[ https://issues.apache.org/jira/browse/MNG-7842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Sitnikov updated MNG-7842: --- Description: I have a problem that Maven discards **all** transitive dependencies. I'm using Maven 3.8.6. Sample: {code:xml} http://maven.apache.org/POM/4.0.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd";> 4.0.0 org.example TestBugMaven 1.0-SNAPSHOT 17 17 UTF-8 org.apache.jmeter ApacheJMeter_core 5.6.1 {code} Test: {{mvn dependency:tree}} Output: {noformat} [WARNING] The POM for org.apache.jmeter:ApacheJMeter_core:jar:5.6.1 is invalid, transitive dependencies (if any) will not be available, enable debug logging for more details [INFO] [INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ TestBugMaven --- [INFO] org.example:TestBugMaven:jar:1.0-SNAPSHOT [INFO] \- org.apache.jmeter:ApacheJMeter_core:jar:5.6.1:compile {noformat} Frankly speaking, I do not understand why Maven discards ALL transitive dependencies in case it observes a single one with "missing version". Note: adding {{dependencyManagement}} does not seem to fix the case, so it is even more confusing. The following still discards transitive dependencies: {code:xml} com.google.auto.service auto-service-annotations compile 1.1.1 org.apache.jmeter ApacheJMeter_core 5.6.1 {code} was: I have a problem that Maven discards **all** transitive dependencies. Sample: {code:xml} http://maven.apache.org/POM/4.0.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd";> 4.0.0 org.example TestBugMaven 1.0-SNAPSHOT 17 17 UTF-8 org.apache.jmeter ApacheJMeter_core 5.6.1 {code} Test: {{mvn dependency:tree}} Output: {noformat} [WARNING] The POM for org.apache.jmeter:ApacheJMeter_core:jar:5.6.1 is invalid, transitive dependencies (if any) will not be available, enable debug logging for more details [INFO] [INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ TestBugMaven --- [INFO] org.example:TestBugMaven:jar:1.0-SNAPSHOT [INFO] \- org.apache.jmeter:ApacheJMeter_core:jar:5.6.1:compile {noformat} Frankly speaking, I do not understand why Maven discards ALL transitive dependencies in case it observes a single one with "missing version". Note: adding {{dependencyManagement}} does not seem to fix the case, so it is even more confusing. The following still discards transitive dependencies: {code:xml} com.google.auto.service auto-service-annotations compile 1.1.1 org.apache.jmeter ApacheJMeter_core 5.6.1 {code} > Keep using transitive dependencies even if one of the declarations misses a > version > --- > > Key: MNG-7842 > URL: https://issues.apache.org/jira/browse/MNG-7842 > Project: Maven > Issue Type: Improvement > Components: Core, Dependencies >Reporter: Vladimir Sitnikov >Priority: Major > > I have a problem that Maven discards **all** transitive dependencies. > I'm using Maven 3.8.6. > Sample: > {code:xml} > > http://maven.apache.org/POM/4.0.0"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 > http://maven.apache.org/xsd/maven-4.0.0.xsd";> > 4.0.0 > org.example > TestBugMaven > 1.0-SNAPSHOT > > 17 > 17 > UTF-8 > > > > org.apache.jmeter > ApacheJMeter_core > 5.6.1 > > > > {code} > Test: {{mvn dependency:tree}} > Output: > {noformat} > [WARNING] The POM for org.apache.jmeter:ApacheJMeter_core:jar:5.6.1 is > invalid, transitive dependencies (if any) will not be available, enable debug > logging for more details > [INFO] > [INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ TestBugMaven --- > [INFO] org.example:TestBugMaven:jar:1.0-SNAPSHOT > [INFO] \- org.apache.jmeter:ApacheJMeter_core:jar:5.6.1:compile > {noformat} > Frankly speaking, I do not understand why Maven discards ALL transitive > dependencies in case it observes a single one with "missing version". > Note: adding {{dependencyManagement}} does not seem to fix the case, so it is > even more confusing. >
[jira] [Created] (MNG-7842) Keep using transitive dependencies even if one of the declarations misses a version
Vladimir Sitnikov created MNG-7842: -- Summary: Keep using transitive dependencies even if one of the declarations misses a version Key: MNG-7842 URL: https://issues.apache.org/jira/browse/MNG-7842 Project: Maven Issue Type: Improvement Components: Core, Dependencies Reporter: Vladimir Sitnikov I have a problem that Maven discards **all** transitive dependencies. Sample: {code:xml} http://maven.apache.org/POM/4.0.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd";> 4.0.0 org.example TestBugMaven 1.0-SNAPSHOT 17 17 UTF-8 org.apache.jmeter ApacheJMeter_core 5.6.1 {code} Test: {{mvn dependency:tree}} Output: {noformat} [WARNING] The POM for org.apache.jmeter:ApacheJMeter_core:jar:5.6.1 is invalid, transitive dependencies (if any) will not be available, enable debug logging for more details [INFO] [INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ TestBugMaven --- [INFO] org.example:TestBugMaven:jar:1.0-SNAPSHOT [INFO] \- org.apache.jmeter:ApacheJMeter_core:jar:5.6.1:compile {noformat} Frankly speaking, I do not understand why Maven discards ALL transitive dependencies in case it observes a single one with "missing version". Note: adding {{dependencyManagement}} does not seem to fix the case, so it is even more confusing. The following still discards transitive dependencies: {code:xml} com.google.auto.service auto-service-annotations compile 1.1.1 org.apache.jmeter ApacheJMeter_core 5.6.1 {code} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7776) don't fingerprint Sigstore signatures (like GPG)
[ https://issues.apache.org/jira/browse/MNG-7776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736878#comment-17736878 ] Vladimir Sitnikov commented on MNG-7776: The checksums exits for artifacts, so it is not clear why making a deviation for .sigstore There are non-https servers still used, so having checksums would make sense. > don't fingerprint Sigstore signatures (like GPG) > > > Key: MNG-7776 > URL: https://issues.apache.org/jira/browse/MNG-7776 > Project: Maven > Issue Type: Improvement >Affects Versions: 3.9.1, 4.0.0-alpha-5 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: 3.9.2, 4.0.0-alpha-7, 4.0.0 > > > Maven repository format requires .md5 and .sha1 fingerprints/checksums for > every artifact: https://maven.apache.org/repository/layout.html > .GPG signature (.asc) is not considered as an artifact, and it does not > require these fingerprints > While working on Sigstore support in addition to GPG, the same should be done > for Sigstore signatures: no fingerprint for .sigstore files (like no GPG > signature for Sigstore signature: see MGPG-86) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7776) don't fingerprint Sigstore signatures (like GPG)
[ https://issues.apache.org/jira/browse/MNG-7776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736874#comment-17736874 ] Vladimir Sitnikov commented on MNG-7776: If only all the servers used TLS > don't fingerprint Sigstore signatures (like GPG) > > > Key: MNG-7776 > URL: https://issues.apache.org/jira/browse/MNG-7776 > Project: Maven > Issue Type: Improvement >Affects Versions: 3.9.1, 4.0.0-alpha-5 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: 3.9.2, 4.0.0-alpha-7, 4.0.0 > > > Maven repository format requires .md5 and .sha1 fingerprints/checksums for > every artifact: https://maven.apache.org/repository/layout.html > .GPG signature (.asc) is not considered as an artifact, and it does not > require these fingerprints > While working on Sigstore support in addition to GPG, the same should be done > for Sigstore signatures: no fingerprint for .sigstore files (like no GPG > signature for Sigstore signature: see MGPG-86) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7776) don't fingerprint Sigstore signatures (like GPG)
[ https://issues.apache.org/jira/browse/MNG-7776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736869#comment-17736869 ] Vladimir Sitnikov commented on MNG-7776: Checksums for {{.sigstore}} files would help for verifying transfer integrity. For instance, when client pushes artifacts to a server, the server would be able to verify if the received {{.sigstore}} file is corrupted or not (TCP and HTTPS do not guarantee file integrity during transfer). The same goes for receiving the file from the repository: if the repository serves a checksum, then client can verify the received file is ok, and it is not truncated or accidentally corrupted. Skipping the checksum does not make any good, yet it is bad for verifying integrity. Of course, it makes no sense to sign {{.sigstore}} files with PGP, however, that is a completely different story. I would suggest that Maven should generate checksums for both {{.sigstore}} and {{.asc}} files. > don't fingerprint Sigstore signatures (like GPG) > > > Key: MNG-7776 > URL: https://issues.apache.org/jira/browse/MNG-7776 > Project: Maven > Issue Type: Improvement >Affects Versions: 3.9.1, 4.0.0-alpha-5 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: 3.9.2, 4.0.0-alpha-7, 4.0.0 > > > Maven repository format requires .md5 and .sha1 fingerprints/checksums for > every artifact: https://maven.apache.org/repository/layout.html > .GPG signature (.asc) is not considered as an artifact, and it does not > require these fingerprints > While working on Sigstore support in addition to GPG, the same should be done > for Sigstore signatures: no fingerprint for .sigstore files (like no GPG > signature for Sigstore signature: see MGPG-86) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-6771) Please fix license issues on binary distribution
[ https://issues.apache.org/jira/browse/MNG-6771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16950383#comment-16950383 ] Vladimir Sitnikov commented on MNG-6771: {quote}I'm not an expert, any hints welcome {quote} I'm really sorry, I don't have many spare cycles here. I would suggest you ask the dependencies to bundle the license under META-INF/LICENSE file, so you could get the license information from the jar files. That is basically what I do with license-gather-plugin which is used in Apache JMeter to keep the licenses up to date. On the other hand, the number of Maven dependencies is not that high, so you could copy-paste the licenses for now. The tricky bit would be to keep the licenses consistent as the versions are updated / new dependencies added. > Please fix license issues on binary distribution > > > Key: MNG-6771 > URL: https://issues.apache.org/jira/browse/MNG-6771 > Project: Maven > Issue Type: Bug > Components: General >Affects Versions: 3.6.2 >Reporter: Vladimir Sitnikov >Priority: Major > Labels: licenses > > Please feel free to adjust the priority, however > [http://www.apache.org/legal/release-policy.html#licensing] says that license > clearance is a must, thus I report this as a Blocker. > {quote}Every ASF release MUST comply with ASF licensing policy. This > requirement is of utmost importance > {quote} > I downloaded apache-maven-3.6.2-bin.zip, and I see the following issues with > it (note: there might be more): > h2. 1) jcl-over-slf4j:1.7.25 > in apache-maven-3.6.2/LICENSE: > {quote} - JCL 1.2 implemented over SLF4J > ([http://www.slf4j.org|http://www.slf4j.org/]) > org.slf4j:jcl-over-slf4j:jar:1.7.25 > License: MIT License (MIT) > [http://www.opensource.org/licenses/mit-license.php] > (lib/jcl-over-slf4j.license){quote} > The license for the artifact is most likely Apache 2.0 rather than MIT: > [https://github.com/qos-ch/slf4j/tree/master/jcl-over-slf4j] > h2. 2) slf4j-api:1.7.25 > in apache-maven-3.6.2/LICENSE: > {quote} - SLF4J API Module ([http://www.slf4j.org|http://www.slf4j.org/]) > org.slf4j:slf4j-api:jar:1.7.25 > License: MIT License (MIT) > [http://www.opensource.org/licenses/mit-license.php] > (lib/slf4j-api.license){quote} > Maven does not comply with SLF4j license. > Here's license for SLF4j: [https://www.slf4j.org/license.html] > It requires to include slf4j copyright notice, however, Maven fails to do > that > h2. 3) MIT license > [http://www.opensource.org/licenses/mit-license.php] must not be used as it > almost never points to a true license. It is extremely unlucky that someone > would copyright their work as "Copyright (c) " > h2. 4) org.eclipse.sisu.inject:0.3.3 > in apache-maven-3.6.2/LICENSE: > {quote} - org.eclipse.sisu.inject > ([http://www.eclipse.org/sisu/org.eclipse.sisu.inject/]) > org.eclipse.sisu:org.eclipse.sisu.inject:eclipse-plugin:0.3.3 > License: Eclipse Public License, Version 1.0 (EPL-1.0) > [http://www.eclipse.org/legal/epl-v10.html] > (lib/org.eclipse.sisu.inject.license){quote} > The link to eclipse.org/sisu responds with 404. > sisu might have their own copyright notices that should be retained, however > Maven re-distributes none of them (org.eclipse.sisu.inject.site-0.3.3.zip has > notice.html file which is not present in Maven re-distribution) > h2. 5) ASM in org.eclipse.sisu.inject-0.3.3.jar > lib/org.eclipse.sisu.inject-0.3.3.jar bundles ASM. ASM is MIT licensed, thus > every re-distribution MUST retain ASM copyright notice. > Maven re-distributes ASM and fails to comply with ASM license. > h2. 6) jsoup in wagon-http-3.3.3-shaded.jar > lib/wagon-http-3.3.3-shaded.jar bundles jsoup ([https://jsoup.org/license]) > which is MIT-licensed. Maven fails to comply with jsoup license. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (MNG-6771) Please fix license issues on binary distribution
[ https://issues.apache.org/jira/browse/MNG-6771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16950338#comment-16950338 ] Vladimir Sitnikov edited comment on MNG-6771 at 10/13/19 2:48 PM: -- {quote}do you see how to automate retrieval and addition to our binary bundle?{quote} I have https://github.com/vlsi/vlsi-release-plugins/blob/master/README.md#license-gather-plugin , however, I'm not sure Gradle plugins are acceptable here. was (Author: vladimirsitnikov): {quote}do you see how to automate retrieval and addition to our binary bundle?{quote} I have https://github.com/vlsi/vlsi-release-plugins/blob/master/README.md#license-gather-plugin > Please fix license issues on binary distribution > > > Key: MNG-6771 > URL: https://issues.apache.org/jira/browse/MNG-6771 > Project: Maven > Issue Type: Bug > Components: General >Affects Versions: 3.6.2 >Reporter: Vladimir Sitnikov >Priority: Major > Labels: licenses > > Please feel free to adjust the priority, however > [http://www.apache.org/legal/release-policy.html#licensing] says that license > clearance is a must, thus I report this as a Blocker. > {quote}Every ASF release MUST comply with ASF licensing policy. This > requirement is of utmost importance > {quote} > I downloaded apache-maven-3.6.2-bin.zip, and I see the following issues with > it (note: there might be more): > h2. 1) jcl-over-slf4j:1.7.25 > in apache-maven-3.6.2/LICENSE: > {quote} - JCL 1.2 implemented over SLF4J > ([http://www.slf4j.org|http://www.slf4j.org/]) > org.slf4j:jcl-over-slf4j:jar:1.7.25 > License: MIT License (MIT) > [http://www.opensource.org/licenses/mit-license.php] > (lib/jcl-over-slf4j.license){quote} > The license for the artifact is most likely Apache 2.0 rather than MIT: > [https://github.com/qos-ch/slf4j/tree/master/jcl-over-slf4j] > h2. 2) slf4j-api:1.7.25 > in apache-maven-3.6.2/LICENSE: > {quote} - SLF4J API Module ([http://www.slf4j.org|http://www.slf4j.org/]) > org.slf4j:slf4j-api:jar:1.7.25 > License: MIT License (MIT) > [http://www.opensource.org/licenses/mit-license.php] > (lib/slf4j-api.license){quote} > Maven does not comply with SLF4j license. > Here's license for SLF4j: [https://www.slf4j.org/license.html] > It requires to include slf4j copyright notice, however, Maven fails to do > that > h2. 3) MIT license > [http://www.opensource.org/licenses/mit-license.php] must not be used as it > almost never points to a true license. It is extremely unlucky that someone > would copyright their work as "Copyright (c) " > h2. 4) org.eclipse.sisu.inject:0.3.3 > in apache-maven-3.6.2/LICENSE: > {quote} - org.eclipse.sisu.inject > ([http://www.eclipse.org/sisu/org.eclipse.sisu.inject/]) > org.eclipse.sisu:org.eclipse.sisu.inject:eclipse-plugin:0.3.3 > License: Eclipse Public License, Version 1.0 (EPL-1.0) > [http://www.eclipse.org/legal/epl-v10.html] > (lib/org.eclipse.sisu.inject.license){quote} > The link to eclipse.org/sisu responds with 404. > sisu might have their own copyright notices that should be retained, however > Maven re-distributes none of them (org.eclipse.sisu.inject.site-0.3.3.zip has > notice.html file which is not present in Maven re-distribution) > h2. 5) ASM in org.eclipse.sisu.inject-0.3.3.jar > lib/org.eclipse.sisu.inject-0.3.3.jar bundles ASM. ASM is MIT licensed, thus > every re-distribution MUST retain ASM copyright notice. > Maven re-distributes ASM and fails to comply with ASM license. > h2. 6) jsoup in wagon-http-3.3.3-shaded.jar > lib/wagon-http-3.3.3-shaded.jar bundles jsoup ([https://jsoup.org/license]) > which is MIT-licensed. Maven fails to comply with jsoup license. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6771) Please fix license issues on binary distribution
[ https://issues.apache.org/jira/browse/MNG-6771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16950338#comment-16950338 ] Vladimir Sitnikov commented on MNG-6771: {quote}do you see how to automate retrieval and addition to our binary bundle?{quote} I have https://github.com/vlsi/vlsi-release-plugins/blob/master/README.md#license-gather-plugin > Please fix license issues on binary distribution > > > Key: MNG-6771 > URL: https://issues.apache.org/jira/browse/MNG-6771 > Project: Maven > Issue Type: Bug > Components: General >Affects Versions: 3.6.2 >Reporter: Vladimir Sitnikov >Priority: Major > Labels: licenses > > Please feel free to adjust the priority, however > [http://www.apache.org/legal/release-policy.html#licensing] says that license > clearance is a must, thus I report this as a Blocker. > {quote}Every ASF release MUST comply with ASF licensing policy. This > requirement is of utmost importance > {quote} > I downloaded apache-maven-3.6.2-bin.zip, and I see the following issues with > it (note: there might be more): > h2. 1) jcl-over-slf4j:1.7.25 > in apache-maven-3.6.2/LICENSE: > {quote} - JCL 1.2 implemented over SLF4J > ([http://www.slf4j.org|http://www.slf4j.org/]) > org.slf4j:jcl-over-slf4j:jar:1.7.25 > License: MIT License (MIT) > [http://www.opensource.org/licenses/mit-license.php] > (lib/jcl-over-slf4j.license){quote} > The license for the artifact is most likely Apache 2.0 rather than MIT: > [https://github.com/qos-ch/slf4j/tree/master/jcl-over-slf4j] > h2. 2) slf4j-api:1.7.25 > in apache-maven-3.6.2/LICENSE: > {quote} - SLF4J API Module ([http://www.slf4j.org|http://www.slf4j.org/]) > org.slf4j:slf4j-api:jar:1.7.25 > License: MIT License (MIT) > [http://www.opensource.org/licenses/mit-license.php] > (lib/slf4j-api.license){quote} > Maven does not comply with SLF4j license. > Here's license for SLF4j: [https://www.slf4j.org/license.html] > It requires to include slf4j copyright notice, however, Maven fails to do > that > h2. 3) MIT license > [http://www.opensource.org/licenses/mit-license.php] must not be used as it > almost never points to a true license. It is extremely unlucky that someone > would copyright their work as "Copyright (c) " > h2. 4) org.eclipse.sisu.inject:0.3.3 > in apache-maven-3.6.2/LICENSE: > {quote} - org.eclipse.sisu.inject > ([http://www.eclipse.org/sisu/org.eclipse.sisu.inject/]) > org.eclipse.sisu:org.eclipse.sisu.inject:eclipse-plugin:0.3.3 > License: Eclipse Public License, Version 1.0 (EPL-1.0) > [http://www.eclipse.org/legal/epl-v10.html] > (lib/org.eclipse.sisu.inject.license){quote} > The link to eclipse.org/sisu responds with 404. > sisu might have their own copyright notices that should be retained, however > Maven re-distributes none of them (org.eclipse.sisu.inject.site-0.3.3.zip has > notice.html file which is not present in Maven re-distribution) > h2. 5) ASM in org.eclipse.sisu.inject-0.3.3.jar > lib/org.eclipse.sisu.inject-0.3.3.jar bundles ASM. ASM is MIT licensed, thus > every re-distribution MUST retain ASM copyright notice. > Maven re-distributes ASM and fails to comply with ASM license. > h2. 6) jsoup in wagon-http-3.3.3-shaded.jar > lib/wagon-http-3.3.3-shaded.jar bundles jsoup ([https://jsoup.org/license]) > which is MIT-licensed. Maven fails to comply with jsoup license. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6771) Please fix license issues on binary distribution
[ https://issues.apache.org/jira/browse/MNG-6771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16950337#comment-16950337 ] Vladimir Sitnikov commented on MNG-6771: {quote}Official Apache releases are source releases only:{quote} I'm afraid you are not quite right here. Binary artifacts are the part of the release. PMC do vote for releasing the binary artifacts, and Apache defines the release as anything that is shared outside of the development community. That is license clearance for binary artifacts is extremely important. I haven't seen a page that says the release might include improperly licensed binaries. > Please fix license issues on binary distribution > > > Key: MNG-6771 > URL: https://issues.apache.org/jira/browse/MNG-6771 > Project: Maven > Issue Type: Bug > Components: General >Affects Versions: 3.6.2 >Reporter: Vladimir Sitnikov >Priority: Major > Labels: licenses > > Please feel free to adjust the priority, however > [http://www.apache.org/legal/release-policy.html#licensing] says that license > clearance is a must, thus I report this as a Blocker. > {quote}Every ASF release MUST comply with ASF licensing policy. This > requirement is of utmost importance > {quote} > I downloaded apache-maven-3.6.2-bin.zip, and I see the following issues with > it (note: there might be more): > h2. 1) jcl-over-slf4j:1.7.25 > in apache-maven-3.6.2/LICENSE: > {quote} - JCL 1.2 implemented over SLF4J > ([http://www.slf4j.org|http://www.slf4j.org/]) > org.slf4j:jcl-over-slf4j:jar:1.7.25 > License: MIT License (MIT) > [http://www.opensource.org/licenses/mit-license.php] > (lib/jcl-over-slf4j.license){quote} > The license for the artifact is most likely Apache 2.0 rather than MIT: > [https://github.com/qos-ch/slf4j/tree/master/jcl-over-slf4j] > h2. 2) slf4j-api:1.7.25 > in apache-maven-3.6.2/LICENSE: > {quote} - SLF4J API Module ([http://www.slf4j.org|http://www.slf4j.org/]) > org.slf4j:slf4j-api:jar:1.7.25 > License: MIT License (MIT) > [http://www.opensource.org/licenses/mit-license.php] > (lib/slf4j-api.license){quote} > Maven does not comply with SLF4j license. > Here's license for SLF4j: [https://www.slf4j.org/license.html] > It requires to include slf4j copyright notice, however, Maven fails to do > that > h2. 3) MIT license > [http://www.opensource.org/licenses/mit-license.php] must not be used as it > almost never points to a true license. It is extremely unlucky that someone > would copyright their work as "Copyright (c) " > h2. 4) org.eclipse.sisu.inject:0.3.3 > in apache-maven-3.6.2/LICENSE: > {quote} - org.eclipse.sisu.inject > ([http://www.eclipse.org/sisu/org.eclipse.sisu.inject/]) > org.eclipse.sisu:org.eclipse.sisu.inject:eclipse-plugin:0.3.3 > License: Eclipse Public License, Version 1.0 (EPL-1.0) > [http://www.eclipse.org/legal/epl-v10.html] > (lib/org.eclipse.sisu.inject.license){quote} > The link to eclipse.org/sisu responds with 404. > sisu might have their own copyright notices that should be retained, however > Maven re-distributes none of them (org.eclipse.sisu.inject.site-0.3.3.zip has > notice.html file which is not present in Maven re-distribution) > h2. 5) ASM in org.eclipse.sisu.inject-0.3.3.jar > lib/org.eclipse.sisu.inject-0.3.3.jar bundles ASM. ASM is MIT licensed, thus > every re-distribution MUST retain ASM copyright notice. > Maven re-distributes ASM and fails to comply with ASM license. > h2. 6) jsoup in wagon-http-3.3.3-shaded.jar > lib/wagon-http-3.3.3-shaded.jar bundles jsoup ([https://jsoup.org/license]) > which is MIT-licensed. Maven fails to comply with jsoup license. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6771) Please fix license issues
[ https://issues.apache.org/jira/browse/MNG-6771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16942232#comment-16942232 ] Vladimir Sitnikov commented on MNG-6771: {quote}They likely need to be fixed and then we can continue with the issues you have mentioned{quote} The order is up to Maven developers. I just guess improper licensing would be a showstopper for Maven release. > Please fix license issues > - > > Key: MNG-6771 > URL: https://issues.apache.org/jira/browse/MNG-6771 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.6.2 >Reporter: Vladimir Sitnikov >Priority: Blocker > > Please feel free to adjust the priority, however > [http://www.apache.org/legal/release-policy.html#licensing] says that license > clearance is a must, thus I report this as a Blocker. > {quote}Every ASF release MUST comply with ASF licensing policy. This > requirement is of utmost importance > {quote} > I downloaded apache-maven-3.6.2-bin.zip, and I see the following issues with > it (note: there might be more): > 1) apache-maven-3.6.2/LICENSE: > {quote} - JCL 1.2 implemented over SLF4J > ([http://www.slf4j.org|http://www.slf4j.org/]) > org.slf4j:jcl-over-slf4j:jar:1.7.25 > License: MIT License (MIT) > [http://www.opensource.org/licenses/mit-license.php] > (lib/jcl-over-slf4j.license){quote} > The license for the artifact is most likely Apache 2.0 rather than MIT: > [https://github.com/qos-ch/slf4j/tree/master/jcl-over-slf4j] > 2) apache-maven-3.6.2/LICENSE: > {quote} - SLF4J API Module ([http://www.slf4j.org|http://www.slf4j.org/]) > org.slf4j:slf4j-api:jar:1.7.25 > License: MIT License (MIT) > [http://www.opensource.org/licenses/mit-license.php] > (lib/slf4j-api.license){quote} > Maven does not comply with SLF4j license. > Here's license for SLF4j: [https://www.slf4j.org/license.html] > It requires to include slf4j copyright notice, however, Maven fails to do > that > 3) [http://www.opensource.org/licenses/mit-license.php] must not be used as > it almost never points to a true license. It is extremely unluky that someone > would copyright their work as "Copyright (c) " > 4) apache-maven-3.6.2/LICENSE: > {quote} - org.eclipse.sisu.inject > ([http://www.eclipse.org/sisu/org.eclipse.sisu.inject/]) > org.eclipse.sisu:org.eclipse.sisu.inject:eclipse-plugin:0.3.3 > License: Eclipse Public License, Version 1.0 (EPL-1.0) > [http://www.eclipse.org/legal/epl-v10.html] > (lib/org.eclipse.sisu.inject.license){quote} > The link to eclipse.org/sisu responds with 404. > sisu might have their own copyright notices that should be retained, however > Maven re-distributes none of them (org.eclipse.sisu.inject.site-0.3.3.zip has > notice.html file which is not present in Maven re-distribution) > 5) lib/org.eclipse.sisu.inject-0.3.3.jar bundles ASM. ASM is MIT licensed, > thus every re-distribution MUST retain ASM copyright notice. > Maven re-distributes ASM and fails to comply with ASM license. > 6) lib/wagon-http-3.3.3-shaded.jar bundles jsoup > ([https://jsoup.org/license]) which is MIT-licensed. Maven fails to comply > with jsoup license. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6771) Please fix license issues
[ https://issues.apache.org/jira/browse/MNG-6771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16942229#comment-16942229 ] Vladimir Sitnikov commented on MNG-6771: I agree it would be great if all the third-party dependencies had perfect licensing information. However, it might easily happen their poms will always be wrong. For instance, org.eclipse.sisu.inject-3.3.0 is 3 year old now. Can they still release? Who knows :-/ > Please fix license issues > - > > Key: MNG-6771 > URL: https://issues.apache.org/jira/browse/MNG-6771 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.6.2 >Reporter: Vladimir Sitnikov >Priority: Blocker > > Please feel free to adjust the priority, however > [http://www.apache.org/legal/release-policy.html#licensing] says that license > clearance is a must, thus I report this as a Blocker. > {quote}Every ASF release MUST comply with ASF licensing policy. This > requirement is of utmost importance > {quote} > I downloaded apache-maven-3.6.2-bin.zip, and I see the following issues with > it (note: there might be more): > 1) apache-maven-3.6.2/LICENSE: > {quote} - JCL 1.2 implemented over SLF4J > ([http://www.slf4j.org|http://www.slf4j.org/]) > org.slf4j:jcl-over-slf4j:jar:1.7.25 > License: MIT License (MIT) > [http://www.opensource.org/licenses/mit-license.php] > (lib/jcl-over-slf4j.license){quote} > The license for the artifact is most likely Apache 2.0 rather than MIT: > [https://github.com/qos-ch/slf4j/tree/master/jcl-over-slf4j] > 2) apache-maven-3.6.2/LICENSE: > {quote} - SLF4J API Module ([http://www.slf4j.org|http://www.slf4j.org/]) > org.slf4j:slf4j-api:jar:1.7.25 > License: MIT License (MIT) > [http://www.opensource.org/licenses/mit-license.php] > (lib/slf4j-api.license){quote} > Maven does not comply with SLF4j license. > Here's license for SLF4j: [https://www.slf4j.org/license.html] > It requires to include slf4j copyright notice, however, Maven fails to do > that > 3) [http://www.opensource.org/licenses/mit-license.php] must not be used as > it almost never points to a true license. It is extremely unluky that someone > would copyright their work as "Copyright (c) " > 4) apache-maven-3.6.2/LICENSE: > {quote} - org.eclipse.sisu.inject > ([http://www.eclipse.org/sisu/org.eclipse.sisu.inject/]) > org.eclipse.sisu:org.eclipse.sisu.inject:eclipse-plugin:0.3.3 > License: Eclipse Public License, Version 1.0 (EPL-1.0) > [http://www.eclipse.org/legal/epl-v10.html] > (lib/org.eclipse.sisu.inject.license){quote} > The link to eclipse.org/sisu responds with 404. > sisu might have their own copyright notices that should be retained, however > Maven re-distributes none of them (org.eclipse.sisu.inject.site-0.3.3.zip has > notice.html file which is not present in Maven re-distribution) > 5) lib/org.eclipse.sisu.inject-0.3.3.jar bundles ASM. ASM is MIT licensed, > thus every re-distribution MUST retain ASM copyright notice. > Maven re-distributes ASM and fails to comply with ASM license. > 6) lib/wagon-http-3.3.3-shaded.jar bundles jsoup > ([https://jsoup.org/license]) which is MIT-licensed. Maven fails to comply > with jsoup license. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6771) Please fix license issues
[ https://issues.apache.org/jira/browse/MNG-6771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16942227#comment-16942227 ] Vladimir Sitnikov commented on MNG-6771: One does not simply get a license from ASM: [https://gitlab.ow2.org/asm/asm/issues/317881] > Please fix license issues > - > > Key: MNG-6771 > URL: https://issues.apache.org/jira/browse/MNG-6771 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.6.2 >Reporter: Vladimir Sitnikov >Priority: Blocker > > Please feel free to adjust the priority, however > [http://www.apache.org/legal/release-policy.html#licensing] says that license > clearance is a must, thus I report this as a Blocker. > {quote}Every ASF release MUST comply with ASF licensing policy. This > requirement is of utmost importance > {quote} > I downloaded apache-maven-3.6.2-bin.zip, and I see the following issues with > it (note: there might be more): > 1) apache-maven-3.6.2/LICENSE: > {quote} - JCL 1.2 implemented over SLF4J > ([http://www.slf4j.org|http://www.slf4j.org/]) > org.slf4j:jcl-over-slf4j:jar:1.7.25 > License: MIT License (MIT) > [http://www.opensource.org/licenses/mit-license.php] > (lib/jcl-over-slf4j.license){quote} > The license for the artifact is most likely Apache 2.0 rather than MIT: > [https://github.com/qos-ch/slf4j/tree/master/jcl-over-slf4j] > 2) apache-maven-3.6.2/LICENSE: > {quote} - SLF4J API Module ([http://www.slf4j.org|http://www.slf4j.org/]) > org.slf4j:slf4j-api:jar:1.7.25 > License: MIT License (MIT) > [http://www.opensource.org/licenses/mit-license.php] > (lib/slf4j-api.license){quote} > Maven does not comply with SLF4j license. > Here's license for SLF4j: [https://www.slf4j.org/license.html] > It requires to include slf4j copyright notice, however, Maven fails to do > that > 3) [http://www.opensource.org/licenses/mit-license.php] must not be used as > it almost never points to a true license. It is extremely unluky that someone > would copyright their work as "Copyright (c) " > 4) apache-maven-3.6.2/LICENSE: > {quote} - org.eclipse.sisu.inject > ([http://www.eclipse.org/sisu/org.eclipse.sisu.inject/]) > org.eclipse.sisu:org.eclipse.sisu.inject:eclipse-plugin:0.3.3 > License: Eclipse Public License, Version 1.0 (EPL-1.0) > [http://www.eclipse.org/legal/epl-v10.html] > (lib/org.eclipse.sisu.inject.license){quote} > The link to eclipse.org/sisu responds with 404. > sisu might have their own copyright notices that should be retained, however > Maven re-distributes none of them (org.eclipse.sisu.inject.site-0.3.3.zip has > notice.html file which is not present in Maven re-distribution) > 5) lib/org.eclipse.sisu.inject-0.3.3.jar bundles ASM. ASM is MIT licensed, > thus every re-distribution MUST retain ASM copyright notice. > Maven re-distributes ASM and fails to comply with ASM license. > 6) lib/wagon-http-3.3.3-shaded.jar bundles jsoup > ([https://jsoup.org/license]) which is MIT-licensed. Maven fails to comply > with jsoup license. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MNG-6771) Please fix license issues
Vladimir Sitnikov created MNG-6771: -- Summary: Please fix license issues Key: MNG-6771 URL: https://issues.apache.org/jira/browse/MNG-6771 Project: Maven Issue Type: Bug Components: core Affects Versions: 3.6.2 Reporter: Vladimir Sitnikov Please feel free to adjust the priority, however [http://www.apache.org/legal/release-policy.html#licensing] says that license clearance is a must, thus I report this as a Blocker. {quote}Every ASF release MUST comply with ASF licensing policy. This requirement is of utmost importance {quote} I downloaded apache-maven-3.6.2-bin.zip, and I see the following issues with it (note: there might be more): 1) apache-maven-3.6.2/LICENSE: {quote} - JCL 1.2 implemented over SLF4J ([http://www.slf4j.org|http://www.slf4j.org/]) org.slf4j:jcl-over-slf4j:jar:1.7.25 License: MIT License (MIT) [http://www.opensource.org/licenses/mit-license.php] (lib/jcl-over-slf4j.license){quote} The license for the artifact is most likely Apache 2.0 rather than MIT: [https://github.com/qos-ch/slf4j/tree/master/jcl-over-slf4j] 2) apache-maven-3.6.2/LICENSE: {quote} - SLF4J API Module ([http://www.slf4j.org|http://www.slf4j.org/]) org.slf4j:slf4j-api:jar:1.7.25 License: MIT License (MIT) [http://www.opensource.org/licenses/mit-license.php] (lib/slf4j-api.license){quote} Maven does not comply with SLF4j license. Here's license for SLF4j: [https://www.slf4j.org/license.html] It requires to include slf4j copyright notice, however, Maven fails to do that 3) [http://www.opensource.org/licenses/mit-license.php] must not be used as it almost never points to a true license. It is extremely unluky that someone would copyright their work as "Copyright (c) " 4) apache-maven-3.6.2/LICENSE: {quote} - org.eclipse.sisu.inject ([http://www.eclipse.org/sisu/org.eclipse.sisu.inject/]) org.eclipse.sisu:org.eclipse.sisu.inject:eclipse-plugin:0.3.3 License: Eclipse Public License, Version 1.0 (EPL-1.0) [http://www.eclipse.org/legal/epl-v10.html] (lib/org.eclipse.sisu.inject.license){quote} The link to eclipse.org/sisu responds with 404. sisu might have their own copyright notices that should be retained, however Maven re-distributes none of them (org.eclipse.sisu.inject.site-0.3.3.zip has notice.html file which is not present in Maven re-distribution) 5) lib/org.eclipse.sisu.inject-0.3.3.jar bundles ASM. ASM is MIT licensed, thus every re-distribution MUST retain ASM copyright notice. Maven re-distributes ASM and fails to comply with ASM license. 6) lib/wagon-http-3.3.3-shaded.jar bundles jsoup ([https://jsoup.org/license]) which is MIT-licensed. Maven fails to comply with jsoup license. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6677) Ability to declare machine-readable license identifier for project
[ https://issues.apache.org/jira/browse/MNG-6677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16861468#comment-16861468 ] Vladimir Sitnikov commented on MNG-6677: {quote}This still does not the id of the license in the list. {quote} The point of field is to provide machine-readable meaning. In other words, it is intentional that I don't put "Tomcat BSD-Style License" to expression. Does that answer the question? PS. We could just have a small conversation over zoom/hangout if you think that would be faster. PPS. I do get the topic is complicated, and I'm really sorry it takes time to type/read :-/ PPPS. All this thread appeared for me when I was trying to verify third-party licenses for Apache JMeter. > Ability to declare machine-readable license identifier for project > -- > > Key: MNG-6677 > URL: https://issues.apache.org/jira/browse/MNG-6677 > Project: Maven > Issue Type: Improvement > Components: POM >Affects Versions: 3.6.1 >Reporter: Vladimir Sitnikov >Priority: Major > > Current model for license is something, yet it is not machine-friendly. > Developers tend to put random data into > {{..}}, and it is hard to analyze in > automatic way. > What if we could use SPDX license identifiers/expressions for license > information? > Note: currently POM allows to list multiple tags, and it is not > clear how they should be treated (and? or?). So a machine-readable field > should probably allow for AND/OR license expressions. > So it would be nice if there was a way to declare a machine-readable license > tag. > I'm not affiliated with SPDX, however OSGi use those ids: > https://osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module-bundle-license -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6677) Ability to declare machine-readable license identifier for project
[ https://issues.apache.org/jira/browse/MNG-6677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16861464#comment-16861464 ] Vladimir Sitnikov commented on MNG-6677: {quote}As an alternative, you can reuse the name element to write your SPDX ID. Isn't that enough for the moment? {quote} I tried that, however there are lots of "license variations". For instance: [http://jtidy.sourceforge.net/license.html] It is not a "standard" license. So it is somewhat expected to list that license in pom.xml as {code:xml} Java HTML Tidy License http://jtidy.sourceforge.net/license.html {code} For most of the cases (all?) it would be equivalent to BSD-3-Clause, however it would probably be incorrect to label the license as just BSD-3-Clause. That is why I'm inclined that name/url seem to be not that bad, and it would probably make sense to have a field for "machine-readable effective meaning" of the license. > Ability to declare machine-readable license identifier for project > -- > > Key: MNG-6677 > URL: https://issues.apache.org/jira/browse/MNG-6677 > Project: Maven > Issue Type: Improvement > Components: POM >Affects Versions: 3.6.1 >Reporter: Vladimir Sitnikov >Priority: Major > > Current model for license is something, yet it is not machine-friendly. > Developers tend to put random data into > {{..}}, and it is hard to analyze in > automatic way. > What if we could use SPDX license identifiers/expressions for license > information? > Note: currently POM allows to list multiple tags, and it is not > clear how they should be treated (and? or?). So a machine-readable field > should probably allow for AND/OR license expressions. > So it would be nice if there was a way to declare a machine-readable license > tag. > I'm not affiliated with SPDX, however OSGi use those ids: > https://osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module-bundle-license -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6677) Ability to declare machine-readable license identifier for project
[ https://issues.apache.org/jira/browse/MNG-6677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16861452#comment-16861452 ] Vladimir Sitnikov commented on MNG-6677: {quote}Please make a proposal how you would like the next POM version look like.{quote} For instance: {code:xml} (Apache-2.0 AND MIT) OR (Apache-2.0 AND BSD-3-Clause) Tomcat BSD-Style License tomcat.apache.org/license-bsd.txt Tomcat MIT-Style License tomcat.apache.org/license-mit.txt {code} > Ability to declare machine-readable license identifier for project > -- > > Key: MNG-6677 > URL: https://issues.apache.org/jira/browse/MNG-6677 > Project: Maven > Issue Type: Improvement > Components: POM >Affects Versions: 3.6.1 >Reporter: Vladimir Sitnikov >Priority: Major > > Current model for license is something, yet it is not machine-friendly. > Developers tend to put random data into > {{..}}, and it is hard to analyze in > automatic way. > What if we could use SPDX license identifiers/expressions for license > information? > Note: currently POM allows to list multiple tags, and it is not > clear how they should be treated (and? or?). So a machine-readable field > should probably allow for AND/OR license expressions. > So it would be nice if there was a way to declare a machine-readable license > tag. > I'm not affiliated with SPDX, however OSGi use those ids: > https://osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module-bundle-license -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6677) Ability to declare machine-readable license identifier for project
[ https://issues.apache.org/jira/browse/MNG-6677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16861449#comment-16861449 ] Vladimir Sitnikov commented on MNG-6677: However it would be quite complicated if licensing for different uses is different (e.g. MIT in winter and BSD in summer). I guess there should be a pre-defined value for those cases like ITS_COMPLICATED_CONSULT_LAWYERS, so machine-reader could figure out that the case is complicated and require manual intervention. > Ability to declare machine-readable license identifier for project > -- > > Key: MNG-6677 > URL: https://issues.apache.org/jira/browse/MNG-6677 > Project: Maven > Issue Type: Improvement > Components: POM >Affects Versions: 3.6.1 >Reporter: Vladimir Sitnikov >Priority: Major > > Current model for license is something, yet it is not machine-friendly. > Developers tend to put random data into > {{..}}, and it is hard to analyze in > automatic way. > What if we could use SPDX license identifiers/expressions for license > information? > Note: currently POM allows to list multiple tags, and it is not > clear how they should be treated (and? or?). So a machine-readable field > should probably allow for AND/OR license expressions. > So it would be nice if there was a way to declare a machine-readable license > tag. > I'm not affiliated with SPDX, however OSGi use those ids: > https://osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module-bundle-license -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (MNG-6677) Ability to declare machine-readable license identifier for project
[ https://issues.apache.org/jira/browse/MNG-6677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16861440#comment-16861440 ] Vladimir Sitnikov edited comment on MNG-6677 at 6/11/19 8:10 PM: - {quote}The problem is with the list of licenses also that some people write two licenses in the name element because it is so. So is Tomcat, for example. How do you want to cover that? {quote} Technically speaking, SPDX has notion of "license expressions" which looks like {{Apache-2.0+ WITH Bison-exception-2.2}} (which is (Apache 2.0 or later) with Bison exception...) The same would go for "(Apache-2.0 AND MIT) OR (Apache-2.0 AND BSD-3-Clause)" I don't think we need to have xml representation of that expression though, and we could be just fine with a string field with "license expression" inside. {quote}What we could do is to add the license id optionally to the manifest or the properties bundled the archiver, but that you can already do on your own{quote} Unfortunately, that is not enforced by default. Maven Central enforces everybody to have tag. So they have it. As you know it is not parsable :( was (Author: vladimirsitnikov): {quote}The problem is with the list of licenses also that some people write two licenses in the name element because it is so. So is Tomcat, for example. How do you want to cover that? {quote} Technically speaking, SPDX has notion of "license expressions" which looks like {{Apache-2.0+ WITH Bison-exception-2.2}} (which is (Apache 2.0 or later) with Bison exception...) I don't think we need to have xml representation of that expression though, and we could be just fine with a string field with "license expression" inside. {quote}What we could do is to add the license id optionally to the manifest or the properties bundled the archiver, but that you can already do on your own{quote} Unfortunately, that is not enforced by default. Maven Central enforces everybody to have tag. So they have it. As you know it is not parsable :( > Ability to declare machine-readable license identifier for project > -- > > Key: MNG-6677 > URL: https://issues.apache.org/jira/browse/MNG-6677 > Project: Maven > Issue Type: Improvement > Components: POM >Affects Versions: 3.6.1 >Reporter: Vladimir Sitnikov >Priority: Major > > Current model for license is something, yet it is not machine-friendly. > Developers tend to put random data into > {{..}}, and it is hard to analyze in > automatic way. > What if we could use SPDX license identifiers/expressions for license > information? > Note: currently POM allows to list multiple tags, and it is not > clear how they should be treated (and? or?). So a machine-readable field > should probably allow for AND/OR license expressions. > So it would be nice if there was a way to declare a machine-readable license > tag. > I'm not affiliated with SPDX, however OSGi use those ids: > https://osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module-bundle-license -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6677) Ability to declare machine-readable license identifier for project
[ https://issues.apache.org/jira/browse/MNG-6677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16861440#comment-16861440 ] Vladimir Sitnikov commented on MNG-6677: {quote}The problem is with the list of licenses also that some people write two licenses in the name element because it is so. So is Tomcat, for example. How do you want to cover that? {quote} Technically speaking, SPDX has notion of "license expressions" which looks like {{Apache-2.0+ WITH Bison-exception-2.2}} (which is (Apache 2.0 or later) with Bison exception...) I don't think we need to have xml representation of that expression though, and we could be just fine with a string field with "license expression" inside. {quote}What we could do is to add the license id optionally to the manifest or the properties bundled the archiver, but that you can already do on your own{quote} Unfortunately, that is not enforced by default. Maven Central enforces everybody to have tag. So they have it. As you know it is not parsable :( > Ability to declare machine-readable license identifier for project > -- > > Key: MNG-6677 > URL: https://issues.apache.org/jira/browse/MNG-6677 > Project: Maven > Issue Type: Improvement > Components: POM >Affects Versions: 3.6.1 >Reporter: Vladimir Sitnikov >Priority: Major > > Current model for license is something, yet it is not machine-friendly. > Developers tend to put random data into > {{..}}, and it is hard to analyze in > automatic way. > What if we could use SPDX license identifiers/expressions for license > information? > Note: currently POM allows to list multiple tags, and it is not > clear how they should be treated (and? or?). So a machine-readable field > should probably allow for AND/OR license expressions. > So it would be nice if there was a way to declare a machine-readable license > tag. > I'm not affiliated with SPDX, however OSGi use those ids: > https://osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module-bundle-license -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6677) Ability to declare machine-readable license identifier for project
[ https://issues.apache.org/jira/browse/MNG-6677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16861406#comment-16861406 ] Vladimir Sitnikov commented on MNG-6677: [~michael-o], I have tried to search for the request, and I fail to find one. I see similar issues like https://issues.apache.org/jira/browse/RAT-251 and https://issues.apache.org/jira/browse/MPIR-382 Did you have something else in mind? The fun fact is I came from https://github.com/spdx/tools/issues/192 "Support normalization of license names" (which is very close to MPIR-382), however for now it looks like the idea of trying to use "standard ID/URL" in tag won't fly. That is why I wonder if a dedicated machine-readable field could appear. Note: I know that 4.0.0 is here "for ages". > Ability to declare machine-readable license identifier for project > -- > > Key: MNG-6677 > URL: https://issues.apache.org/jira/browse/MNG-6677 > Project: Maven > Issue Type: Improvement > Components: POM >Affects Versions: 3.6.1 >Reporter: Vladimir Sitnikov >Priority: Major > > Current model for license is something, yet it is not machine-friendly. > Developers tend to put random data into > {{..}}, and it is hard to analyze in > automatic way. > What if we could use SPDX license identifiers/expressions for license > information? > Note: currently POM allows to list multiple tags, and it is not > clear how they should be treated (and? or?). So a machine-readable field > should probably allow for AND/OR license expressions. > So it would be nice if there was a way to declare a machine-readable license > tag. > I'm not affiliated with SPDX, however OSGi use those ids: > https://osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module-bundle-license -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MNG-6677) Ability to declare machine-readable license identifier for project
[ https://issues.apache.org/jira/browse/MNG-6677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Sitnikov updated MNG-6677: --- Description: Current model for license is something, yet it is not machine-friendly. Developers tend to put random data into {{..}}, and it is hard to analyze in automatic way. What if we could use SPDX license identifiers/expressions for license information? Note: currently POM allows to list multiple tags, and it is not clear how they should be treated (and? or?). So a machine-readable field should probably allow for AND/OR license expressions. So it would be nice if there was a way to declare a machine-readable license tag. I'm not affiliated with SPDX, however OSGi use those ids: https://osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module-bundle-license was: Current model for license is something, yet it is not machine-friendly. Developers tend to put random data into {{..}}, and it is hard to analyze in automatic way. What if we could use SPDX license identifiers/expressions for license information? Note: currently POM is allowed to list multiple tags, and it is not clear how they should be treated (and? or?). So it would be nice if there was a way to declare a machine-readable license tag. I'm not affiliated with SPDX, however OSGi use those ids: https://osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module-bundle-license > Ability to declare machine-readable license identifier for project > -- > > Key: MNG-6677 > URL: https://issues.apache.org/jira/browse/MNG-6677 > Project: Maven > Issue Type: Improvement > Components: POM >Affects Versions: 3.6.1 >Reporter: Vladimir Sitnikov >Priority: Major > > Current model for license is something, yet it is not machine-friendly. > Developers tend to put random data into > {{..}}, and it is hard to analyze in > automatic way. > What if we could use SPDX license identifiers/expressions for license > information? > Note: currently POM allows to list multiple tags, and it is not > clear how they should be treated (and? or?). So a machine-readable field > should probably allow for AND/OR license expressions. > So it would be nice if there was a way to declare a machine-readable license > tag. > I'm not affiliated with SPDX, however OSGi use those ids: > https://osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module-bundle-license -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MNG-6677) Ability to declare machine-readable license identifier for project
Vladimir Sitnikov created MNG-6677: -- Summary: Ability to declare machine-readable license identifier for project Key: MNG-6677 URL: https://issues.apache.org/jira/browse/MNG-6677 Project: Maven Issue Type: Improvement Components: POM Affects Versions: 3.6.1 Reporter: Vladimir Sitnikov Current model for license is something, yet it is not machine-friendly. Developers tend to put random data into {{..}}, and it is hard to analyze in automatic way. What if we could use SPDX license identifiers/expressions for license information? Note: currently POM is allowed to list multiple tags, and it is not clear how they should be treated (and? or?). So it would be nice if there was a way to declare a machine-readable license tag. I'm not affiliated with SPDX, however OSGi use those ids: https://osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module-bundle-license -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1430) Parallel parameterized JUnit test hangs on Linux
[ https://issues.apache.org/jira/browse/SUREFIRE-1430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16854987#comment-16854987 ] Vladimir Sitnikov commented on SUREFIRE-1430: - Just in case, here's a thread dump of the failure case. It looks like maven-surefire creates a Semaphore with capacity of 1, and: 1) main thread acquires a permit just before {{at org.apache.maven.surefire.junitcore.pc.Scheduler.schedule(Scheduler.java:346)}} 2) pool-1-thread-1 tries to acquire another permit {{at org.apache.maven.surefire.junitcore.pc.Scheduler.schedule(Scheduler.java:342)} It looks like "main thread" is executing "a suite" while "pool-1-thread-1" is executing tests. I don't want to make quick judgements, however it looks like "suite executor" should not acquire permits in case its only purpose is to delegate work to a worker pool. {noformat} Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.151-b12 mixed mode): "pool-1-thread-1" #8 prio=5 os_prio=0 tid=0x7f4f40326000 nid=0x12e5 waiting on condition [0x7f4f29c33000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0xe06102e0> (a java.util.concurrent.Semaphore$FairSync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) at java.util.concurrent.Semaphore.acquire(Semaphore.java:312) at org.apache.maven.surefire.junitcore.pc.ThreadResourcesBalancer.acquirePermit(ThreadResourcesBalancer.java:75) at org.apache.maven.surefire.junitcore.pc.Scheduler.schedule(Scheduler.java:342) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) at org.junit.runners.ParentRunner.run(ParentRunner.java:363) at org.junit.runners.Suite.runChild(Suite.java:128) at org.junit.runners.Suite.runChild(Suite.java:27) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) at org.apache.maven.surefire.junitcore.pc.Scheduler$1.run(Scheduler.java:387) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) "Service Thread" #7 daemon prio=9 os_prio=0 tid=0x7f4f40141000 nid=0x12e3 runnable [0x] java.lang.Thread.State: RUNNABLE "C1 CompilerThread1" #6 daemon prio=9 os_prio=0 tid=0x7f4f4013e000 nid=0x12e2 waiting on condition [0x] java.lang.Thread.State: RUNNABLE "C2 CompilerThread0" #5 daemon prio=9 os_prio=0 tid=0x7f4f4013b000 nid=0x12e1 waiting on condition [0x] java.lang.Thread.State: RUNNABLE "Signal Dispatcher" #4 daemon prio=9 os_prio=0 tid=0x7f4f40139800 nid=0x12e0 waiting on condition [0x] java.lang.Thread.State: RUNNABLE "Finalizer" #3 daemon prio=8 os_prio=0 tid=0x7f4f40107000 nid=0x12df in Object.wait() [0x7f4f2ae4f000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0xe0008ec8> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143) - locked <0xe0008ec8> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:164) at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:209) "Reference Handler" #2 daemon prio=10 os_prio=0 tid=0x7f4f40102800 nid=0x12de in Object.wait() [0x7f4f2af5] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0xe0006b68> (a java.lang.ref.Reference$Lock) at java.lang.Object.wait(Object.java:502) at java.lang.ref.Reference.tryHandlePending(Reference.java:191) - locked <0xe0006b68> (a java.lang.ref.Reference$Lock) at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:153) {noformat} main thread: {noformat} "main" #1 prio=5 os_prio=0 tid=0x7f4f40009800 nid=0x12da waiting on condition [0x7f4f4617d000] java.lang.Thread.State: WAITI
[jira] [Commented] (MRRESOURCES-91) Avoid overwrite of the destination file if the produced contents is the same
[ https://issues.apache.org/jira/browse/MRRESOURCES-91?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1661#comment-1661 ] Vladimir Sitnikov commented on MRRESOURCES-91: -- [~krosenvold], would you please release maven-remote-resources-plugin 1.6? It has been a while since the patch was merged. > Avoid overwrite of the destination file if the produced contents is the same > > > Key: MRRESOURCES-91 > URL: https://issues.apache.org/jira/browse/MRRESOURCES-91 > Project: Maven Remote Resources Plugin > Issue Type: Bug >Affects Versions: 1.5 >Reporter: Vladimir Sitnikov >Assignee: Kristian Rosenvold >Priority: Major > Fix For: 1.6.0 > > > maven-remote-resource-plugin is used in Apache pom to add DEPENDENCIES, and > the resulting file is overwritten on each build. > It leads to jar being rebuild, etc leading to longer compilation times. > I suggest to compare the produced contents with the existing file. > If both are equal, skip the file being overwritten. > The net win is subsequent build times are improved. > Here's pull request that fixes the problem: > https://github.com/apache/maven-plugins/pull/40 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] (MRRESOURCES-91) Avoid overwrite of the destination file if the produced contents is the same
Vladimir Sitnikov created MRRESOURCES-91: Summary: Avoid overwrite of the destination file if the produced contents is the same Key: MRRESOURCES-91 URL: https://jira.codehaus.org/browse/MRRESOURCES-91 Project: Maven Remote Resources Plugin Issue Type: Bug Affects Versions: 1.5 Reporter: Vladimir Sitnikov maven-remote-resource-plugin is used in Apache pom to add DEPENDENCIES, and the resulting file is overwritten on each build. It leads to jar being rebuild, etc leading to longer compilation times. I suggest to compare the produced contents with the existing file. If both are equal, skip the file being overwritten. The net win is subsequent build times are improved. Here's pull request that fixes the problem: https://github.com/apache/maven-plugins/pull/40 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSHARED-394) Avoid rewrite of destination in DefaultMavenFileFilter#filterFile when producing the same contents
[ https://jira.codehaus.org/browse/MSHARED-394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=359194#comment-359194 ] Vladimir Sitnikov commented on MSHARED-394: --- This https://github.com/apache/maven-plugins/pull/40 solves DEPENDENCIES, LICENSE, NOTICE being overwritten. However the following properties resource file triggers jar rebuild: {noformat} driver.name=Calcite JDBC Driver driver.version=${pom.version} product.name=Calcite product.version=${pom.version}{noformat} So, technically, some kind of smart maven-filtering is required. > Avoid rewrite of destination in DefaultMavenFileFilter#filterFile when > producing the same contents > -- > > Key: MSHARED-394 > URL: https://jira.codehaus.org/browse/MSHARED-394 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-filtering >Affects Versions: maven-filtering-1.2 >Reporter: Vladimir Sitnikov >Assignee: Kristian Rosenvold > > See relevant MRESOURCES-168. > When processing "filtered" resources, maven-filtering always overwrites > destination files, leading to rebuild of the upstream results (e.g. jar file > being repackaged due to "DEBUG] isUp2date: false (Resource with newer > modification date found.)"). > I think maven-filtering can do better job here: it can double-check if the > resource contents after filtering is equal to the contents of the existing > file, then it should avoid overwrite of the destination file. > The change would be localized in > {{org.apache.maven.shared.filtering.DefaultMavenFileFilter#filterFile}}: > {code:java} > private void filterFile(@Nonnull File from, @Nonnull File to, @Nullable > String encoding, @Nullable List wrappers) throws IOException, > MavenFilteringException { > if(wrappers != null && wrappers.size() > 0) { > Reader fileReader = null; > Writer fileWriter = null; > try { > fileReader = this.getFileReader(encoding, from); > fileWriter = this.getFileWriter(encoding, to); // Here > temporary buffer should be used to avoid accidental file overwrite > Reader src = this.readerFilter.filter(fileReader, true, > wrappers); > IOUtil.copy(src, fileWriter); > } finally { > IOUtil.close(fileReader); > IOUtil.close(fileWriter); > } > } else if(to.lastModified() < from.lastModified()) { > FileUtils.copyFile(from, to); > } > }{code} > The change would require to buffer the contents in memory, thus it might lead > to OutOfMemory errors. I suggest disabling this buffering if the size of the > source file exceeds some threshold. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSHARED-394) Avoid rewrite of destination in DefaultMavenFileFilter#filterFile when producing the same contents
[ https://jira.codehaus.org/browse/MSHARED-394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=359191#comment-359191 ] Vladimir Sitnikov commented on MSHARED-394: --- Well, I thought Velocity is somewhere inside maven-filtering. I did a double-check and it turns out the offending velocity is inside maven-remote-resources-plugin. I'll file a pull request there. However, the improvement to properties filtering still makes sense. For resource-based filtering, you'll have hard time "caching" input properties for reader-based filtering. It does not contain file name, thus you can't tell if the source was modified or not. > Avoid rewrite of destination in DefaultMavenFileFilter#filterFile when > producing the same contents > -- > > Key: MSHARED-394 > URL: https://jira.codehaus.org/browse/MSHARED-394 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-filtering >Affects Versions: maven-filtering-1.2 >Reporter: Vladimir Sitnikov >Assignee: Kristian Rosenvold > > See relevant MRESOURCES-168. > When processing "filtered" resources, maven-filtering always overwrites > destination files, leading to rebuild of the upstream results (e.g. jar file > being repackaged due to "DEBUG] isUp2date: false (Resource with newer > modification date found.)"). > I think maven-filtering can do better job here: it can double-check if the > resource contents after filtering is equal to the contents of the existing > file, then it should avoid overwrite of the destination file. > The change would be localized in > {{org.apache.maven.shared.filtering.DefaultMavenFileFilter#filterFile}}: > {code:java} > private void filterFile(@Nonnull File from, @Nonnull File to, @Nullable > String encoding, @Nullable List wrappers) throws IOException, > MavenFilteringException { > if(wrappers != null && wrappers.size() > 0) { > Reader fileReader = null; > Writer fileWriter = null; > try { > fileReader = this.getFileReader(encoding, from); > fileWriter = this.getFileWriter(encoding, to); // Here > temporary buffer should be used to avoid accidental file overwrite > Reader src = this.readerFilter.filter(fileReader, true, > wrappers); > IOUtil.copy(src, fileWriter); > } finally { > IOUtil.close(fileReader); > IOUtil.close(fileWriter); > } > } else if(to.lastModified() < from.lastModified()) { > FileUtils.copyFile(from, to); > } > }{code} > The change would require to buffer the contents in memory, thus it might lead > to OutOfMemory errors. I suggest disabling this buffering if the size of the > source file exceeds some threshold. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSHARED-394) Avoid rewrite of destination in DefaultMavenFileFilter#filterFile when producing the same contents
[ https://jira.codehaus.org/browse/MSHARED-394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=359172#comment-359172 ] Vladimir Sitnikov edited comment on MSHARED-394 at 12/16/14 2:34 PM: - This is non-trivial. 0) My main concern is Velocity templates. org.apache:apache pom uses Velocity templates to render {{DEPENDENCIES}}, etc. 1) Regular property-only interpolations are important as well, however it does not make much sense if we cover just the basic stuff. 2) In Velocity, I expect the following expressions are very hard to tame: {{#include("one.gif","two.txt","three.htm")}}, {{#evaluate}}, {{#define}} 3) {{MavenProject}} is passed to the {{VelocityContext}}. I am not sure if you can identify "the required bits". If you try to hash the whole {{MavenProject}} thing, I expect the cache will always miss. Do you still think this kind of coupling between filtering and Velocity is worth doing? was (Author: vladimirsitnikov): This is non-trivial. 0) My main concern is Velocity templates. org.apache:apache pom uses Velocity templates to render {{DEPENDENCIES}}, etc. 1) Regular property-only interpolations are important as well, however I does not make much sense if we cover just the basic stuff. 2) In Velocity, I expect the following expressions are very hard to tame: {{#include("one.gif","two.txt","three.htm")}}, {{#evaluate}}, {{#define}} 3) {{MavenProject}} is passed to the {{VelocityContext}}. I am not sure if you can identify "the required bits". If you try to hash the whole {{MavenProject}} thing, I expect the cache will always miss. Do you still think this kind of coupling between filtering and Velocity is worth doing? > Avoid rewrite of destination in DefaultMavenFileFilter#filterFile when > producing the same contents > -- > > Key: MSHARED-394 > URL: https://jira.codehaus.org/browse/MSHARED-394 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-filtering >Affects Versions: maven-filtering-1.2 >Reporter: Vladimir Sitnikov >Assignee: Kristian Rosenvold > > See relevant MRESOURCES-168. > When processing "filtered" resources, maven-filtering always overwrites > destination files, leading to rebuild of the upstream results (e.g. jar file > being repackaged due to "DEBUG] isUp2date: false (Resource with newer > modification date found.)"). > I think maven-filtering can do better job here: it can double-check if the > resource contents after filtering is equal to the contents of the existing > file, then it should avoid overwrite of the destination file. > The change would be localized in > {{org.apache.maven.shared.filtering.DefaultMavenFileFilter#filterFile}}: > {code:java} > private void filterFile(@Nonnull File from, @Nonnull File to, @Nullable > String encoding, @Nullable List wrappers) throws IOException, > MavenFilteringException { > if(wrappers != null && wrappers.size() > 0) { > Reader fileReader = null; > Writer fileWriter = null; > try { > fileReader = this.getFileReader(encoding, from); > fileWriter = this.getFileWriter(encoding, to); // Here > temporary buffer should be used to avoid accidental file overwrite > Reader src = this.readerFilter.filter(fileReader, true, > wrappers); > IOUtil.copy(src, fileWriter); > } finally { > IOUtil.close(fileReader); > IOUtil.close(fileWriter); > } > } else if(to.lastModified() < from.lastModified()) { > FileUtils.copyFile(from, to); > } > }{code} > The change would require to buffer the contents in memory, thus it might lead > to OutOfMemory errors. I suggest disabling this buffering if the size of the > source file exceeds some threshold. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSHARED-394) Avoid rewrite of destination in DefaultMavenFileFilter#filterFile when producing the same contents
[ https://jira.codehaus.org/browse/MSHARED-394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=359172#comment-359172 ] Vladimir Sitnikov commented on MSHARED-394: --- This is non-trivial. 0) My main concern is Velocity templates. org.apache:apache pom uses Velocity templates to render {{DEPENDENCIES}}, etc. 1) Regular property-only interpolations are important as well, however I does not make much sense if we cover just the basic stuff. 2) In Velocity, I expect the following expressions are very hard to tame: {{#include("one.gif","two.txt","three.htm")}}, {{#evaluate}}, {{#define}} 3) {{MavenProject}} is passed to the {{VelocityContext}}. I am not sure if you can identify "the required bits". If you try to hash the whole {{MavenProject}} thing, I expect the cache will always miss. Do you still think this kind of coupling between filtering and Velocity is worth doing? > Avoid rewrite of destination in DefaultMavenFileFilter#filterFile when > producing the same contents > -- > > Key: MSHARED-394 > URL: https://jira.codehaus.org/browse/MSHARED-394 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-filtering >Affects Versions: maven-filtering-1.2 >Reporter: Vladimir Sitnikov >Assignee: Kristian Rosenvold > > See relevant MRESOURCES-168. > When processing "filtered" resources, maven-filtering always overwrites > destination files, leading to rebuild of the upstream results (e.g. jar file > being repackaged due to "DEBUG] isUp2date: false (Resource with newer > modification date found.)"). > I think maven-filtering can do better job here: it can double-check if the > resource contents after filtering is equal to the contents of the existing > file, then it should avoid overwrite of the destination file. > The change would be localized in > {{org.apache.maven.shared.filtering.DefaultMavenFileFilter#filterFile}}: > {code:java} > private void filterFile(@Nonnull File from, @Nonnull File to, @Nullable > String encoding, @Nullable List wrappers) throws IOException, > MavenFilteringException { > if(wrappers != null && wrappers.size() > 0) { > Reader fileReader = null; > Writer fileWriter = null; > try { > fileReader = this.getFileReader(encoding, from); > fileWriter = this.getFileWriter(encoding, to); // Here > temporary buffer should be used to avoid accidental file overwrite > Reader src = this.readerFilter.filter(fileReader, true, > wrappers); > IOUtil.copy(src, fileWriter); > } finally { > IOUtil.close(fileReader); > IOUtil.close(fileWriter); > } > } else if(to.lastModified() < from.lastModified()) { > FileUtils.copyFile(from, to); > } > }{code} > The change would require to buffer the contents in memory, thus it might lead > to OutOfMemory errors. I suggest disabling this buffering if the size of the > source file exceeds some threshold. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSHARED-394) Avoid rewrite of destination in DefaultMavenFileFilter#filterFile when producing the same contents
[ https://jira.codehaus.org/browse/MSHARED-394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=359160#comment-359160 ] Vladimir Sitnikov commented on MSHARED-394: --- Thanks for the update. Good to know there is better solution. Can you please give a high-level overview? What's the idea? > Avoid rewrite of destination in DefaultMavenFileFilter#filterFile when > producing the same contents > -- > > Key: MSHARED-394 > URL: https://jira.codehaus.org/browse/MSHARED-394 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-filtering >Affects Versions: maven-filtering-1.2 >Reporter: Vladimir Sitnikov >Assignee: Kristian Rosenvold > > See relevant MRESOURCES-168. > When processing "filtered" resources, maven-filtering always overwrites > destination files, leading to rebuild of the upstream results (e.g. jar file > being repackaged due to "DEBUG] isUp2date: false (Resource with newer > modification date found.)"). > I think maven-filtering can do better job here: it can double-check if the > resource contents after filtering is equal to the contents of the existing > file, then it should avoid overwrite of the destination file. > The change would be localized in > {{org.apache.maven.shared.filtering.DefaultMavenFileFilter#filterFile}}: > {code:java} > private void filterFile(@Nonnull File from, @Nonnull File to, @Nullable > String encoding, @Nullable List wrappers) throws IOException, > MavenFilteringException { > if(wrappers != null && wrappers.size() > 0) { > Reader fileReader = null; > Writer fileWriter = null; > try { > fileReader = this.getFileReader(encoding, from); > fileWriter = this.getFileWriter(encoding, to); // Here > temporary buffer should be used to avoid accidental file overwrite > Reader src = this.readerFilter.filter(fileReader, true, > wrappers); > IOUtil.copy(src, fileWriter); > } finally { > IOUtil.close(fileReader); > IOUtil.close(fileWriter); > } > } else if(to.lastModified() < from.lastModified()) { > FileUtils.copyFile(from, to); > } > }{code} > The change would require to buffer the contents in memory, thus it might lead > to OutOfMemory errors. I suggest disabling this buffering if the size of the > source file exceeds some threshold. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSHARED-394) Avoid rewrite of destination in DefaultMavenFileFilter#filterFile when producing the same contents
[ https://jira.codehaus.org/browse/MSHARED-394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=359090#comment-359090 ] Vladimir Sitnikov edited comment on MSHARED-394 at 12/15/14 4:20 AM: - {quote}This feature is currently only implemented in assembly-plugin but "someone" might want to take a look at migrating this to other plugins.{quote} Can you please pin-point the API? I still see no good reason why say "maven-assembly-plugin" should double-check the contents of resource "just in case the contents is equal". Well, there might be ill-behaving plugins (including external to maven) that regenerate files for no reason, however, it is still an overhead to maven-assembly when it has to recheck the contents. It would be better if well-known maven-resource-plugin would not regenerate the file in the first place. It turns out, maven-resources-plugin relies on maven-filtering, thus there is nothing to fix in maven-resource-plugin itself. Here's real life scenario: Apache recommends the following parent.pom: {code:xml} org.apache apache 14 {code} This pom defines maven-resources-plugin that creates {{DEPENDENCIES, LICENSE, NOTICE}} files. Due to "filtered files are always rewritten bug", maven-jar-plugin always rebuilds the jar. This takes noticeable time and this impacts lots of projects that inherit this pom. It impacts other projects that use filtered resources as well. The net effect is "maven is slow, just use gradle". {quote}This feature is currently only implemented in assembly-plugin but "someone" might want to take a look at migrating this to other plugins.{quote} Please clarify if you consider updating {{DefaultMavenFileFilter#filterFile}} a valid option. I guess I can figure out some pull request, however before I start the work I need to know if it has chances being committed. >From my point of view, 1) If maven-filtering must not be changed it would complicate client code with no significant reason 2) Updated {{filterFile}} would improve build times for all current plugin versions, while update of each "client" plugin would take a while 3) While having this feature implemented at different levels (in both maven-filtering, maven-jar, maven-assembly, etc) helps to cover more cases, I would suggest still cover the very basic case in maven-filtering as a quick-win. was (Author: vladimirsitnikov): {quote}This feature is currently only implemented in assembly-plugin but "someone" might want to take a look at migrating this to other plugins.{quote} Can you please pin-point the API? I still see no good reason why say "maven-assembly-plugin" should double-check the contents of resource "just in case the contents is equal". Well, there might be ill-behaving plugins (including external to maven) that regenerate files for no reason, however, it is still an overhead to maven-assembly when it has to recheck the contents. It would be better if well-known maven-resource-plugin would not regenerate the file in the first place. It turns out, maven-resources-plugin relies on maven-filtering, thus there is nothing to fix in maven-resource-plugin itself. Here's real life scenario: Apache recommends the following parent.pom: {code:xml} org.apache apache 14 {code} This pom defines maven-resources-plugin that creates {{DEPENDENCIES, LICENSE, NOTICE}} files. Due to "filtered files are always rewritten bug", maven-jar-plugin always rebuilds the jar. This takes noticeable time and this impacts lots of projects that inherit this pom. It impacts other projects that use filtered resources as well. The net effect is "maven is slow, just use gradle". {quote}This feature is currently only implemented in assembly-plugin but "someone" might want to take a look at migrating this to other plugins.{quote} Please clarify if you consider updating {{DefaultMavenFileFilter#filterFile}} a valid option. I guess I can figure out some pull request, however before starting the work I need to know if it has changes being committed. >From my point of view, 1) If maven-filtering must not be changed it would complicate client code with no significant reason 2) Updated {{filterFile}} would improve build times for all current plugin versions, while update of each "client" plugin would take a while 3) While having this feature implemented at different levels (in both maven-filtering, maven-jar, maven-assembly, etc) helps to cover more cases, I would suggest still cover the very basic case in maven-filtering as a quick-win. > Avoid rewrite of destination in DefaultMavenFileFilter#filterFile when > producing the same contents > -- > > Key: MSHARED-394 > URL: https://jira.codehaus.org/browse/MSHARED-394 > Project: Maven Sha
[jira] (MSHARED-394) Avoid rewrite of destination in DefaultMavenFileFilter#filterFile when producing the same contents
[ https://jira.codehaus.org/browse/MSHARED-394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=359090#comment-359090 ] Vladimir Sitnikov commented on MSHARED-394: --- {quote}This feature is currently only implemented in assembly-plugin but "someone" might want to take a look at migrating this to other plugins.{quote} Can you please pin-point the API? I still see no good reason why say "maven-assembly-plugin" should double-check the contents of resource "just in case the contents is equal". Well, there might be ill-behaving plugins (including external to maven) that regenerate files for no reason, however, it is still an overhead to maven-assembly when it has to recheck the contents. It would be better if well-known maven-resource-plugin would not regenerate the file in the first place. It turns out, maven-resources-plugin relies on maven-filtering, thus there is nothing to fix in maven-resource-plugin itself. Here's real life scenario: Apache recommends the following parent.pom: {code:xml} org.apache apache 14 {code} This pom defines maven-resources-plugin that creates {{DEPENDENCIES, LICENSE, NOTICE}} files. Due to "filtered files are always rewritten bug", maven-jar-plugin always rebuilds the jar. This takes noticeable time and this impacts lots of projects that inherit this pom. It impacts other projects that use filtered resources as well. The net effect is "maven is slow, just use gradle". {quote}This feature is currently only implemented in assembly-plugin but "someone" might want to take a look at migrating this to other plugins.{quote} Please clarify if you consider updating {{DefaultMavenFileFilter#filterFile}} a valid option. I guess I can figure out some pull request, however before starting the work I need to know if it has changes being committed. >From my point of view, 1) If maven-filtering must not be changed it would complicate client code with no significant reason 2) Updated {{filterFile}} would improve build times for all current plugin versions, while update of each "client" plugin would take a while 3) While having this feature implemented at different levels (in both maven-filtering, maven-jar, maven-assembly, etc) helps to cover more cases, I would suggest still cover the very basic case in maven-filtering as a quick-win. > Avoid rewrite of destination in DefaultMavenFileFilter#filterFile when > producing the same contents > -- > > Key: MSHARED-394 > URL: https://jira.codehaus.org/browse/MSHARED-394 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-filtering >Affects Versions: maven-filtering-1.2 >Reporter: Vladimir Sitnikov > > See relevant MRESOURCES-168. > When processing "filtered" resources, maven-filtering always overwrites > destination files, leading to rebuild of the upstream results (e.g. jar file > being repackaged due to "DEBUG] isUp2date: false (Resource with newer > modification date found.)"). > I think maven-filtering can do better job here: it can double-check if the > resource contents after filtering is equal to the contents of the existing > file, then it should avoid overwrite of the destination file. > The change would be localized in > {{org.apache.maven.shared.filtering.DefaultMavenFileFilter#filterFile}}: > {code:java} > private void filterFile(@Nonnull File from, @Nonnull File to, @Nullable > String encoding, @Nullable List wrappers) throws IOException, > MavenFilteringException { > if(wrappers != null && wrappers.size() > 0) { > Reader fileReader = null; > Writer fileWriter = null; > try { > fileReader = this.getFileReader(encoding, from); > fileWriter = this.getFileWriter(encoding, to); // Here > temporary buffer should be used to avoid accidental file overwrite > Reader src = this.readerFilter.filter(fileReader, true, > wrappers); > IOUtil.copy(src, fileWriter); > } finally { > IOUtil.close(fileReader); > IOUtil.close(fileWriter); > } > } else if(to.lastModified() < from.lastModified()) { > FileUtils.copyFile(from, to); > } > }{code} > The change would require to buffer the contents in memory, thus it might lead > to OutOfMemory errors. I suggest disabling this buffering if the size of the > source file exceeds some threshold. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCOMPILER-205) maven-compiler-plugin: incremental compilation broken
[ https://jira.codehaus.org/browse/MCOMPILER-205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=359081#comment-359081 ] Vladimir Sitnikov commented on MCOMPILER-205: - What if maven-compiler-plugin generates package-info.class files if the compilation was successful and package-info.class is missing for a particular package-info.java? > maven-compiler-plugin: incremental compilation broken > - > > Key: MCOMPILER-205 > URL: https://jira.codehaus.org/browse/MCOMPILER-205 > Project: Maven Compiler Plugin > Issue Type: Bug >Affects Versions: 3.1 >Reporter: Lukas Fryc > Attachments: hello.tgz, no-class-in-java-file.zip > > > When we do {{clean}} -> {{compile}} -> {{compile}}, all Java sources are > re-compiled for second compilation steps: > {code} > [framework]$ mvn clean > ... > [framework]$ mvn compile > ... > [INFO] --- maven-compiler-plugin:3.1:compile (precompile-sources-for-cdk) @ > richfaces-framework --- > [INFO] Changes detected - recompiling the module! > [INFO] Compiling 915 source files to > /mnt/workspace/workspaces/richfaces/richfaces5/framework/target/classes > ... > [framework]$ mvn compile > ... > [INFO] --- maven-compiler-plugin:3.1:compile (precompile-sources-for-cdk) @ > richfaces-framework --- > [INFO] Changes detected - recompiling the module! > [INFO] Compiling 915 source files to > /mnt/workspace/workspaces/richfaces/richfaces5/framework/target/classes > ... > {code} > The source code of the affected project: > https://github.com/richfaces/richfaces5/tree/077dcfc0a46d03d7ba9a7ac3e701a4adfb834c71 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MRESOURCES-168) Don't overwrite unchanged resource to prevent unnecessary subsequent processing
[ https://jira.codehaus.org/browse/MRESOURCES-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=359080#comment-359080 ] Vladimir Sitnikov commented on MRESOURCES-168: -- As far as I can understand, org.apache.maven.shared.filtering.DefaultMavenFileFilter#filterFile is responsible for this filtering. I've filed a bug for maven-filtering: MSHARED-394 > Don't overwrite unchanged resource to prevent unnecessary subsequent > processing > --- > > Key: MRESOURCES-168 > URL: https://jira.codehaus.org/browse/MRESOURCES-168 > Project: Maven Resources Plugin > Issue Type: Improvement > Components: filtering > Environment: MVN3.0.4 Win7 Pro SP1 64 Bit JDK 1.6.0_07 >Reporter: Markus KARG >Priority: Minor > > When filtering resources, the resulting files' last-modified date is updated. > This is correct, as the file just got produced. But, there might be lots of > files that passed the filter unchanged -- but now have changed last-modified > date, too. > This induces unneccesary subsequent processing and should be prevented. > Example: Filtering of Java sources, then compiling those. The Java compiler > typically will only compile modified files, but not thinks ALL files are > modified. > A solution could be to check whether at least one property was actually found > in the filtered file and to reset the last-modified date in all other cases. > Another solution could be to rename the previous output file and compare both > files after filtering. If they are identical, the new fill can be discarded > and the previous file can be renamed back. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSHARED-394) Avoid rewrite of destination in DefaultMavenFileFilter#filterFile when producing the same contents
Vladimir Sitnikov created MSHARED-394: - Summary: Avoid rewrite of destination in DefaultMavenFileFilter#filterFile when producing the same contents Key: MSHARED-394 URL: https://jira.codehaus.org/browse/MSHARED-394 Project: Maven Shared Components Issue Type: Improvement Components: maven-filtering Affects Versions: maven-filtering-1.2 Reporter: Vladimir Sitnikov See relevant MRESOURCES-168. When processing "filtered" resources, maven-filtering always overwrites destination files, leading to rebuild of the upstream results (e.g. jar file being repackaged due to "DEBUG] isUp2date: false (Resource with newer modification date found.)"). I think maven-filtering can do better job here: it can double-check if the resource contents after filtering is equal to the contents of the existing file, then it should avoid overwrite of the destination file. The change would be localized in {{org.apache.maven.shared.filtering.DefaultMavenFileFilter#filterFile}}: {code:java} private void filterFile(@Nonnull File from, @Nonnull File to, @Nullable String encoding, @Nullable List wrappers) throws IOException, MavenFilteringException { if(wrappers != null && wrappers.size() > 0) { Reader fileReader = null; Writer fileWriter = null; try { fileReader = this.getFileReader(encoding, from); fileWriter = this.getFileWriter(encoding, to); // Here temporary buffer should be used to avoid accidental file overwrite Reader src = this.readerFilter.filter(fileReader, true, wrappers); IOUtil.copy(src, fileWriter); } finally { IOUtil.close(fileReader); IOUtil.close(fileWriter); } } else if(to.lastModified() < from.lastModified()) { FileUtils.copyFile(from, to); } }{code} The change would require to buffer the contents in memory, thus it might lead to OutOfMemory errors. I suggest disabling this buffering if the size of the source file exceeds some threshold. -- This message was sent by Atlassian JIRA (v6.1.6#6162)