On Mon, Sep 5, 2011 at 2:32 PM, Igor Fedorenko <i...@ifedorenko.com> wrote: > Introducing tycho-specific lifecycles is not practically feasible.
That's not what I was suggesting. I was suggesting the use of a convention on execution id's as a way of allowing order control. I also was musing about signed-eclipse-plugin versus just eclipse-plugin, but that's insane. All > lifecycle phase names must be globally unit across all lifecycles, which > means we'd have to invent "tycho-compile", "tycho-validate" and so on. > This means we'd have to explain these new names to Tycho users. Many > standard maven plugins used by Tycho default lifecycle have @phase > annotations, which will likely cause at least some problems if these > plugins were used with Tycho-specific phase names. > > skip flag does not work either, because at least signing has to be > pluggable. > > -- > Regards, > Igor > > On 11-09-05 7:44 AM, Benson Margulies wrote: >> >> On Sun, Sep 4, 2011 at 10:48 PM, Igor Fedorenko<i...@ifedorenko.com> >> wrote: >>> >>> I agree that adding new phase (or phases) does not look like a scalable >>> solution. For example, in addition to signing, >> >> Tycho could add more lifecycles. Since those are selected by >> 'packaging', however, and not variable by profile, it would be very >> cumbersome. What seems to be wanted here is a concept of optional >> lifecycle segments. Tycho could lay out signing and pack200-ing, and >> then users could turn them on and off. >> >> Is one way to do that is to put them in the lifecycle with skip=true >> configuration, and document for users to flip to skip=false on the >> correctly-named execution to turn them on? I'm assuming that there is >> some way for lifecycles to add<configuration> for the plugins they >> call out, even if the Tycho lifecycle does not. >> >> Another thought: If lifecycles can assign ids to plugin executions, >> could they simple specify an id with no plugin? This would, in >> essence, allow a lifecycle to add phases. A plugin execution whose id >> started with one of these would be sorted into the plan at that point. >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
