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
under dependencyManagement of m2 and maven-plugins, and removed
versions in all poms having either as a parent.
Used version 1.0.2-SNAPSHOT for plexus-utils as that was used in maven-core
and is not overridable.
o Bumped maven-archiver version to 2.0-beta-1-SNAPSHOT for maven-ear-plugin
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@227084 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
Added new mojos to the plugin-plugin that will update the plugins.xml mapping metadata in the plugin's group on the distribution repository.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@210153 13f79535-47bb-0310-9956-ffa450edef68
o Normalized all references to plugins to use either o.a.m.model.Plugin or o.a.m.plugin.PluginDescriptor instances
o Changed DefaultLifecycleExecutor, PluginManager, DefaultPluginManager, MavenPluginCollector, and DoxiaMojo to reflect the above
o Added mapped-plugin resolution of goal prefixes to the DefaultLifecycleExecutor
o Added caching of PluginMappingManager instance inside of MavenSession
o Modified SettingsUtils to be more resistant to null String-Lists for pluginGroups and activeProfiles during merge.
o Added checks to MavenProject.addPlugin(..) to only add if the plugin doesn't already exist in the model.
Next step is to modify installation and deployment process for plugins to publish plugins.xml repository metadata.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@209677 13f79535-47bb-0310-9956-ffa450edef68
o Added component descriptor for the MavenPluginMappingBuilder
o Added a new ComponentDiscoveryListener implementation to factor the DefaultPluginManager out of the plexus.xml for maven-core...the DefaultPluginManager now delegates to this component for plugin registration/lookup/etc. and has proper component requirements.
o Moved the DefaultPluginManager component declaration into components.xml, and added a component definition for MavenPluginCollector to plexus.xml in maven-core
Next step is to get rid of the old pluginKey junk, and start using o.a.m.Plugin instances to hold g🅰️v info for all plugins in the system...this will make the interface cleaner and remove the need to concat/parse the plugin identity. Then, I'll add the mapped-plugin lookup functionality to the lifecycle executor.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@209563 13f79535-47bb-0310-9956-ffa450edef68
o Added maven-plugin-mapping project to handle repository metadata that contains prefix-to-artifactId mappings for groups of plugins
o Added builder classes for plugin mappings
o Modified maven-artifact and maven-artifact-manager to handle the concept of repository metadata in addition to artifact metadata.
o Added pluginGroups section to settings.xml, new code to merge these lists of plugin groups, and a unit test to ensure that this merge is taking place properly.
o Added maven-plugin-mapping to dependencies of maven-core, along with the list of builds to be performed by mboot.
Should be ready to incorporate plugin mapping consultation into the lifecycle executor and the deploy mojo...
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@209550 13f79535-47bb-0310-9956-ffa450edef68
o Pressing [ENTER] at a plugin update prompt should result in the plugin being registered, as indicated by the prompt.
o Use CLI switch '--no-plugin-updates' to suppress usage of the plugin registry
o Use CLI switch '--update-plugins' to force updated/resolved plugin versions to be registered
o Neither of these has a short CLI option, since we're starting to run out of sensible char options for these types of things.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@193082 13f79535-47bb-0310-9956-ffa450edef68
simplified by removing a bunch of duplicated code in addArtifacts - no need to merge, you have the full list.
separated the original artifacts (dependency artifacts) from the resolved artifacts (getArtifacts)
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@191667 13f79535-47bb-0310-9956-ffa450edef68
o Pressing [ENTER] at a plugin update prompt should result in the plugin being registered, as indicated by the prompt.
o Use CLI switch '--no-plugin-updates' to suppress usage of the plugin registry
o Use CLI switch '--update-plugins' to force updated/resolved plugin versions to be registered
o Neither of these has a short CLI option, since we're starting to run out of sensible char options for these types of things.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@191664 13f79535-47bb-0310-9956-ffa450edef68
split artifact impl from api so that dep resolution can be used independently of wagon
only the first step in making maven-artifact more useful as a public api - more changes to be made
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@191634 13f79535-47bb-0310-9956-ffa450edef68
o During addPlugin() only the plugin's artifact is resolved/added...just enough to get the plugin container to discover the pluginDescriptor.
o During getConfiguredMojo(), the rest of the plugin's artifacts will be transitively resolved and added to the plugin container (if this hasn't already been done). The deciding factor for attempting to complete the plugin container's artifact list is whether the only artifact in the pluginDescriptor's artifact list is the plugin artifact itself. If that makes sense.
It's a bit of black magic, but I think it'll work unless/until we find something more elegant. I'm abusing the container a little bit here, so it might be sensitive to plexus changes in future.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@191582 13f79535-47bb-0310-9956-ffa450edef68
o Adding extraction of mojo-specific configuration from the merged config for the plugin
o Warning at the DEBUG log-level for unused plugin configuration during the extraction process above
o Added integration test it0028 to test with unused plugin configuration present.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@191552 13f79535-47bb-0310-9956-ffa450edef68
John Dennis Casey
Kenney Westerhof
Brett Leslie Porter
Emmanuel Venisse
Jason van Zyl
Trygve Laugstol