ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject Re: Improt task and project basedir
Date Thu, 09 Jan 2003 15:25:35 GMT
What about introducing a "BuildFile" in ProjectHelper - to store info about
the file that is processed - including location and other info that we
might need in future. The "resolve" can take into account the build file.
( and the helper would associate the UE with the BuildFile )

Seems clean.

Regarding behavior - we should look at XSLT if applicable, but try
to keep it simple. I think we can implement both choices ( basedir of
the parent or basedir of imported file ), and we could make it 
customizable if really needed.

I preffer using regular ant files and resolving based on the imported
file location ( and basedir ). This would allow imported files to also
work standalone - for example tomcat has 4-5 big components and a master
build file that calls the smaller buildfiles. 


Nicola Ken Barozzi wrote:

> Conor MacNeill wrote:
>> Jose Alberto Fernandez wrote:
>>> This seem to be a not so simple issue.
>> Indeed. As I've thought about it more, I wonder what we should be doing
>> here. All the other tasks in the imported build file will be resolving
>> relative to the basedir of the importing build, not the build in which
>> they are defined. Is that good? I feel it may cause some problems, some
>> unexpected behaviour.
> This is the reason why I asked to introduce the ant.file.projectname
> property, that gives me the real path of the imported build.
>> Perhaps we need to examine the use cases for imported builds. I'm sure
>> Nicola Ken will tell me some :-)
> :-)
> Centipede is based on this, because it makes it possible to use
> predefined targets.
> What happens is that we use plugins called cents that are in fact jars
> that contain a buildfile to import, some tasks, resources and classes.
> These are versioned, and autodownloaded and autoimported.
> Here are some cents we have built:
> More are in CVS.
>> If the imported files need to be designed apriori to be importable,
> Now it does, and I tend to think that it's not a bad thing. Similarly
> buildfiles called by <ant> in many cases are designed to be called by a
> parent.
>> then
>> perhaps we should use a different container element for them.
>> <importable> instead of <project> and leave the basedir out of it.
> A normal project does not necessarily behave well if imported, because
> of the basedir issue, but it can. Probably we should set the
> ant.file.projectname  property for the main buildfile too to fully
> enable this.
> An imported file might not necessarily behave well if not imported,
> since it might rely on prior properties being set.
> My point is that this solution should have the least possible complexity
> for the users. That means that I'm not against <importable>, but I do
> question the actual need of it. We already use <ant> with inherited
> properties by default, and this ties the called file to the caller in
> the same way; users have learned to expect this.
> To solve the problem we could add a importable="true" attribute to the
> project. We can post a message that warns that it's not marked as
> importable, and if the build fails and a file was imported, we can add
> to the message a note that tells the user that the file that was
> imported was not marked as importable.

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

View raw message