ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Chalko <>
Subject Re: Import use cases, basedir behavior and target, property prefixing
Date Wed, 15 Jan 2003 00:06:14 GMT
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.

I do not think (2) is a usecase for import.  I think it is better 
handled by the "ant" task.

> 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.

we already have ant.file.<>   Which is the complete path to 
the imported file.   The <dirname > task will already strip off the file 
name part.

> 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 
> automatically.
> -------------
> Claas Thiele
> -- 
> To unsubscribe, e-mail:   <>
> For additional commands, e-mail: <>

Nick Chalko                                         Show me the code.
  Ant + autodownloadable build plugins + needed jars autodownload.

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

View raw message