[
https://issues.apache.org/jira/browse/SUREFIRE-2210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17784965#comment-17784965
]
ASF GitHub Bot commented on SUREFIRE-2210:
------------------------------------------
dmlloyd opened a new pull request, #686:
URL: https://github.com/apache/maven-surefire/pull/686
Following this checklist to help us incorporate your
contribution quickly and easily:
- [X] Make sure there is a [JIRA
issue](https://issues.apache.org/jira/browse/SUREFIRE) filed
for the change (usually before you start working on it). Trivial
changes like typos do not
require a JIRA issue. Your pull request should address just this
issue, without
pulling in other changes.
- [X] Each commit in the pull request should have a meaningful subject line
and body.
- [X] Format the pull request title like `[SUREFIRE-XXX] - Fixes bug in
ApproximateQuantiles`,
where you replace `SUREFIRE-XXX` with the appropriate JIRA issue.
Best practice
is to use the JIRA issue title in the pull request title and in the
first line of the
commit message.
- [X] Write a pull request description that is detailed enough to
understand what the pull request does, how, and why.
- [X] Run `mvn clean install` to make sure basic checks pass. A more
thorough check will
be performed on your pull request automatically.
- [X] You have run the integration tests successfully (`mvn -Prun-its clean
install`).
If your pull request is about ~20 lines of code you don't need to sign an
[Individual Contributor License
Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure
please ask on the developers list.
To make clear that you license your contribution under
the [Apache License Version 2.0, January
2004](http://www.apache.org/licenses/LICENSE-2.0)
you have to acknowledge this by using the following check-box.
- [X] I hereby declare this contribution to be licenced under the [Apache
License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0)
--
The recent change (47eb1974ef2fb, since 3.2.0) to support more additional
class path items during test has broken the use case of testing multi-release
projects where ordering of class path elements is significant by changing the
additional class path items collection from a `List` to a `HashSet`, which has
unreliable ordering semantics. This simple fix preserves the original class
path order specified in the POM by using a `LinkedHashSet`, which preserves
insertion order, instead of a `HashSet`, which does not.
/cc @kwin
> Additional class path ordering broken since 3.2.0
> -------------------------------------------------
>
> Key: SUREFIRE-2210
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2210
> Project: Maven Surefire
> Issue Type: Bug
> Affects Versions: 3.2.1, 3.2.2
> Reporter: David M. Lloyd
> Priority: Critical
>
> Since commit
> [47eb1974ef2fb77c621e5cb0c47ac10ab8f4753d|https://github.com/apache/maven-surefire/commit/47eb1974ef2fb77c621e5cb0c47ac10ab8f4753d]
> ([#667|https://github.com/apache/maven-surefire/pull/667], SUREFIRE-2179),
> the ordering of the {{additionalClasspathElements}} list configuration
> property is no longer preserved. This breaks testing of multi-release JARs,
> where the directories for newer JDKs *must* be strictly ordered *before* the
> directories for older JDKs.
> The problem is likely due to changing the additional class paths collection
> from a `List` to a `Set`, which does not preserve ordering.
> One simple fix could be to change the line {{Set<String>
> additionalClasspathElements = new HashSet<>();}} to construct a
> {{LinkedHashSet}} instead.
> /cc [~kwin] who wrote the original patch back in June.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
