Gant 0.4 - Creating a powerful DSL for building Java projects

[hdockter]

On May 23, 2007, at 5:03 PM, Jochen Theodorou wrote:

> Hans Dockter schrieb:
>> On May 23, 2007, at 9:10 AM, Jochen Theodorou wrote:
>>> Russel Winder schrieb:
>>> [...]
>>>>> My basic idea of a lifecycle that time was to have simple  
>>>>> method calls:
>>>>>
>>>>> def build() {
>>>>>    init()
>>>>>    compile()
>>>>>    test()
>>>>>    jar()
>>>>>    deploy()
>>>>> }
>>>> If the lifecycle is fixed then there is no need to program it  
>>>> per se.
>>>> Also of course you need entry points, hence the idea of targets  
>>>> rather
>>>> than just functions.
>>>
>>> well... in this idea the lifecycle consist on a custom set of  
>>> targets. Each target is a method. That means the user is  
>>> specifying the lifecycle as well as the targets by overwriting  
>>> and calling methods.
>>>
>> What we want is a mechanism which offers entry points and make  
>> sure that the former phases of this entry point are also called.  
>> How would you implement this with your approach? Adding a call to  
>> the compile method within the test method?  Having aggregate  
>> methods like build to enable
> > this?
>
> adding a call is the way I think of. build is a target on its  
> own... if we need to make a difference between helper methods and  
> build targets, then we could name it for example buildTarget,  
> targetBuild.. something like that.
>

I would like to discuss certain features regarding lifecycle that  
came to my mind:

I would like to define the term lifecycle in the following way:

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

There is no such thing as one default lifecycle (according to the  
definition above). We have a jar lifecycle, a war lifecycle, etc... .  
They differ at least in the associated actions.

What I would like to offer to our users is a way to create custom  
lifecycles (custom phases and actions). Of course they should also be  
able to customize a standard lifecycle like the Jar lifecycle.  And  
our users should be able to reuse a custom lifecycle they have  
defined across multiple projects.

We should also keep in mind that we want to offer multiproject  
support. To me this is a main feature of Gant 0.4. The question is  
how to realize this. The Maven way, with a build script in every  
project. Or the buildr way, with one (logical) script that spans over  
all the projects.

I start to understand Jochens points. I have no idea right now which  
approach to lifecycle handling to prefer.

- Hans










---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[hdockter]

On May 23, 2007, at 9:31 PM, Jochen Theodorou wrote:

> Hans Dockter schrieb:
> [...]
>> I see your point now. But one could easily define a policy that  
>> the target is just a wrapper.
>> target ( compile : 'compile' ) {
>>    Build.compile()
>> }
>> Then you could overwrite the compile target:
>> target ( compile : 'compile' ) {
>>   Build.compile()
>>   compileGroovy()
>> }
>
> that's right, but then I need to know the contents of compile, or  
> not? You really think it is good to need such detailed knowledge?
>
> You could only rescue the situation by putting all code in methods,  
> document what method is called... why do I need then the target  
> description?
>

I'm not saying that this is a good idea. I'm not sure. The purpose of  
the targets is to establish the dependencies of the lifecycle. It  
should be:

target ( compile : 'compile' ) {
    depends( resources )
    Build.compile(project) // something like this may be
}

- Hans

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[hdockter]

>>>> 2.  We use a few exemplar projects as foci for discussing what the
>>>> Gant
>>>> scripts should look like.
>>>
>>> I like this idea very much. The respective projects should be  
>>> complex
>>> enough. Anybody reading this, who is responsible for a build of some
>>> open source project and would like to join?
>>
>>> A friend of mine knows the nutch search engine project very well
>>> including its build. He says they have a complex ant based build but
>>> does not think there is any interest from the nutch commiters in
>>> changing there build. But as a guinea pig, why not. We could at  
>>> least
>>> have a look at it.
>>
>> I am not sure it is necessary to actually work with real projects,  
>> but
>> we need to create a set of highly stripped down test projects that we
>> can amend in order to drive the way that the Gant scripts look.
>>
>> I wonder if we should start by creating a set of test projects in the
>> Gant Subversion store?
>
> You are right. This is a good idea. I gonna start setting up some  
> tests projects there this week.

How should I call the folders for the projects structure? We said  
that we don't want src/main/java. But src/main/src is not very  
convincing either.

- Hans

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email