Hello Anders, I was the one who triggered the mail from Jason as I and lot of other people had the same kind of questions than yours :) The net conclusion I came up to is that if you want to do something with custom lifecyles, you jsut have to live with the three lifecycles that exists right now: default, clean and site.
Apart from the name problem, this is not really an issue: just pretend that compile = install, install = overlay, ... and everything will be ok. Also, there may some confusion between phases naming and mojo naming: It would have been better to name the phases 'phase1' 'phase2' ... You can think in terms of "programs" and "functions": a mojo is a function, a phase and a lifecycle are programs. You have more than enough phases to create complex lifecycles. Actually, from a a theoretical point of view, as a plugin can trigger a lifecycle, I think you just need 2 phases to create a complex build tree ! As usual, I am not aware of your particular problem but what I would do would be to just stick to the default lifecycle, bind your mojos to it and don't care to fork lifecycles within the mojo themselves (it is always possible to do the binding in the pom) and use your custom packaging as the example you gave us. HTH -- OQube < software engineering \ génie logiciel > Arnaud Bailly, Dr. \web> http://www.oqube.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
