Yes. My last job was working for a government-regulated project. The problem was, that they got write-off from the FDA of their build system 10 years ago. There was no way it could change (which is unfortunate, because it sucked). So I wrote a maven front-end to the packaging system, so at least the developers could leverage things like Maven and CVS. However, the project structure still had to interact with that legacy build system for legal reasons. If it weren't for Maven's flexibility in that matter, we never could have used it.
IMO it is enough simply to make it easier to create new projects in a correct way. New projects will tend to do whats easiest at the time. Thats almost a good case for making it complicated and ugly to add multiple steps into a phase via an extension, rather than modifying the phases at its core. But it still needs to be possible for those sad souls who cannot change their project structures at all. Eric On 2/17/06, John Casey <[EMAIL PROTECTED]> wrote: > > BTW, Jesse and I have already had this discussion off-list, but I wanted > to reflect it in the thread. :-) > > > > I couldn't agree more, WRT new projects. Or where people have the > ability to manage their project structures. > > My original example was of two source-generation processes in the same > porject, but in reality this *really* should be split into multiple > projects: > > project-model > project-parser > project-* > > in the same way Maven itself is split up. > > HOWEVER, I think we also need to understand that there are going to be > legacy use cases out there, where people don't have control over the > project structure. If someone can't split up their project like above, > do we want to turn them away at the door? In the past, I think Maven has > tended to focus a little too tightly on new project development. IMO, we > need to be more careful to accommodate these legacy cases in the future. > > To be clear, I don't want to encourage bad project design. I'm very much > against shoving everything into one build just because it's possible. > But, it should be possible, in order to accommodate those users who are > dealing with bad project design that is outside of their control. > > Cheers, > > John > > Jesse McConnell wrote: > > I really wonder about adding in more complexity into the pom with things > > like ordering... > > > > one of the attractions of maven imo is that it facilitates making the > build > > a simple thing, small easily digestable chunks of build process, > leveraging > > the dependency mechanism to weave it all together. Adding in more > phases, > > or ordering within a phase just makes the pom get more and more complex > > which (in my mind) defeats one of the goals of maven... > > > > sure it is technically possible to glom as much as you can into a pom, > but > > understandability goes down quickly and we are left with a process that > > isn't a scads better then the others, like maven is right now IMO. :) > > > > I understand people are really used to combining as much as they can > into > > one building entity, but it that going to be our best practice? > > > > jesse > > > > > > On 2/17/06, John Casey <[EMAIL PROTECTED]> wrote: > >> IMO a consolidation goal is another workaround. It's definitely > possible > >> now, but if we had phase-ordering, we wouldn't need it, right? > >> > >> -j > >> > >> Eric Redmond wrote: > >>> +0 to the pre/post phase. As it has been mentioned a million times > >> before, > >>> what's the difference between the post of one phase, and the pre of > the > >>> next. > >>> > >>> However, I am seeing a need for more than a single execution per > stage. > >> I > >>> like John's suggesting alot. It makes sense. Within a particular > phase, > >> I > >>> have a list of goals that need met. With the pre/post thing, it is > >>> effectively saying "You can have at most three goals met per phase". > >> Another > >>> option is to have some sort of consolidation goal that would then be > >> called > >>> on a phase, whose definition is an ordered list of goals, I kind of > like > >>> this better, as it will keep the syntax cleaner, and honestly, how > often > >> do > >>> you need to cram multiple goals into a phase? One or two at most? > >>> > >>> Eric > >>> > >>> On 2/17/06, John Casey <[EMAIL PROTECTED]> wrote: > >>>> I understand that this is sort of a slippery slope WRT when we stop > >>>> adding new phases. While there are major categories for the phases of > a > >>>> build, things like the following could occur: > >>>> > >>>> 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. > >>>> Maybe the solution is to split the project in two, one -model, and > >>>> another -parser or something. Still, it seems like we're putting a > >>>> band-aid on the problem by adding more phases. Would it be better to > >> add > >>>> control over ordering within a phase? How would that even look in > >>>> syntax? > >>>> > >>>> What do you all think? > >>>> > >>>> -j > >>>> > >>>> 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. 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] > >>>> > >>>> > >> --------------------------------------------------------------------- > >> 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] > >
