Return-Path: Delivered-To: apmail-jakarta-ant-dev-archive@apache.org Received: (qmail 49592 invoked from network); 3 Apr 2002 10:08:40 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 3 Apr 2002 10:08:40 -0000 Received: (qmail 10616 invoked by uid 97); 3 Apr 2002 10:08:45 -0000 Delivered-To: qmlist-jakarta-archive-ant-dev@jakarta.apache.org Received: (qmail 10546 invoked by uid 97); 3 Apr 2002 10:08:44 -0000 Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Ant Developers List" Reply-To: "Ant Developers List" Delivered-To: mailing list ant-dev@jakarta.apache.org Received: (qmail 10516 invoked from network); 3 Apr 2002 10:08:43 -0000 Message-Id: <200204031008.g33A8Vi04778@mail019.syd.optusnet.com.au> Content-Type: text/plain; charset="utf-8" From: Peter Donald To: , , ant-dev@jakarta.apache.org Subject: Re: Ant approach vs Descriptor approach Date: Wed, 3 Apr 2002 19:57:03 +1000 X-Mailer: KMail [version 1.3.2] References: <000501c1da8d$e9d440d0$0200a8c0@octovma> In-Reply-To: <000501c1da8d$e9d440d0$0200a8c0@octovma> X-Wisdom-Cookie: . MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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: For additional commands, e-mail: