maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tibor Adam Varga (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (MNG-5899) Reactor is no longer using the dependency reduced pom created by maven-shade-plugin
Date Mon, 25 Apr 2016 18:56:13 GMT

    [ https://issues.apache.org/jira/browse/MNG-5899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15256780#comment-15256780
] 

Tibor Adam Varga edited comment on MNG-5899 at 4/25/16 6:55 PM:
----------------------------------------------------------------

In addition to the problems mentioned above caused by that [hack|https://github.com/apache/maven/blame/3533599e42a4a563abca33a69ed0f34c19815479/maven-aether-provider/src/main/java/org/apache/maven/repository/internal/DefaultArtifactDescriptorReader.java#L287],
it also breaks transitive dependency collection functionality in general, because it employs
a [Reactor-wide|https://github.com/apache/maven/blame/3533599e42a4a563abca33a69ed0f34c19815479/maven-core/src/main/java/org/apache/maven/ReactorReader.java#L69]
[cache|https://github.com/apache/maven/blame/3533599e42a4a563abca33a69ed0f34c19815479/maven-core/src/main/java/org/apache/maven/ReactorReader.java#L145]
of parsed POMs that fails to take into account the `RepositorySystemSession` contexts in which
the cached POMs were parsed.

A cache with a broken key scheme is not a cache, it's a source of unexpected behavior: if
any {{RepositorySystemSession}} is at play other than the one used by the Reactor, collecting
transitive dependencies now results in a dependency tree that is *practically random*, as
it depends on:

  * what POMs have already been parsed by the Reactor during the build,
  * what other {{RepositorySystemSession}} instances have been used to parse and cache POMs
so far, and
  * what command line arguments were used to invoke Maven.

I have a Maven plugin that needs to compute transitive dependencies of the host project by
cloning the {{RepositorySystemSession}} used by the reactor to set / unset properties that
activate / deactivate build profiles, which in turn contain dependencies to be taken into
account when computing a custom dependency tree.

The API to do so is [public|http://wiki.eclipse.org/Aether] so one expects the functionality
work, which it did until Maven 3.3 came out. Now because of that hack, it stopped working
reliably.

Speed is important, sure, but correct functionality is probably even more so. Please remove
that hack.


was (Author: vta):
In addition to the problems mentioned above caused by that [hack|https://github.com/apache/maven/blame/3533599e42a4a563abca33a69ed0f34c19815479/maven-aether-provider/src/main/java/org/apache/maven/repository/internal/DefaultArtifactDescriptorReader.java#L287],
it breaks transitive dependency collection functionality in general, because it employs a
[Reactor-wide|https://github.com/apache/maven/blame/3533599e42a4a563abca33a69ed0f34c19815479/maven-core/src/main/java/org/apache/maven/ReactorReader.java#L69]
[cache|https://github.com/apache/maven/blame/3533599e42a4a563abca33a69ed0f34c19815479/maven-core/src/main/java/org/apache/maven/ReactorReader.java#L145]
of parsed POMs that fails to take into account the `RepositorySystemSession` contexts in which
the cached POMs were parsed.

A cache with a broken key scheme is not a cache, it's a source of unexpected behavior: if
any {{RepositorySystemSession}} is at play other than the one used by the Reactor, collecting
transitive dependencies now results in a dependency tree that is *practically random*, as
it depends on:

  * what POMs have already been parsed by the Reactor during the build,
  * what other {{RepositorySystemSession}} instances have been used to parse and cache POMs
so far, and
  * what command line arguments were used to invoke Maven.

I have a Maven plugin that needs to compute transitive dependencies of the host project by
cloning the {{RepositorySystemSession}} used by the reactor to set / unset properties that
activate / deactivate build profiles, which in turn contain dependencies to be taken into
account when computing a custom dependency tree.

The API to do so is [public|http://wiki.eclipse.org/Aether] so one expects the functionality
work, which it did until Maven 3.3 came out. Now because of that hack, it stopped working
reliably.

Speed is important, sure, but correct functionality is probably even more so. Please remove
that hack.

> Reactor is no longer using the dependency reduced pom created by maven-shade-plugin
> -----------------------------------------------------------------------------------
>
>                 Key: MNG-5899
>                 URL: https://issues.apache.org/jira/browse/MNG-5899
>             Project: Maven
>          Issue Type: Bug
>    Affects Versions: 3.3.1, 3.3.3
>            Reporter: Trask Stalnaker
>
> This works with maven 3.2.5 and prior, but does not work with the latest releases (3.3.1
and 3.3.3), or master (tested against 3.3.7-SNAPSHOT).
> I did some bisecting and found the commit that caused the breakage:
> https://github.com/apache/maven/commit/be3fb200326208ca4b8c41ebf16d5ae6b8049792
> In particular, this commit introduced some code to not rebuild the model if it was already
loaded during reactor resolution.
> This is causing maven not to use the dependency reduced pom created by the maven-shade-plugin.
> Removing this code fixes the situation.  I'm hoping that code was just introduced as
a performance optimization, and that I haven't broken anything functionally by removing it
(the tests still pass at least).
> I will submit a pull request with the change for review.
> Here is the original maven-shade-plugin issue as reported by the Apache Storm team: https://issues.apache.org/jira/browse/MSHADE-206



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message