On 31/08/2006, at 7:44 PM, Arnaud Bailly wrote:
Questions (which may be trivial) are:
1. Is there one mojo instance for each project in the hierarchy ? I
think this is the case but I am not sure.
The mojo is instantiated every time it is run (so yes, per project,
but also per execution per project).
2. How can I retrieve a mojo instance from another mojo in the same
or a sub project ?
I think the answer is that you can't. All plugin communication is
meant to happen through the project instance.
We certainly need to find a way to make that extensible, but I'd
suggest for now that you should be taking in XML output files that
most plugins generate and processing them for starters.
The various POM's ingredients describes either:
1. data *values*, to be later processed by *functions*: File path
settings, configuration options, project's id card all fall into
this case. These values are organized in a tree such that one can
refer to variable's values using dotted notation (eg.
=foo.bar.baz=)
2. *functions* that process the project's data, that is essentially
plugins (essentiallye mojos), which may themselves be
parameterized by some more
data or values.
Yes, I identified this mix as an issue some time back and we've only
really half talked about it and how it will be addressed. If we get
some momentum on 2.1 design tasks at any point I'll certainly push it
forward again (you can see that in the archives by searching for POM
inheritance).
Thinking that way, one can imagine doing the following things:
- provide a non-XML language layer tha would allow expressing a build
process in an easier to use form than what is actually available
- compile the build program for:
- optimizing the build time
- eventually detecting concurrency pattern such that distributed
execution (eg. using compile farms) coul be provided
Is this plain scrap or has someone else already thought about doing
that kind of things ?
I have seen some people think about it from time to time, but not in
any detail. Definitely worth investigating, particularly as a way of
reviewing how we handle the lifecycle concurrency issues.
Cheers,
Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
