You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Brian Topping <to...@codehaus.org> on 2006/11/01 05:02:43 UTC
Re: Plugin execution ordering within a phase
Hi Kenney,
Thanks for your thoughts on this. I like most all these ideas.
Comments inline.
On Oct 31, 2006, at 12:25 AM, Kenney Westerhof wrote:
>
> Brian Topping wrote:
>
> Hi,
>
> there's a bug in maven 2.0.4 for the plugin ordering. It uses a Set.
> This is fixed in SVN (LinkedHashSet that preserves ordering), and will
> be available in 2.0.5 and 2.1.
I hope that the patch for MNG-2626 can make it in for 2.0.5, it's a
very simple test case that needs to be cooked for it (system scope
dependency in parent POM) so I'll try to get that done today after
all the other fires are put out (this being one of them).
>
> Thinking about this, it may be a too harsh limitation of M2:
> plugins are meant to
> be independent of eachother, so you really shouldn't have to
> execute several plugins
> to achieve 1 task, or even set up something specific for another
> plugin.
With the focus on having a test for everything that is committed, I
would hope there is an integration test that went in for this to make
sure that the plugins run in the order they are in the POM, then none
of the other stuff should be necessary.
>
> Looking at the assembly/debian plugin problem, a solution could be
> to support the debian packaging in the assembly plugin, perhaps by
> specifying a <dependency> in the assembly plugin declaration; the
> dependency would
> have a components.xml for a .deb archiver. I'm guessing there's a
> lot more to it though.
Maybe not a lot actually. The two do go together, but there's a lot
of potential configuration possible with the assembly plugin, causing
potential overlap between them.
>
> Another way would be to fix/extend the assembly plugin to be able
> to point to the original locations used by the assembly plugin to
> create the structure.
>
> I agree that this poses some limitations (no dependency-unpack
> calls) and you probably have other structures like this for other
> plugins.
>
> Maybe the lifecycle should be extended with a prepare-package phase
> before package,
> and possibly a process-package phase afterwards?
This is another good idea because there are issues like this to be
resolved around packaging, although extending the lifecycle because
of limitations in the lifecycle processing place an additional burden
on new users trying to absorb the system. It's nothing that better
documentation couldn't solve though. It just depends on the primary
target audience and who we want to cater to.
-b
>
> -- Kenney
>
>
>> Greetings,
>> I'm having a problem using assembly plugin to create a work
>> directory for another plugin (the debian plugin). I started off
>> by putting these plugins in different phases to force the order,
>> but as the project has evolved, this has become unworkable because
>> there are no open phases left that are a good place to put these
>> different plugins. The two plugins are ordered as they should be
>> run in the POM file, but they execute in the opposite order.
>> As a really flimsy hack, I tried reversing the order of the two,
>> but they still execute in the wrong order.
>> I'm not at all convinced that the right way to be doing this is to
>> make a plugin that executes two plugins.
>> It seems like the right thing to be doing here is for the <plugin>
>> elements to have an <order> element, but it would require a
>> different POM schema. Not easy to do.
>> Thoughts?
>> Brian
>> ---------------------------------------------------------------------
>> 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
MNG-2626 (was Re: Plugin execution ordering within a phase)
Posted by Brian Topping <to...@codehaus.org>.
On Nov 1, 2006, at 1:03 AM, Kenney Westerhof wrote:
> Brian Topping wrote:
>> I hope that the patch for MNG-2626 can make it in for 2.0.5, it's
>> a very simple test case that needs to be cooked for it (system
>> scope dependency in parent POM) so I'll try to get that done today
>> after all the other fires are put out (this being one of them).
>
> I'll comment on the issue - the patch is not taking the right
> approach IMHO.
I'd definitely be interested in how it could be done better in a
reasonable amount of time. I know people are talking about other
solutions to this problem, but our team here is blocked on this
issue. Take the patch out and our build dies.
The key goal of this patch is it is localized and easy to remove if/
when someone with a different approach decides to spend the time on
it. I don't see any other bugs on this and can't imagine that it has
any priority. It's just too much of an edge case. Having said that,
I took a balance between getting the bug fixed, making it easy to
remove when the time is right, and not spending time on a solution
that others have already started. It's a good solution given the
constraints.
I have the build that demonstrates the problem working, just waiting
for Jason to get some time to help me turn it into an integration test.
-b
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Plugin execution ordering within a phase
Posted by Aa...@Globus.ch.
> > There's just one problem - inheritance. Should plugins/executions
> > defined
> > in the parent be placed before or after the ones in the child pom?
> > I'd say before, but maybe they need to be interleaved..
>
> This is where an <order> element makes a lot of sense. The order
> doesn't have to be sequential integers, you just sort whatever you
> have from all the inherited POMs.
In the AROS project, we use MetaMake (a tool which we developed
ourselves). Basically, in MetaMake, you can depend on targets defined
elsewhere in the project.
In the first pass, MM collects all meta-targets and then looks for targets
which don't depend on anything else. These are run. Now all dependencies
to these are deleted and the cycle starts again until everything is built.
This is very easy for the developers to handle: They just say "run me
after Xyz". This feels natural and is easy to implement without assigning
priorities.
Cycles are easy to detect in MM (set a flag which gets cleared if
something could be built and check the flag after one cycle) but they
appear very rarely, so this solution works pretty well for us.
Therefore, I suggest using a "depends" or "after" element so maven can
build the dependency chains for us instead of developers having to think
about the ordering of the whole process.
I guess there are two types of these dependencies:
goal/phase: Do the build step after a specific goal or phase has
completed.
id-based: Devs should be able to assign IDs to plugins, so you can say
"before you run me, run that first" in your pom.
One could argue that the latter ones could be dangerous when their POMs
get installed in the maven repo. I'm not sure if that's really an issue,
though. Most of the time, these dependencies will be necessary for
internal (complex) projects which don't get deployed. Also, if I
understand this correctly, maven doesn't import build instructions from
dependencies (only parent POMs), so we need only care about parent POMs.
How hard would it be to make sure parent POMs in the maven repo don't use
this feature?
(Note: The parent-POM problem is not related to my solution!)
Regards,
--
Aaron Digulla
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Plugin execution ordering within a phase
Posted by Brian Topping <to...@codehaus.org>.
On Nov 1, 2006, at 1:03 AM, Kenney Westerhof wrote:
> Brian Topping wrote:
> There's just one problem - inheritance. Should plugins/executions
> defined
> in the parent be placed before or after the ones in the child pom?
> I'd say before, but maybe they need to be interleaved..
This is where an <order> element makes a lot of sense. The order
doesn't have to be sequential integers, you just sort whatever you
have from all the inherited POMs.
>
>>> Looking at the assembly/debian plugin problem, a solution could
>>> be to support the debian packaging in the assembly plugin,
>>> perhaps by
>>> specifying a <dependency> in the assembly plugin declaration; the
>>> dependency would
>>> have a components.xml for a .deb archiver. I'm guessing there's a
>>> lot more to it though.
>> Maybe not a lot actually. The two do go together, but there's a
>> lot of potential configuration possible with the assembly plugin,
>> causing potential overlap between them.
>
> Yeah, I can imagine that. Maybe we could add some archiver specific
> configuration
> section to the assembly descriptor, like <archiver type="deb">...</
> archiver> to set
> archiver specific settings..
Makes sense.
>>> Maybe the lifecycle should be extended with a prepare-package
>>> phase before package,
>>> and possibly a process-package phase afterwards?
>> This is another good idea because there are issues like this to be
>> resolved around packaging, although extending the lifecycle
>> because of limitations in the lifecycle processing place an
>> additional burden on new users trying to absorb the system. It's
>> nothing that better documentation couldn't solve though. It just
>> depends on the primary target audience and who we want to cater to.
>
> True. We just need to get a hold of a lot of 'real world' usecases
> to see
> what's the best approach here. But for now I think the plugin
> ordering fix
> should solve most problems.
Agreed.
>
> Btw, in the jira issue you said you built a maven version for your
> company;
> I assume 2.0.5? Does it indeed solve the ordering (as there's no IT
> for it)?
Eh? I thought all fixes needed tests? Or is that just for people
without karma? Yeesh! :-)
In any event, the IT test for this needs to run the same plugins from
two different POMs in different order so as to confirm that the
natural hash order does not accidentally coincide with the order of
the test and give a false positive.
:b
>
> -- Kenney
>
>
>
>> -b
>>>
>>> -- Kenney
>>>
>>>
>>>> Greetings,
>>>> I'm having a problem using assembly plugin to create a work
>>>> directory for another plugin (the debian plugin). I started off
>>>> by putting these plugins in different phases to force the order,
>>>> but as the project has evolved, this has become unworkable
>>>> because there are no open phases left that are a good place to
>>>> put these different plugins. The two plugins are ordered as
>>>> they should be run in the POM file, but they execute in the
>>>> opposite order.
>>>> As a really flimsy hack, I tried reversing the order of the two,
>>>> but they still execute in the wrong order.
>>>> I'm not at all convinced that the right way to be doing this is
>>>> to make a plugin that executes two plugins.
>>>> It seems like the right thing to be doing here is for the
>>>> <plugin> elements to have an <order> element, but it would
>>>> require a different POM schema. Not easy to do.
>>>> Thoughts?
>>>> Brian
>>>> -------------------------------------------------------------------
>>>> --
>>>> 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
>
> ---------------------------------------------------------------------
> 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: Plugin execution ordering within a phase
Posted by Kenney Westerhof <ke...@apache.org>.
Hi,
Comments inline.
Brian Topping wrote:
> Hi Kenney,
>
> Thanks for your thoughts on this. I like most all these ideas.
> Comments inline.
> On Oct 31, 2006, at 12:25 AM, Kenney Westerhof wrote:
>> Brian Topping wrote:
>>
>> Hi,
>>
>> there's a bug in maven 2.0.4 for the plugin ordering. It uses a Set.
>> This is fixed in SVN (LinkedHashSet that preserves ordering), and will
>> be available in 2.0.5 and 2.1.
>
> I hope that the patch for MNG-2626 can make it in for 2.0.5, it's a very
> simple test case that needs to be cooked for it (system scope dependency
> in parent POM) so I'll try to get that done today after all the other
> fires are put out (this being one of them).
>
I'll comment on the issue - the patch is not taking the right approach IMHO.
>> Thinking about this, it may be a too harsh limitation of M2: plugins
>> are meant to
>> be independent of eachother, so you really shouldn't have to execute
>> several plugins
>> to achieve 1 task, or even set up something specific for another plugin.
>
> With the focus on having a test for everything that is committed, I
> would hope there is an integration test that went in for this to make
> sure that the plugins run in the order they are in the POM, then none of
> the other stuff should be necessary.
Yup, we definitely need an integration test for this.
There's just one problem - inheritance. Should plugins/executions defined
in the parent be placed before or after the ones in the child pom?
I'd say before, but maybe they need to be interleaved..
>> Looking at the assembly/debian plugin problem, a solution could be to
>> support the debian packaging in the assembly plugin, perhaps by
>> specifying a <dependency> in the assembly plugin declaration; the
>> dependency would
>> have a components.xml for a .deb archiver. I'm guessing there's a lot
>> more to it though.
>
> Maybe not a lot actually. The two do go together, but there's a lot of
> potential configuration possible with the assembly plugin, causing
> potential overlap between them.
Yeah, I can imagine that. Maybe we could add some archiver specific configuration
section to the assembly descriptor, like <archiver type="deb">...</archiver> to set
archiver specific settings..
>> Another way would be to fix/extend the assembly plugin to be able to
>> point to the original locations used by the assembly plugin to create
>> the structure.
I meant fix the debian plugin/extend the assembly plugin here..
>>
>> I agree that this poses some limitations (no dependency-unpack calls)
>> and you probably have other structures like this for other plugins.
>>
>> Maybe the lifecycle should be extended with a prepare-package phase
>> before package,
>> and possibly a process-package phase afterwards?
>
> This is another good idea because there are issues like this to be
> resolved around packaging, although extending the lifecycle because of
> limitations in the lifecycle processing place an additional burden on
> new users trying to absorb the system. It's nothing that better
> documentation couldn't solve though. It just depends on the primary
> target audience and who we want to cater to.
True. We just need to get a hold of a lot of 'real world' usecases to see
what's the best approach here. But for now I think the plugin ordering fix
should solve most problems.
Btw, in the jira issue you said you built a maven version for your company;
I assume 2.0.5? Does it indeed solve the ordering (as there's no IT for it)?
-- Kenney
>
> -b
>
>>
>> -- Kenney
>>
>>
>>> Greetings,
>>> I'm having a problem using assembly plugin to create a work directory
>>> for another plugin (the debian plugin). I started off by putting
>>> these plugins in different phases to force the order, but as the
>>> project has evolved, this has become unworkable because there are no
>>> open phases left that are a good place to put these different
>>> plugins. The two plugins are ordered as they should be run in the
>>> POM file, but they execute in the opposite order.
>>> As a really flimsy hack, I tried reversing the order of the two, but
>>> they still execute in the wrong order.
>>> I'm not at all convinced that the right way to be doing this is to
>>> make a plugin that executes two plugins.
>>> It seems like the right thing to be doing here is for the <plugin>
>>> elements to have an <order> element, but it would require a different
>>> POM schema. Not easy to do.
>>> Thoughts?
>>> Brian
>>> ---------------------------------------------------------------------
>>> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org