ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From roger day <>
Subject Re: pros and cons!
Date Wed, 21 Jul 2004 09:53:22 GMT
Thanks for that, it looks interesting. At first sight, it seems that
we're less wedded to any particular component model. All our
distributions contain loosely connected components, few of which need
classloaders. In addition, for our commercial products, we have
multiple build systems, none of which are currently Ant, in spite of
my persistent hammering. However, I'll download it and give it a spin.

Also, you might be interested in:

It's part of our project to produce distributions which can be
transformed into InstallAnywhere (ZeroG) distributions.


On Wed, 21 Jul 2004 07:55:47 +0200, Stephen McConnell
<> wrote:
> Roger:
> Magic is another project doing something similar to what you're
> describing below.
> Cheers, Steve.
> -----Original Message-----
> From: roger day []
> Sent: Tuesday, July 20, 2004 9:26 AM
> To: Ant Users List
> Subject: Re: pros and cons!
> Interestingly, I maintain a piece of software which is called the
> Warehouse. It's core is a set of XML which controls an "artifact
> repository" for distributions of software. The warehouse uses
> different files for these purposes - a build.xml, which drives
> whatever build tools are installed (*not* Ant currently) and
> partlist.xml to define what you say below. We also use product.xml
> files which allow us to define a product with it's components -
> something, I think, which Ant is missing.
> The original design was built from build files upwards, but this
> approach has been unsatisfactory.
> We (in the team that I work for) are going through a refactoring
> exercise where a distribution, or single deliverable is defined by a
> single XML manifest, and this is used to drive the deliveable
> configuration, the build, the distribution and the installation.
> If you do go down this route - and I'm not sure if the Ant team want
> to build XML which defines the configuration for a product - then Ant
> could, IMO, potentially, become a larger project, but this would look
> like feature creep unless Ant is given a serious overhaul.
> BTW, we're also considering using Ant as a minimalist installer as
> well...
> Roger
> > Pros and Cons I'm not sure about:
> > ---------------------------------
> >
> > Notions of a artifact repository (thing produced and consumed by
> builds)
> > is not something understood within ant.  It is existed then you could
> > consider path objects that acquired real absolute paths from abstract
> > repository artifact identifiers - which would potentially improve
> > significantly the reusabiliy of build.xml files.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message