If you've done the work, go ahead and submit a patch. I think I'll
find the code easier to read than this mail :)
I think we definitely need a solution to being able to know in
advance of the build, how all the source directories, etc will be
bound in (Milos has been asking for this in the Netbeans integration
for some time too). Hopefully this will help.
- Brett
On 05/09/2006, at 6:21 AM, Wendell Beckwith wrote:
I was hoping to get some discussion going about
http://jira.codehaus.org/browse/MNG-2546. For handling eclipse
plugins this
is a big issue. I really see this as extending the support that maven
provides to single project builds to multi-project builds. A lot
of plugins
dynamically add information to a MavenProject instance such as new
source
paths, dependencies, resources, etc. These plugins can typically
do their
job by binding to a phase before the information is needed. Plugins
functioning in multi-project reactor builds need the same thing but
maven
does not provide a phase to bind to before the reactor build is
kicked off.
I have fixed this for the maven 2.1 trunk and passed all 101
tests. Do I
need to submit a patch now or is this consider blasphemous and it
needs to
be aired out a little bit in discussion?
For those who are interested I extended the LifecycleExecuter
interface and
added a method that will do reactor builds for a single phase,
super-init.
The ReactorManager picked up a new method, sortProjects(List
projects) that
sorts the projects and I removed the final modifier from the sorter
attribute because if the super-init phase is executed then we need the
ability to reset the field with a new ProjectSorter instance. The
Lifecycle
class has methods getPhases() and getDefaultPhases(), however the
getPhases() method would create and set a new empty list if the
attribute
was null while the getDefaultPhases() method would just return
null. I
changed the getDefaultPhases() method to work similar and it now
creates and
sets an empty map if the attribute is null. The
DefaultLifecycleExecutor
was changed to extend my LifecycleExecutor extension and implement the
executeSuperInit() method. The executeSuperInit() method creates a
single
goal, super-init, and then executes it. A <lifecycle> element with
the id,
super-init and a single phase also named super-init was added to the
components.xml. The phase has no plugin bindings. Finally the
DefaultMaven
class has picked up a method to check if any projects in the
reactor has
plugin execution bindings to the super-init phase. If so then the
LifecycleExecutor is called to execute the super-init phase and
then if
there are no errors the reactor's projects are resorted and normal
reactor
processing kicks in. This is all 100% backwards compatible because
unless
you bind a plugin to the phase then the extra processing won't
happen and it
will be business as usual.
Right now this is working great, but is it a direction maven
intends to
support?
Wb
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
