ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Rich" <>
Subject RE: AW: parsing ant build scripts from unusual sources
Date Sat, 16 Oct 2004 05:22:27 GMT
I agree with you up to a point. Ant is useful as a process control tool and
the process can be outside the realm of build. A build process is only one
type of process that Ant can handle. Other types of processes may lend
themselves to your ideas better than build.

For example, a localization process can be controlled through an Ant file
(that is what I am using it for). Given that we may have a database to use
in the l10n process we may want to include some process control information
in it for specific projects. If this process control information were in the
form of an Ant blob then we could use the database to help manage the
process right along with managing the translations.

For this purpose we may need your extensions for the <import> and
<properties> elements. I don't have any specific requirements at this time
but I am glad to see that there is a possible route to extending your ideas
to satisfy a more general requirement.

Thanks.  Bill 

Bill Rich
Wilandra Consulting LLC
1325 Addiewell Place
San Jose, CA  95120-3905
phone:      +1 408 268-2452
mobile:     +1 408 410-9713
Santa Cruz: +1 831 464-9007
fax:        +1 413 669-9716

-----Original Message-----
From: Robert Dockins [] 
Sent: Friday, October 15, 2004 8:51 PM
To: Bill Rich
Subject: RE: AW: parsing ant build scripts from unusual sources

On Fri, 2004-10-15 at 12:11, Bill Rich wrote:
> Here is a real example of what Dominique is referring to.


> In this example, if all the .xml files are contained in db blobs what 
> would I need to do to the <import> to make this work? How could I 
> develop the XML file using the file system them store it in the db without
changing it?

The cop-out answer is, make all build files self-contained and don't use
<import>; <properties> et al will be resolved relative to ${basedir}

The slightly more realsitic answer is that, because we are using the ant API
to initilize and run builds, we can simply use the enclosing application to
"import" multiple build files if necessary.  I think it could work something
like this:

Project project = new Project();
MyHelper helper = new MyHelper(); 
       //hacked up helper that loads from InputSource helper.parse( project,
mainBuildFileStream ); helper.parse( project, auxiliryBuildFileStream );
for( Iterator i=myProps.getKeys().iterator(); i.hasNext(); ) {
   String key=(String);
   project.setUserProperty( key, myProps.getProperty(key) ); }
project.init(); project.executeTarget("main");


I think this pattern is most usable for the kind of applications I have in
mind (ie, using ant as a kind of "action engine", where the ant build syntax
becomes a user-visible scripting tool).

To answer the question you have put, however, requires rethinking how ant
finds build script resources (and perhaps other resources as well). 
You would assign them some kind of identifier, which would be interpreted
depending on the context and delivered into the build. 
Perhaps we could add a <BuildResource> type or similar and do something

  <BuildResource id="L10NProcess/L10NProcess-macros"/>

  <BuildResource id="${USER}"/>

In a filesystem context, the id's are interpreted in a straightforward
manner.  In other contexts, some manner of mapping would have to be
performed (eg, for a database, perhaps something like "select script_text
from scripts where scrip_id = ?").

Is it worth the trouble?  Not for me.  I'll probably live with the fact that
I can't <import>.  Other people might be interested in doing something like
this.  However, I can't imagine a situation where migrating filesystem-based
build scripts to a database context would be desirable.  I'm thinking of
scripts that are designed with the limitations of the database context in
mind (in fact, this discussion is helping me discover exactily what those
limitations are).

For the people willing to accept the limitations, I think being able to load
from funky sources is a great way to repurpose ant.

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

View raw message