ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: Improt task and project basedir
Date Thu, 09 Jan 2003 09:01:48 GMT

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:
http://www.krysalis.org/cents/cents/index.html

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.


-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


Mime
View raw message