Details
-
Type:
Improvement
-
Status:
Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: None
-
Fix Version/s: 2.0-beta-1
-
Component/s: Plugins and Lifecycle
-
Labels:None
Description
We have a default rule which will be used as a fallback, where the
prefix "idea" is turned into "maven-idea-plugin". This will be retained
if no other information is found.
Before applying the default rule, some more metadata from the repository
will be consulted. This will be stored at the group level, and named
"plugins.xml".
/org/apache/maven/plugins/plugins.xml
/org.apache.maven.plugins/plugins.xml
While this could potentially include version information as well, it is
worth being able to check these on a plugin-by-plugin basis, and it also
fits with the potential RELEASE specifier on dependencies. This could be
reconsidered in future versions.
Format of the file for now is simple:
<prefixes>
<groupId>org.apache.maven.plugins</groupId>
<plugins>
<plugin>
<prefix>idea</prefix>
<artifactId>maven-idea-plugin</artifactId>
</plugin>
...
</plugins>
</prefixes>
This particular file will also be updated at release time for a plugin
(though it should rarely be necessary as only new additions need to be
published back).
The list of group IDs to search will be configured from settings.xml,
with the default being just org.apache.maven.plugins. The process will
be to load the plugins.xml file from each of the configured groups, then
build the map of prefixes to plugin group/artifactIDs. If there is a
clash, initially it should fail. We might allow using the first
discovered or some other resolution mechanism, but would hope not to get
that situation as a goal representation might start taking on different
meanings in different contexts.
I think I've got the issue condensed to the following:
----------------------------------
requirements
===============
should be modified to ensure that the plugin's information is provided.
toplugin g:a will be constructed in memory using the user'ssearch groups
search-groups are empty.
'normal' cases (non-offline mode) to refresh it, to pick up newly published
plugins.
modification points
======================
of Strings.
-> Look at the release plugin and RELEASE transformation for some ideas on how to do this.
I'll use this as a basis for implementing these changes. If you see any problems with this plan, please comment.
toplugin g:a will be constructed in memory using the user's search groups- plugin.xml files can be cached locally, but an attempt should be made in all
'normal' cases (non-offline mode) to refresh it, to pick up newly published
plugins.
modification points ======================- modify the plugin upload (install?) process to modify the plugins.xml in the groupId directory
-> Look at the release plugin and RELEASE transformation for some ideas on how to do this.- create PluginGroupResolver to handle plugin-group mappings searches against same
I'll use this as a basis for implementing these changes. If you see any problems with this plan, please comment.