You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Claas Thiele <ct...@ct42.de> on 2003/01/14 23:52:47 UTC
Import use cases, basedir behavior and target, property prefixing
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Import use cases, basedir behavior and target, property prefixing
Posted by Claas Thiele <ct...@ct42.de>.
Nick Chalko wrote:
> Claas Thiele wrote:
>
>> Costin Manolache wrote:
>>
>>> Nick Chalko wrote:
>>>
>>>
>>>
>>>>> (2) linking subprojects in a large project
>>>>>
>>>>>
>>>>
>>>>
>>>> I do not think (2) is a usecase for import. I think it is better
>>>> handled by the "ant" task.
>>>>
>>>
>>>
>>>
>>> I think (2) is an important usecase - at least for me.
>>>
>>> If you use import, you can call any target you want from any
>>> of the build files, reuse fragments and targets
>>> from other build files, etc.
>>>
>>>
>> Possible disadvantages of <ant> use:
>> - cannot span dependencies to 'imported' targets
>> - cannot access properties and data (i.e. xmlcatalogs, ...) of
>> 'imported' files
>>
>> Example for missing dependecy feature:
>>
>> Assuming some subprojects. Each subproject uses a common library to
>> be build before building the subproject.
>> Calling the subprojects from main project via <ant> activates the
>> build of common lib for each subproject even it is not nessesary.
>
>
> I would leave inter project depenencies to Gump, or some other tool.
>
> I think use case 2 complicates import with providing enough to really
> handle what users want out of use case 2.
On second thought I agree.
Claas Thiele
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Import use cases, basedir behavior and target, property prefixing
Posted by Nick Chalko <ni...@chalko.com>.
Claas Thiele wrote:
> Costin Manolache wrote:
>
>> Nick Chalko wrote:
>>
>>
>>
>>>> (2) linking subprojects in a large project
>>>>
>>>>
>>>
>>> I do not think (2) is a usecase for import. I think it is better
>>> handled by the "ant" task.
>>>
>>
>>
>> I think (2) is an important usecase - at least for me.
>>
>> If you use import, you can call any target you want from any
>> of the build files, reuse fragments and targets
>> from other build files, etc.
>>
>>
> Possible disadvantages of <ant> use:
> - cannot span dependencies to 'imported' targets
> - cannot access properties and data (i.e. xmlcatalogs, ...) of
> 'imported' files
>
> Example for missing dependecy feature:
>
> Assuming some subprojects. Each subproject uses a common library to be
> build before building the subproject.
> Calling the subprojects from main project via <ant> activates the
> build of common lib for each subproject even it is not nessesary.
I would leave inter project depenencies to Gump, or some other tool.
I think use case 2 complicates import with providing enough to really
handle what users want out of use case 2.
Let me try to give a use case 2 example
<project name="main" >
<import name="common/build.xml">
<import name="sub1/build.xml">
<import name="sub2/build.xml">
<target name = "compile" depends "sub1-build.compile,
sub2-build.compile" />
</project>
<project name ="common>
<target name="compile" />
<project>
<project name ="sub1">
<target name="compile" depends="common-build.compile,sub2.compile"/>
<project>
<project name ="sub2-build">
<target name="compile" depends="common.compile"/>
<project>
given this case 2 would suggest
ant compile
would execute common-compile, sub2-build.compile, sub1-build.compile
even getting this is not enough, you still have to hangle classpath.
ant -f sub2/build.xml
will fail unless you add
<import file="../common.build.xml"/>
There is to many complications for import to handle on it's own.
Let another tool handle it.
--
Nick Chalko Show me the code.
Centipede
Ant + autodownloadable build plugins + needed jars autodownload.
http://krysalis.org/centipede
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Import use cases, basedir behavior and target, property prefixing
Posted by Claas Thiele <ct...@ct42.de>.
Costin Manolache wrote:
>Nick Chalko wrote:
>
>
>
>>>(2) linking subprojects in a large project
>>>
>>>
>>>
>>I do not think (2) is a usecase for import. I think it is better
>>handled by the "ant" task.
>>
>>
>
>I think (2) is an important usecase - at least for me.
>
>If you use import, you can call any target you want from any
>of the build files, reuse fragments and targets
>from other build files, etc.
>
>
Possible disadvantages of <ant> use:
- cannot span dependencies to 'imported' targets
- cannot access properties and data (i.e. xmlcatalogs, ...) of
'imported' files
Example for missing dependecy feature:
Assuming some subprojects. Each subproject uses a common library to be
build before building the subproject.
Calling the subprojects from main project via <ant> activates the build
of common lib for each subproject even it is not nessesary.
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Import use cases, basedir behavior and target, property prefixing
Posted by Costin Manolache <cm...@yahoo.com>.
Nick Chalko wrote:
>> (2) linking subprojects in a large project
>>
> I do not think (2) is a usecase for import. I think it is better
> handled by the "ant" task.
I think (2) is an important usecase - at least for me.
If you use import, you can call any target you want from any
of the build files, reuse fragments and targets
from other build files, etc.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Import use cases, basedir behavior and target, property prefixing
Posted by Nick Chalko <ni...@chalko.com>.
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.
Agree
>
> 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.<project.name> 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 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: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
Nick Chalko Show me the code.
Centipede
Ant + autodownloadable build plugins + needed jars autodownload.
http://krysalis.org/centipede
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Import use cases, basedir behavior and target, property prefixing
Posted by Nick Chalko <ni...@chalko.com>.
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: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
Nick Chalko Show me the code.
Centipede
Ant + autodownloadable build plugins + needed jars autodownload.
http://krysalis.org/centipede
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>