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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
