Introducing tycho-specific lifecycles is not practically feasible. 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

Reply via email to