[ http://jira.codehaus.org/browse/MNG-379?page=comments#action_41285 ]
John Casey commented on MNG-379:
--------------------------------
Been doing some design work on this. I'm pasting my notes here, so others can
comment on them.
----------------- PASTE FOLLOWS -------------------------------------
My Design/Implementation Notes for MNG-379
-------------------------------------------
Marching orders:
=====================
1. Implement tracking of source for instances in maven-settings. This includes
all sub-elements.
Rewriting of user-settings SHOULD NOT result in global settings being
respecified at the user level.
**NOTE: Make everything in settings.mdo extend from a base class that
tracks source, with restrictions on source-value to USER|GLOBAL?
2. Modify the settings model to add the new plugin-versions stuff:
<pluginUpdates>
<pluginUpdate>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-deploy-plugin</artifactId>
<autoUpdate>false</autoUpdate>
<useVersion>1.0</useVersion>
<rejectedVersions>
<!-- signifies that the user declined to upgrade to this plugin -->
<rejectedVersion>1.1</rejectedVersion>
</rejectedVersions>
</pluginUpdate>
</pluginUpdates>
**NOTE: These update definitions will have to be MERGED during
inheritance...
3. Wire up the new settings elements to the verifyPlugin()/addPlugin() methods
of DefaultPluginManager.
Implementations of PluginUpdateManager will be responsible for managing
plugin version info, including rewriting user-settings and prompting the
user to install a new version of the plugin.
-> Implement org.apache.maven.plugin.update
* PluginUpdateManager <<ifc>>
* DefaultPluginUpdateManager
* PluginUpdatePolicy <<ifc>>
* ManualUpdatePolicy
eventually:
* IntervalUpdatePolicy (will require changes to maven-artifact
for metadata-upToDate check...)
* Interval (parses things like '12h' from String to a Date or long...)
4. Add prompting before upgrading the current plugin-version if
(autoInstall != true)
-> This will be a modification to DefaultPluginUpdateManager (see above)
-> If source == GLOBAL for a pluginUpdate, then require
-DpluginPrompts=true to prompt/upgrade the plugin. This is a backdoor for
admins only...
5. Figure out how the hell profiles factor into all this junk...
Required components:
=====================
- User input interface (need a console impl. for first pass, but should allow
IDEs to plugin here too)
-> Plexus has a component, used in release plugin currently.
-> CHECK INTO THIS, it may need upgrades...
- settings.xml section for plugin-updates or somesuch - to include:
* update-freq policy (manual|interval|daily default to manual)
> worry about this later
* auto-install policy (true|false, default to false to prompt the user)
> worry about this later
* currently installed plugin versions
* plugin versions which have been rejected in the past
- Profile addition for settings.xml to allow changes to the plugin versions and
the update-freq. update-prompt policies
- Interval class to parse/format user-specified update intervals in a terse
form (ex. 12h)
> worry about this later
- Some way of tracking which settings are global, so these are not re-written
to user.home
- NEVER rewrite plugin versions which are specified in the globals...
* Never prompt for their upgrade, either...
Functional Notes:
===================
- plugins don't get an entry in settings.xml pegging it at a version until the
first time they're resolved.
At this point, RELEASE is resolved to a concrete version, and recorded
as the installed version in the user's settings.
- the only way to specify a plugin's version in the globals is via manual
entry. The pattern here is for the admin user to update his plugins, confirm
versions to be installed, and then copy this version info from his
user-level settings into the globals.
> more control over plugin updates
> --------------------------------
>
> Key: MNG-379
> URL: http://jira.codehaus.org/browse/MNG-379
> Project: Maven 2
> Type: Improvement
> Reporter: Brett Porter
> Assignee: John Casey
> Fix For: 2.0-alpha-3
>
>
> currently, plugin updates are checked daily (or whatever the plugin
> repository's snapshot policy is), and new versions downloaded automatically.
> The user needs more control:
> - prompting for updates
> - ability to stick to a particular version
> - ability to check on different intervals than snapshots (probably default to
> never, and use a --update-plugins clie or something)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
