Brett,
If I understand this right, you'll be able to tell Maven to automatically
check for an update of a particular plugin (great for automatically
distributing bug fixes across projects, much like the Eclipse Update
Manager). This would be accomplished by adding a plugin dependency without
version to the POM? Based on a schedule you define (as for snapshots), M2
will compare your local plugin's version with the version listed in e.g.
maven-idea-plugin-RELEASE.version.txt?
This sounds great.
Thomas
On 5/5/05, Brett Porter <[EMAIL PROTECTED]> wrote:
>
> (first draft, after initial feedback I will turn it into a doc, likewise
> for the lifecycle).
>
> We have a feature in m2 that will take the prefix of a goal name eg
> "idea:idea" -> idea, and discover the plugin either locally or remotely
> and use it. Currently, it is hardcoded to
> org.apache.maven.plugins.maven-${PREFIX}-plugin:1.0-SNAPSHOT.
>
> Here are the changes I am implementing to make this more future-proof.
>
> Firstly it is worth nothing there are parallels to other concepts:
> - SNAPSHOT handling in general
> - the concepts of both "unversioned" dependencies and "latest release"
> dependencies
>
> How will it be used?
>
> It will be most important for users getting the plugin they don't have
> for the first time, though I imagine it would also be important for
> getting updates of those plugins.
> It should only be referencing released plugins, though I think if we
> separate the SNAPSHOT repository and publish nightlies as "releases" on
> there, including that in your list of plugin repositories will allow you
> to get more frequent updates.
> I think the update checks should be identical to snapshots: you can
> configure it to be never, daily, interval based, or every execution,
> with the default being daily.
>
> When will it be used?
>
> When a goal is entered on the command line that was not recognised from
> the plugin definitions already in the POM. In addition, the version
> resolution will be used for plugins specified in the POM without a
> version.
>
> What about reproducibility?
>
> The release tool will need to fill in resolved version information for
> plugins into the POM.
>
> What if I don't want the latest version?
>
> There are a lot of potential configurations that we might want to have
> for this in the settings.xml, but I'd like keep it simple for now and
> let usage drive the features. Some thoughts are excluding specific
> versions from use, or setting a sticky version for certain plugins
> (overridden by anything in the POM, however). Another option might be to
> prompt whether a user wants to update or not, and store that information
> in the local repository.
>
> I think we should leave it to tools or IDE integration to do anything
> fancy like presenting a list of available versions.
>
> ===
>
> Alternate goal specification
> ---
>
> I think we should support goals of the format:
> groupId:artifactId:version:goal. eg.
> org.apache.maven.plugins:maven-idea-plugin:1.0-alpha-1:idea.
> Obviously this is far too ugly for general use, but it does allow a user
> to be incredibly specific in some case, and can be used in the lifecycle
> definitions to make them more deterministic.
>
> The rest will cover how the first 3 are determined when the traditional
> prefix is used, eg "idea:idea"
>
> Versioning
> ---
>
> Firstly, we need to be able to identify the latest version of a plugin.
> This involves the knowledge of what is released, at a per-artifact ID
> level.
>
> Depending on repository format, the file would be:
> /org/apache/maven/plugins/maven-idea-plugin/maven-
> idea-plugin-RELEASE.version.txt
> /org.apache.maven.plugins/poms/maven-idea-plugin-RELEASE.version.txt
>
> Like SNAPSHOT.version.txt, this would simply contain the version that is
> the designated release.
>
> This file would be written at _release_ time, not _deploy_ time, so is
> an independant operation from deployment, and should happen afterwards.
> In fact, there may well be a release lifecycle phase after deploy for
> this purpose (this can be determined as the release tool is fleshed out).
>
> Note that the release transformation will not at this point be exposed
> to dependencies in general - I'd prefer that we take a proper review of
> our dependency mediation requirements first.
>
> This covers how the version is discovered if not specified in the POM,
> or the goal came from the command line - but what about finding out the
> groupID and artifactID?
>
> Discovering the Group and Artifact ID from a Prefix
> ---
>
> 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.
>
> That's about it... any thoughts?
>
> - Brett
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
