Consolidated plugin realm setup logic in DefaultMavenPluginManager.
Extensions realm is fully setup during project loading and the same
realm is used to both load extensions and execute plugin goals now.
Signed-off-by: Igor Fedorenko <ifedorenko@apache.org>
DefaultJavaToolChain was the only way to access JDK toolchain
javaHome parameter and was used by some clients, notably Tycho.
The class is now marked as deprecated and clients are adviced to
use JavaToolchainImpl instead.
Signed-off-by: Igor Fedorenko <ifedorenko@apache.org>
this hides use of deprecated/legacy ArtifactFactory and allows custom
project dependency artifact creation logic.
Signed-off-by: Igor Fedorenko <ifedorenko@apache.org>
MojoExecution scope was only available for maven plugins and could not
be used for components defined in maven core or maven code extensions.
Session scope was only available for maven core and core extensions
but did not work for components from maven plugins.
Made both custom scopes available available in all realms.
Signed-off-by: Igor Fedorenko <ifedorenko@apache.org>
Fixed JDK8 IT failure for MavenITmng3004ReactorFailureBehaviorMultithreadedTest#testitFailFastSingleThread
It turns out the execution order of the modules in the build can be incorrect, in some cases severely incorrect.
For parallel builds this can have all sorts of interesting side effects such as classpath
appearing to be intermittently incorrect, missing jars/resources and similar.
The -am options and -amd options may simply fail with the incorrect build order
because expected dependencies have not been built and actual dependencies may not have been built.
The underlying problem was that ProjectDependencyGraph#getDownstreamProjects and getUpstreamProjects
did not actually obey the reactor build order as defined by ProjectDependencyGraph#getSortedProjects,
even though the javadoc claims they should.
This has only worked by accident on earlier JDK's and might not have worked at all (basically
depends on Set iteration order being equal to insertion order). JDK8 has slightly different
iteration order, which caused the IT failure.
This problem may be the root cause of MNG-4996 and any other issue where the modules build
in incorrect order.
The bug affects:
parallel builds
command line -am (--also-make) option
command line -amd (also-make-dependents) option
On all java versions, although visibility might be somewhat different on different jdks.
Added simple unit test that catches the problem.
The cuplrit was the resetRepositories method in tandem with the repository
list instances being shared between ModelResolvers.
- The copy constructor for the ModelResolvers now creates new lists.
- The resetRepositories method has been removed. Instead there is a
'replace' parameter on the addRepository method that allows the
desired parameter replacement of MNG-5639 to take place.
Signed-off-by: Jason van Zyl <jason@tesla.io>
Igor Fedorenko
Robert Scholte
Jason van Zyl
Hervé Boutemy
Michael Osipov
Kristian Rosenvold
brianf
Igor Fedorenko
markdingram