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 <br...@apache.org> on 2005/10/05 11:34:16 UTC

take 2: tracking m1 vs m2 plugins

Hi,

We discussed this briefly before. From looking at that, this seems to be
the most workable solution:
- for any new features added in m1 or m2, we add a description to the
plugin site so that we have a comparitive checklist
- for any bugs fixed in m1 that potentially impact m2, when fixed, clone
the issue and move it to the other project, linking the original (this
should only be a small % of issues as they usually relate to jelly-isms,
etc) - this would include minor features (ie other options or
configurations).

Of course, the best solution where practical is to have them share the
code (eg JXR).

My main concern is that all the great work Lukas, Arnaud and Carlos have
done recently would need to be duplicated later and hard to track.

Does this sound ok?

- Brett

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


Re: take 2: tracking m1 vs m2 plugins

Posted by Lukas Theussl <lt...@apache.org>.
Sounds reasonable to me. Somebody wants to come up with a template for 
the plugin feature list?

Concerning all the great work we've done recently (:)), it shouldn't be 
too hard to extract the information from the entries in changes.xml. 
Maybe this could be implemented as part of the changes plugin?


-Lukas


Brett Porter wrote:
> Hi,
> 
> We discussed this briefly before. From looking at that, this seems to be
> the most workable solution:
> - for any new features added in m1 or m2, we add a description to the
> plugin site so that we have a comparitive checklist
> - for any bugs fixed in m1 that potentially impact m2, when fixed, clone
> the issue and move it to the other project, linking the original (this
> should only be a small % of issues as they usually relate to jelly-isms,
> etc) - this would include minor features (ie other options or
> configurations).
> 
> Of course, the best solution where practical is to have them share the
> code (eg JXR).
> 
> My main concern is that all the great work Lukas, Arnaud and Carlos have
> done recently would need to be duplicated later and hard to track.
> 
> Does this sound ok?
> 
> - Brett
> 
> ---------------------------------------------------------------------
> 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: take 2: tracking m1 vs m2 plugins

Posted by Brett Porter <br...@apache.org>.
Arnaud HERITIER wrote:

>Who can do that ? 
>I think it will concern only updates and new features on plugins (bugs are not significant because m2 plugins were totally rewriten
>from scratch). 
>  
>
an example of a bug is MPIDEA-39. This probably affects both.

>But actually I don't know which features are done in m2 plugins (and it'll take me some time to know them).
>Are there some m2 committers who can follow the issues we close in m1 ?
>  
>
if you do something new in m1, you should definitely be checking m2
first, as if they've implemented it you don't want to redo it :)

As for the format - I'm fine with any simple page for this right now.

- Brett

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


RE: take 2: tracking m1 vs m2 plugins

Posted by Arnaud HERITIER <ah...@gmail.com>.
> 
> Hi,

Hi,

> 
> We discussed this briefly before. From looking at that, this 
> seems to be the most workable solution:
> - for any new features added in m1 or m2, we add a 
> description to the plugin site so that we have a comparitive checklist

+1, I'll try to do it as soon as possible in plugins I use(d).

> - for any bugs fixed in m1 that potentially impact m2, when 
> fixed, clone the issue and move it to the other project, 
> linking the original (this should only be a small % of issues 
> as they usually relate to jelly-isms,
> etc) - this would include minor features (ie other options or 
> configurations).

Who can do that ? 
I think it will concern only updates and new features on plugins (bugs are not significant because m2 plugins were totally rewriten
from scratch). 
But actually I don't know which features are done in m2 plugins (and it'll take me some time to know them).
Are there some m2 committers who can follow the issues we close in m1 ?

> 
> Of course, the best solution where practical is to have them 
> share the code (eg JXR).

YES. +1000 ;-)

> 
> My main concern is that all the great work Lukas, Arnaud and 
> Carlos have done recently would need to be duplicated later 
> and hard to track.

Yes I know :-( but I don't have another solution to release maven 1.1 before m2 ;-). 
We don't have the time and people to try to reuse plugins between m1 and m2 (unfortunately).

> 
> Does this sound ok?

Ok for me.

Arnaud

> 
> - Brett
> 
> ---------------------------------------------------------------------
> 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