o If the metadata version is still in the plugin artifact after it's resolved, then simply return null and allow the plugin version resolution process to fail.
o Added a new mojo to update the plugin registry (if it's enabled) with newly installed versions of plugins.
o Added comments to maven-settings and maven-plugin-parameter-documenter poms marking the packageWithVersion config as deprecated pending modello alpha-5
o Cleaned up it0013 and it0020 to work with the new resolution (point one above).
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@293520 13f79535-47bb-0310-9956-ffa450edef68
attempt to move toward true embeddability.
- System properties are still populated in the CLI to make sure that the
system property profile activator functions and the settings are dealt with
correctly. I will look at each of those shortly but this is a first step.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@293504 13f79535-47bb-0310-9956-ffa450edef68
o Added pluginManagement injection to MavenProject.addPlugin(..) so that no Plugin definition added to the project can go without having managed info injected into it.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@293454 13f79535-47bb-0310-9956-ffa450edef68
o aggregating goal that forks a lifecycle should run reactor over projects
o don't show reactor summary if an aggregation goal was run that didn't fork a lifecycle.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@293235 13f79535-47bb-0310-9956-ffa450edef68
o Improved the error diagnostics related to artifact resolution errors.
o Added xml-based documentation of supported plugin parameter expressions, including info about how to affect them ('-o' for example), how to specify them (<distributionManagement><repository/> for example in ${project.distributionManagementArtifactRepository}), and what the expressions are actually used for. This can also serve as a basis for creating documentation for plugin parameter expressions on the website.
o Improved the error diagnostics for plugin configuration errors.
o Added a couple of ITs in the 1000 series to test these two error conditions.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@292750 13f79535-47bb-0310-9956-ffa450edef68
o Extracting basedir from the project instance when PluginParameterExpressionEvaluator is init'ed if project != null...otherwise, using ${user.dir} from sysprops.
o Extracting values for resolution from POM properties before POM instance during POM interpolation, and adding checks to guard against self-reference of POM elements.
o Added three ITs (one contra) to test these resolutions.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@291735 13f79535-47bb-0310-9956-ffa450edef68
as a parameter. this method is currently being used in the embedder
o see MNG-1015 for notes on where the monitor may be bested placed. if
everything eventually uses the embedder then it won't matter so much.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@291499 13f79535-47bb-0310-9956-ffa450edef68
o We should have a viable offline mode now. Plugin sensitivity updates to follow.
o See it0069 and it1014 for offline mode tests.
o Brett, building maven-plugins in offline mode with org/apache/maven/plugin/* removed will now give a nice error message. :)
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@291124 13f79535-47bb-0310-9956-ffa450edef68
o Fixed DefaultMaven to use the release-pom.xml for MavenProjects loaded via <modules/> if the parent project is loaded from release-pom.xml
o Adjusted tests to have dependencyManagement.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@290539 13f79535-47bb-0310-9956-ffa450edef68
currently executing plugin, so that both getClass().getClassLoader()
and Thread.currentThread().getContextClassLoader() return the same
classloader (and hence resources).
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@290040 13f79535-47bb-0310-9956-ffa450edef68
o Added it0068 to guard against regressions of the type causing MNG-836
o Added it2001, which must be run manually, to verify the test case laid out in MNG-757
o Reinstated the repository accumulation for successive traversal down the transitivity chain, so that transitively resolved artifacts can be found in repositories declared by POMs up the chain.
o Added a check for 'file:' at the beginning of the Settings.getLocalRepository() result, before prepending 'file://' to allow for relative definition of the local repository in test cases
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@280755 13f79535-47bb-0310-9956-ffa450edef68
1.0-alpha-5-SNAPSHOT for all so they're all the same.
o Updated modello plugin invocations in all poms to by adding execution elements
and fixing goals section to get rid of deprecated notation.
o Removed dependency on modello-core in maven-plugin-tools; it seems it
was there because maven-plugin-tools-java used StringUtils from modello -
changed that to use the plexus-utils version.
o Reversed commons-cli version back to 1.0 (brett asked me to, a few days back).
o Updated all models to use fully qualified classnames - do not assume
java.util.* is included! (it won't be anymore from modello
1.0-alpha-5-SNAPSHOT onward).
o Added some <?xml processing instructions to some models that didn't have them
- vim now recognizes these files as XML (so I get syntax highlighting :))
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@280539 13f79535-47bb-0310-9956-ffa450edef68
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
Brett Leslie Porter
John Dennis Casey
Jason van Zyl
Kenney Westerhof
Trygve Laugstol