https://bz.apache.org/bugzilla/show_bug.cgi?id=70168
Stefan Bodewig <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- OS| |All --- Comment #1 from Stefan Bodewig <[email protected]> --- WRT to your last paragraph, the use case for the ${ant.file.projectname} properties is import/include rather than subbuilds, where ant.file is the importing file and task in the imported file can find the location of their own file using the property with the name of their own project defined in the imported file. Just as you I don't see an easy way to find you are inside a subproject build - you could rely on project.getExceutor() being an instance of SingleCheckExecutor but this will not work in contexts where executors are swapped out or AntMain creates subclasses of Project. And I don't see any easy way to find your parent project. I could think of hacks involving BuildListeners, but that's not a good way to deal with it IMHO. I'd like to better understand what you really want to with the references to the parent projects or even build files. As far as I understand one scenario is you want to access properties and referencs of the parent project without explicitly specifying them when creating the subproject. Here I believe one reason we'e done it the way it is might be isolation which we'd break by changing things be default. Where the bigger danger is subbuilds modifying the parent's properties or references. One approach I could think about is to add a magic reference to project that points to itself. The you could do something like (making up names) <ant..><reference refid="ant.project" to="parent.project"/>...</ant> and have the parent explicitly opt-in. -- You are receiving this mail because: You are the assignee for the bug.
