design for transparent plugin downloading

[Brett Porter <br...@apache.org>]

(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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: design for transparent plugin downloading

[Thomas Van de Velde <th...@gmail.com>]

Thanks for this clarification. M2 really starts to look great.

On 5/6/05, Brett Porter <br...@apache.org> wrote:
> 
> Thomas Van de Velde wrote:
> 
> >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?
> >
> >
> Yes, though this relates to two situations:
> - declaration in <plugins/> without a version
> - calling from the command line (eg idea:idea) when it is not declared
> as part of the project
> 
> Plugin "depedencies" is not a good way to explain it, as that sounds
> like something listed in the dependencies section, which it is not.
> While this was done in m1, it is now fully controlled by the plugin 
> section.
> 
> - Brett
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 
>

Re: design for transparent plugin downloading

[Brett Porter <br...@apache.org>]

Thomas Van de Velde wrote:

>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?
>  
>
Yes, though this relates to two situations:
- declaration in <plugins/> without a version
- calling from the command line (eg idea:idea) when it is not declared
as part of the project

Plugin "depedencies" is not a good way to explain it, as that sounds
like something listed in the dependencies section, which it is not.
While this was done in m1, it is now fully controlled by the plugin section.

- Brett


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: design for transparent plugin downloading

[Thomas Van de Velde <th...@gmail.com>]

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 <br...@apache.org> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 
>