Skip to end of metadata
Go to start of metadata

Maven brought the idea of standard project directory tree structures and standardized project lifecycles to the world of Java project builds. With Ant you have to specify everything about the build, with Maven everything is standardized. Ant has the benefit of being completely general, Maven has the benefit of convention. Gant sits with Ant, it is a gneral mechanism for scripting Ant tasks using Groovy rather than XML. Using a dynamic programming language means that it is possible to write complete target sets that can be included. So we don't have to use a completely different framework to harness the power of convention. Examples of prepackaged target sets are gant.targets.Clean and gant.targets.Maven. These are, in effect, mixins that can be used to create build specifications.
An example:

The Maven target set imports the targets: initialize, compile, test-compile, test, package, install, and deploy. We can add any other targets just as we might in any Gant file.

An alternative way of writing this is:

With either of the above, we can see what targets are available using the -p (or -T) option:

NB The site target does not work as yet. Note that the comments explain as much as possible about the action inclusing sources and targets where known. The above example is for building Gant itself -- the 1.0.1-SNAPSHOT version.

For those people who prefer to use Test'N'Groove rather than JUnit for unit tests, simply specify the testFramework property to be 'testng'. So for example, the ADS Package build file is:

NB The Maven target set automatically pulls in the Clean target so we can use the standard Gant clean support features. Checking the available targets for the above Gant file:

Note that the test target tells us which unit test framework is being used. Groovy's GString in action.

What about dependencies? Simply add to the compileDependencies or testDependencies property, for example:

A dependency is a hash with keys for all the attributes required by the Maven dependency resolution system. During completion of the initialize target all specified dependencies will be checked for presence in the standard Maven local repository or downloaded if not present. Although we have presented the example of downloading TestNG here, you don't need it for using Test'N'Groove since this dependency is automatically added when testFramework is set to 'testng'.

Currently the list of amendable properties is:

Options for testFramework are currently 'junit' and 'testng'. Options for packaging are currently 'jar' and 'war' (but the war packaging has not been tested).

NB The Maven target set is a work in progress. Currently it seems to work for simple Maven structured projects, but it does not yet have all the plugin control facilities of Maven itself. If you find anything that is missing or doesn't work, please create a JIRA issue.

  • No labels

1 Comment

  1. I'd love to move my declarative pom code into groovy (would cut the bloat in half), but that would eliminate my IDE's maven dependency support.

    Is it possible to declare my maven project structure in a pom.xml but then use gant's maven target set?

    If not, I will probably end up doing something like:

    ... of course the downside to that is I don't get the tasks for free, just the dependency management.