ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claas Thiele <>
Subject Import use cases, basedir behavior and target, property prefixing
Date Tue, 14 Jan 2003 22:52:47 GMT
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 (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 ( in a 
special ProjectHelperImpl while parsing the project file. ANT 
integration hints are given ( 
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 

Claas Thiele

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message