Github user aqueance commented on the pull request:
https://github.com/apache/maven/pull/69#issuecomment-216595519
In addition to the problems mentioned above, that
[hack](https://github.com/apache/maven/blame/3533599e42a4a563abca33a69ed0f34c19815479/maven-aether-provider/src/main/java/org/apache/maven/repository/internal/DefaultArtifactDescriptorReader.java#L287)
also breaks the 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
(this is why splitting the build into multiple phases works around the problems
caused by this bug),
* what other `RepositorySystemSession` instances have been used to parse
and cache POMs so far,
* what command line arguments were used to invoke Maven.
I have a Maven plugin that computes transitive dependencies of the host
project by cloning the `RepositorySystemSession` used by the reactor to set
properties that activate 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 along. Now because of
that bug, the functionality stopped working reliably.
Speed is important, sure, but correct functionality is probably even more
so. So please remove that hack, and if its function is indeed necessary, then
it needs to be replaced with a proper cache, one that takes the active
`RepositorySystemSession` into account.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]