Re: Ant approach vs Descriptor approach

[Peter Donald <pe...@apache.org>]

On Wed, 3 Apr 2002 07:32, Vincent Massol wrote:
> * Use a project descriptor based approach. This is what Gump and Maven
> uses
> * Use an Ant approach, i.e. the Ant build file contains the project
> information, mixed with actions to perform on this data. This is the
> approach that CruiseControl is following. It is a wrapper around a
> master Ant build file.

Both are useful approaches. As you note it basically came down to how 
different or close the two build processes are. For instance I once worked 
with a client that had about 9 projects that had their build.xml file 
generated from a fairly simple xslt sheet + descriptors. However when I tried 
to apply the same thing to the avalon project I was only able to generate 
LogKit and the Framework build files because the others were too different 
build processes.

Now in part of avalon we have 17 build files that are only minimally 
different (1-4 lines difference except for one that had an extra rmic step). 
These could be easily generated from descriptor. 

> * Continuous Integration is about building projects and it happens that
> Ant is more than a build tool, it is a build platform and thus, from an
> architecture point of view, it makes sense to me to use Ant as the
> infrastructure to build such a tool. Same as it would make sense to me
> to use Eclipse or Netbeans if I had to write a Development Tool.

This is precisely where I am trying to push ant2. I have already asked a few 
people from other projects to look at the proposal I am working to see what 
would need changing to get it acceptable for their use cases. Even went as 
far as to ask people who were building testing frameworks, XML shells and 
others who were contemplating java cron/inittab style products. Haven't got 
all of the feedback yet but much of it has been positive.

> * One thing that look sure is that when you start working with a Project
> Descriptor approach, you have a model in memory and it's very difficult
> to use a build script like Ant to provide some features (how do you
> transfer the model?). Thus is forces you to go all the way. The ideal
> solution would be to express only data in a Project Descriptor and have
> an Ant build file for executing all "actions". But how do you bridge the
> gap ?

see below.

> I'm curious to know what your opinion is. I don't think there is one
> answer. You have to balance flexilibity vs ease of use. Maybe a
> templating engine in Ant is the solution ... :-)

Thats exactly what I have been saying since ages ago. I plan to make sure ant 
does support templating in some form or for ant2. I have played with a few 
different styles (from generating via xslt/velocity, to including XML 
snippets to being able to define tasks as aggregations of other tasks etc).

Heres the model I used to use when building complex C/C++ projects. Basically 
I think of the build being made of 3 parts

[1] config
[2] data
[3] rules

[1] is generally things like paths to different libraries, tools etc or 
constants indicating whether support for a feature should be built into 
product (ie should you build phoenix with JMX support or not)

[2] is things like location of src files, which files to compile, which to 
rmic, which to junit etc

[3] is the rules about how to use [2] to build targets/end products.

I never used to use any of the the auto-* tools - I used to hand craft them 
but [1] roughly coresponds to "autoconf". I don't know if [2] or [3] have any 
direct correspondance to any auto* tools (maybe automake?) but my [2] often 
looked like;


###########################################################################
# Rendering library
###########################################################################

REND.NAME            = rend
REND.DESCRIPTION     = Rendering library
REND.DEPEND          = $(SCF.NAME) $(STDDBG.NAME)
REND.SRC             = $(wildcard $(SRCDIR)/engine/renderer/opengl/*.cpp 
$(SRCDIR)/engine/renderer/opengl/glx/*.cpp )
REND.DEFINES         = -DRENDAPI=EXPORT
REND.LIB.EXTRA       = GL GLU
REND.LIB.PATH.EXTRA  = /usr/X11R6/lib/

###########################################################################
# Engine library
###########################################################################

ENGINE.NAME          = engine
ENGINE.DESCRIPTION   = Engine library
ENGINE.DEPEND        = $(SCF.NAME) $(STDDBG.NAME)
ENGINE.DEFINES       = -DENGINEAPI=EXPORT
ENGINE.SRC           = $(wildcard $(SRCDIR)/core/*.cpp $(SRCDIR)/engine/*.cpp 
$(SRCDIR)/engine/input/$(OS)/*.cpp $(SRCDIR)/engine/texture/*.cpp 
$(SRCDIR)/util/*.cpp $(SRCDIR)/engine/geometry/*.cpp 
$(SRCDIR)/engine/geometry/*/*.cpp $(SRCDIR)/engine/geometry/*/*/*.cpp 
$(SRCDIR)/engine/view/*.cpp )
ENGINE.LIB.EXTRA     = jpeg
ENGINE.LIB.PATH.EXTRA= /usr/lib/


while [3] was a mass of complex make scripts.


Maven has rough equivelents to all this. [2] coresponds to mavens descriptor 
format while [3] coresponds to some of their build scripts. [1] is similar to 
defaults.properties.

The problem that I see with maven is that [2] is not open-ended and thus some 
build scenarios will not be supported. If [2] and [3] were open ended then it 
would be much easier to support additional build processes.

Anyways I definetly intend to get ant2 to do this in some form or another. It 
probably wont support any templates/rules out of the box (unless someone 
creates an antlib for the templates and donates them to ant-dev).

-- 
Cheers,

Pete

It said "Don't Panic" in big friendly letters.

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>