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 [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) ---------------------------------------------------------------------
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
