The largest build I converted to Maven was about five years ago, and it had roughly 100 projects in Ant. Intriguingly, they had written an Ant plugin to process Eclipse project metadata. It strikes me you might be able to take the same shortcut with your project if your build is somehow able to create eclipse projects. The code that I wrote generated dependencies for subprojects, and most of the interesting plugin configuration was inherited, so the child projects were very thin.
If you do things this way, consider keeping your non-central repository references in the project they are used in, and definitely be sure to explicitly define whether a repository is snapshot and/or release. If you don't, snapshots will be looked for all over the internet for each build and in all the repositories that are hanging around the top level, slowing your builds tremendously. A repository manager like Nexus can help you a lot here, and if you have the resources, makes sense to deploy as early as possible. Regarding the desire to do partial builds and run with relatively current code, having a shared corporate repository will allow developers to deploy snapshot binaries after they are satisfied with the changes they have made to modules they were working on. Maven will naturally check for snapshots on this shared repository, and if some code has been changed outside your module, you'll pick up the binaries and be running with the latest. Note this is not "bleeding-edge trunk", but binaries for modules in a state that your peers were comfortable with before they deployed them. Of course, if you configure the build to deploy source jars as well, you'll have sources in your IDE for whatever version your peers deployed as well. The hardest thing I've found in such large migrations is effort required to migrate the source tree if most of your peers will continue to work on other projects with the old build during the migration. Working on a branch is practically impossible since there are a lot of non-linear mappings between subtrees spread throughout your trunk. Merging changes between them becomes impossible with many SCMs out there. Hope that helps.. On Sep 23, 2010, at 5:30 PM, David Karr 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? --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
