David, Im looking at exactly the same thing - moving from ant to maven. One of the first things I ran into was maven's concept of one artifact per project. With ant its quite easy to take a set of files for a webapp, and create both an ear and war file, and be ready for deployment. With maven each artifact needs to go in its own project. This means some re-organizing and re-partitioning of things. I havent touched the maven eclipse plugin yet - so please share what you find.
Thanks, Jon. On Thu, Sep 23, 2010 at 2:30 PM, David Karr <[email protected]>wrote: > I work on a pretty large project that uses Ant for builds. We're doing some > research on converting to Maven. I'd like to describe some of the elements > of our situation, hopefully to find some conceptual "cookbook" strategies > for those aspects. > > The "application" consists of the aggregation of several (10-20) separate > SVN/Eclipse projects on a particular branch. Sometimes a project is used > on > the branch, sometimes on the trunk. The "build", when spawned from one of > those projects expects the other projects to exist with expected names in > peer directories (like "../module"). In order to complete a build of the > entire application, a developer has to check out all of the projects > required for the build, even if they only do work in one of them. The > plans > for a particular release define which projects will be on the branch, and > which on the trunk. > > Although the deployment unit of the application is an EAR, the present > build > process uses a vendor-specific assembly mechanism to produce the EAR > modules. We're examining how/whether we can simplify that part to be more > conventional, but we may have to just figure out how to integrate more > closely with that mechanism so we can control it, instead of replacing it. > > Developers use Eclipse on Windows, although the official build and > deployment is on Unix/Solaris. Developers would likely use the m2eclipse > plugin in Eclipse. > > One thing that I'm particularly looking forward to is the ability to just > have to check out a single project from SVN in order to build the entire > application, as I'm hoping it can somehow know to pull subproject builds > from the repo instead of expecting to build the source locally. I'm not > certain exactly how that will work, but I believe that should be an > expected > benefit of this conversion. > > I know I've left out a lot of specific details of our environment, but can > you enumerate specific strategies and steps we should be examining? >
