Since the early days of SQuirreL in 2001, two tools have been used to
develop the code - namely Ant and CVS. We are currently reviewing the
benefits that Maven2 and Subversion would afford this project and
wanted to give everyone an idea of what to expect in the coming
months. I must admit that I was a doubter when I first began to use
Maven2 and Subversion at my day job over a year ago now. But in the
time since then, I have gained an appreciation for both of them and
seen their adoption lead to great strides in improved productivity
through integration with other tools. The key features that I see
SQuirreL benefiting from are:
1. Ease of resource (file and directory) relocation without loss of
history (essential to help re-arrange our current source tree to
conform to Maven2 convention)
2. Integration with Trac (project management) which is hosted on
SourceForge and to which we have already opted to use for our wiki.
3. Ability to easily identify all files that were changed in a given changeset.
1. Dependency declaration: we can declare all of our dependencies in
one place (pom.xml file(s)) instead of in build.xml and the IDE (e.g.
.classpath in Eclipse), for all IDEs that support maven.
2. Build Plugin Dependency bootstrapping: we can resolve dependencies
on build plugins (e.g. emma, findbugs, pmd) automatically. This
eliminates the need for the developer to first download
special-purpose build task jars and place them in ANT_HOME/lib (for
example, findbugs Ant task jar).
3. We can simplify the build scripts by taking advantage of Maven's
convention over configuration (for example - no need to state where
output directories and artifacts are placed).
4. We can use maven plugins (like assembly, release, IzPack) to
eliminate the need for our special-purpose release ant build script
5. With the M2Eclipse plugin, importing projects into Eclipse is super-easy.
6. We can create a project archetype that can be used to generate an
example plugin project that eases the setup burden on new developers
(i.e. no need to checkout the entire codebase, and no need to modify
other ant build scripts to build it)
7. Maven can generate an alternate simple project website with links
to source code, javadocs, bug tracking, mailing lists, projects
reports (unit test, code coverage, findbugs, pmd, etc.)
Here is an outline of what I believe needs to happen in chronological order:
1. Get a fresh checkout from CVS, restructure code to conform to Maven
conventions, write pom files, and test build using Maven to ensure
equivalence with current Ant build.
2. Migrate from SourceForge CVS to SourceForge Subversion using
cvs2svn (http://cvs2svn.tigris.org/) - keep exactly what we have today
except hosted in Subversion; same project structure, still using Ant.
3. Checkout from Subversion and test Ant build scripts to ensure all
resources were migrated properly to Subversion.
4. Create tag in Subversion.
5. Restructure source files to conform to Maven2 hierarchical
structure (i.e. src/main/java/, src/main/resources, src/test/java,
etc.), just like what was done in step 1.
6. Place project poms from prototype (step 1) into fw, app and all
7. Test build using Maven and commit changes. (At this point we are no
longer using CVS nor Ant).
I'd like to get feedback from developers - especially those with prior
experience migrating from Ant to Maven. Let me know if you have
suggestions or concerns. I'll update this thread periodically as
progress is made toward the final goal.