You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Christian Schulte <sc...@apache.org> on 2016/03/01 01:01:40 UTC
MNG-5799
Before doing anything about it, I'd like to ask here first. Is the Maven
2 behaviour really what should be retained? I would need to revert some
"regression" commits making Maven 3 behave the same way Maven 2 did.
People are reporting the Maven 2 behaviour as being broken
independently. I would not want to do anything about it, if I would need
to revert the changes afterwards.
[1] https://issues.apache.org/jira/browse/MNG-5799
Regards,
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: MNG-5799
Posted by he...@free.fr.
+1 good idea
there are so many cases that I don't think any algorithm can give really meaningfull result, unless we add more fields to describe precisely how to keep a meaningfull order on each merge
trying to summarize the current situation is a good first step
Regards,
Hervé
----- Mail original -----
De: "Christian Schulte" <cs...@schulte.it>
À: "Maven Developers List" <de...@maven.apache.org>
Envoyé: Jeudi 3 Mars 2016 08:27:06
Objet: Re: MNG-5799
<https://issues.apache.org/jira/browse/MNG-5987>
---------------------------------------------------------------------
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: MNG-5799
Posted by Christian Schulte <cs...@schulte.it>.
<https://issues.apache.org/jira/browse/MNG-5987>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: MNG-5799
Posted by Manfred Moser <ma...@simpligility.com>.
I would NOT do any work on this in 3.x. From all I know more control over the plugin execution order is part of the work on 4.x so until that comes out I would not do any work to adjust how 3.x beha=
ves compared to 2.x. Better spend it on the work to make it better towards 4.x.
After all 2.x is deprecated...
Manfred
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: MNG-5799
Posted by Christian Schulte <sc...@apache.org>.
Am 03/01/16 um 20:47 schrieb Robert Scholte:
> If many projects suddenly break we should really decide if this is worth
> implementing or that we need to teach our users to RTFM ;)
That's not documented anywhere. People order the plugin declarations
intuitively. Current behaviour is the result of patching Maven 2 to
preserve some order as requested by users (JIRA issues) and later
patching Maven 3 (which behaved differently) to behave the same way
Maven 2 did. Goal would be to stop people from reporting such issues. I
am not sure if just documenting the current behaviour is what should be
done. It's not behaving as people expect. So maybe we should make it
behave the way people expect it and document that instead. Just closing
those issues "Not a problem" will not stop getting the same reports a
few weeks later again.
Regards,
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: MNG-5799
Posted by Robert Scholte <rf...@apache.org>.
Is the main issue that a lifecycle bound plugin always goes first?
Going through the issues it seems more about controlling plugin execution
orders with regard to plugin & pluginManagement, parent plugin &
pluginManagement, profile plugin & pluginManagement.
IMHO that's a much more critical issue, but that requires modifications to
the pom schema.
I didn't see all the usecases, but I noticed one about starting a server
during test. That's wrong! Either start it as part of the (JUnit) test are
use the pre-integration-test to start a server, stop it during
post-integration-test.
In one of the Jira issues Benjamin says that that lifecycle bound plugins
are handled a bit differently compared to other plugins. The details are
missing but it probably holds the key to its current behavior.
I would do *a lot of* testing when trying to change this, maybe it reveals
the reason.
If many projects suddenly break we should really decide if this is worth
implementing or that we need to teach our users to RTFM ;)
my 2c,
Robert
On Tue, 01 Mar 2016 01:01:40 +0100, Christian Schulte <sc...@apache.org>
wrote:
> Before doing anything about it, I'd like to ask here first. Is the Maven
> 2 behaviour really what should be retained? I would need to revert some
> "regression" commits making Maven 3 behave the same way Maven 2 did.
> People are reporting the Maven 2 behaviour as being broken
> independently. I would not want to do anything about it, if I would need
> to revert the changes afterwards.
>
> [1] https://issues.apache.org/jira/browse/MNG-5799
>
> Regards,
>
> ---------------------------------------------------------------------
> 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