maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason van Zyl <>
Subject Re: custom maven plugin default phase
Date Sat, 20 Feb 2010 19:59:25 GMT

On Feb 20, 2010, at 2:41 PM, tbee wrote:

> Hm. There is a tad too much assumption in that previous post. First let me
> introduce myself; 15 years ago I graduated with honors from a software
> engineering study. I've done everything from C, Cobol, lowlevel embedded
> systems and assembly (I worked on one of the first mobile GPS hardware),
> Pascal, Miranda, ObjectiveC to Java and DotNet. (I always steered clear of
> C++ ;-) In project ranging from local webshops to full ERP systems and
> software for banks and insurances. Using all the build systems and source
> control revision that came with them. I know my way around.
> Secondly, let me repeat that Maven is a great concept and that I have no
> intention whatsoever to discredit it. All I did was bring forward some of my
> experiences with my attempt on migrating to Maven.
> 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?

> I've initially tested Maven 2 about half year ago, and I found it complex.

Relative to what?

> The basic rule I always follow is that if I assume myself as being average,
> then there will be others that will find it complex as well. If the average
> user finds it complex, then it on average is complex.

I argue that is any more complex then any other tool required for use at a group level, additionally
a well setup Maven project at the infrastructure level is the majority of the time not fiddled
with by developers. Developers should not be altering the build on a regular basis out of
necessity for the project. There is just a certain amount of infrastructure involved and 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.

> In my first attempt I really understood the basic goal of Maven; default
> directory structure, default build phases, almost nothing to configure if
> you stick to the standard. However, real life usage showed me that Maven may
> not be as easy to grasp for the casual user. I don't want them thinking
> about the build, it just has to work, also if they start a new project. That
> is why I decided to examine other approaches, not because I want Maven to do
> whatever I want, because I -as the average user- found it fairly complex. 
> These other approaches had their drawbacks as well, and that is why I came
> full circle back to Maven, but diving deeper now; trying some real world
> projects. "Ok, so it may be hard to fully grasp, but if I can set it up so
> the others won't really have to think about it, it'll be ok. There are a lot
> of advantages to Maven." As you have pointed out; you don't need to sell
> Maven, I've come full circle.

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.

> But the complexity remains my major hickup; even small projects quickly
> become a configuration complexity with execution environments, phases,
> goals... No.

The complexity to a large degree for an application running in many environments, against
many databases, against varied configurations is part of the game. It's something that is
improving as we see patterns emerge.

> That must be encapsulated inside the plugins.

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.

> Yes, software
> building can be complex, but it shouldn't be this quickly. I'm not even
> using parent pom's, just simple artifacts. My coders need to think: "I need
> A, I include A-plugin and it works". 

Well, if you wrote the plugin for them, or you tested the plugins you commonly use then this
is possible. If you take Maven plugin you've never used before would you treat it differently
then any other piece of third party software you might use and just expect it to work? Lots
of Maven plugins do, but this is where we can't control everything even without the Maven
project itself the quality varies wildly.

> And that is what I mean with its the EJB2ness. (I still think it's a good
> metaphore.) EJB2 also exposes too much of its innards. 

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.

> I've read the sheets on Maven 3 and it looks promissing; I'm reading what
> I'm looking for. Extention points, plugin, mixin... Maybe I'm simply trying
> just a minute too soon.

Still much of what you want is possible. I think you're honestly confusing what might be expose
to the developer versus the work you have to do in order to make it work for those developers.
Ultimately whether there are mixins, extension points, whatever, the resultant is a small
POM for the target project and that's totally possible now. Not as elegant as with a mixin,
but certainly possible.

> -- 
> View this message in context:
> Sent from the Maven Developers mailing list archive at
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:



Jason van Zyl
Founder,  Apache Maven

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message