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
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
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
implement ability to retrieve packaging handlers (lifecycle mappings) from extension plugins. Remove plugin mapping
metadata for the same
integration tests are in place for type handlers but commented out until implemented (41)
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@225263 13f79535-47bb-0310-9956-ffa450edef68
o Fixing core-library resolution for expression: ${plugin.artifacts} and ${plugin.artifactMap} (latter is keyed by g:a)
o Modified maven-core-it-plugin to accept something like "-DartifactToFile=org.apache.maven:maven-artifact"...it'll lookup that artifact in ${plugin.artifactMap}, and touch a file that's a mutation of the abs. path for that artifact.
o Added pomArtifact to ResolutionGroup, since the MavenMetadataSource ALWAYS creates a new Artifact for a pom...this allows us to retrieve the resolved Artifact for that pom.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@225234 13f79535-47bb-0310-9956-ffa450edef68
o Added '-f' CLI option, to allow use of non-standard pom files, or spawning of a build from outside of the project dir.
o Added preferential processing of release-pom.xml over pom.xml if it exists (assumes that the current checkout is a release of the software)
o Moved all file discovery from MavenCli to DefaultMaven, to allow embedders to have access to this logic.
o Modified MavenExecutionRequest to add a flag for reactor-activation and the name of a non-standard pom to use, if appropriate.
o Removed getFiles() and getProjectFiles() from MavenExecutionRequest, since file discovery is now done in the DefaultMaven.
o Added integration tests to check preference of release-pom.xml in standalone and '-r' mode
o Added integration tests to check usage of '-f' option within and outside of the project directory
o Added processing for cli-options.txt to maven-core-it-verifier (Verifier.java) to allow specification of '-f' and '-r' in tests
NOTE: the release plugin still doesn't correctly remove the release-pom.xml from HEAD/trunk, since I don't have access to the SCM remove command from maven-scm. I'm waiting for Emmanuel to finish some API changes before moving to the new maven-scm version, and implementing this final step.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@225226 13f79535-47bb-0310-9956-ffa450edef68
allow separate snapshot and release repositories
deprecate existing snapshotPolicy and checksumPolicy in favour of updatePolicy and checksumPolicy within the <releases> and <snapshots> elements in the <repository> element.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@224707 13f79535-47bb-0310-9956-ffa450edef68
o Changed MavenMetadataSource to a component, to avoid having to lookup artifactFactory and projectBuilder in order to
construct it.
o Added add(..) method to ScmBean in the release plugin to allow addition of release-pom.xml
o Changed the PrepareReleaseMojo to resolve ONLY version and parent-version for the normal pom.xml, and fully resolve all
artifacts used in the release-pom.xml, including version, parent-version, dependency closure (given by project.getArtifacts()), plugins, and reports. It will then add the release-pom.xml, and (attempt to) delete it before performing the final commit for next development version.
o Added some mapping methods to ArtifactUtils, to key by artifact.getId, and to create an Artifact.getId()-compatible string from parameters.
o Added TestProjectBuilder to remove the requirement in ProjectClasspathTest to modify the fields of the project builder directly.
o Cleaned up the AbstractReleaseMojo and PrepareReleaseMojo to avoid container lookups...they're now mojo parameters with the 'component.' prefix.
NOTE: Next step is to figure out how to use maven-scm to remove an SCM resource, to enable the prepare mojo to take the release-pom.xml back out of HEAD after the tag is complete.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@224413 13f79535-47bb-0310-9956-ffa450edef68
allow a plugin to specify the minimum Maven version (will apply for both building and its execution - this should be separated later).
If you are running an older version then it will not prompt to update when found, and will fail if it is encountered with a hardcoded version.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@220239 13f79535-47bb-0310-9956-ffa450edef68
Changed download strategy for plugins.xml metadata to download only when non-existent locally or when plugin prefix cannot be located within local metadata. NOTE: This could lead to local-only installs of plugins having their prefix mappings overwritten.
Next step is to change the maven-plugin-plugin.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@219615 13f79535-47bb-0310-9956-ffa450edef68
o Added ResolutionGroup class which contains a set of artifacts and a list of repositories to resolve them.
o Made the ResolutionNode a standalone class, and added the remote repositories to it
o Changed ArtifactMetadataSource.retrieve(..) to return ResolutionGroup rather than Set, in order to help keep track of the repositories which should be used to resolve the retrieved artifacts.
We need some tests for this...
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@219276 13f79535-47bb-0310-9956-ffa450edef68
o Added four command-line options:
--check-plugin-updates is a synonym for --update-plugins
--no-plugin-registry turns off usage of plugin-registry.xml for plugin version resolution for the current build.
--check-plugin-latest turns on usage of LATEST metadata for plugin version resolution for the current build.
--no-plugin-latest turns off usage of LATEST metadata for plugin version resolution for the current build.
o Added settings.xml configuration <usePluginRegistry>true|false</usePluginRegistry> to en/disable the use of plugin-registry.xml for plugin version resolution. The default value is true, to use the plugin-registry.xml.
o Added plugin-registry.xml configuration <checkLatest>true|false</checkLatest> to en/disable the use of LATEST metadata when resolving plugin versions. The default value is false, or do not use LATEST.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@219089 13f79535-47bb-0310-9956-ffa450edef68
o Implemented plan from my comments on MNG-576 for looking up lifecycle mappings within plugins.
o Fixed subtle bug in DefaultWagonManager for verifying checksums, where the destination file was being used to verify the checksum rather than the recently download temp destination.
o Fixed the DefaultRepositoryMetadataManager.resolve(..) method to allow the locally-installed metadata to be used if it is newer than the one resolved from the repository.
o Moved the lifecycle mappings for the EJB and WAR plugins out to META-INF/plexus/components.xml in the respective plugin's src/main/resources directory. it0016 and it0017 still pass.
o Changed the distributionManagement repository for maven-plugins/pom.xml to have id of 'central-plugins' and then added a normal artifact repository definition for central-plugins to that pom, to allow locally-installed repository metadata for the plugins to be put in the right place (and these builds should have access to the central plugin repo anyway).
o Changed the DefaultPluginMappingBuilder to only warn when plugins.xml for a particular plugin group is missing.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@216273 13f79535-47bb-0310-9956-ffa450edef68
MNG-511
MNG-513
Working on:
MNG-449
o Added code to stop the version manager from prompting the user for unregistered plugins; it will simply register them with the resolved version.
o Added failover fourth plugin-version resolution option, which is a plugin-specific artifact metadata called LATEST.version.txt, and will be published with each install/deployment
o Added MavenProject.get/setArtifact(..) to handle a single artifact instance for a project (allows injection of artifact metadata without having to handle it all within the install/deploy mojos).
o Changed plugin-version resolution to only use MavenMetadataSource rather than resolving the whole plugin artifact.
o Changed the install and deploy mojos to only use ${project.artifact} rather than constructing their own, so they can take advantage of metadata added elsewhere in the build.
o Factored the "RELEASE".equals(..) check in the DefaultRepositoryLayout to use new metadata method storedInArtifactDirectory() instead, since RELEASE and LATEST both share this characteristic.
NOTE: I'm not going to resolve MNG-449 yet, because I'm not sure what else Brett had in mind related to the plugin-development-without-release use case...
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@215919 13f79535-47bb-0310-9956-ffa450edef68
Brett Leslie Porter
John Dennis Casey
Jason van Zyl
Kenney Westerhof
Trygve Laugstol
Vincent Massol
Emmanuel Venisse