You are viewing a plain text version of this content. The canonical link for it is here.
Posted to alexandria-dev@jakarta.apache.org by Vincent Massol <vm...@octo.com> on 2002/04/02 23:32:32 UTC
Ant approach vs Descriptor approach
I'm crossposting to both Alexandria-dev and Turbine-Maven-dev as I am
curious to know what these 2 projects think ... :-)
--
I've been playing a little with CI tools for the past week and it seems
to me there are 2 possible approach to such tools :
* 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.
I'm still not sure which one is the best but if I had to make a choice
today, I would be tempted to choose the Ant-based approach for the
following reasons :
* 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.
* I fear that the problem with making a generic Continuous Integration
tool is that requirements from different projects are well ...
different. And thus to accommodate everyone, we'll find that our initial
Project Descriptors which fine neat and small will tend to grow big ...
and reinventing a description language a la Ant in the end ... For
example : take the latest discussion on the maven mailing lists. Someone
said "I need a war construct". Ok, then you add <war/> element in the
descriptor. Then someone else says "But in my project I need to generate
more than 1 war". Ok then you add <war><fileset/></war>. Same thing for
<checkstyle> ("but I don't want to run checkstyle on my full src/
directory as I have some AspectJ code there", etc. Then you add an
<aspectj> tag, etc). There isn't a one size fit all in term of project
descriptors. An Ant approach is more flexible (although it is probably
more work for a user).
That said, it could work on a restricted scope (not sure Jakarta is a
restricted one though :-)). It would be possible to say, in our
community, all our project must have a project descriptor and not use
Ant build file, which would give all the projects a common directory
structure and such (but also prevent new ideas and cross-fertilization
unfortunately).
* When I tried Gump, it was real nice. With some minimal effort, I could
build my project (although I had duplicated definition of my
dependencies both in my project Ant build files and in Gump
descriptors). However, it was far from finished to make it a perfect CI
tool :
- working on all platforms
- deciding when to trigger a build (like every 10 minutes of CVS
inactivity, etc)
- sending emails
- deploying project deliverables and build logs to a website
- looping
- customization, like 10 unclean builds for 1 clean build (full
checkout), etc
Of course, I could have written batch files, perl scripts, even Ant
scripts to provide for this but then all the work is still to be done.
Ok generating a dependency graph is very useful when you need to build
50 projects but it is less crucial when you're working on a customer
project with only 4-5 dependent subprojects (for which dependencies can
easily be captured in Ant itself).
* 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 ?
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 ... :-)
Thanks
-Vincent
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Ant approach vs Descriptor approach
Posted by 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>
Re: Ant approach vs Descriptor approach
Posted by 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>
RE: Ant approach vs Descriptor approach
Posted by Berin Loritsch <bl...@apache.org>.
> -----Original Message-----
> From: Vincent Massol [mailto:vmassol@octo.com]
>
> I've been playing a little with CI tools for the past week
> and it seems to me there are 2 possible approach to such tools :
>
> * 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 provide different needs. For simple projects using maven,
Ant's build.xml file isn't really needed at all. Unfortunately,
sometimes there are more complex requirements.
The project.xml file is useful for a couple of reasons:
1) Documentation framework builds the index.html from the project
description.
2) Dependent descriptors for realizing GUMP and JJar distribution
networks can be generated from the core.
Currently, Maven uses both the build.xml and the project.xml.
For most tags, the build.xml file merely delegates work to maven.
There is a lot to like with the project descriptor as it stands.
Unfortunately, if you deviate from a simple build, things get
a bit more complicated.
Example:
Project Foo has optional dependancies. If the jars exist, Ant
will compile the optional jars. This can be accomplished by
copying the source and removing the class files that are affected
before forwarding the targets to Maven. Maven should be able
to download the necessary jars for you--which if it is in the
"repository" (directory on Maven's site) it will do that.
However, if you have several jars that are built, do you
have a project.xml for each jar?
That is where the the project descriptor breaks down.
You do have to consider what a project descriptor is for:
to describe a project. It is not a build file, although it
can be used to generate a build file. In fact, that might
not be a bad idea.
Anyone who has built a C based GNU software project knows that
you type "./configure; make all check" to get a binary and run
any tests for it. The configure and build scripts are generated
from autoconf/automake/libtool build environment scripts. While
I don't like the obtuseness of M4 as a language, the concept is
fairly powerful.
If Maven could be moved into the role of the autoconf/automake/libtool,
we can have the advantage of both a project descriptor and a
templated build file.
Maven would generate the *real* Ant build file from the template in the
project directory. Something like this could work:
/foo
project.xml
build.template
build.xml
Build.template would look something like this:
<project
xmlns:maven="http://jakarta.apache.org/turbine/maven/template/v1.0">
<target name="docs">
<maven:docs>
<maven:src>
<pathelement file="...."/>
</maven:src>
</maven:docs>
</target>
</project>
That way the project developers have finer grained control over the
actual build process without massacering the project.xml and forcing
it to do things it should not do.
Thoughts?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>