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. Costin 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: > 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. > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
