I'd imagine that you would use something like 'site#initialize', unless you wanted to use the default lifecycle, in which case you'd just use 'initialize'. Then, I'm not sure whether you'd get into <phases/>. You'd probably have to, particularly if you assume that 'initialize' == 'default#initialize'.
BTW, I'm +1 for calling the default lifecycle the 'build' lifecycle...since it's the only time that you're really building the project. I also think that we should flesh out the other lifecycles to mimic the main/default/build lifecycle, for occasions where you need to do initialization/etc. tasks...I mean, beyond just initialize/validate, where it makes sense. Brian, either way, this looks like something to put in the Maven 2.1 design section: http://docs.codehaus.org/display/MAVEN/Maven+2.1+Design+Documents If you put together a relatively complete proposal for implementing this, we can start discussing it and see about putting it on the road map for 2.1-alpha-N. Thanks, john On 4/4/07, Eric Redmond <[EMAIL PROTECTED]> wrote:
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] > > 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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] > > > 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For > > > additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > -- > > Eric Redmond > > http://codehaus.org/~eredmond > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > -- Eric Redmond http://codehaus.org/~eredmond
