This reply grabs bits from everywhere and summarises. John Casey wrote: > Hi, > > I'd like to add pre/post phases for all of the major lifecycle phases > that don't already have it.
For the record, I'm against this as the solution based on the thread so far. Some basic reasons before going into details: 1) pre/post is wrong in general, as pre-two = post-one. So we should have one phase between, but there we need an appropriate name. Likely this is something sensible and becomes a new lifecycle phase - just like we have now. Then we later discover that needs pre/post, and so on :) I think this really degrades to prereqs and pre/post goals that we had in m1/pre-alpha m2, which we eliminated for good reasons. 2) Some of this discussion around rearranging the lifecycle defeats the actual purpose of the lifecycle in the first place > 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. If you have a problem with suppress and augment as you've coined it, I'd suggest your packaging might be too granular. Maybe you need a couple of different packaging types? > Say I have two mojos bound to the package phase, for lack of a better > place. This is a common example picked because I think we are missing the prepare-package phase. > It doesn't seem like a good idea to continue addressing this problem an > issue at a time in successive Maven releases. Actually, I think we should. That means we carefully assess each one and take care in adding it. > I'd like to get this into 2.0.3, since it affects some work I'm doing > for a client. Since you have a workaround, I'd prefer we look at the proper solution for 2.1. I had great reservations about allowing this for integration tests in 2.0.2. Piéroni Raphaël wrote: > can you add a post-compile-generate-resources phase ? sometimes a resource > is generated (wsdl file) after the compile phase. I thought we established this could just be generated directly to the resources target. [MOJO-143] Jesse McConnell wrote: > Providing a mechansim of strict execution ordering inside of a lifecycle > phase could address this.. We already have an ordering (by inheritence, with profiles last, executions are in pom declared order within a phase). This is possibly limited. I think one of our items for 2.1 was to make this easier to specify and possibly order. But I'm worried about jumping in and out of things in different POMs within a phase. It seems wrong. John Casey wrote: > I generate a model using Modello, and would like to use my own custom > Antlr grammar to create instances of that model. > > Both should fit in generate-sources, but there's a definite order here. Sorry, don't understand what the order is here (what is "creating an instance of the model"?) > Maybe the solution is to split the project in two, one -model, and > another -parser or something. This is a possible solution we should be considering in some cases, I think. John Casey wrote: > I'm not sure that's enough, actually. There will be times (there already > are) when people will want to set a flag that suppresses the default > mojo for a particular phase in the lifecycle mapped by a packaging, then > substitute in their own. While I don't like this, it might be a useful inclusion. I'd like to see more specific examples - I'm worried that the things being excluded are only doing so because the original mojo over-reached its duties (rather than sensible defaults, it assumed too much about your environment and isn't configurable enough). Ok, to track back over this a bit, there are a few issues: 1) needing to exclude lifecycle phases * I'd prefer not to. I think the packaging may be over reaching or the involved mojos not configurable enough. Would like to see more examples. 2) ordering of lifecycle phases * Do not want to customise the order of *phases*, that defeats the purpose. * It appears sometimes there are multiple iterations of the same phases (the axis example), see below. 3) ordering of goals in phases * we already have this within a pom. We need examples of reasons it needs to be ordered through inheritance (including profiles) in a way that doesn't match the current parent first ordering. * we have scope to improve this in 2.1 as we wanted to reassess at least the declaration of goals. Ok, things you can do to address issues here, some already mentioned: 1) split your project into two things. Sometimes this iterations indicate you are building two different things with a dependency between them 2) introduce a goal in the lifecycle that forks a new lifecycle to do the generate, compile stage, then continue with generate, compile. This is a form of iteration. 3) You can use compound goals to enforce ordering. This is similar to 2 in some ways. I don't think this is too hacky under the current arrangement. 4) We can explicitly allow iteration in 2.1. I think we already have other use cases for this - eg to create both a regular jar and a debug version of the jar every time. I'm not sure if this covers the axis example though - maybe that is still done by (2). 5) We can improve the declaration of 1, 2, 3 in 2.1. I suggest we try and make all our use cases work under (1), (2), (3), and then aim to simplify them as a review of the lifecycle in 2.1 (we also want to review forking in general, as it causes too much execution in some instances). How does this sound? - Brett --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
