Even test is skipped by `@Disabled` annotation
newer surefire schedule it for execution.
When tests are missing in TestSuiteOrdering
are executed as one of first tests in unpredictable order.
* [MNG-7737] IT for profiles
Just a simple IT that would catch issues like Maven 3.9.0
went out with, where files were wrongly interpolated: MNG-7726
---
https://issues.apache.org/jira/browse/MNG-7737
The original fix MNG-7672 matched the "scope" but missed the "order". `project.collectedProjects` are in order as loaded (POM order), is not topologically sorted.
Fix is to use DAG of projects, ask for downstream projects (will return more then we need but sorted) and narrow that list to only contain collected projects.
---
https://issues.apache.org/jira/browse/MNG-7720
If ConcurrencyDependencyGraph#getRootSchedulableBuilds returns an empty
list then MultiThreadedBuilder is locked forever as it never gets a
build result (because nothing is scheduled).
This changes the method, that in such case just the first project is
returned, this might not give the best performance, but ensures that
there is at least one build scheduled and the build-loop can proceed.
This closes#1029
Related IT change, as the change for this issue made MNG-7128 IT
to fail, as it was too eagerly match whole error message string
that has now due MNG-5181 changed.
To fix it, match only the key parts of the expected error message,
that project failed, due transfer failure, as insecure mirror
was blocked. This makes IT assert same thing, but is more
flexible regarding error text change in MNG-5181.
---
https://issues.apache.org/jira/browse/MNG-5185
As with previous PR (simple removal) the `-llr` got
interpreted as `-l lr`, it logged all output to `lr`
file. This would maean that use of `-llr` would still
sneakily 'work' and probably cause surprise down the
road to users.
Returned the option, and expicitly checking for it's
presence to be able to fail with meaningful message.
---
https://issues.apache.org/jira/browse/MNG-7713
There is really no need for it, and there is a resolver option if really must (but really should not, local repo is and should be considered as transient).
---
https://issues.apache.org/jira/browse/MNG-7713
The MNG-7706 deprecates ancient ArtifactRepository type use to get access to local repository, and issues warning as for any other deprecated Mojo parameters.
But alas, in ITs the MNG-5576 completely unrelated IT there is an assertion to have WARNING-free log. This IT uses the IT-plugins/IT-plugin-expression EvalMojo, that in turn uses the deprecated `${localRepository}` parameter (but does not use it). Result is, Maven 3.9.1 emits a WARNING about use of deprecated parameter and the IT fails.
Further inspection shows, that while EvalMojo injects ArtifactRepository for local repository, there is only one IT that actually uses it, the MNG-4305, but even that one is interested in basedir of the local repository only. So to say, the use of deprecated ArtifactRepository type is not needed at all.
Fix:
* change EvalMojo to not expose in context the localRepository (w/ type ArtifactRepository), but a new expression `localRepositoryBasedir` only, that is injected in non-deprecated way (in real life repoSysSession would be injected, but in IT we keep all super-safe and use Object types).
* adjusted MNG-4305 to use new epxression instead to use object reflection in template to get basedir from ArtifactRepository
* This makes the originally failing MNG-5576 pass, as warning due EvalMojo is gone.
See
https://issues.apache.org/jira/browse/MNG-7706https://github.com/apache/maven/pull/1009
Guillaume Nodet
Michael Osipov
Slawomir Jaranowski
Petr Široký
Tamas Cservenak
Elliotte Rusty Harold
Hervé Boutemy
Andrey Bruykhov
Elliotte Rusty Harold
Christoph Läubrich
Alexey Venderov