[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=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=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17748173
or
https://issues.apache.org/jira/browse/MNG-7852?focusedCommentId=17748217=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=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 protobuf-java. Maven's "the first
[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=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=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, sigstore-java depends on
[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=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=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=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 using Guice, so
[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=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 stop using Guice,
[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=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=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
[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=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=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=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, the `myfaces-api`
[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=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 [~hboutemy] analysis
>
[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=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=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=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
[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
[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]
[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:
[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=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 speaking,
[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.
> The
[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=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=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=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=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=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=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=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=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=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=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=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=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=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=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=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=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=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=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: WAITING (parking)
[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=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] (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-tabpanelfocusedCommentId=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 ListFilterWrapper 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-tabpanelfocusedCommentId=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 ListFilterWrapper 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] (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-tabpanelfocusedCommentId=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 ListFilterWrapper 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-tabpanelfocusedCommentId=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 ListFilterWrapper 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-tabpanelfocusedCommentId=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 ListFilterWrapper 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
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 ListFilterWrapper 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] (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-tabpanelfocusedCommentId=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] (MCOMPILER-205) maven-compiler-plugin: incremental compilation broken
[
https://jira.codehaus.org/browse/MCOMPILER-205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] (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-tabpanelfocusedCommentId=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} parent
groupIdorg.apache/groupId
artifactIdapache/artifactId
version14/version
/parent{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 ListFilterWrapper 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-tabpanelfocusedCommentId=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} parent
groupIdorg.apache/groupId
artifactIdapache/artifactId
version14/version
/parent{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} parent
groupIdorg.apache/groupId
artifactIdapache/artifactId
version14/version
/parent{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
