[ 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
