Message-ID: <979625448.1697.1419054898648.JavaMail.email@example.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_1696_991450303.1419054898648" ------=_Part_1696_991450303.1419054898648 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
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
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
(My) Requirements for the lifecycle handling:=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
This is enough to compile, test and create a jar of our test project.=20 =20
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
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=
gant compile for example, all lifecycle methos are cal=
led that correspond to entries in this list up to the compile phase.
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
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.