The Parent POM section reads a bit confusingly because it uses "Ahead"
both times, but you've switched the order of the POMs :)
I'm trying to understand what the real scenario is where there is a
"child" POM that doesn't declare it's parent? Could that just be
declared as a build failure/warning? I think modules really needs to
reflect the hierarchical relationship - and it's an easier problem to
attack than to change the order if that scenario is used.
With regards to the assembly - we probably need to look at some
alternative ways to attack that problem.
For me, the main things I think we should focus on with plugin
lifecycle are:
- assembly lifecycle (perhaps related to the aggregator changes you
propose)
- decent integration of code coverage plugins (we never got this
forked lifecycle quite right)
I'm not sure about the aggregator changes - I realise the problems you
describe, but will need to give it more thought - I think more digging
on the proposed solutions will be needed, referring to an example as I
had trouble visualising it from your description (I may just need more
coffee :).
Build introspection is a good thing, some thoughts:
- this would enable guarded mojo execution too
- I don't think legacy mojos is a big deal - you just miss some
information you never had - just need to make sure that things assume
the information is always partial (since plugin devs will be lazy
sometimes too) - as long as it still provides correct results (or
correct based on knowledge given) I think this is ok.
- I think annotations are a good idea, possibly with additional
interfaces so that you can code the conditional logic necessary if the
annotations don't suffice (so, a combo of the two proposals)
- I think an alternative way to look at this might be to structure
mojo execution such that you can essentially run it in dry run (so you
can run the whole build, just not affect anything). This would
unfortunately significantly affect mojo design, however - but worth
thinking about how it might help for the more complicated logic cases.
Given all this, I think the 3 proposals can actually be split up into
separate documents.
Thanks John!
Cheers,
Brett
On 14/02/2008, at 9:34 AM, John Casey wrote:
Hi,
I'm trying to document some of the design problems with sort of
exotic plugin use cases, things like aggregation and use of $
{reactorProjects}, that we're running into under the current setup.
I have proposals to address most of the issues, but I'd love to hear
what you would propose...or even tell me about plugin-design issues
that I haven't thought of.
I'd really like to take a whack at the bigger problems for 2.1, but
if that doesn't happen, 2.2 is a fine target for me, as long as we
start the discussion now. We have a lot of experience with what
works and what doesn't from 2.0.x, so let's take advantage of that
to see what we got wrong, and how we can correct it.
The page is here:
http://docs.codehaus.org/display/MAVEN/Atypical+Plugin+Use+Cases
Thanks in advance,
-john
---
John Casey
Committer and PMC Member, Apache Maven
mail: jdcasey at commonjava dot org
blog: http://www.ejlife.net/blogs/john
rss: http://feeds.feedburner.com/ejlife/john
--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
