Claas Thiele wrote:
There are at least 2 use cases of import: (1) providing reusable functionality - providing ant build file fragments by framework distributors - using parts of a buildsystem in a cross project manner. (2) linking subprojects in a large project
Both partially contrary in terms of basedir handling.
For (1) imported functionality would be used in the context of the main project. Basedir should always the basedir of the main project.
For (2) imported functionality would be used in the context of the import (the subproject). The basedir should be set to import context.
proposed behavior:
If basedir is set in project element it means: basedir is set in context to the file containing the project element (as before). This is used for subproject handling.
If basedir is not set it will be inherited from the importing project. Thats for module usage.
May be downward compatible (basedir not set in main project is always '.').
Sometimes it is necessary to address resources in the context of an import. For that reason the basedir (context) of each imported project should be accessible from everywhere. A property can be instanciated with name like imports.<import-name>.basedir while importing a project. imports.basedir should be responsible for main (root) projects basedir so root context is accessible from everywhere.
Implementation proposal for basedir handling:
Each target is executed in a context holding the basedir. If basedir is set in an imported project a new context is instanciated and used. Otherwise the existing context is used. So basedir is hold by a context not the project.
Proposed behavior for target and property name prefixing
Each target and property name and id (forgot something?) should be seen as in a namespace. The namespace is formed by the containing project and named by the containing project name. Inside a project the namespace (prefix) is implicit and can be omitted. Referencing targets and properties outside the containing project the namespace is used.
The resulting name or id is constructed by namespace, delemiter, local name.
The root resources can be referenced using an empty namespace (lokal name with preceding delimiter).
Concrete examples at http://ct42.de/en/ch02s05.html (Except the root of imported files is named 'module'):
Namespace collisions by independent developed imports can be prevented by using naming conventions like for java packages (preceed url of provider of import).
Proposed implementation:
It is done for targets in ANTModule (http://ct42.de/en/ch02.html) in a special ProjectHelperImpl while parsing the project file. ANT integration hints are given (http://ct42.de/en/ch02s07.html). Additionally the namespace resolving functionality provided by the projecthelper must be used for all property names, id's and target names and dependencies while initialising this objects.
In my opinion importing and providing namespace related functionality should be placed in the projecthelper not in a task.
So the existing order problem for top level elements is solved automatically.
------------- Claas Thiele
http://ct42.de
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- Nick Chalko Show me the code. Centipede Ant + autodownloadable build plugins + needed jars autodownload. http://krysalis.org/centipede ---------------------------------------------------------------------
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
