In general, the phases available in the lifecycle are controlled. That is,
new plugin developers cannot add phases to the build lifecycle; they can
only bind to existing ones.
I'm not sure whether this will continue to be the case in the future, but I
can say that there is a strong inclination toward this, since it ensures
that the basic commands necessary to perform a build stay the same.
As for the naming of the reactor-scoped lifecycle phases, I agree that the
names above aren't perfect, but I also think that reactor-scoped phases
should be readily apparent to the user. Also, I think there's some value in
overloading the names of the phases (by using a "reactor-" namespace or
something, f.e.) so users who are familiar with the project lifecycle will
know how these new phases fit together to construct the reactor lifecycle.
Personally, I'd love to see something like this:
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<executions>
<execution>
<id>binary</id>
<binding>
<scope>reactor</scope>
<phase>package</phase>
<type>normal</type> <!-- see comments below on this -->
</binding>
<goals>
<goal>assembly</goal>
</goals>
</execution>
</executions>
</plugin>
Now, this (obviously) is non-compatible with a 4.0.0 <modelVersion/>.
However, it expresses a new type of binding that I'd like to explore...we
have the phase, which gives meaning about the type of activity executed
here, and we have a scope, which tells us that this is going to operate in
the reactor-level lifecycle. The <type/> element is related, but new. In all
existing use cases, this would be "normal" or similar. However, in cases
where you want this mojo to execute tear-down semantics, where you want
things to happen regardless of whether the other phase bindings succeed or
fail, you might use:
<type>finally</type>
In other cases, where you would only want a mojo to send notification when
the phase fails, you might use:
<type>catch</type>
This is just a little aside, but I think we have much more to do WRT
refactoring the Maven lifecycle than simply adding a reactor context.
However, I also think it's important to think about the reactor context as a
feature for 4.0.0 modelVersions.
Cheers,
John
On 9/6/06, Wendell Beckwith <[EMAIL PROTECTED]> wrote:
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]
> >
> >
>
>
