One change:
o Applied lifecycle mapping patch to a new file in src/main/resources of the ear plugin project, to create META-INF/plexus/components.xml with the custom lifecycle mapping.
This plugin needs an integration test.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@216275 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
Now, in order to build a maven plugin, you need two things:
1. a repository defined in distributionManagment
2. a repository defined in <repositories/> which has the same id as the one in distributionManagement.
This is necessary, since in most cases SSH will be used in the distributionManagement definition for uploading the plugin...which means that the download of the existing plugins.xml file might not be available for users trying to run an install. SSH requires authentication information, and users (particularly those running the bootstrap) might not have this auth info.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@216013 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
- The CloverCheckMojo still doesn't seem to work and report a coverage error when used in the simple sample. Not sure why yet
- The CloverReportMojo doesn't work as mixed plugins do not seem to be supported yet.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@209751 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 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
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
- refactor project out of MavenSession so that it can be cloned
- refactor lifecycle construction out so we can clone the existing one and pass it into a new execution
- only resolve plugins that are executed (MNG-489)
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@191413 13f79535-47bb-0310-9956-ffa450edef68
configure reports according to spec:
- <reporting> section affects reports run through site and standalone
- <build> section affects reports run standalone and overrides anything already in <reporting>
- command line parameters rule all
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@191298 13f79535-47bb-0310-9956-ffa450edef68
o Changed <reports/> in the Model to <reporting/>, to accommodate the <reports/> inside of <reportSet/>.
o Changed the report-plugin class <plugins/> inside of <report[ing]/> to <reporters/>, which means using a new class called Reporter (this is meant to be a Plugin-like model for reports, with reportSets rather than executions...)
o Changed the MavenProject to reflect these two model changes
o Added support to the inheritance assembler to perform deep inheritance of the reporting model (complete with calculations based on the <inherit/> attributes on Reporter and ReportSet).
o Updated DoxiaMojo, Pom, and DefaultPluginVersionManager to reflect the new model classes and MavenProject methods.
This is only round one of the changes for this issue. The next step is to start binding report configuration to the plugin manager via the lifecycle executor (it will traverse the reporting section, and verifyPlugin() to enable direct calls to the report's mojo).
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@191239 13f79535-47bb-0310-9956-ffa450edef68
- hook up the source:jar goal to packaging, but only execute for non-SNAPSHOT builds
- allow comma-delimited list of goals in phase definitions
- only register necessary phases for the goals given
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@191111 13f79535-47bb-0310-9956-ffa450edef68
refactor artifact creation to all go through the factory, and assign the type handler from there.
Attach EJB client to the EJB artifact so that it is installed/deployed along with it.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@191096 13f79535-47bb-0310-9956-ffa450edef68
o Added support for update-all and update-none when prompting the user.
o Added --update-plugins/-F option to force an update of the plugins used in the project.
o Added autoUpdate setting for the plugin registry. This is used when in non-interactive mode, to determine whether to register plugin updates
o Added updateInterval to determine when/how often to check for updates to registered plugins. Supports three syntaxes:
- 'never'
- 'always'
- 'interval:XXX' (where XXX can be a combination of weeks, days, hours, and minutes in the syntax: 1w1d1h1m)
> this renders the interval syntax similar to 'interval:1w' to check every week.
NOTE: update intervals are calculated from the time a particular plugin was last checked.
o Added lastChecked attribute for registered plugins, to use as a basis for calculating update-check interval
o Added RuntimeInfo classes for maven-settings and maven-plugin-registry, to help in tracking the file each instance comes from, in addition to merging info which is useful when extracting the user-level instance from the merged instance (for persisting changes to the user instance, f.e.).
o Changed verifyPlugin(..) to take an instance of Settings, to allow persistent decisions across the session (like update-all, update-none in the plugin version manager)
This should take care of outstanding issues with this new feature. I'm closing the JIRA issue now, and we'll deal with any bugs/shortcomings as separate issues.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@191021 13f79535-47bb-0310-9956-ffa450edef68
Added specified stop-gap patch for issue: MNG-473 (affects settings-builder and registry-builder)
Today I've made the following progress on this so far:
- Added a new project, called maven-plugin-registry, to house the model for this new file.
- Developed/debugged/tested PluginVersionManager/DefaultPluginVersionManager to isolate the plugin-version checks/management code away from the PluginManager
- Added interactiveMode (<interactiveMode>true|false</interactiveMode> directly under the root element of settings.xml, or -B short CLI option or --batch-mode CLI option, where the CLI options turn OFF interactiveMode). This will allow things like the maven-plugins build to register new plugins (and, for now, new versions of plugins) automatically.
- Added user input handler for when interactiveMode = true, to get a yes/no on whether to use the discovered version over the installed version and/or no version at all. If there is no installed version, and the user selects 'n', then the discovered version is used FOR THAT SESSION ONLY, and won't be recorded in the registry.
- Added checks/recording rejected versions against the registry, before attempting to use the discovered version.
Pending:
- Still need to add update-policies, to determine two things:
1. how often to check for updates
2. what to do when updates are found (autoUpdate, etc.)
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@190854 13f79535-47bb-0310-9956-ffa450edef68
o Adding @phase declarations for those mojos that seem to be part of the main build, just for completeness
o Added two ITs, to test that <executions/> doesn't mess up the normal operation, and to test multi-execution for a goal.
Should resolve: MNG-172.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@190335 13f79535-47bb-0310-9956-ffa450edef68
current goals:
projecthelp:active-profiles
projecthelp:effective-pom
o Added source attribute to the Profile model class in maven-model, along with code in the normalization utilities (converters from profiles.xml and settings.xml models to maven-model instances) to identify the source of a particular profile.
o Added a activeProfiles cache of the Profiles in effect for the current project, on the MavenProject class
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@189612 13f79535-47bb-0310-9956-ffa450edef68
reverse the reference. DoxiaMojo depends on maven-core instead of maven-core depending on the reporting api + doxia
This is not a great solution, but it gets us closer. It is currently not possible, as before, to get the correct set of reports as they are all loaded into the one container and then everything found is returned.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@188690 13f79535-47bb-0310-9956-ffa450edef68
o Moved marmalade support dependencies out of maven-core, since they can be supported on demand now
o changed the ordering of the ant and assembly plugins, to show that the classloader (plugin param) bug is fixed.
o added a method in PluginDescriptor which is similar to o.a.m.model.Plugin.getId() (I think that's the method; it's the one that results in a key of 'g:a')
o moved wagon-ssh dependency into maven-core, since there is a new issue related to nested containers and wagons which are introduced as plugin dependencies. This should be solved using a mechanism similar to plugin-manager for wagon-manager impl in future anyway
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@187639 13f79535-47bb-0310-9956-ffa450edef68
Brett Leslie Porter
Vincent Siveton
John Dennis Casey
Emmanuel Venisse
Vincent Massol
Trygve Laugstol
Jason van Zyl