I answer more tomorrow, but for now here's a blog on making a custom lifecycle.
http://www.sonatype.com/people/2009/08/create-a-customized-build-process-in-maven/ On Feb 20, 2010, at 5:20 PM, tbee wrote: > > > > jvanzyl wrote: >> >>> The migration to Maven is not because I want to migrate one of my >>> projects; >>> I'm setting up the development toolchain for our company, using one of >>> our >>> more complex projects as the testcase. >>> >> >> As the first test case? >> >> By yourself, with a team? >> > > Yes. > Small team; 3 people, I'm the lead. > > > jvanzyl wrote: >> >> >>> I've initially tested Maven 2 about half year ago, and I found it >>> complex. >> >> Relative to what? >> >> > > The build environments so far, notably ANT. We've got a infrastructure on > ant; the actual build files are composed using a library of preconfigured > Ant tasks with the option to override. We also have default target names > quite similar to Maven's phases. We lack good dependency management; the > artificats are simply checked into the source control. > > > > jvanzyl wrote: >> >> >> is the majority of the time not fiddled with by developers >> >> > > We are -as a company- not that big, and developers often work fairly > autonomously on their projects. Sometimes in pairs of threes. So they often > will setup their build environment themselves. > > > > jvanzyl wrote: >> >> >> if you stepped back objectively and looked at your Ant build scripts I >> think you will find they are just, if not more, complicated to the average >> person. >> >> > > Ant build script can get messy indeed, so -as you need to do with code- you > need good practice. For us this is a lot of imports or call-outs in the > build. The actual builds scrips are targets with imports of the > preconfigured tasks. > > > > jvanzyl wrote: >> >> >> A well setup project that is vetted by a team lead, where the dependencies >> are managed internally by a repository manager and corrections made to >> protect the team from the bad metadata in Maven Central, which is >> currently unavoidable given the nature of how we've allow artifact >> submissions to date, then your team members should onboard as you did >> given your environment doesn't change underneath them. >> >> > > Yes. Well, we are not that big and don't really do huge multi team projects. > So maybe that is where our difference in perspective lays. > > > jvanzyl wrote: >> >> For phases, this is encapsulated inside plugins, and further more in >> packaging lifecycles. And even further with mixins in 3.x. But I >> categorically disagree that executions for particular environments should >> be encapsulated in plugins. Then you're dealing with the interactions of N >> plugins trying to do this and you wind up with a mess. >> > > Let me give you an example. We have a swing application delivery method > similar to "onejar", but with a few twist, so that is why it is custom. In > essence it is identical to onejar: it includes all dependency jars and the > actual jar in one deliverable. It should run during packaging but after the > artifact jar is created. The plugin has a clear execution moment. It would > be great that the user doesn't need to concern himself with that. > > > > jvanzyl wrote: >> >> Lots of Maven plugins do, but this is where we can't control everything >> even without the Maven project itself the quality varies wildly. >> > > Agreed, we're talking about my own custom plugin. I'm in control there. > > > jvanzyl wrote: >> >> You can expose as much or as little as you want. If you come up with >> common patterns for a particular flavor of development you can hide it all >> with a lifecycle if that's what you're trying to do with your team. It >> might be more onerous then you would like, and we're fixing that, but you >> certainly don't have to expose that to your developers. This is how we >> typically setup teams either by putting commons parts on parent POMs, or >> making custom lifecycles. It generally results in very little in child >> projects. >> > > That is very interesting. Do you know of an example on how that is done? > > Thanks for the discussion, BTW! > > -- > View this message in context: > http://old.nabble.com/custom-maven-plugin-default-phase-tp27626122p27671036.html > Sent from the Maven Developers mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl ----------------------------------------------------------
