Tag Archives: conferences

Apache Maven Training in Atlanta: Nov 1, 2010

ApacheCon is fast approaching! If you’re coming to the conference, or anywhere near Atlanta, then I hope you’ll take a look at the training course I’m running there this year, Apache Maven: Effective Implementation:

This training course is designed to go beyond your current assumptions about Apache Maven and learn how to use it most effectively to manage the build and development process. Whether you are a novice aiming to start on the right foot, or a regular user looking to get more out of Maven and avoid common frustrations, this course will give you the skills you need to apply to your own projects.

By working through a series of short exercises applied to a complete sample application, you will learn how to apply common patterns in Maven builds to achieve the desired outcome, while learning best practices and common pitfalls along the way.

Topics include installation, Maven fundamentals, working efficiently with multi-module projects, simplifying the POM, the best general purpose plugins that you should know about, integration and functional testing, when (and when not) to use Maven sites and reporting, the role of profiles, snapshots and dependency management, repository management, and performing releases.

The content is updated for the latest improvements in Maven 2.2 and Maven 3, and will cater to your preference of development environment.

Time is reserved for sharing specific situations that attendees have encountered in existing projects. A laptop already configured for Java development is essential.

This year gives us the unique opportunity to get a first look at a GA release of Maven 3.0 in addition to building on a comprehensive example of how to use Maven effectively in your projects and with your teams.

Early bird prices end this Friday, October 8. Register for Apache Maven: Effective Implementation now!

I’ll be at the conference all week, and as usual hope to catch up with users and contributors as much as possible. I’ll also be speaking – though surprisingly on a topic completely unrelated to Maven (possibly a first!).

John Smart on Hudson and “The Tools You Should Be Using”

This morning at JavaOne I took the opportunity to catch John Smart’s first talk on Advanced Hudson Usage. Not that I’m thinking of switching, of course :) I was keen to compare how he handled several tasks in Hudson to how we’ve been doing similar things with Continuum.

It was an interesting talk for anyone looking at build management in general, highlighting the need for feedback, visibility and delivery; and how to work with different tools all through the development spectrum. Some details from the talk are on the Hudson live blog.

True to his form from Java Power Tools, John spent some time highlighting those other tools that everyone should be using. The responses particularly caught my attention. There were plenty of people in the room using Maven, which wasn’t surprising. However uptake on others was lower. Who is using an enterprise repository manager? Several hands, but not close to being all of the Maven users. Checkstyle, FindBugs? Sonar? Failing the build on quality checks? Only a handful I could see in each case. Automated deployment? Only moderate usage. Distributed builds? Described as the feature all self-respecting build server should have, there were again very few people using it in the room.

John’s response to many of the “are you using… ?” questions was a strong “You should be!”. I certainly agree, and having had many of these in place in varying degrees for several years, I often take for granted that they are the first thing to set up on a new project.

The amount of work and resources needed to get them all up and running, and working together seamlessly, needs to become easier. In our environment, even though we had a well integrated set of tools, we faced challenges with scaling when creating several new projects and managing multiple branches, and going the last mile on very frequent patch releases.

That was the motivation for what has gone into Maestro 3 this year, and the responses at the conference so far give me strong encouragement that we’ve been heading in the right direction. Instantly setting up integrated Maven, Continuum, Archiva, Sonar, Selenium and deploying the application bundle through a single UI was the first step, and we now have the basis for greater consistency and reuse for project set up and configuration through Maestro compositions. We’re now gearing up for more frequent build and test cycles over distributed agents from both our private cloud and Amazon EC2.

MaestroDev at JavaOne next week

After being in “stealth mode” for some time, MaestroDev is launching something new at JavaOne next week.

In the next few days, we’ll be unveiling our new website, with information on what we’ve been working on recently, and the latest of our news and upcoming webinars on software build, test, release and deployment infrastructure for Maven projects.

At JavaOne, we’ll have a booth where we’ll be discussing the company and showing off a sneak preview of the latest development in the upcoming release of Maestro 3. Be sure to come by and say hi!

It has been a few years since I’ve been to JavaOne and this year will obviously be a little different. I’m not sure what to expect just yet, but looking forward to it, and hopefully catching up with a few people. And while conferences are exhausting enough, it’ll be nice to be out of the crazy busy mode that has been the last few months!

Apache Maven: End-to-end training in November

It’s that time of year again! ApacheCon US in Oakland is on 2-6 November 2009. There are still discounts for registration by September 25.

I’m presenting my full-day Maven and development infrastructure training again on Monday November 2, called Apache Maven: End-to-end:

This training session will walk through the lifecycle of developing a typical Java application from creation to deployment, and show how to use Apache Maven most effectively to manage the build and development process. In addition to the fundamental building blocks of the project, the session will cover testing, day-to-day development in the IDE, application of Maven best practices, effective dependency management, establishing a release process, using profiles effectively, setting up documentation, tracking development reports and practices. Effective use of continuous integration (illustrated with Apache Continuum) and repository management (using Apache Archiva) as a part of development infrastructure for team and enterprise environments will be demonstrated. This course will be suitable both for those that are looking to get the most out of their existing Maven projects, and those that are looking to use Maven for the first time. Time is reserved for addressing specific situations that attendees have encountered in existing projects.

The material is aimed to offer most to the intermediate Maven user, while still being appropriate for Maven beginners, and is refreshed with the latest work from the book.

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.