ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob van Oostrum <rvanoost...@ezgov.com>
Subject Re: [VOTE] The late stuff
Date Thu, 26 Apr 2001 12:21:12 GMT
here's a nested property reference use case that I posted to the user list
the other day:

I have a generic script that will build, let's say 'an application'. One
of the properties I need to do this, is the service name of the web server
that this application is running on (what I'm trying to give developers is
the abiltity to get a project from source control, execute the ant script,
and have a fully operational instance of the application. Since developers
work on different projects that may very well run on different versions of
different web servers, you will need to configure the name of the service
on a per-developer basis).

My master build file invokes my generic app build script passing the
project name as a property. So the name of the property in the generic app
script is httpd.service.name.${project.name}

Setting the property works fine, but what's the point in this if I'm not
able to reference the property

I more or less hardcode the defaults (by setting the property to default
properties inside the project, so that introducing the props in a prop
file overrides them), and I want developers to be able to override this
property on a per-project basis. So rather than have a httpd.service.name
property, I call it httpd.service.name.[project name]. Developers can then
go into a file build.properties and override for example the
httpd.service.name.coreapp property, without affecting their builds of any
other app. As I will need to build in more and more of this flexibility
(different web/app servers use different structures for deploying
webapps), I really really need these nested property refs to make this
work, and I think it only makes sense to have them. I tried working around
not having the nested prop refs by using ant calls, but it gets really
ugly really fast.

If the code for parsing these strings is set up to work recursively (the
only 'drawback' IMHO would be that you can't use the ${} chars in property
names, which is a good rule to have anyway), it shouldn't cause too many
problems. Unless of course the way the code that handles this is currently
set up in a way that makes it difficult to add this kind of functionality.

I'm new to the DEV list, so could somebody explain to me what the argument
is for not having it (other than "what's the point of having it?"). I'd be
more than happy to help out on the development of this, if that's what
it'll take.

cheers
Rob

Stefan Bodewig wrote:

> >>> * recursive property resolution( ie resolving ${dist.${name}.dir}
> >>> * )
> >>
> >>Could I have a use case for this please - something real worldish,
> >>that you cannot (conveniently) solve be something other than that?
> >
> > I use the pattern all the way through my Makefiles to implement
> > "generic targets". Ie you define a whole lot of properties like
>
> I agree with your later opinion that <antcall> would solve this
> use case nicely.
>
> Stefan


Mime
View raw message