You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by di...@multitask.com.au on 2003/11/27 06:53:20 UTC
[pom3/4] element.
Where did this discussion end up.
>From what I can tell, I suggested we re-use the <dependency> element with
a new <type>, and then discussion stalled.
Is that it?
--
dIon Gillard, Multitask Consulting
Blog: http://blogs.codehaus.org/people/dion/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [pom3/4] element.
Posted by Peter Lynch <pe...@mindspring.com>.
Vincent,
Perhaps just keep it simple. Only indicate what the minimum Maven version that
the plugin needs. Going beyond that will get extremely complex IMO.
I wouldn't bother failing either even if the plugin is run in a maven older than
that stated in the plugin POM. Maybe just give a warning to the user and let
the user decide if they care. Some goals in the plugin may fail, others may
work, etc...
My 2 cents...
-Peter
Vincent Massol wrote:
> Here is what I said in an email:
>
> -----------
>
> As requested by dIon here's a summary of the 2 proposals we have for
> introducing compatibility definition in the POM for plugins (i.e. what
> version of Maven a given plugin is compatible with).
>
> Proposal 1:
>
> * Add the following to project.xml (this is an example):
>
> <compatibilities>
> <compatibility>1.0-rc1</compatibility>
> <compatibility>1.0-rc2</compatibility>
> <compatibility>1.0-rc3-SNAPSHOT</compatibility>
> </compatibilities>
>
> Proposal 2:
>
> * Reuse the dependencies elements of project.xml (this is an example):
>
> <dependency>
> <groupId>maven</groupId>
> <artifactId>maven</artifactId>
> <version>1.0+</version>
> <type>maven</type>
> </dependency>
>
> My analysis:
>
> * First question to answer: whether we wish to support complex
> versioning right now. i.e. the use of "+". I am personally not in favor
> of using that now for 2 reasons:
> * It is complex to implement and we could easily use a list of
> versions as showin in proposal 1
> * It raises lots of ugly questions. Like: if I say "1.0-rc1+", how can
> I know that my plugin will be compatible with 1.1 when it is not even
> yet designed nor released? So in practice I cannot say 1.0-rc1+ but I'll
> have to say something like "1.0-rc1"-"1.0"
>
> * I like the dependency reuse but for the following points:
> * We will need to really tackle the <type> element properly and
> provide Resolvers for each type. We'll also need to provide better APIs
> for plugin developers as I believe some plugins are currently iterating
> over any dependency. Something like project.getDependencies(type) maybe.
> * How do we specify multiple versions? Using a comma-separated list
> seem to have been rejected by everyone (see previous posts on
> compatibility in archives).
>
> * Although we could reuse the dependency stuff, Maven core is something
> special and unlike other dependencies. Why? Because other dependencies
> can be downloaded whereas Maven core is installed and cannot be changed
> automatically. Also Maven is not an artifact. It is not composed only of
> a JAR. It is a complete system. That means there's no relationship
> between the Maven system installed on your machine and the remote
> repository. It happens there is a maven jar but this not the
> compatibility we are stating. We are stating a compatibility with the
> full installed Maven, not an API compatibility with the maven jar.
>
> * Are we going to also specify what version of the POM a plugin
> supports? Now that plugins are extracted from the core and could be
> provided by third parties, it may become necessary. One solution would
> be to link Maven versions with POM versions but I don't know if it
> provides enough flexibility.
>
> Thanks
> -Vincent
>
> -----
>
> Could you comment on the 2 proposals?
>
> Thanks
> -Vincent
>
>
>>-----Original Message-----
>>From: dion@multitask.com.au [mailto:dion@multitask.com.au]
>>Sent: 27 November 2003 06:53
>>To: dev@maven.apache.org
>>Subject: [pom3/4] <compatibilities> element.
>>
>>Where did this discussion end up.
>>
>>>From what I can tell, I suggested we re-use the <dependency> element
>
> with
>
>>a new <type>, and then discussion stalled.
>>
>>Is that it?
>>--
>>dIon Gillard, Multitask Consulting
>>Blog: http://blogs.codehaus.org/people/dion/
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: [pom3/4] element.
Posted by Vincent Massol <vm...@pivolis.com>.
Here is what I said in an email:
-----------
As requested by dIon here's a summary of the 2 proposals we have for
introducing compatibility definition in the POM for plugins (i.e. what
version of Maven a given plugin is compatible with).
Proposal 1:
* Add the following to project.xml (this is an example):
<compatibilities>
<compatibility>1.0-rc1</compatibility>
<compatibility>1.0-rc2</compatibility>
<compatibility>1.0-rc3-SNAPSHOT</compatibility>
</compatibilities>
Proposal 2:
* Reuse the dependencies elements of project.xml (this is an example):
<dependency>
<groupId>maven</groupId>
<artifactId>maven</artifactId>
<version>1.0+</version>
<type>maven</type>
</dependency>
My analysis:
* First question to answer: whether we wish to support complex
versioning right now. i.e. the use of "+". I am personally not in favor
of using that now for 2 reasons:
* It is complex to implement and we could easily use a list of
versions as showin in proposal 1
* It raises lots of ugly questions. Like: if I say "1.0-rc1+", how can
I know that my plugin will be compatible with 1.1 when it is not even
yet designed nor released? So in practice I cannot say 1.0-rc1+ but I'll
have to say something like "1.0-rc1"-"1.0"
* I like the dependency reuse but for the following points:
* We will need to really tackle the <type> element properly and
provide Resolvers for each type. We'll also need to provide better APIs
for plugin developers as I believe some plugins are currently iterating
over any dependency. Something like project.getDependencies(type) maybe.
* How do we specify multiple versions? Using a comma-separated list
seem to have been rejected by everyone (see previous posts on
compatibility in archives).
* Although we could reuse the dependency stuff, Maven core is something
special and unlike other dependencies. Why? Because other dependencies
can be downloaded whereas Maven core is installed and cannot be changed
automatically. Also Maven is not an artifact. It is not composed only of
a JAR. It is a complete system. That means there's no relationship
between the Maven system installed on your machine and the remote
repository. It happens there is a maven jar but this not the
compatibility we are stating. We are stating a compatibility with the
full installed Maven, not an API compatibility with the maven jar.
* Are we going to also specify what version of the POM a plugin
supports? Now that plugins are extracted from the core and could be
provided by third parties, it may become necessary. One solution would
be to link Maven versions with POM versions but I don't know if it
provides enough flexibility.
Thanks
-Vincent
-----
Could you comment on the 2 proposals?
Thanks
-Vincent
> -----Original Message-----
> From: dion@multitask.com.au [mailto:dion@multitask.com.au]
> Sent: 27 November 2003 06:53
> To: dev@maven.apache.org
> Subject: [pom3/4] <compatibilities> element.
>
> Where did this discussion end up.
>
> From what I can tell, I suggested we re-use the <dependency> element
with
> a new <type>, and then discussion stalled.
>
> Is that it?
> --
> dIon Gillard, Multitask Consulting
> Blog: http://blogs.codehaus.org/people/dion/
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org