This is a way better idea than what I had. I did see the need in the future
to adding additional phases to the super-init lifecycle, but I really like
the idea of moving the reactor to it's own lifecycle and letting plugins
bind before and after in an extensible fashion. One thing, I think should
also be fixed is that lifecycle phase names are global and instead they
should be scoped. In keeping with the maven conventions lifeclycles should
have a groupId. This will allow other people to have generate-resources,
package etc without coming up with foo-package and bar-package just to work
around this issue.
Wb
On 9/6/06, John Casey <[EMAIL PROTECTED]> wrote:
I've actually been thinking about the need for pre-reactor phases a little
differently, actually. In the assembly plugin, we currently have an issue
where assemblies which are attached to the top-level POM and which require
the binaries of the module projects will not work well. The reason is a
quirk involved with when the parent project for a given module gets built
vs. when the module itself gets built. The short story is that the parent
must be processed prior to building the child, and yet the parent requires
the child to complete its own assembly - so you have a sort of chicken and
egg. The assembly really needs the children to be processed ahead of its
own
construction, so it becomes necessary to execute:
mvn package assembly:assembly
in order to first create the child binaries, then construct the assembly
using them.
This has bearing on the present conversation in that the assembly plugin
*actually* needs to execute in a super-context of any given project build.
To some extent, we tried to address this issue with @aggregator plugins,
but
as you can see, this attempt has failed pretty miserably. I believe the
super-init phase discussed here and in MNG-2546 is a similar super-context
issue.
I propose that instead of putting in a single, hard-coded phase for
pre-reactor binding, we should address this using scoped build contexts.
In
other words, provide a reactor-level lifecycle, in which one phase
executes
the lifecycles of all modules. This will allow us to preserve some level
of
declarative ordering in the reactor-specific lifecycle, so we can also
express the ways in which pde or assembly plugins bind relative to one
another, and to the module builds.
So, using this, we might have a lifecycle that looks sort of like this:
- reactor-init
- reactor-start
- reactor-build
- initialize
- validate
- generate-sources
[...]
- package
[...]
- verify
- reactor-stop
- reactor-assemble
( - reactor-install/deploy/distribute/publish )
- reactor-verify
- reactor-dispose
Binding to this sort of reactor context would allow a plugin to specify
it's
place in the larger build, or (as it can do now) in the build of an
individual module. I have gripes to share about the binding syntax, and
some
other nifty things we should be looking at WRT the lifecycle's semantics,
but I believe the above reactor-context lifecycle could be implemented
without changing the POM syntax at all.
I'd much prefer exploring an extensible approach to binding outside of the
reactor, rather than targeting a solution at this single use case. We have
a
chance to fix problems that are occurring in the assembly and clover
plugins
as well, I believe.
Cheers,
John
On 9/5/06, Jason van Zyl <[EMAIL PROTECTED]> wrote:
>
>
> On 5 Sep 06, at 2:55 AM 5 Sep 06, Milos Kleint wrote:
>
> > On 9/5/06, Wendell Beckwith <[EMAIL PROTECTED]> wrote:
> >> On 9/4/06, Brett Porter <[EMAIL PROTECTED]> wrote:
> >> >
> >> > 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 :)
> >>
> >>
> >> Done. Yeah, the email was verbose but the code changes were
> >> simple once I
> >> found where the reactor was located.
> >>
> >> 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.
> >>
> >>
> >> I can imagine wanting to plug into maven before it gets going and
> >> after it
> >> has stopped. The current patch only handles the initialization
> >> phase but it
> >> would not be too much more to add a finalization phase too. I
> >> doubt it
> >> would be possible/practical to try and know how everything will
> >> eventually
> >> shake out ahead of time. Instead it would be more practical to allow
> >> plugins/external entities to register as framework listeners and
> >> notify them
> >> of certain events. Thus if a new source root is added the IDE
> >> could be
> >> informed and it could take the appropriate action, whatever that is.
> >>
> >> Wb
> >>
> >>
> >
> > I'm not sure I understand how the MNG-2546 issue is related to what I
> > need in the IDE. let me reiterate my requirements.
>
> For what we were talking about it might be the place where plugins
> offer up all the information they have so that you can update any IDE/
> UI settings that might want. So what's been plugged in there is an
> information gathering phase, similar to what could be added at the
> end of the default lifecycle. I think I might alter this patch a bit
> but it is a good idea and one that existed long ago in maven 1.x
> where you could bind to a pseudo goal that executed before any other
> build related goals.
>
> > 1. find out what the source roots are (even if not existing yet) for a
> > given project without executing it. That sort of points in the
> > directtion of declaratively marking some mojo parameters as source
> > roots and making it available from the mojo descriptions.
> > 2. plugging into the maven execution cycle from the IDE is already
> > possible. A simple method is to register the loggers, a more advanced
> > one is to replace plexus components with custom, proxying versions of
> > my own that do additional bookkeeping. It wouldn't hurt to make it
> > easier but it's generally possible.
> > 3. I want to keep the actual building as separated from the IDE
> > environment as possible. This might sound contrary to 2. but is
> > actually complimentary. I want a peek tool into the project definition
> > (2), but the actual process of execution shall be untouched(3).
> > Additionally one might want to have multiple versions of maven to
> > execute in the IDE environment at once (in case of some binary
> > incompatibility). That's where having the IDE's build to depend on one
> > particular version could hurt.
> >
> > Milos
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
> Jason van Zyl
> [EMAIL PROTECTED]
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
