o Updated to fix parent version range resolution broken since 3.2.3 and to
remove parent version range resolution logic obsolete since Maven
3.2.3 which changed the initialization of MavenProject instances.
o Updated local parent resolution to behave the same way remote parent
resolution behaves. When referencing a parent using version ranges,
inheriting the version or using version expressions should not be supported.
It has been implemented that way for remote parent resolution as it got
introduced in Maven 3.2.2. For local parent resolution the version in parent
declarations had been ignored completely as of Maven 3.3.0 due to commit
be3fb20032 removing all local parent version
validation. Work on fixing this is tracked by MNG-5840 released with Maven
3.3.9. This commit adds the final missing bits to make local and remote parent
resolution behave the same way as much as possible. As an exception, remote
parent resolution still is a bit more strict than local parent resolution due
to a different API in use. When resolving a parent from a repository using
version ranges, the ModelBuilder verifies the range in use to declare an upper
bound. When resolving a parent locally using version ranges, those ranges are
not required to declare an upper bound because the API in use does not support
querying that. Authoring a POM relying on this difference should be considered
a bug.
o Added test cases to maven-core testing parent version range resolution for
local and remote parent models.
o Followup to MNG-5894 of Maven 3.3.9 where the maven-ejb3-plugin
has been removed from life cycle.
o Removed the ArtifactHandler for ejb3 cause without
a bound life cycle it does not make sense.
o Removed entry from artifact-handlers.apt site.
Refactoring the current code setting system properties to synchronize correctly on the given ones: avoids ConcurrentModificationException and NullPointerException if the properties is modified by another thread.
While MNG-5805 restored binary compatibility of Lifecycle.getPhases
it didn't do the same for Lifecycle.setPhases. This breaks plugins
like flexmojos-maven-plugin which have their own lifecycle mapping
implementations.
This closes#77
Set maven.conf to default ${maven.home}/conf in ${maven.home}/bin/m2.conf
to have a canonical property pointing to global configuration files from
within Java code.
This also helps package maintainers to decouple the Maven installation
from a global configuration by solely modifying m2.conf instead of using
dirty hacks, if possible at all.
MultiThreadedBuilder must set parallel to true when it's using more than
1 thread to build: i.e. a degree of concurrency greater than 1 (-T) and
more than 1 project to build. Since each ProjectSegment works on a
cloned session instance (see
BuildListCalculator#calculateProjectBuilds), the flag must be also set
on each cloned session.
It broke various plugins with missing classes ( org.slf4j.helpers.MarkerIgnoringBase, org.slf4j.helpers.MessageFormatter ) like:
* net.java.truelicense:truelicense-maven-plugin (2.3.4)
* com.github.eirslett:frontend-maven-plugin (0.0.20, 0.0.22)
* maven-antrun-plugin with the cobertura ant task
* org.mortbay.jetty:jetty-maven-plugin (7.6.16.v20140903)
The first step here is deprecating the publicly accessible method that allows
plugins to inject dependencies. The only plugin I currently know of that does
this is the cobertura-maven-plugin. Looking at that plugin it appears the user
can specify the cobertura dependency for the instrumentation process but if
they do not the plugin attempts to inject the dependency. I believe the path
forward here is making sure these types of plugins instruct their users to
add the dependency explicitly.
I'm going to try and create a call-graph for all of Maven Central with my
first test to see if I can accurately detect all usages of MavenProject.setDependencyArtifacts
of artifact in Maven Central.
Some plugins, e.g., cobertura-maven-plugin, use ${plugin.artifacts}
to setup classpath of externally launched jvms and they expect slf4j
to be available among plugin dependencies. At the same time slf4j
is already part of maven core runtime and it needs to be filtered
out from plugin and build extension realms to avoid duplicate classes
on classpath.
The fix is to move core artifact filtering from plugin dependency
resolver to class realm manager. This way ${plugin.artifacts} still
includes all compile/runtime scoped plugin dependencies but runtime
classpath only has plugin unique artifacts.
Signed-off-by: Igor Fedorenko <ifedorenko@apache.org>
read ${maven.projectBasedir}/.mvn/extensions.xml and create core
extensions realms during maven runtime bootstrap. this required
short-lived bootstrap plexus container to resolve extensions.
individual extensions realms are wired to maven.ext realm according
to META-INF/maven/extension.xml exported packages specification
Signed-off-by: Igor Fedorenko <ifedorenko@apache.org>
javax.inject.* and org.slf4j.* packages were already exported, but
corresponding artifacts were not. this resulted in same classes
present in multiple classlaoders and caused hard-to-troubleshoot
build failures in some cases.
Signed-off-by: Igor Fedorenko <ifedorenko@apache.org>
I will try and collect all deprecated code at the bottom of classes with Munge markers and
use this in conjunction with a definitive list of classes to be purged in order to use
one code line to safely experiment with Maven 4.x.
Push MavenExecutionRequestPopulator down to only operate in the MavenCli. Two of the three methods were already called from MavenCli so now all of them are. In the process I deleted a bunch of code and pursue my quest to remove Settings from the core in order to make a general configuration mechanism that can be plugged into the core via the MavenCli.
Also removed the requirement of the LegacyRepositorySystem in the DefaultMavenExecutionRequestPopulator which breaks another tie with the legacy code. I took the bits that were needed and a lot of the code, after tracing through it, is redundant so it has been deleted.
Turning off:
injectMirror( request, request.getRemoteRepositories(), request.getMirrors() );
injectMirror( request, request.getPluginArtifactRepositories(), request.getMirrors() );
in DefaultMavenExecutionRequestPopulator
Results :
Failed tests:
MavenITmng4190MirrorRepoMergingTest>AbstractMavenIntegrationTestCase.runTest:220->testit:76 null expected:<[1]> but was:<[4]>
Tests in error:
MavenITmng4991NonProxyHostsTest>AbstractMavenIntegrationTestCase.runTest:220->testit:89 » Verification
MavenITmng4963ParentResolutionFromMirrorTest>AbstractMavenIntegrationTestCase.runTest:220->testit:58 » Verification
There is mirror evaluation code in DefaultMaven:newRepositorySession( MavenExecutionRequest request ) which appears to
duplicate this logic but not quite enough for the ITs to pass.
---
Turning off:
injectProxy( request.getRemoteRepositories(), request.getProxies() );
injectProxy( request.getPluginArtifactRepositories(), request.getProxies() );
in
DefaultMavenExecutionRequestPopulator
Result:
The ITs pass
So the code is not needed so it has been deleted.
---
Turning off:
injectProxy( request.getRemoteRepositories(), request.getProxies() );
injectProxy( request.getPluginArtifactRepositories(), request.getProxies() );
injectAuthentication( request.getRemoteRepositories(), request.getServers() );
injectAuthentication( request.getPluginArtifactRepositories(), request.getServers() );
in
DefaultMavenExecutionRequestPopulator
Result:
The ITs pass
The code in DefaultMaven:newRepositorySession( MavenExecutionRequest request ) appears to populate proxies and authentication correctly. The injectAuthentication code has been deleted.
---
This is also perfunctory in DefaultMavenExecutionRequestPopulator after tracing through it:
request.setRemoteRepositories( getEffectiveRepositories( request, request.getRemoteRepositories() ) );
request.setPluginArtifactRepositories( getEffectiveRepositories( request, request.getPluginArtifactRepositories() ) );
MavenExecutionRequest has been extended with toolchains, which is filled by MavenCli
Interfaces have been extended with new methods, assuming only Maven provides implementations
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>
When maven is invoked from m2e, container.lookup(WorkspaceReader.class)
returns component with role-hint=ide, which I believe is a bug in Susi
or Guice (or at least well misunderstood feature). This masks
ReactorReader workspace reader implementation and breaks reactor
dependency resolution.
The solution is to use explicit "reactor" role hint for ReactorReader.
This avoids fuzzy default component lookup logic and guarantees reactor
reader is always used regardless of presence of other workspace readers.
Signed-off-by: Igor Fedorenko <ifedorenko@apache.org>
Alex Henrie
Christian Schulte
Archimedes Trajano
Josh Soref
Harald Wellmann
Karl Heinz Marbaise
Guillaume Boué
Stuart McCulloch
Hervé Boutemy
Michael Osipov
Stephen Connolly
Jason van Zyl
Robert Scholte
Arnaud Héritier
Anton Tanasenko
Kristian Rosenvold
sugartxy
Florencia Tarditti
Igor Fedorenko
Tibor17
brianf
Igor Fedorenko
markdingram
Christian Schulte
Mark Ingram
Tamas Cservenak
Pavel Sorokin