maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From tbee <t...@tbee.org>
Subject Re: custom maven plugin default phase
Date Sat, 20 Feb 2010 22:20:38 GMT



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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Mime
View raw message