Recent changes in ProjectBuilder make that the compile roots could be
set erroneously on 1st phase and propagated in the results.
This patch just skips setting the compile source root in the 1st pass
(when buildParentIfNonExisting==false).
It also tests some other fields of MavenProject
Reviewers: Michael Osipov, Robert Scholte, Hervé Boutemy
This closes#274
Otherwise the sessionFinished event may be sent before some
projects/goals finish, which violates the contracts of execution
listeners and makes it hard to properly life cycle components that
are needed for goal execution.
This closes#272
This map is not used by Maven and the computation can be quite heavy, so lazily
compute it. In addition, do not clone the map as it's an unmodifiable one already.
This closes#263
If a dependency on another project is found, don't parse its
POM again, but instead use the model we already have in memory.
This saves a large amount of time and memory for builds that have
lots of subprojects and dependencies between them.
The approach was directly copied from DefaultArtifactDescriptorReader,
which does the same optimization.
This closes#244
ExcludesArtifactFilter was highly inefficient.
It took the group and artifact ID of an Exclusion, concatenated them into
a new String, which was kept in memory for the whole duration
of the build and then compared that String against the concatenation
of group and artifact ID of each incoming artifact, adding more
CPU cycles than necessary.
Instead we now just wrap the existing Exclusion object and check its
groupId and artifactId against the artifact to tell whether it should
be excluded.
The old class is kept around for binary compatibility, but is now unused.
Closes#243
* [MNG-6405] Fix basedir in MavenProject.deepCopy.
* Reproduced bug in test.
Failure without patch:
junit.framework.AssertionFailedError: Base directory is preserved across clone expected:<…/maven-core/target/test-classes> but was:<…/maven-core/target/test-classes/target>
at org.apache.maven.project.MavenProjectTest.testCloneWithBaseDir(MavenProjectTest.java:188)
* Code style. Not enforced in tests during build?
Initialize the interim project with "simple" items (ie do not build
not reference parent if it's not yet in the projectIndex) and returns
it when installation fails further.
This give a partial validation of the file, pretty convenient in IDEs.
The global model cache introduced in MNG-6311 causes severe regressions
in case of POM files changing during application lifetime.
This patch adds a system property
`defaultProjectBuilder.disableGlobalModelCache` that disables this global
model cache when set to true, ensure pom modifications are honored.
This closes#194
File#toURI()#toString() produces a non-compliant URI making tools like
Subversion or Git to choke on those URIs. Whereas Path#toUri()#toASCIIString()
does the right job.
Adding exportedPackage to find class:
javax.annotation.security.RolesAllowed
First maven commit :) Works but might be deeper issue
Signed-off-by: Karl Heinz Marbaise <khmarbaise@apache.org>
Now with correct issue reference.
Adding exportedPackage to find class:
javax.annotation.security.RolesAllowed
First maven commit :) Works but might be deeper issue
Signed-off-by: Karl Heinz Marbaise <khmarbaise@apache.org>
- The tests assume that the JRE has a ScriptEngineFactory
- Not all JREs have a ScriptEngineFactory (I'm looking at Azul's Zulu Open JDK 7 builds)
- Ideally we'd skip these tests using Assume.assumeThat(...) but PlexusTestCase doesn't support
AssumptionViolatedException for marking tests as skipped.
Issue identified during testing of the 3.5.1 release candidate
Maven Core needs to export the maven-aether-provider artifact so that its components do not get added twice in plugin realm. This happens if the build uses an extension plugin depending on maven-aether-provider, before it was renamed to maven-resolver-provider
Updated to correctly map the optional flag of Maven model dependencies to
Aether dependencies. Prior to this change all managed dependencies implicitly
had the optional flag set to 'false' leading to Aether managing that flag to
'false' on all managed dependencies when transitive.
This reverts commit 13adc1bc2b *not changing
anything* just because someone did not react in time when this issue had been
lying around on a branch. If we would set pace for the industrie, everyone would
still be using 5.25" floppy disks and 8 bit hardware and we would tell them
that upgrading to be able to use new software would be too risky and they
better keep theire broken assembly routines until the machine goes up in
smoke.
This commit removes the initialization of the MavenSession object from the
DefaultGraphBuilder. The GraphBuilder implementation should only build the
graph and should not touch the MavenSession object passed into it.
To allow complete initialization of the MavenSession the ProjectDependencyGraph
interface got enhanced so that GraphBuilder implementations can communicate all
collected projects in addition to the processed list of projects.
This closes#105
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
Joseph Walton
Karl Heinz Marbaise
rfscholte
Hervé Boutemy
Michael Osipov
thelproad
Lipmanpoi
Sylwester Lachiewicz
Rostislav Krasny
Artem Krosheninnikov
Christian Wansart
Stig Rohde Døssing
Dezhi Cai
Enrico Olivelli
Mickael Istria
Ray Tsang
tibordigana
Stefan Oehme
Guillaume Nodet
Bo Zhang
Christian Schulte
MartinKanters
Stephen Connolly
Sergey Chernov
Jesse Glick
Romain Manni-Bucau
Josh Soref
Duarte Meneses
HoaPhan
Christian Schulte
Sylwester Lachiewicz
Phillip Webb
Stephen Connolly
Łukasz Dywicki
Bengt Söderberg
Mario Krizmanic
Guillaume Boué
Dan Tran
Anton Tanasenko
Igor Fedorenko
Christoph Böhme
Alex Henrie
Archimedes Trajano
Josh Soref
Harald Wellmann
Stuart McCulloch
Jason van Zyl
Robert Scholte
Arnaud Héritier
Kristian Rosenvold
sugartxy
Florencia Tarditti