Is ordering necessarily the right way to think about the problem? My usage of Maven is fairly simple, so maybe I'm not really conceptualizing some of the use cases. But I think about more in terms of prerequisites. For instance, I have several assembly tasks that I have attached to the package phase at the moment. For now it seems to work due to luck/pom ordering.
First, I also run dependency:copy-dependencies. If performRelease=true is set, I run an assembly:assembly with a couple of descriptors. One of those is zipping up the result of copy-dependencies. So this goal has dependency:copy-dependencies as a prerequisite. Then I run assembly:directory with another descriptor to create a directory that contains 1) the result of source:jar and javadoc:jar (done automagically with performRelease=true), and 2) the results of the assembly:assembly descriptor. So this goal should really have three prerequisites: source:jar, javadoc:jar, and assembly:assembly The positive side of looking at this way is that it keeps ordering knowledge de-centralized. It would be analgous to a multi-project build: based on prerequisites, Maven would determine the order to execute the plugins that occur during the same lifecycle phase. The downsides are: how would identify a particular execution as a prerequisite? Would you always know your prerequisites, or just that you should always be last (my assembly:directory actually outputs target/*.jar and target/*.zip, for instance). Also I guess you'd probably end up repeating yourself: I'd have to both specify the prereq on javadoc:jar and source:jar, but also declare them (if they weren't automatically down by having profiles with the same activation property+value). Sorry for thinking on e-paper here, but I'm hoping if I go through the whole thought process, you guys with more experience might be able to take more out of it. Looking at my downsides, I have a more extreme suggestion. Rather than specifying executions, and additionally specifying prerequisites, could you just fully specify the prerequisite as a fully-defined plugin/execution within another execution? If this were allowed to be nested, it could solve at least a fair number of use cases. Does the reactor currently handle build-ordering of nested levels of subprojects? Or would this be a new foray into ordering resolution? Anyhow, just my ideas to toss out. Any thoughts? -Stephen On 2/17/06, John Casey <[EMAIL PROTECTED]> wrote: > The more I think of it, the more I dislike this solution, actually. It > simply doesn't address the larger problem, as Raphael inadvertently > pointed out. ;-) > > The only trouble with strict ordering comes with the syntax, and dealing > with the various layers of inheritance and injection. Plugin bindings > can come from: > > 1. packaging lifecycle mapping > 2. parent POM > 3. profiles > 4. POM > 5. (am I missing something?) > > So, any syntax would have to support this layering in a way that > wouldn't be overly confusing. > > FWIW, I think I have a band-aid on my client's project that will work > for the time being. I'd much rather see this stuff fixed correctly soon, > rather than have 10,000 lifecycle phases to support for backward > compatibility later on... > > -john > > Jesse McConnell wrote: > > +1 on this, with a caveat....it is a huge slippery slope that I think we > > ought to be really clear on...especially since Raphaël already took us down > > the slope some more :P > > > > I am +1 for adding these in to address the immediate need with the > > understanding that that is it and revisit the issue for the next layer of > > complexity with some type of ordering maybe.. > > > > Providing a mechansim of strict execution ordering inside of a lifecycle > > phase could address this.. Custom lifecycle phases and goals declared in > > the pom that can be bound by plugins inside of the pom? (icky) Otherwise it > > is just too easy to keep adding on layers of pre and post processing :) > > > > > > my 2cents > > > > -- > > > > to address the axistools pluign, we have discussed this on irc before. it > > is completely reasonable to compile some classes, generate a wsdl off of > > those classes for something like a server side wrapping of webservices and > > then want to generate the client code off of that wsdl.. > > > > but what we decided at the time was that it was also ok to just embed that > > wsdl into the final jar and then in another project process that wsdl out of > > the dependency jar and generate the client code...perhaps that can be > > revisited, but the idea of having to support a compile -> generate sources > > -> compile cycle is not one that has been addressed completely. Especially > > since I have personally written 4 plugins that needed this type of cycle > > already, and just swiped code out of the compiler mojo to do it :P > > > > jesse > > > > > > > > On 2/17/06, Piéroni Raphaël <[EMAIL PROTECTED]> wrote: > >> +1 > >> > >> can you add a post-compile-generate-resources phase ? sometimes a resource > >> is generated (wsdl file) after the compile phase. > >> for example, the axistool plugin needs for the classes to be generated in > >> order to generated the wsdl files from them. and the plugin also try to > >> add > >> it to the resources. > >> > >> Raphaël > >> > >> > >> 2006/2/17, Emmanuel Venisse <[EMAIL PROTECTED]>: > >>> +1 > >>> > >>> Emmanuel > >>> > >>> John Casey a écrit : > >>>> Hi, > >>>> > >>>> I'd like to add pre/post phases for all of the major lifecycle phases > >>>> that don't already have it. I'm starting to see cases where a > >> particular > >>>> packaging maps multiple mojos to the same lifecycle phase, and this > >>>> means we cannot control that phase through the old > >> suppress-and-augment > >>>> approach anymore. I'll give you an example: > >>>> > >>>> Say I have two mojos bound to the package phase, for lack of a better > >>>> place. The first takes the tested code, and assembles the directory > >>>> structure for the archive. The second creates the archive. If I want > >> to > >>>> replace the first step, I can add a 'skip' flag to it, but I *cannot* > >>>> bind a new mojo in its place; any new binding will be added after the > >>>> second step. Obviously, it makes no sense to prepare an archive > >>>> directory structure *after* the archive is created. > >>>> > >>>> This is not the first time we've discussed this sort of thing. We have > >>>> pre/post phases for setup and tear-down of integration tests, and > >> should > >>>> probably have something similar for unit tests...not to mention, > >>>> install, deploy... > >>>> > >>>> It doesn't seem like a good idea to continue addressing this problem > >> an > >>>> issue at a time in successive Maven releases. Why not make a > >> reasonable > >>>> concession to these use cases, and add pre/post phases to each major > >>>> lifecycle phase (those which are themselves pre/post phases are not > >> what > >>>> I consider major). > >>>> > >>>> I'd like to get this into 2.0.3, since it affects some work I'm doing > >>>> for a client. > >>>> > >>>> What do you all think? > >>>> > >>>> -john > >>>> > >>>> --------------------------------------------------------------------- > >>>> To unsubscribe, e-mail: [EMAIL PROTECTED] > >>>> For additional commands, e-mail: [EMAIL PROTECTED] > >>>> > >>>> > >>>> > >>>> > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: [EMAIL PROTECTED] > >>> For additional commands, e-mail: [EMAIL PROTECTED] > >>> > >>> > > > > > > > > -- > > jesse mcconnell > > jesseDOTmcconnellATgmailDOTcom > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
