migrating tomcat web apps in eclipse to maven advice - where to start?

[Stuart Swearengen]

I thought it was about time I start using maven or at least prototype to see if it will do what I want. I'm hoping it can make the whole ant build+release process faster?
I have a series of large applications running in tomcat, build using ant and hudson for releases and eclipse for local dev environments. So, where to start looking at moving to maven?

given that:

I don't want to impact the developer / debug experience

eclipse + wtp + tomcat + selennium + svn + hudson is always in the mix

how do you migrate?

would there be a local build in maven and a remote one for builds? or just one?

can maven do all the code checkout / labelling/ running test code/ deploying?

any good stuff to read? poms seem impenetrable at first glance as do archetypes

any recommendations on useful eclipse tools

thanks,

Stu

[Tim Holloway]

I strongly recommend getting Eclipse + WTP out of the mix when doing nightly and production builds. Myself, I have a firm policy on all projects that they must be buildable from the command line with only Maven (or Ant) with no IDE installed on the computer at all. I also design my webapps so that any environmental information comes from external sources so that the exact same WAR file can be used on development, test, and production machines without alteration.

The "mvn clean deploy" goal will do a complete cleanup, compile, packaging and deployment cycle. I don't know about checkout, since I normally checkout before commencing work on a project. Maven will, however, automatically pull in binary dependencies; that's one of Maven's most celebrated characteristics.

For production builds, I can do a step further. Once I check all the changes in, a "mvn release:prepare" followed by a "mvn release:perform" will tag the production build in version control, run the unit tests, build javadocs and create/deploy a project management website (the "mvn site" goal). One-button solution.

Just in case you hadn't already figured it out - yes, the same maven project (and POM) does all of this, whether it's development, Beta, or production. I run my development builds inside Eclipse. I don't use WTP however, since I frankly consider WTP to be an abomination (I use sysdeo).

If you don't have the m2eclipse plugin installed into Eclipse, I believe it's located at tigris.org.

An archetype is basically just a snapshot of a prototype project, and fairly easy to create and easier to use.

POMs are actually fairly simple to start with. Then they grow. At least you don't have to explicitly specify each and every dependency (unless you want to), since Maven will transitively resolve cascading dependencies.

Probably the biggest adjustment required is Maven's strict project layout rules. In order to accomplish this much magic with minimal configuration specifications, you must put things where Maven expects to find them. While you can forcibly override these rules, it's messy, painful, and likely to provide a series of rude shocks at inconvenient times. On the plus side, however, this means that you can generally figure out where a given project component is in an unfamiliar project without too much digging.

[Peter Johnson]

Start off with some reading. A good place to start is Better Builds with Maven: http://www.maestrodev.com/support/
Work your way through that using simple test projects.

Then for a better detailed look, read Maven: The Complete Reference: http://www.sonatype.com/books/mvnref-book/reference/
That provides a better understanding of Maven.

Once you understand Maven better, then you can start converting your existing projects into Maven.

To answer your specific questions:
1) We use only a single pom.xml which does the builds on both the developer's machine and on the build machine. The build can be run from within Eclipse (which I never do, but it's what my colleagues do) or from the command line (the only way that I build). We use profiles if there are differences in the build (there are lots of them, but mostly configuration related, but in some instances hat are additional goals that get run on the build machine)
2) Leave the checkout to Eclipse and Hudson. What do you mean by "labelling"? Maven runs unit tests automatically as part of the build. Maven can also run integration tests, but doesn't run them automatically. But you can use profiles to run integration tests automatically on the build machine, assuming that your build also sets up the environment. (We haven't got that far in our builds but our environment is a little unusual.) And what do you mean by "deploying"? In Maven terminology, "deploy" means to upload the resulting artifact into a remote repository (you will want to set up Nexus or Artifactory as a repository server in your build environment, that us where you "deploy" to). But if you mean "deploy to an app server", then yes it can be done, the details depend on the app server and availability of plugins (google searches often yield handy plugins).
3) See above
4) Tim mentioned m2eclipse, it is a must have.

[Tim Holloway]

As I said, I inject environmental information from the server itself. I tried doing it via profiles and I didn't care for the results. Since I've been burned by having the wrong WAR installed on the wrong server, a "one-size-fits-all" WAR is much safer for me. I use profiles for case such as doing my testing on Tomcat and deploying to WebSphere, where the dependencies vary.

The Maven "release" plugin, as I said, does a major job. A number of the jakarta projects use it as a one-button solution to update the app, the javadocs, and the support website all in one swell foop. I shouldn't have used the term "labelled", however. When the source code archive is a Subversion archive, the release plugin creates a tag for the source code that was released. It also automatically bumps the version number in the POM.

Don't confuse the different types of deployments, though. The simple "deploy" goal can be used to push a jar out to a Nexus server. The release:deploy goal updates the project website. IIRC, to deploy to an appserver, you have to use an appserver-specific goal such as "tomcat:deploy".

[Stuart Swearengen]

Thanks for the replies, some great help in there. Sorry for the delay a collarbone break stopped me. As I thought, it may take me some time to get all the legacy projects migrated.

One of the points I worried about the most was that by removing eclipse+ wtp, the debugging experience would be less good to devs. It seems you all have gone down the command line route,potentially invoked in conjunction with an IDE.

How are you debugging the code if you need to? remote debugging like http://stackoverflow.com/questions/1536445/preferred-way-of-developing-web-applications-with-m2eclipse or just using logging?

[Jeanne Boyarsky]

The developers still use Eclipse to develop and debug. The point is that Maven builds instead of Eclipse specific settings. M2Eclipse imports project configuration from Maven so you only have one set of configuration.

You will "affect" developer experience as:
1) They will need to install M2Eclipse.
2) You'll want to refactor the directory structure of your project to "the Maven way."

[Peter Johnson]

Personally, I use logging. Perhaps just out of habit. But many of my co-workers debug from within Eclipse. They also installed the WTP/Maven tools (don't have eclipe up right now so don't have the exact name, but it is usually the first result in the Eclipse Marketplace when you search for Maven).