Learning from Maven Training

One of the interesting side effects of hosting a Maven training course is the things I learn as an instructor. Some of them you already know but need reminding of, others you just don’t get until you watch someone try it unaided.

Recently, I ran my "Apache Maven, End-to-end" course, firstly with the beginners course in Manila and then the intermediate course at ApacheCon US. Both had reasonable turn outs, with a late increase in registration to the ApacheCon session that was encouraging.

Some of the things I took away from it:

  • Maven’s diagnostics when things go wrong still suck. I do all I can to prevent network issues from impacting the class by providing a repository that covers the required parts of all the content, but there were still 2 or 3 instances of the "plugin not found" message when a network failure occurs.
  • The basics are still helpful. Though those in the intermediate course already had quite a bit of exposure to Maven, I received positive feedback to covering the basic principles again. It reinforces the "Maven way" of doing things and some of the reasoning behind it starts to make more sense, even if you already know how it works.
  • Repository managers are still taking hold. While a number of people were using one of the available managers, it seemed to be largely for proxying, and no one was running one on their own machine. Even though I only covered it briefly, that section was well received even by those running something other than Archiva.
  • The devil is in the details. You can cover all that you need to be able to do with Maven itself in about a half day, and it provides enough to do 80% of what you’ll ever do with Maven. You can only run a few specialised sections, such as sites, assemblies and releases. The other 20% widely varies and requires learning and researching specific plugins for those tasks. None of this is surprising – but it is encouraging that learning Maven is not as hard as it looks to some, but also that a better way of collating plugins and practices is limiting the ability of people to use Maven.  The course I run has basically an exponential ramp in what you are assumed to know and able to do once the basics are in place – as you set up infrastructure and team capabilities it is still reasonably easy to piece things together gradually if you’re building on a solid project structure.
  • Test more on Windows. I had almost forgotten how much harder life is to be a Java developer on Windows as seemingly trivial things go wrong. Trying to start a server, pinning to wrong Java versions, etc.

There’s always more and every time I run a course I come back with a series of notes to re-apply to the material, and bugs to fix in the software. But an encouraging point, and one I noticed from the conference in general, is that Maven acceptance is on the rise. Even though there haven’t been radical improvements to the underlying software since 2.0.x, the principles behind it have started to sink in, and complaints tend to be specific fixable issues rather than general frustration. Alternatives continue to get mileage, but none (yet) have been the Maven-killer they each claimed to be. Underneath it all, it seems we got a lot right after all.

3 responses to “Learning from Maven Training

  1. Emmanuel Lecharny

    Hi Brett,

    interesting ! Maven is definitively gaining steam. Even guys like me start to feel comfortable with it 😉

    There are some few things though which can make life easier :
    – allow concurrent downloads of plugins/jar : when you start a full build after having doomed a repo, it takes forever to download something like the whole internet. Gathering all the jars to download, and do it in // can save time !
    – Surefire should gives a list of failed tests, with a direct access to the .txt files, _or_ just don’t produce a txt file for successful tests
    – Running mvn eclipse:eclipse remove some targets file. I see no reason why it should do that

    Otherwise, it’s now pretty usable. Funny how things have evolved since m1 !

  2. The thing that stopped me dead in my tracks from learning maven for a long time was the completely awful command line UI. --help wasn’t helpful at all. The lifecycle stuff wasn’t mentioned in there — so I had no clue as to what I should add in. There was no mention of the help plugin.

    On top of that, the first thing that most maven users come across is how to use archetype:create. And the command line for that is ridiculously long. That gave me a serious WTF moment.

    And then, when you do figure out what to do, the first thing that maven does is spend 15 minutes downloading all the plugins it needs from the Internet. Which is not great UX. I reckon that packaging maven with a “default” set of plugins for things like the compiler would be a huge win.

    I know, I know, I should really supply patches. 🙂

  3. You are right about the “complaints tend to be specific fixable issues rather than general frustration”. Most of the time my colleagues are complaining about m2eclipse in combination with wtp. They tend to mix up maven, m2eclipse and wtp quite often, so I have to explain them the difference and make sure they don’t blaim maven itself 😉

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s