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 support for global (installation-level) settings.xml file which is identical to the one in ~/.m2, and which will be overridden by user-level settings. The default location for this is ${maven.home}/settings.xml.
o Adding IT to test merging of global- and user-level settings.xml files
o Moved DefaultMavenSettingsBuilder/MavenSettingsBuilder to maven-settings project, to make them more generally available (to ant, for instance)
Resolves issue: MNG-294
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@190517 13f79535-47bb-0310-9956-ffa450edef68
Now, we're using all artifacts referenced by the plugin in the artifacts list for that PluginDescriptor...the only drawback is since we're not using a repository layout for the maven /lib, there is no good way to include the artifact-path from /lib...we're using the artifact-file from the local repo for those deps. This SHOULDN'T cause a problem, but it's possible...
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@190414 13f79535-47bb-0310-9956-ffa450edef68
o Split ModelNormalizationUtils into two utility classes in the maven-profile and maven-settings projects, to be used for converting Profile instances from the settings.xml and profiles.xml into maven-model instances.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@190344 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
o External profiles (from settings.xml, profiles.xml) are now available before the main MavenProject is constructed, which allows repositories defined in external profiles to be used to resolve project parents and dependencies.
NOTE: I need to double-check whether the profile-defined repos are actually used to resolve the parent project(s)...there may be another commit following on the heels of this one.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@189667 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
move default value into configuration, rather than relying on Java. More convenient for other languages, and allows us to validate/document it. Cleaned up the plugin manager handling. More should be pushed into plexus proper.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@188647 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
This is restoring the settings to their original package structure, and putting profiles next to it...the change I'm reversing was not a good one, conceptually.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@179289 13f79535-47bb-0310-9956-ffa450edef68
o Created corresponding runtime exception: InvalidArtifactRTException
o Added error diagnoser for InvalidArtifactRTException
o Changed logError() in DefaultMaven to use error diagnosers (even the devs could use a hand!)
o Added unit test for InvalidArtifactDiagnoser.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@179265 13f79535-47bb-0310-9956-ffa450edef68
o changed the semantics of when the unsetInheritanceApplied() method is called...it's now only when <inherit/> is NOT set.
o changed the default inheritByDefault attribute on MojoDescriptor to be true
o added inheritByDefault to PluginDescriptor (even though we don't have tools supporting it yet), with semantics identical to MojoDescriptor
o added generator/builder support for the inheritByDefault attribute of PluginDescriptor
o added calculation of inheritanceApplied || inheritByDefault to lifecycle executor before allowing plugins/mojos to bind.
o Everything builds, but we need some sort of IT to test the finer points.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@178836 13f79535-47bb-0310-9956-ffa450edef68
o Added annotation inheritedByDefault (looks like: @inheritedByDefault true|false) for java mojos
o Added support for inheritedByDefault to MojoDescriptor, descriptor generator and builder
o Factored the plugin combinatorial logic into ModelUtils in o.a.m.project, for later reuse in a plugin-aware model inheritance builder
o Refactored the DefaultModelDefaultsInjector to use the new ModelUtils for plugin merging (this is factored into a utility for reuse in inheritance assembly)
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@178733 13f79535-47bb-0310-9956-ffa450edef68
o Added concept of ErrorDiagnoser to help interpret errors and provide user feedback
o Added PluginParameterException to provide richer information than simply PluginConfigurationException (it's derived from PluginConfigurationException)
o Added implementations of ErrorDiagnoser for artifact resolution and plugin configuration handling.
o Modified DefaultMaven's logFailure(..) method to use errorDiagnosers Map (injected via Plexus)
I approached the plugin parameter expression/name feedback in this way, as it seems like a general pattern for interpreting errors without embedding this logic deep within the app itself. Feel free to rollback if this causes issues.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@169379 13f79535-47bb-0310-9956-ffa450edef68
o Added listing of error messages from getCause() chain in DefaultMaven rather than simply spitting out the (often useless) aggregator Exception's message.
o Added '-e' to the IT verifier's invocation of m2.
I'm trying to get visibility to errors here...
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@169230 13f79535-47bb-0310-9956-ffa450edef68
o changed the exception(s) throws during mojo descriptor extraction to be derivatives of InvalidPluginDescriptorException
o changed PluginConfigurationException in plugin.descriptor to InvalidPluginDescriptorException
o changed all "true".equals(something) to Boolean.valueOf(something).booleanValue()
o added validation of 'modelVersion' back to [Default]ModelValidator
o Fixed/added tests for new 'modelVersion' validation
o changed all requiresXXX in MojoDescriptor to XXXRequired, and getRequiresXXX():boolean to isXXXRequired():boolean to help maintain bean-ness for future use
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@168630 13f79535-47bb-0310-9956-ffa450edef68
John Dennis Casey
Brett Leslie Porter
Emmanuel Venisse
Trygve Laugstol
Jason van Zyl