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: [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]
