ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject RE: Scope of Types
Date Fri, 01 Jun 2001 18:37:14 GMT
At 06:32 PM 6/1/01 +0100, Jose Alberto Fernandez wrote:
>The question for me is how reusable do we want the information in the "peer"
>projects to be. 

You know I advocate using it as a separate component ;)

>In one extreme, if we want it to behave like "include" (not
>that I am advocating anything) it will require for the including project to
>have access to anything available in the included project. Because it is
>like a macro expansion.

right - yuck.

>What we habe been talking is that <projectref> loads an instantiation of the
>project (given the <param>s passed in the declaration). You can access
>anything in the namesapace, any properties AND any IDed type instances. If
>you can access the instantiated values of a type, then it seems to be a
>logical consequence that you may need to have access to the type itself.

I am not sure we have 100% decided about accessing of propertys in other
projects just yet. At this stage I haven't seen any need for such

>For <tasks> one may have a simillar argument. If you have access to the
>targets in the instantiated project, you may also want to have access to the
>tasks defined in there.

not likely. I don't think any access path should have access to task
objects/proxys. We discussed this sort of thing ages ago with respect to
scripting using BSF task and it was generally poo pooed ;)

>For example a projectref may define a group of libraries that are used for
>performing its work. The tasks may be interdependent in the sense of
>compatibility between version or what have you.
>I would think, one may want all this things said in just one place, for
>maintainability reasons. The referring projects will just use the consistent
>by just indirecting on the projectref namespace.

I could see a need for centralizing it *if* we were making task definitions
not location independent. But I think it would be good to make typedefs
position independent. So much like you do "import;" everywhere
you need I think the same should apply to build files. The only exception
being tasks that are not packaged in an antlib jar - however I think that
that is rare case and we shouldn't encourage that sort of behaviour. 

>> Personally I would prefer namespace resolution for types (and
>> aspects) to
>> be static "type" information rather than dynamic "instance"
>> information. So
>> namespace of type would refer to the library it was exported
>> from (or a
>> user assigned value).
>But if you look at <projectref> as static. It is not a task, it is simillar
>to <taskdef> but for projects. I know that there is certain dynamic behavior
>for <taskdef> and such, but in principle it is defining a static thing that
>cannot once defined.

Yes - it is an integration of templating into the core ... *shudder*. I am
fairly certain I don't agree with your vision ;)

>> Can anyone give a good usecase forsharing type defs between
>> peer projects?
>Does anyone has a good example on when one may need a new type definition?
>The predefined ones have been sufficient for me. I would need something like
>that first, to be able to come up with an example. ;-)

I have a few. I use ant for content creation for a Virtual Environment
(think 3d game). This involves tasks for texture manipulation/packing,
geometry compiling/manipulation/packing, script compiling/manipulating etc.
I have to define all these taskdefs in the the top of my build files.

There is a similar case for a specialize build environment for web
development. Basically it is manipulating and shuffling web docs around
which required some specialized site-specific tasks.



| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |

View raw message