tracking changes in m1 plugins vs m2 plugins

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

Hi,

I notice some great work going into m1 plugins. Thanks to everyone for
the work going on there and for keeping them going. In addition, there
are new jira issues coming in, sometimes with patches.

As we progress towards a final release of Maven 2.0 and look to
maintaining both in parallel in the future, I'm looking for thoughts
from people on how we can ensure features and bugfixes in the m1 plugins
don't get overlooked for m2.

The ideal solution is for the m1 plugin to be rewritten as a wrapper on
the m2 version, but this might be too much work in some cases,
especially if there is heavy project interaction. It's also an issue if
we've deliberately decided to remove a feature from the m2 version.

That said, are there any plugins where people think this would make
sense to try?

What fallbacks do we have otherwise? Some options:
- Cease new features on the m1 plugins to reduce the amount of work.
This is probably too harsh, esp. if m1 users contribute patches
- open an issue on the m2 plugin when the m1 version is closed, linking
to the original
- others?

Cheers,
Brett

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

Re: tracking changes in m1 plugins vs m2 plugins

[Carlos Sanchez <ca...@apache.org>]

In the m2 plugin matrix you can add the version of the m1 plugin that
matches features with m2. This way you can easily see that changes
after that version were not ported to m2,

On 9/23/05, Jason van Zyl <ja...@maven.org> wrote:
> On Sat, 2005-09-24 at 10:05 +1000, Brett Porter wrote:
> > Hi,
> >
> > I notice some great work going into m1 plugins. Thanks to everyone for
> > the work going on there and for keeping them going. In addition, there
> > are new jira issues coming in, sometimes with patches.
> >
> > As we progress towards a final release of Maven 2.0 and look to
> > maintaining both in parallel in the future, I'm looking for thoughts
> > from people on how we can ensure features and bugfixes in the m1 plugins
> > don't get overlooked for m2.
> >
> > The ideal solution is for the m1 plugin to be rewritten as a wrapper on
> > the m2 version, but this might be too much work in some cases,
> > especially if there is heavy project interaction. It's also an issue if
> > we've deliberately decided to remove a feature from the m2 version.
> >
> > That said, are there any plugins where people think this would make
> > sense to try?
>
> I think the plugin matrix would be an ideal for people to comment as to
> what plugins this might work for. As I'm working on doco I can start the
> process as I can see a handful of plugins where I don't think this would
> be too hard i.e. use a wrapped mojo in m1.
>
> But if we use the matrix then opinions as to hard something will be, or
> not, can be measured by the group. Of course I'm always overly
> optimistic but I think a good chunk of the m1 plugins can be replaced by
> wrapped mojos.
>
> > What fallbacks do we have otherwise? Some options:
> > - Cease new features on the m1 plugins to reduce the amount of work.
> > This is probably too harsh, esp. if m1 users contribute patches
>
> Yah, I don't think we can do this.
>
> > - open an issue on the m2 plugin when the m1 version is closed, linking
> > to the original
>
> +1
>
> At least we can then see how the features are changing in the m1 version
> wrt to the mojo.
>
> > - others?
>
> It would be nice to track features provided by each plugin. I certainly
> don't want to go back through each m1 plugin and enumerate each feature
> but this might be something we could do with the m2 plugins and then we
> could have a way to highlight a feature that is present in the m1 plugin
> which is not present in the m2 plugin. So we can easily see the
> relationship for each plugin but still be focused on the m2 side. As a
> practical issue it would simply be nice for users to see a feature list
> as the first thing they see in the plugin documentation so they can
> figure out if it does what they need.
>
> > Cheers,
> > Brett
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
> --
> jvz.
>
> Jason van Zyl
> jason at maven.org
> http://maven.apache.org
>
> First, the taking in of scattered particulars under one Idea,
> so that everyone understands what is being talked about ... Second,
> the separation of the Idea into parts, by dividing it at the joints,
> as nature directs, not breaking any limb in half as a bad carver might.
>
>   -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander)
>
>
> ---------------------------------------------------------------------
> 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: tracking changes in m1 plugins vs m2 plugins

[Jason van Zyl <ja...@maven.org>]

