I don't know if a conclusion has been reached - but I think it is clear that we need a way to support the various
options - regardless of what default is chosen.
Costin,
My thoughts:
I think the <import> proposal is being overloaded with two concerns. A basic inclusion mechanism for build files which are suitable for inclusion and a more complex mechanism to compose independent builds into a single build context.
Trying to do the latter with import is probably not a good idea as it really requires multiple independent project instances within the build context. Renaming and prefixing things seems to me a kludge to fit this all into a single project context. The chance of interactions and collisions is very high. The whole basedir question is a symptom of this problem.
My preference, therefore, would be to keep things simple and use import as mostly a simple inclusion mechanism. The only basedir of importance in this case would be the top level project being run. All properties and paths would be resolved relative to this basedir regardless of the basedir of the project actually containing the task definition.
The renaming of clashing targets is something I have not looked into yet in much detail - it sounds useful for creating build templates and overriding generic build steps but perhaps this too should be removed in favour of simplicity.
I think a simple inclusion mechanism is still very useful. The builds have to be defined with inclusion in mind but this is not a bad thing.
So, what do you think - keep it simple :-)
Conor
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
