Development Ideas -- Hans Dockter -- 2007

For the next version of Gant we want to introduce project tool s=
upport a la Maven. Here you can find a discussion in the gr=
oovy user mailing list about this topic.

=20

Basically we want to implement three abstractions:

=20
=20

Build lifecycle

=20

Multiproject builds

=20

Dependency handling

=20
=20

I have submitted a framework (see attached Gant04.zip) for lifecycle han=
dling based on an idea Jochen has brought up. The framework is good enough =
to get an idea and to discuss it, it is by no means complete. There is no s=
upport for multiproject builds yet and only the simplest support for depend=
ency handling. There is no integration with the current Gant yet.

=20

Lifecycle

=20

Lifecycle Definition

=20

1.) A list of phases (Jochens approach) or a set of phases related via d=
ependency relations (Gants approach) 2.) Certain actions that are ass=
ociated with a phase. (The statements of the target or of the methods above=
, depending on the approach).

=20

=20

(My) Requirements for the lifecycle handling:

=20
=20

Easy customization of the lifecycle (which includes an easy reuse of an=
existing implementation of a phase).

Customization should also be possible by removing or creating new phase=
s. Of course you can squeeze in any custom behavior by customizing existing=
phases. But this might be not expressive.

=20

=20
=20

We have been discussing two alternative approaches for lifecycle handlin=
g. One is based on Gant targets where the lifcycle is established by the de=
pendencies of the targets. The other is to have a lifecycle class with meth=
ods implementing a phase of the lifecycle. I have implemented the latter ap=
proach.

=20

Examp=
les of build scripts

=20

=20

group =3D 'org.codehaus.groovy.gant.test'
name =3D 'test1'
version =3D 1.0
lifecycle =3D new org.codehaus.groovy.graven.JarLifecycle() // We could eas=
ily add a method like createLifecycle('jar') to make this more convenient f=
or the standard lifecycles.
lifecycle.dependencies =3D ['./src/test/libs/commons-io-1.2.jar'] // Depend=
ency support is very rudimentary. The only objective has been to make the e=
xamples work.
lifecycle.testDependencies =3D ['./src/test/libs/junit-3.8.2.jar']

This is one way of customizing the lifecycle. It is a non reusable custo=
mization applied directly in the build script. If there is a closure named =
like a lifecycle phase, this closure gets called instead of the lifecycle m=
ethod. The other way of using a non standard lifecycle is: creating a new l=
ifecycle from scratch, inheriting from an existing lifecycle, etc...

=20

One implementation detail is how to define an order for the methods of a=
lifecycle class. One possibility would be, that the lifecycle method calls=
it predecessor directly. This has two disadvantages:

=20
=20

You can't customize an existing lifecycle class by adding a new phase.<=
/li>=20

You can't call a lifecycle method in isolation. I have no use case yet,=
where this is a problem. But I'm pretty sure they will come up.

=20
=20

My approach is to use a list which defines the lifecycle phases. Each na=
me of the list corresponds to a lifecycle method name. If the build is star=
ted via gant compile for example, all lifecycle methos are cal=
led that correspond to entries in this list up to the compile phase.

=20

Using the =
framework

=20

Right now the framework is not capable of being used from the command li=
ne. The only user right now are the integration tests which call the main m=
ethod of the Gant04 class and passes it the basedir and the buildscript pat=
h.

=20

I might be a good idea to have first a look at /Gant04/src/test/integTes=
ts/org/codehaus/groovy/graven/BuildTest.groovy to best understand the frame=
work.

=20

Conclusions

=
=20

The framework is a prototype. There are many things that can be improved=
. The main question is whether we want to implement the lifecycle handling =
in such a manner or not. I personally think this is a good approach. And I =
think this complements what Gant offers right now. In a build there are alw=
ays lifecycle related action and non lifecycle related actions. For the lat=
ter the current Gant approach is a good way to implement them.