Strategies for converting from Ant

[David Karr <da...@gmail.com>]

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?

Re: Strategies for converting from Ant

[Brian Topping <to...@codehaus.org>]

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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Strategies for converting from Ant

[Greg Akins <an...@gmail.com>]

On Thu, Sep 23, 2010 at 5:30 PM, David Karr <da...@gmail.com> 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.
>

I just did the same thing..

The biggest problem I ran into was that many of our builds created
multiple jars.  Since Maven is really designed around a "one jar per
project" much of my work was made easier if I split projects up into
individual projects.

Nexus was a great time saver.. You can take existing jars and put them
into the repo so that you can build from them until you get them
mavenized.

Finally, I left some builds in Ant because they will take a bit more
thought to mavenize, but I used Ivy to pull the jars from Nexus so I
don't have to worry about copying jars anymore.

I wish everything was in Maven so I could start using the master poms,
but this has been a pretty painless starting point.
-- 
Greg Akins

http://insomnia-consulting.org
http://www.pghcodingdojo.org
http://pittjug.dev.java.net
http://twitter.com/akinsgre
http://www.linkedin.com/in/akinsgre

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Strategies for converting from Ant

[Jon Paynter <ki...@gmail.com>]

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 <da...@gmail.com>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?
>