maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Redmond" <eric.redm...@gmail.com>
Subject Re: [discuss] add validate/initialize to site lifecycle
Date Wed, 04 Apr 2007 22:37:14 GMT
How would you know a specific lifecycle then? Something like
default#initialize, versus site#initialize? I'm also not against it, just
curious if people were open to changing the command line. I kind of like
that idea, actually.

On 4/4/07, John Casey <casey.john.d@gmail.com> wrote:
>
> In any case, you're talking about new functionality...wouldn't it be
> better
> to redesign the lifecycle subsystem somehow so phase names don't have to
> be
> globally unique? (I'm not saying that would be simple, but I'm guessing it
> would be less complex for the user.)
>
> -john
>
> On 4/4/07, Brian E. Fox <brianf@reply.infinity.nu> wrote:
> >
> > I think this phase couldn't be invoked from the cli because obviously it
> > wouldn't know which to pick.
> >
> > An alternative solution to all this would be to allow @phase to accept
> > multiples and allow a single execution to be bound to multpile phases.
> > Then we could bind to validate,pre-site.
> >
> > -----Original Message-----
> > From: Eric Redmond [mailto:eric.redmond@gmail.com]
> > Sent: Wednesday, April 04, 2007 11:08 AM
> > To: Maven Developers List
> > Subject: Re: [discuss] add validate/initialize to site lifecycle
> >
> > How would this phase work, in a practical manner? If someone runs the
> > phase, which lifecycle gets executed? Or are you proposing a phase that
> > cannot be explicitly called... like some sort of phase interface?
> >
> > Eric
> >
> > On 4/4/07, Brian E. Fox <brianf@reply.infinity.nu> wrote:
> > >
> > > Right, so we're looking at a 2.1+ thing here. Adding them but changing
> >
> > > the name defeats the whole purpose. Thanks for the info.
> > >
> > > -----Original Message-----
> > > From: John Casey [mailto:casey.john.d@gmail.com]
> > > Sent: Wednesday, April 04, 2007 10:21 AM
> > > To: Maven Developers List
> > > Subject: Re: [discuss] add validate/initialize to site lifecycle
> > >
> > > Max is right, if you add these phases to the site lifecycle (fine by
> > > me, I suppose), they'll have to have different names. This is really
> > > unfortunate, but that's the only way they can be incorporated into
> > > 2.0.x, or 2.1 (without some redesign).
> > >
> > > -john
> > >
> > > On 4/4/07, Max Bowsher <maxb1@ukf.net> wrote:
> > > >
> > > > Brian E. Fox wrote:
> > > > > As Jerome pointed out earlier today on the enforcer thread, it
> > > > > would
> > >
> > > > > be nice to be able to bind some plugins like the enforcer to a
> > > > > phase
> > >
> > > > > that affects both default and site. After all, if you don't want
> > > > > to support some Maven/Jdk/Os/other version, chances are that
> > > > > applies to
> > >
> > > > > sites and reports as well (especially since they might fork to
> > > > > compile aka cobertura etc).
> > > > >
> > > > >
> > > > >
> > > > > Is there any drawback to adding one or both of those to the
> > > > > lifecycle, and if so, what about a new one for both? (although I
> > > > > suspect this is what validate was really intended for)
> > > >
> > > > Maven seems to require that phases be globally unique across all
> > > > lifecycles. DefaultLifecycleExecutor specifically tests for this and
> >
> > > > throws a LifecycleExecutionException if a violation is detected.
> > > >
> > > > Max.
> > > >
> > > >
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For
> > > additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
> >
> > --
> > Eric Redmond
> > http://codehaus.org/~eredmond
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>



-- 
Eric Redmond
http://codehaus.org/~eredmond

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message