On Sat, 2005-09-24 at 10:05 +1000, Brett Porter wrote:
> Hi,
> 
> I notice some great work going into m1 plugins. Thanks to everyone for
> the work going on there and for keeping them going. In addition, there
> are new jira issues coming in, sometimes with patches.
> 
> As we progress towards a final release of Maven 2.0 and look to
> maintaining both in parallel in the future, I'm looking for thoughts
> from people on how we can ensure features and bugfixes in the m1 plugins
> don't get overlooked for m2.
> 
> The ideal solution is for the m1 plugin to be rewritten as a wrapper on
> the m2 version, but this might be too much work in some cases,
> especially if there is heavy project interaction. It's also an issue if
> we've deliberately decided to remove a feature from the m2 version.
> 
> That said, are there any plugins where people think this would make
> sense to try?

I think the plugin matrix would be an ideal for people to comment as to
what plugins this might work for. As I'm working on doco I can start the
process as I can see a handful of plugins where I don't think this would
be too hard i.e. use a wrapped mojo in m1.

But if we use the matrix then opinions as to hard something will be, or
not, can be measured by the group. Of course I'm always overly
optimistic but I think a good chunk of the m1 plugins can be replaced by
wrapped mojos. 

> What fallbacks do we have otherwise? Some options:
> - Cease new features on the m1 plugins to reduce the amount of work.
> This is probably too harsh, esp. if m1 users contribute patches

Yah, I don't think we can do this.

> - open an issue on the m2 plugin when the m1 version is closed, linking
> to the original

+1

At least we can then see how the features are changing in the m1 version
wrt to the mojo.

> - others?

It would be nice to track features provided by each plugin. I certainly
don't want to go back through each m1 plugin and enumerate each feature
but this might be something we could do with the m2 plugins and then we
could have a way to highlight a feature that is present in the m1 plugin
which is not present in the m2 plugin. So we can easily see the
relationship for each plugin but still be focused on the m2 side. As a
practical issue it would simply be nice for users to see a feature list
as the first thing they see in the plugin documentation so they can
figure out if it does what they need.

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

Jason van Zyl
jason at maven.org
http://maven.apache.org

First, the taking in of scattered particulars under one Idea,
so that everyone understands what is being talked about ... Second,
the separation of the Idea into parts, by dividing it at the joints,
as nature directs, not breaking any limb in half as a bad carver might.

  -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander)


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

RE: tracking changes in m1 plugins vs m2 plugins

[Arnaud HERITIER <ah...@gmail.com>]

Hi,

Sorry for the delay ..

> 
> Hi,
> 
> I notice some great work going into m1 plugins. Thanks to 
> everyone for the work going on there and for keeping them 
> going. In addition, there are new jira issues coming in, 
> sometimes with patches.
> 
> As we progress towards a final release of Maven 2.0 and look 
> to maintaining both in parallel in the future, I'm looking 
> for thoughts from people on how we can ensure features and 
> bugfixes in the m1 plugins don't get overlooked for m2.
> 
> The ideal solution is for the m1 plugin to be rewritten as a 
> wrapper on the m2 version, but this might be too much work in 
> some cases, especially if there is heavy project interaction. 
> It's also an issue if we've deliberately decided to remove a 
> feature from the m2 version.
> 
> That said, are there any plugins where people think this 
> would make sense to try?

We should find some easy plugins to begin.
We already talked about the genapp one.
I didn't yet invastigate.


> 
> What fallbacks do we have otherwise? Some options:
> - Cease new features on the m1 plugins to reduce the amount of work.
> This is probably too harsh, esp. if m1 users contribute patches

Yes, it'll not be possible.
We'll find certainly during several months/years a lot of m1 users who will not be able to migrate their old and big projects (with
a lot of jelly ..).
These users will certainly continue to enhance m1 and its plugins.
I hope it will be a majority of bug fixes but we can't be sure.

> - open an issue on the m2 plugin when the m1 version is 
> closed, linking to the original

Too annoying.
We'll not think to do it each time :-(

> - others?

A good idea (and useful for the users) is to list them in the homepage of each plugin (m1 to begin and m2 ASAP). But we must find
the courage to do it !! I can try to do it little by little for m1 plugins.

Arnaud

> 
> Cheers,
> 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