ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <>
Subject Re: programmatically creating and marshalling antfiles
Date Fri, 12 Aug 2005 10:05:41 GMT
Jack Woehr wrote:
> Steve Loughran wrote:
>> Even if you could retro-fit every task out there with getters,
>>   -what about overloaded set operatons? which one should the get return?
>>   -what about property assignments. Tasks get their setters with 
>> properties expanded.

also there is the issue of addXXX things; that is, nested elements.

> Hmm. Ah, well. Writing out the project seems to be a fairly obvious 
> functionality in comparison
> to some of the exotic functionality of Ant. I guess it's just one of 
> those things which in hindsight
> the design should have accomodated, but which are difficult to retrofit 
> given that the design
> did not so accomodate.

Maybe it depends what you want to write things out for. It isnt normal 
'build process' stuff, and the more you add to the requirements of a 
task, the harder it is for a task to be implemented,

In smartfrog, the deployment descriptors do get marshalled across the 
network, so there is a model of the configuration graph that is separate 
from the state of the components that deploy the different things on the 
graph. But this is done at the expense of introspective binding to 
setters; you need to explicitly get things, here getting some options 
with the default false and a required flag of false (i.e. optional).

         mustExist = getBool(ATTR_MUST_EXIST, false, false);
         mustRead = getBool(ATTR_MUST_WRITE, false, false);
         mustWrite = getBool(ATTR_MUST_READ, false, false);
         mustBeDir = getBool(ATTR_MUST_BE_DIR, false, false);
         mustBeFile = getBool(ATTR_MUST_BE_FILE, false, false);
         testOnStartup = getBool(ATTR_TEST_ON_STARTUP, false, false);
         testOnLiveness = getBool(ATTR_TEST_ON_LIVENESS, false, false);

In this bit of the fileimpl class, I then set more attributes describing 
file state:, after probing the full path/state of the file, namely the 
absolutePath and uri attributes, plus some boolean values

defval,null, true,null);
	File newfile=new File(absolutePath);
         sfReplaceAttribute(ATTR_ABSOLUTE_PATH, newfile.getAbsolutePath());
         String uri;
         uri = newfile.toURI().toString();
         sfReplaceAttribute(ATTR_URI, uri);

         setAttribute(ATTR_EXISTS, exists);
         setAttribute(ATTR_IS_DIRECTORY, isDirectory);
         setAttribute(ATTR_IS_FILE, isFile);
         setAttribute(ATTR_IS_EMPTY, isEmpty);
         setAttribute(ATTR_IS_HIDDEN, isHidden);
         setAttribute(ATTR_TIMESTAMP, timestamp);
         setAttribute(ATTR_LENGTH, length);

         String name = getFile().getName();
         setAttribute(ATTR_SHORTNAME, name);

This is cool, as then other things can be deployed that are bound at 
runtime to the absolute values of things, even things deployed on 
different boxes. But this was (a) designed from the outset, (b) 
increases some of the complexity of binding to the system and (c) also 
drops out early-binding cross-references, things that are resolved 
during the parse phase. Which is what you need when you want to sign a 
descriptor as secure before you send it to someone - late binding 
information is more of a security risk, as the things you bind to may be 
less secure.

note also that the security person always complains if we set attributes 
to things that arent serializable. Really the signature of the attribute 
set/replace operations should be (String, Serializable), not (String, 

A weakness of this approach is that after something is deployed, its 
state isnt always updated, so there is no way to change a deployed 
component except by undeploying/redeploying it. Ant lets you set 
different attributes and  call execute()  again.


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

View raw message