You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by "Brett Porter (JIRA)" <ji...@codehaus.org> on 2005/05/10 07:58:29 UTC
[jira] Created: (MNG-379) more control over plugin updates
more control over plugin updates
--------------------------------
Key: MNG-379
URL: http://jira.codehaus.org/browse/MNG-379
Project: m2
Type: Improvement
Reporter: Brett Porter
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Commented: (MNG-379) more control over plugin updates
Posted by "John Casey (JIRA)" <ji...@codehaus.org>.
[ 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Commented: (MNG-379) more control over plugin updates
Posted by "Brett Porter (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-379?page=comments#action_41314 ]
Brett Porter commented on MNG-379:
----------------------------------
I think separating into a separate file, at least initially, is a good idea
this is sounding great, thanks!
> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Commented: (MNG-379) more control over plugin updates
Posted by "Brett Porter (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-379?page=comments#action_41369 ]
Brett Porter commented on MNG-379:
----------------------------------
"- 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."
Shouldn't no mean no? I think it should use the previous version, if that is possible.
"- Added checks/recording rejected versions against the registry, before attempting to use the discovered version. "
I don't understand this, is this fulfilling what I asked above?
> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Commented: (MNG-379) more control over plugin updates
Posted by "Brett Porter (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-379?page=comments#action_41215 ]
Brett Porter commented on MNG-379:
----------------------------------
no, there hasn't been any design.
Let me expand on my thoughts:
- prompting for updates
currently, there are daily checks for a new version, and if found it is downloaded and used. I would like that it is possible (and the default in interactive mode) to prompt whether to use that version, and record the choice in settings.xml.
eg.
A newer version of the Maven IDEA plugin is available.
Current version: 1.4
Available: 1.5.1
Would you like to use the new version?
- ability to stick to a particular version
controlled via the settings model, you should be able to keep a particular version. Answering a no above would probably populate that
- ability to check on different intervals than snapshots (probably default to never, and use a --update-plugins clie or something)
this one is probably self explanatory. Currently ther snapshot policy is used for checking the plugin releases - a different policy might be appropriate
Bear in mind this might later apply to other components in the system.
I think the stuff needed in the settings model is:
- plugin g/a id
- currently selected version, per plugin, default to RELEASE if not given
- previously rejected versions, per plugin (don't prompt again for upgrades to these versions)
- global policy: update frequency (probably a property on the plugin repository, that could be set in the servers section?)
- global policy: prompt for updates, auto-install (no need for never - that would be the check interval above)
And finally - let the profiles change these values :)
What do you think?
I'm happy to move this to beta-1 if it is too large.
> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Closed: (MNG-379) more control over plugin updates
Posted by "John Casey (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-379?page=all ]
John Casey closed MNG-379:
--------------------------
Resolution: Fixed
> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Commented: (MNG-379) more control over plugin updates
Posted by "John Casey (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-379?page=comments#action_41311 ]
John Casey commented on MNG-379:
--------------------------------
I've got the settings model modified to support this, I think. It builds, and I've checked it in.
I'm working on modification of the plugin version resolution stuff in the plugin manager - it'll call out to a PluginVersionManager eventually, which will incorporate the algorithm for searching for a plugin's version in the pom, then settings, then resolving RELEASE and rewriting the user settings with the resolved version. Separating this into a different manager will make it easy to incorporate update policies and auto-update vs. prompt policies.
I'll probably have this finished tomorrow.
> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Commented: (MNG-379) more control over plugin updates
Posted by "John Casey (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-379?page=comments#action_41372 ]
John Casey commented on MNG-379:
--------------------------------
What I meant here is:
1. if the plugin isn't registered in plugin-registry.xml, and we resolve a version based on RELEASE, we present that version to the user, and ask if [s]he wants to use that version as the 'installed' version in the future. If the user says no, then that version is still used for the present build session (there are no alternatives to this; we have to use something). If the user says yes, then a new registry element is created for the plugin, with that resolved version setup in the useVersion field. The above is when interactiveMode == true. When it's false, we're currently skipping the prompt, and directly registering a new plugin entry with the resolved version. This will be handled better once we have update policies in place.
2. What I'm saying here is, in the event that the plugin is registered in plugin-registry.xml, we retrieve that version. Then, based on the update policy (currently set to always...), we check for a newer version. If we find a newer version, we check that version against the list of rejectedVersions (versions the user has specifically chosen NOT to use when prompted previously) before we prompt the user to update. This is a separate piece of logic from (1) above.
The order of precedence for resolving a plugin version is:
1. Check the POM. If the plugin version is there, don't touch OR consult the plugin registry, and don't resolve RELEASE unless that's what the POM asks you to do.
2. Check the plugin-registry.xml for an entry corresponding to the plugin's g:a. If it's there, process the update policy (currently ALWAYS), and maybe resolve a newer version, if there is one. If there is one, consult the list of rejectedVersions before using this new version as a potential update to the plugin.
3. If the plugin-registry doesn't have an entry for the plugin, and it's not in the POM, then default to resolving the RELEASE version. Once we have this, we can also display that resolved version as something we can register the plugin against in the plugin-registry.xml.
Based on #2 or #3, we might wind up prompting the user to accept/decline the new version of a plugin. If maven is running in non-interactive mode, then we have to provide some fallback action (<autoUpdate>true</autoUpdate>, for instance...currently, it silently updates the registry). If the user accepts the updated version, then the appropriate modifications are made to the registry, and it's persisted to disk.
NOTE: If at any time it's determined that a previously registered plugin was provided at the globals level, we WILL NOT modify that plugin's version info in any way. This file is meant to be untouchable by the runtime, and must be manually maintained. At least for now, that's the way the system's designed.
> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Commented: (MNG-379) more control over plugin updates
Posted by "John Casey (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-379?page=comments#action_41295 ]
John Casey commented on MNG-379:
--------------------------------
What is the required logic for merging global and user plugin update policies? I've rethought about this, and I'm going to do a shallow merge for now - that is, add from the global if the user-level update isn't present...otherwise, ignore the global version. I'm not sure this is good for situations where you're trying to maintain a homogenous maven build across multiple developers on a single server/network sharing the same globals. In this case, it makes more sense to make the globals authoritative (though maybe not for the entirety of the global settings.xml), since one developer who uses a different plugin version than the rest could lead to a broken build.
Perhaps we need to add some sort of mergeAdvice to the pluginUpdate, to give a hint on how to merge the globals and the user-level??
> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Commented: (MNG-379) more control over plugin updates
Posted by "John Casey (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-379?page=comments#action_41312 ]
John Casey commented on MNG-379:
--------------------------------
One question: when the plugin version manager rewrites the user settings.xml, it will likely wind up in a different order than it started. Maybe this matters, maybe not...if so, do we want to consider writing/maintaining a separate plugin-versions.xml file to accompany settings.xml?
I don't think it's the right thing to do, but again I wanted to get some feedback.
> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Commented: (MNG-379) more control over plugin updates
Posted by "John Casey (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-379?page=comments#action_41205 ]
John Casey commented on MNG-379:
--------------------------------
has there been any design work on this one yet? From the original description of the issue, I'm not sure what you're envisioning...
What is the specific problem we're trying to solve here? What would acceptable functional solutions be?
> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Commented: (MNG-379) more control over plugin updates
Posted by "Brett Porter (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-379?page=comments#action_41393 ]
Brett Porter commented on MNG-379:
----------------------------------
sounds good.
> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Commented: (MNG-379) more control over plugin updates
Posted by "Brett Porter (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-379?page=comments#action_41304 ]
Brett Porter commented on MNG-379:
----------------------------------
John:
- don't care much about merging with globals for now. I'd just merge by whole pluginUpdate section (ie if plugin doesn't exist, add), not the elements within it.
- honour the pom above this.
> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Commented: (MNG-379) more control over plugin updates
Posted by "John Casey (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-379?page=comments#action_41296 ]
John Casey commented on MNG-379:
--------------------------------
What do we do if the pom specifies one version of a plugin, but it's on the rejectedVersions list in the settings.xml?
> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Commented: (MNG-379) more control over plugin updates
Posted by "John Casey (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-379?page=comments#action_41367 ]
John Casey commented on MNG-379:
--------------------------------
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.)
> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org