an 'id' to use MavenProject instead.
In some parts of the code a DAG is constructed using a version-less key,
and in the api what the id should be is unspecified.
This could result in NPE's (it does!) because the code in plexus-utils
assumes a known id (vertex in the DAG) is supplied.
So, moved the project.getId() calls outside of ReactorManager into the
ReactorManager, so that there's just one place where the decision is made on
how to generate an id (DAG vertex label) from a project. This centralizes
that knowledge for increased maintainability and reduced chances on NPE's.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@279334 13f79535-47bb-0310-9956-ffa450edef68
Note: I'm not sure wheter my tmpDir approach is the best.
It's certain to work all the time (depending on FileUtils.createTempFile),
but it may leave a lot of 'garbage' in target/.
o Updated maven-core's assembly descriptor to make use
of new line endings functionality.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@267344 13f79535-47bb-0310-9956-ffa450edef68
make repository metadata behave more like snapshots with daily updates.
next step is to move the version checking to use that instead and fallback to the old files
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@266298 13f79535-47bb-0310-9956-ffa450edef68
o Artifact attachment via MavenProjectHelper was using string literals of the variables I was trying to use to fill in type and classifier (dumb, I know!)
o Source plugin didn't have an @phase for the JarSourceMojo...added, then added the goal configuration in the release profile in the super-pom
o Removed the source plugin bindings for the lifecycle mappings in maven-core
o Re-added [deprecated] method MavenProjectBuilder.build( File, ArtifactRepository, List )...you should use MavenProjectBuilder.build( File, ArtifactRepository, ProfileManager ) instead.
o Added profile handling/injection for the super-pom in two places: in buildStandaloneSuperPom() and in private build(..). This enables injection of the release profile which is provided in the super-pom.
o Added integration test to verify that using -DperformRelease=true results in the sources being attached...to override this behavior, another profile keyed on -DperformRelease could turn the 'attach' param for the source plugin off.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@233245 13f79535-47bb-0310-9956-ffa450edef68
o Added @requiresDirectInvocation (was: @cliOnly, but this implies m2 is run from CLI...counter-intuitive for embedding)
o Added handling for new @requiresDirectInvocation (generation/parsing, MojoDescriptor support, etc.)
o Added check in DefaultLifecycleExecutor to throw a LifecycleExecutionException if a mojo specified in a lifecycle binding is marked as direct-invocation only.
o Added MavenProjectHelper/DefaultMavenProjectHelper to provide convenience methods for manipulating MavenProject instances (for example, attaching artifacts or adding resources)
o Removed maven-artifact dependency from maven-source-plugin, and added dependency on maven-plugin-api (should've been there)
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@233021 13f79535-47bb-0310-9956-ffa450edef68
Fixing profile application to separate profiles discovered in and around POM from those in settings.xml, and apply them separately in the order:
for-each-project-in-inheritance:{POM, profiles.xml}, settings.xml
Added common interface for accumulating, explicitly activating and deactivating, and retrieving profiles to be applied to a given project. This manager interface (ProfileManager) is general enough to be applicable to both the project-level and settings-level profiles.
Added 'performRelease'-keyed profile to super-POM which will be used by the release plugin and anyone using a parallel process, and which will enable '-DupdateReleaseInfo=true' for the deploy mojo, along with enabling the source attachment for the project.
Added 'attach' parameter to JarSourceMojo to allow local POM to turn off source attachments, overriding release profile in super-pom.
Updated the release:perform mojo to use '-DperformRelease=true' for switching on the new release profile, rather than just using '-DupdateReleaseInfo=true'...
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@233013 13f79535-47bb-0310-9956-ffa450edef68
Fixed a merge problem where only direct children of <configuration> in the POM
appeared in the merged configuration.
(like maven-antrun-plugin, the 'tasks' configuration tag didn't have any
value, but has children. After the merge, the children were gone,
and it was marked as having no value, and hence the field was not updated.)
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@232281 13f79535-47bb-0310-9956-ffa450edef68
PluginParameterExpressionEvaluator now has two static final Maps - BANNED_EXPRESSIONS and DEPRECATED_EXPRESSIONS, each of which contain mappings of restricted expressions to the preferred alternative.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@232200 13f79535-47bb-0310-9956-ffa450edef68
sees the plugin and marks it as 'installed' (it's in a hashtable somewhere).
The official way is to go through verifyPlugin. That gets called later on
for that plugin, which only calls addPlugin (that registers, resolves,
and, most importantly, creates a childContainer for that plugin!) IF
the plugin is NOT yet registered.
Since it is registered in the hashtable, but no childRealm was made there,
addPlugin doesn't get called. Added a simple check to ALSO call 'addPlugin'
if it was added to the hashtable. Side effect is that the version that
was normally going to be used is now used and overrides the other version.
This really needs a cleanup!
Committing anyway:
01:26<trygvis> right now I think we're allowed to push over old ladies and
steal candy from small children to get this to work
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@231353 13f79535-47bb-0310-9956-ffa450edef68
o Added --fail-fast --fail-at-end --fail-never CLI options, with appropriate summary and exclusion of dependent projects from the build when --fail-at-end is specified. Also, implemented it0046 and it1011 to test it.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@227490 13f79535-47bb-0310-9956-ffa450edef68
o Moved extension-artifact creation and caching to MavenProject, initialized by MavenProjectBuilder, just like plugin-artifacts is.
o Added extension-artifact and report-artifact creation (and initialization in MavenProject) to MavenProjectBuilder, for consistency with plugin-artifacts
o Removed dependency on ArtifactFactory in DefaultExtensionManager (extension artifacts are reachable from MavenProject now)
This makes the process of resolving all artifacts referenced by a project much simpler and more consistent (namely, for the release plugin)
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@227147 13f79535-47bb-0310-9956-ffa450edef68
Brett Leslie Porter
Kenney Westerhof
John Dennis Casey
Trygve Laugstol
Vincent Massol
Emmanuel Venisse