You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Peter Donald <do...@apache.org> on 2001/06/01 05:57:11 UTC
Scope of Types
Hi,
I would like to see what people think about the scope of Type definitions
in Ant2. Types include things like tasks, mappers, filesets etc. There has
been three different scopes proposed so far; flat, hierarchial and global.
Global is the scope that Ant1 uses. Once registered a taskdef can no be
unregistered.
Flat is the scope that Connor discussed a bit back (especially in regard to
things like namespace resolution). In this scope the type is defined only
in a particular project. So if you define task "blah" it is only present in
current project. To access a type definition from another project you use
namespace resolution. ie "otherProject:taskname" (though the particular
namespace operator needs to be looked at again.
Hierarchial is like Flat except that any type definitions are inherited by
child projects (ie those invoked by antcall/ant tasks).
My personal preference is for either Flat or Global. Hierarchial can
introduce far too many ambiguities in a project file resolved according to
a context.
Flat is theoretically the best example because all definitions are local.
However I guess I am worried about usability. While the default types could
be registered in every project, it could be troublesome when building large
build files.
If flat is deemed not so useable then I would like to use Global scope.
Thoughts?
Cheers,
Pete
*-----------------------------------------------------*
| "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 |
*-----------------------------------------------------*
RE: Scope of Types
Posted by Peter Donald <do...@apache.org>.
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
functionality.
>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 java.net.URL;" 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.
Cheers,
Pete
*-----------------------------------------------------*
| "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 |
*-----------------------------------------------------*
Re: Scope of Types
Posted by Peter Donald <do...@apache.org>.
At 09:49 AM 6/6/01 +0200, Stefan Bodewig wrote:
>Peter Donald <do...@apache.org> wrote:
>
>> At 09:27 AM 6/6/01 +0200, Stefan Bodewig wrote:
>>
>>>What's the difference between "knowing about a type" and "sharing
>>>the definition of a type"?
>>
>> "knowing about a type" does not imply "***sharing*** the definition
>> of type" between projects.
>
>OK, got your point, finally. 8-)
;)
>Not sharing the definition implies that both projects define the types
>separately - how would you ensure consistency?
same way as it is done in java. "import java.net.URL" is location
independent and means import of same type regardless of where it occurs. I
believe we can achieve the same with antlibs. Types outside libs are
difficult to support across projects - I am not sure we should try to. If
the user does not want to create a manifest/descriptor then they pray and
hope ;)
Cheers,
Pete
*-----------------------------------------------------*
| "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 |
*-----------------------------------------------------*
Re: Scope of Types
Posted by Stefan Bodewig <bo...@apache.org>.
Peter Donald <do...@apache.org> wrote:
> At 09:27 AM 6/6/01 +0200, Stefan Bodewig wrote:
>
>>What's the difference between "knowing about a type" and "sharing
>>the definition of a type"?
>
> "knowing about a type" does not imply "***sharing*** the definition
> of type" between projects.
OK, got your point, finally. 8-)
Not sharing the definition implies that both projects define the types
separately - how would you ensure consistency?
Stefan
Re: Scope of Types
Posted by Peter Donald <do...@apache.org>.
At 09:27 AM 6/6/01 +0200, Stefan Bodewig wrote:
>> If by "data-type must be available to 'outer' project" you mean the
>> project that creates instance must know about datatype - then I
>> agree.
>
>> I thought you were saying you should be able to share
>> imports/definitions of types (ie not instances) between projects.
>
>What's the difference between "knowing about a type" and "sharing the
>definition of a type"?
"knowing about a type" does not imply "***sharing*** the definition of
type" between projects. Projects share instances of a type but I can't see
a reason to share types themselves (or type designators as the case may be).
Cheers,
Pete
*-----------------------------------------------------*
| "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 |
*-----------------------------------------------------*
Re: Scope of Types
Posted by Stefan Bodewig <bo...@apache.org>.
Sorry Pete, must be my dumb week (months?), I don't get it.
Peter Donald <do...@apache.org> wrote:
> If by "data-type must be available to 'outer' project" you mean the
> project that creates instance must know about datatype - then I
> agree.
> I thought you were saying you should be able to share
> imports/definitions of types (ie not instances) between projects.
What's the difference between "knowing about a type" and "sharing the
definition of a type"?
Stefan
Re: Scope of Types
Posted by Peter Donald <do...@apache.org>.
At 02:05 PM 6/5/01 +0200, Stefan Bodewig wrote:
>Peter Donald <do...@apache.org> wrote:
>
>> At 11:20 AM 6/5/01 +0200, Stefan Bodewig wrote:
>>>Using something via refid implies a typed value, using ${} does not
>>>- especially if the defining project doesn't know the type project B
>>>will be using.
>>
>> okay - in that case I would just treat it as a normal proeprty and
>> if it can not be resolved (and possibly converted) to be of correct
>> type then it throws a TaskException.
>
>Which means that it has been of the correct type right from the
>beginning (no conversion necessary) - data-type must be available to
>"outer" project, or somebody has defined a String->type converter,
>right?
If by "data-type must be available to 'outer' project" you mean the project
that creates instance must know about datatype - then I agree. I thought
you were saying you should be able to share imports/definitions of types
(ie not instances) between projects.
Cheers,
Pete
*-----------------------------------------------------*
| "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 |
*-----------------------------------------------------*
Re: Scope of Types
Posted by Stefan Bodewig <bo...@apache.org>.
Peter Donald <do...@apache.org> wrote:
> At 11:20 AM 6/5/01 +0200, Stefan Bodewig wrote:
>>Using something via refid implies a typed value, using ${} does not
>>- especially if the defining project doesn't know the type project B
>>will be using.
>
> okay - in that case I would just treat it as a normal proeprty and
> if it can not be resolved (and possibly converted) to be of correct
> type then it throws a TaskException.
Which means that it has been of the correct type right from the
beginning (no conversion necessary) - data-type must be available to
"outer" project, or somebody has defined a String->type converter,
right?
Stefan
Re: Scope of Types
Posted by Peter Donald <do...@apache.org>.
At 11:20 AM 6/5/01 +0200, Stefan Bodewig wrote:
>Peter Donald <do...@apache.org> wrote:
>
>> At 09:36 AM 6/5/01 +0200, Stefan Bodewig wrote:
>>>Your counterargument is sharing values via the ${} syntax doesn't
>>>require sharing types - but what if you want to share IDs?
>>
>> whats the difference between IDs and property values?
>
>Using something via refid implies a typed value, using ${} does not -
>especially if the defining project doesn't know the type project B
>will be using.
okay - in that case I would just treat it as a normal proeprty and if it
can not be resolved (and possibly converted) to be of correct type then it
throws a TaskException. Thoughtts?
Cheers,
Pete
*-----------------------------------------------------*
| "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 |
*-----------------------------------------------------*
RE: Scope of Types
Posted by Peter Donald <do...@apache.org>.
At 04:44 PM 6/5/01 +0100, Jose Alberto Fernandez wrote:
>> From: Peter Donald [mailto:donaldp@apache.org]
>>
>> >How can I pass a type-value as a parameter to <ant*> I
>> probably do not want
>> >to have to declare the value since I do not want a binding
>> created on the
>> >calling project.
>>
>> As datatype instances are just properties, you pass like any
>> other property.
>>
>> <ant ... >
>> <param name="blah" value="${my.fancy.new.fileset.instance}" />
>> </ant>
>>
>
>What I meant to ask was whether is is possible to pass a value without
>declaring a property in the CALLER project with that value.
>
> <ant ...>
> <param name="myProp" value="3"/> <!-- I do not need to define a prop -->
> <param name="filesetvalue" >
> <fileset ....> <!-- I want to be able to use a locally defined fileset
> like I can do on the <javac> task, for
>example -->
> </param>
> </ant>
>
>That is what I would like to get solved.
It would be easy to implement (assuming we have a DataType interface). Not
sure if it is a good idea though. I suppose it could be useful if you had a
large number of ant-calls.
Cheers,
Pete
*-----------------------------------------------------*
| "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 |
*-----------------------------------------------------*
RE: Scope of Types
Posted by Jose Alberto Fernandez <j_...@yahoo.com>.
> From: Peter Donald [mailto:donaldp@apache.org]
>
> >How can I pass a type-value as a parameter to <ant*> I
> probably do not want
> >to have to declare the value since I do not want a binding
> created on the
> >calling project.
>
> As datatype instances are just properties, you pass like any
> other property.
>
> <ant ... >
> <param name="blah" value="${my.fancy.new.fileset.instance}" />
> </ant>
>
What I meant to ask was whether is is possible to pass a value without
declaring a property in the CALLER project with that value.
<ant ...>
<param name="myProp" value="3"/> <!-- I do not need to define a prop -->
<param name="filesetvalue" >
<fileset ....> <!-- I want to be able to use a locally defined fileset
like I can do on the <javac> task, for
example -->
</param>
</ant>
That is what I would like to get solved.
Jose Alberto
RE: Scope of Types
Posted by Peter Donald <do...@apache.org>.
At 04:02 PM 6/5/01 +0100, Jose Alberto Fernandez wrote:
>So how does this work for a task like <javac> that has a Path for the
>classpath and another Path for the src path. Do I need to declare the values
>before using them int he task? Can it be substitured in place?
doesn't effect the task in any way. It works exactly like it does now.
>How can I pass a type-value as a parameter to <ant*> I probably do not want
>to have to declare the value since I do not want a binding created on the
>calling project.
As datatype instances are just properties, you pass like any other property.
<ant ... >
<param name="blah" value="${my.fancy.new.fileset.instance}" />
</ant>
Cheers,
Pete
*-----------------------------------------------------*
| "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 |
*-----------------------------------------------------*
RE: Scope of Types
Posted by Jose Alberto Fernandez <j_...@yahoo.com>.
> From: Peter Donald [mailto:donaldp@apache.org]
>
> There is actually a nice way to do it that I have been playing with
> recently. It is a side-effect of AbstractContainerTask. The
> AbstractContainerTask is passed TaskModel. It strips the
> attribute name out
> of top-level element and then uses remainder of TaskModel to
> configure the
> data type. The name of the datatype (as used to create instance from
> TypeRegistry) is same as name for task.
>
> So lets assume the following
>
> <fileset name="foo" dir="blah">
> <include name=".../>
> ...
> </fileset>
>
> And lets assume that above that there is definition
>
> <datadef name="fileset" class="org.apache.ant.framework.FileSet"/>
> <taskdef name="fileset"
> class="org.apache.ant.framework.TypeInstanceTask"/>
>
> The task would first identify that name of task is 'fileset'
> and thus it
> would look that up in type registry and create an instance of
> 'fileset'
> datatype. It would then extract top-level attribute 'name'
> from TaskModel
> (the value of which is 'foo'). It would then use remaining part of
> TaskModel to configure the instance. if that is successful it would
> setProperty("foo", fileset ).
>
> Creating new datatypes and coresponding class would be as simple as
>
> <datadef name="patternset"
> class="org.apache.ant.framework.PatternSet"/>
> <taskdef name="patternset"
> class="org.apache.ant.framework.TypeInstanceTask"/>
>
> Easy to implement and easy on user. So in a way I like it.
> Slightly extra
> work (an extra typedef per datatype) but well worth it in my opinion.
>
So how does this work for a task like <javac> that has a Path for the
classpath and another Path for the src path. Do I need to declare the values
before using them int he task? Can it be substitured in place?
How can I pass a type-value as a parameter to <ant*> I probably do not want
to have to declare the value since I do not want a binding created on the
calling project.
I think that is where the pickle of the problem is.
Jose Alberto
RE: Scope of Types
Posted by Peter Donald <do...@apache.org>.
At 12:33 AM 6/6/01 +1000, Peter Donald wrote:
>>Maybe if someone makes a proper case the matter can be re-voted. Was the
>>original vote based on some very strong arguments or was just a go with flow
>>kind of vote? I really have no recollection.
>
>IIRC it was vetoed by Conor because it was too generic and didn't buildfile
>user anything (only task file writer) - at least that was I believe the
>reason. I kinda agree with it too.
TYPO - >
IIRC it was vetoed by Conor because it was too generic and didn't buildfile
user anything (only task writer) - at least that was I believe the
reason. I kinda agree with it too.
Cheers,
Pete
*-----------------------------------------------------*
| "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 |
*-----------------------------------------------------*
RE: Scope of Types
Posted by Peter Donald <do...@apache.org>.
At 01:19 PM 6/5/01 +0100, Jose Alberto Fernandez wrote:
>> From: Stefan Bodewig [mailto:bodewig@apache.org]
>>
>> Jose Alberto Fernandez <j_...@yahoo.com> wrote:
>>
>> > Well, the current rules would require <projectref> to allow for a
>> > <A:mailaddressset> element. But you cannot have it because is
>> > dynamically generated.
>>
>> Right, this is one (the?) major drawback of not collecting all
>> data-types under one construct (be it Peter's <set-item> or an unified
>> <property> or whatever). This is the outcome of the vote, and we have
>> to live with it - but somehow <ant*> and <projectref> will need to
>> deal with non-String properties.
>>
>
>Well, even politicians change their minds. :-)
>
>Maybe if someone makes a proper case the matter can be re-voted. Was the
>original vote based on some very strong arguments or was just a go with flow
>kind of vote? I really have no recollection.
IIRC it was vetoed by Conor because it was too generic and didn't buildfile
user anything (only task file writer) - at least that was I believe the
reason. I kinda agree with it too.
>If we come to believe, given the current more concrete picture, that
>architecturally it would be better to do something different from what was
>voted, I do not see why this cannot be discussed.
There is actually a nice way to do it that I have been playing with
recently. It is a side-effect of AbstractContainerTask. The
AbstractContainerTask is passed TaskModel. It strips the attribute name out
of top-level element and then uses remainder of TaskModel to configure the
data type. The name of the datatype (as used to create instance from
TypeRegistry) is same as name for task.
So lets assume the following
<fileset name="foo" dir="blah">
<include name=".../>
...
</fileset>
And lets assume that above that there is definition
<datadef name="fileset" class="org.apache.ant.framework.FileSet"/>
<taskdef name="fileset" class="org.apache.ant.framework.TypeInstanceTask"/>
The task would first identify that name of task is 'fileset' and thus it
would look that up in type registry and create an instance of 'fileset'
datatype. It would then extract top-level attribute 'name' from TaskModel
(the value of which is 'foo'). It would then use remaining part of
TaskModel to configure the instance. if that is successful it would
setProperty("foo", fileset ).
Creating new datatypes and coresponding class would be as simple as
<datadef name="patternset" class="org.apache.ant.framework.PatternSet"/>
<taskdef name="patternset" class="org.apache.ant.framework.TypeInstanceTask"/>
Easy to implement and easy on user. So in a way I like it. Slightly extra
work (an extra typedef per datatype) but well worth it in my opinion.
Cheers,
Pete
*-----------------------------------------------------*
| "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 |
*-----------------------------------------------------*
Re: Scope of Types
Posted by Stefan Bodewig <bo...@apache.org>.
Jose Alberto Fernandez <j_...@yahoo.com> wrote:
> Was the original vote based on some very strong arguments or was
> just a go with flow kind of vote? I really have no recollection.
Just looked it up in my archives:
Peter has been +1 on having a common element, I've been +0 and -0
respectively (I saw no real reason for the unified element), Glenn
went -1 (why would we need this, we already have unified ${} handling)
and Conor -1ed it because "People want to feel that they are dealing
with filesets, not properties which happen to be filesets."
> If we come to believe, given the current more concrete picture, that
> architecturally it would be better to do something different from
> what was voted, I do not see why this cannot be discussed.
Didn't mean to imply that.
Stefan
RE: Scope of Types
Posted by Jose Alberto Fernandez <j_...@yahoo.com>.
> From: Stefan Bodewig [mailto:bodewig@apache.org]
>
> Jose Alberto Fernandez <j_...@yahoo.com> wrote:
>
> > Well, the current rules would require <projectref> to allow for a
> > <A:mailaddressset> element. But you cannot have it because is
> > dynamically generated.
>
> Right, this is one (the?) major drawback of not collecting all
> data-types under one construct (be it Peter's <set-item> or an unified
> <property> or whatever). This is the outcome of the vote, and we have
> to live with it - but somehow <ant*> and <projectref> will need to
> deal with non-String properties.
>
Well, even politicians change their minds. :-)
Maybe if someone makes a proper case the matter can be re-voted. Was the
original vote based on some very strong arguments or was just a go with flow
kind of vote? I really have no recollection.
If we come to believe, given the current more concrete picture, that
architecturally it would be better to do something different from what was
voted, I do not see why this cannot be discussed.
Jose Alberto
Re: Scope of Types
Posted by Stefan Bodewig <bo...@apache.org>.
Jose Alberto Fernandez <j_...@yahoo.com> wrote:
> Well, the current rules would require <projectref> to allow for a
> <A:mailaddressset> element. But you cannot have it because is
> dynamically generated.
Right, this is one (the?) major drawback of not collecting all
data-types under one construct (be it Peter's <set-item> or an unified
<property> or whatever). This is the outcome of the vote, and we have
to live with it - but somehow <ant*> and <projectref> will need to
deal with non-String properties.
Stefan
RE: Scope of Types
Posted by Jose Alberto Fernandez <j_...@yahoo.com>.
> From: Stefan Bodewig [mailto:bodewig@apache.org]
>
> Jose Alberto Fernandez <j_...@yahoo.com> wrote:
>
> >> From: Stefan Bodewig [mailto:bodewig@apache.org]
>
> >> >><projectref name="A">
> >> >> <A:mailaddressset id="send-report-to">
> >> >> <address to="bodewig@apache.org" />
> >> >> </A:mailaddressset>
> >> >></projectref>
> >> >
> >
> > Here you are defining an id for 'A' within a pseudo-task, so the
> > blank rule about forbidding this sort of thing may not be
> > correct.
>
> Who said I wanted to forbid what? 8-)
>
> Datatypes shouldn't be treated different than properties, right? If I
> can define properties via param, I must have a way to define arbitrary
> data types and pass them to subbuilds or projectrefs as well IMHO.
>
Well, the current rules would require <projectref> to allow for a
<A:mailaddressset> element. But you cannot have it because is dynamically
generated. I would seem that we need something like <param> that allows for
any datatype element specification inside. Much like the <set-item>
operation I think Peter was talking about.
This kinds of issues is what makes me think we are making some funny
distinctions between <properties> and <typedefs>. There seem to be some
missing unifying concept for both. Maybe what was called <item>.
Jose Alberto
Re: Scope of Types
Posted by Stefan Bodewig <bo...@apache.org>.
Jose Alberto Fernandez <j_...@yahoo.com> wrote:
>> From: Stefan Bodewig [mailto:bodewig@apache.org]
>>
>> Peter Donald <do...@apache.org> wrote:
>>
>> > whats the difference between IDs and property values?
>>
>> Using something via refid implies a typed value, using ${} does not
>> - especially if the defining project doesn't know the type project
>> B will be using.
>
> This looks kind of artificial to me. why can't I say <property
> id="..." /> meaning the same thing as name="...." ?
You can. I was talking about refid="..." vs. ${}.
>> >><projectref name="A">
>> >> <A:mailaddressset id="send-report-to">
>> >> <address to="bodewig@apache.org" />
>> >> </A:mailaddressset>
>> >></projectref>
>> >
>
> Here you are defining an id for 'A' within a pseudo-task, so the
> blank rule about forbidding this sort of thing may not be
> correct.
Who said I wanted to forbid what? 8-)
Datatypes shouldn't be treated different than properties, right? If I
can define properties via param, I must have a way to define arbitrary
data types and pass them to subbuilds or projectrefs as well IMHO.
Stefan
RE: Scope of Types
Posted by Jose Alberto Fernandez <j_...@yahoo.com>.
> From: Stefan Bodewig [mailto:bodewig@apache.org]
>
> Peter Donald <do...@apache.org> wrote:
>
> > At 09:36 AM 6/5/01 +0200, Stefan Bodewig wrote:
> >>Your counterargument is sharing values via the ${} syntax doesn't
> >>require sharing types - but what if you want to share IDs?
> >
> > whats the difference between IDs and property values?
>
> Using something via refid implies a typed value, using ${} does not -
> especially if the defining project doesn't know the type project B
> will be using.
>
This looks kind of artificial to me. why can't I say <property id="..." />
meaning the same thing as name="...." ?
> >><projectref name="A">
> >> <A:mailaddressset id="send-report-to">
> >> <address to="bodewig@apache.org" />
> >> </A:mailaddressset>
> >></projectref>
> >
Here you are defining an id for 'A' within a pseudo-task, so the blank rule
about forbidding this sort of thing may not be correct. You could apply the
same reasoning to <ant*> calls.
Jose Alberto
Re: Scope of Types
Posted by Stefan Bodewig <bo...@apache.org>.
Peter Donald <do...@apache.org> wrote:
> At 09:36 AM 6/5/01 +0200, Stefan Bodewig wrote:
>>Your counterargument is sharing values via the ${} syntax doesn't
>>require sharing types - but what if you want to share IDs?
>
> whats the difference between IDs and property values?
Using something via refid implies a typed value, using ${} does not -
especially if the defining project doesn't know the type project B
will be using.
>><projectref name="B">
This should have been name="A" as I wanted to reference a datatype
defined in A from project B. Seems as if you've read what I wanted to
write anyway.
>> <A:mailaddressset id="send-report-to">
>> <address to="bodewig@apache.org" />
>> </A:mailaddressset>
>></projectref>
>
> In that case it is better to redefine mailaddressset in project B
> aswell.
Right, and I think projectref could do just that.
Stefan
Re: Scope of Types
Posted by Peter Donald <do...@apache.org>.
At 09:36 AM 6/5/01 +0200, Stefan Bodewig wrote:
>Peter Donald <do...@apache.org> wrote:
>
>> Can anyone give a good usecase forsharing type defs between peer
>> projects?
>
>Your counterargument is sharing values via the ${} syntax doesn't
>require sharing types - but what if you want to share IDs?
whats the difference between IDs and property values?
>Say project A defines a type mailaddressset - a set of email addresses
>to use in the to field of a custom mailreport task. In project A we
>have
>
><mailaddressset id="send-report-to">
> <address to="bodewig@apache.org" />
> <address to="donaldp@apache.org" />
></mailaddressset>
>
><target name="mail">
> <mailreport>
> <to refid="send-report-to" />
> </mailreport>
></target>
>
>And now in project B I want to do something like
>
><projectref name="B">
> <A:mailaddressset id="send-report-to">
> <address to="bodewig@apache.org" />
> </A:mailaddressset>
></projectref>
>
>as I know Pete is not going to be interested in the reports I generate
>when running it from project B.
In that case it is better to redefine mailaddressset in project B aswell.
Much like if you refer to type URL in a java source file you import it in
the source file. You do not say the type by name of URL imported in source
file X where X is another sourcefile.
Cheers,
Pete
*-----------------------------------------------------*
| "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 |
*-----------------------------------------------------*
Re: Scope of Types
Posted by Stefan Bodewig <bo...@apache.org>.
Peter Donald <do...@apache.org> wrote:
> Can anyone give a good usecase forsharing type defs between peer
> projects?
Your counterargument is sharing values via the ${} syntax doesn't
require sharing types - but what if you want to share IDs?
Say project A defines a type mailaddressset - a set of email addresses
to use in the to field of a custom mailreport task. In project A we
have
<mailaddressset id="send-report-to">
<address to="bodewig@apache.org" />
<address to="donaldp@apache.org" />
</mailaddressset>
<target name="mail">
<mailreport>
<to refid="send-report-to" />
</mailreport>
</target>
And now in project B I want to do something like
<projectref name="B">
<A:mailaddressset id="send-report-to">
<address to="bodewig@apache.org" />
</A:mailaddressset>
</projectref>
as I know Pete is not going to be interested in the reports I generate
when running it from project B.
Stefan
RE: Scope of Types
Posted by Jose Alberto Fernandez <j_...@yahoo.com>.
> From: Peter Donald [mailto:donaldp@apache.org]
>
> At 11:44 AM 6/1/01 +0100, Jose Alberto Fernandez wrote:
> >> From: Stefan Bodewig [mailto:bodewig@apache.org]
> >>
> >> > Flat is theoretically the best example because all
> definitions are
> >> > local. However I guess I am worried about usability.
> >>
> >> What if you'd allow to import types from a nested
> namespace into the
> >> default namespace? Something that is what you call flat
> with a little
> >> bit of global added to it?
> >>
> >
> >We could have something like:
> >
> > <projectref name="mod" ... />
> > <taskdef name="blah" aliasfor="mod->foobar" />
> >or
> > <import name="libblah" lib="mod->modlib" />
> >
> >I do not think we can just use them without redeclaration,
> unless we use a
> >different namespace operator:
> >
> > <mod->foobar ..... /> <!-- This is illegal syntax -->
> > <mod:foobar .... /> <!-- I think this is fine XML -->
> >
> >comments?
>
> Personally I get kinda scared when there is talk of sharing type defs
> between projects in this manner. Where do you see it as
> useful? I can see
> it as useful when propogated via antcalls (ie
> subordinate/child projects)
> but become concerned when peer projects (via projectref) are
> using it.
>
The question for me is how reusable do we want the information in the "peer"
projects to be. 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.
Now, we are not doing "imports" exactly (thank God) so the rules are more
fuzzy.
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.
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.
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.
> 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.
> 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. ;-)
Jose Alberto
RE: Scope of Types
Posted by Peter Donald <do...@apache.org>.
At 11:44 AM 6/1/01 +0100, Jose Alberto Fernandez wrote:
>> From: Stefan Bodewig [mailto:bodewig@apache.org]
>>
>> > Flat is theoretically the best example because all definitions are
>> > local. However I guess I am worried about usability.
>>
>> What if you'd allow to import types from a nested namespace into the
>> default namespace? Something that is what you call flat with a little
>> bit of global added to it?
>>
>
>We could have something like:
>
> <projectref name="mod" ... />
> <taskdef name="blah" aliasfor="mod->foobar" />
>or
> <import name="libblah" lib="mod->modlib" />
>
>I do not think we can just use them without redeclaration, unless we use a
>different namespace operator:
>
> <mod->foobar ..... /> <!-- This is illegal syntax -->
> <mod:foobar .... /> <!-- I think this is fine XML -->
>
>comments?
Personally I get kinda scared when there is talk of sharing type defs
between projects in this manner. Where do you see it as useful? I can see
it as useful when propogated via antcalls (ie subordinate/child projects)
but become concerned when peer projects (via projectref) are using it.
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).
Can anyone give a good usecase forsharing type defs between peer projects?
Cheers,
Pete
*-----------------------------------------------------*
| "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 |
*-----------------------------------------------------*
RE: Scope of Types
Posted by Jose Alberto Fernandez <j_...@yahoo.com>.
> From: Conor MacNeill [mailto:conor@cognet.com.au]
>
> From: "Conor MacNeill" <co...@cortexebusiness.com.au>
> To: <an...@jakarta.apache.org>
> Sent: Friday, June 01, 2001 10:46 PM
> Subject: Re: Scope of Types
>
>
> > From: "Conor MacNeill" <co...@cognet.com.au>
> > >
> > > Anyway, some further thought is required on this in relation to
> <antcall>
> > >
> >
> > OK, here is some further thought. It is somewhat
> conditioned by what I
> have
> > done in mutant.
> >
> > Lets say we have this projectref structure
> >
> > // project A
> > <project>
> >
> > // project B
> > <project>
> > <projectref location="A.ant" name="A"/>
> >
> > //project C
> > <project>
> > <projectref location="B.ant" name="B"/>
> >
> >
> > In mutant, there will be three, linked execution frames -
> one for C, one
> > for B and one for A. Each execution frame has its own copies of data
> > values, task definitions, etc. There are two issues I want to talk
> about -
> > one if property scoping and the other is antcall.
> >
>
> OK, so now let me deal with <ant> and <antcall>. In Ant1 the whole
> environment of the caller is passed to the called instance.
> This is like
> the shell environment model in Unix. The interaction of name
> collisions and
> property immutability makes operation of this often
> unworkable. You can't
> really call arbitrary targets in other build files without
> making sure that
> your definition of "src.dir" won't interfere with the other
> build. The use
> of common names such as these exacerbates the problem.
>
> I prefer an explicit param passing model where selected
> values from the
> caller's environment as passed to the called environment. I'd
> like to know
> if there is general agreement about this.
>
A am 100 pct for that. The only wigle room I would give is that it may be
possible to follow the MAKE model, in which you inherit all values from the
caller, but they do not have precedence over local redefinitions. That is
your local project can change them. With of course the exception of things
passed with <param>.
This is an intermediate model, not as strict, but it allows for having some
form of default values for things like ${build.compiler} and such, which
have global meaning.
> Now consider a scenario where an <antcall> in project C calls
> a target in
> project B
>
> <antcall target="B:compile">
>
> we are calling from an environment with three linked
> execution frames to
> one where there will be two.
I disagree on this. You are not calling project "B" the would be:
<ant target="compile" location="B.ant" />
what you are doing is calling a target on the instantiation of project "B"
defined in "C" which is very different. In this case all the property
overrides made by "C" apply.
So you do have 3 execution frames. To me, <ant*> should be interpreted as a
shortcut syntax for calling recursively to java
org.apache.ant.Main -Dparam=val... <target>.
The fact that we do not create a new JVM is just an optimization. So all the
normal rules, should apply, and whatever additional optimization we do must
be consistent with the above semantics.
>I assume the two frames will be
> initialized
> normally, with A's values being set, then Bs, then B's overrides being
> applied and then overrides from the caller. (This can work in
> the opposite
> order - apply the callers values first (possibly setting
> values in B and
> A), apply B's overrides to A, initialize A (immutability
> preventing the
> override), then initialize B (again immutability preventing
> the caller's
> value being overridden).
>
> So, we could have
> <antcall target="B:compile">
> <param name="A:build.dir" value="BuildAreaC"/>
> <param name="build.dir" value="BuildAreaC"/>
> </antcall>
>
> OK, perhaps that is workable. Note that the passing of the whole
> environment is no longer really practical since it would not
> be clear how
> to map values from the three frames of the caller into the
> two frames of
> the called target.
>
Notice that that would not be an issue, the way I see it.
> Actually, a quick question - should project C only be able to
> manipulate
> values of the projects it directly imports, project B and not
> the values of
> project B's imports, project A.
I do not see much problem on allowing mutilevel access.
> The same goes for the usage
> of types. In
> other words, if project A defines a type <fubar>, can I use it in C as
>
> <B:A:fubar>
>
I am not sure whether XML will allow this syntax :-(
> or would B have to bring the type into it's namespace for it to be
> available to C?
>
Not sure if it would be best to have a general restriction, or to just
require imports for things XML does not allow.
Jose Alberto
Re: Scope of Types
Posted by Conor MacNeill <co...@cognet.com.au>.
From: "Conor MacNeill" <co...@cortexebusiness.com.au>
To: <an...@jakarta.apache.org>
Sent: Friday, June 01, 2001 10:46 PM
Subject: Re: Scope of Types
> From: "Conor MacNeill" <co...@cognet.com.au>
> >
> > Anyway, some further thought is required on this in relation to
<antcall>
> >
>
> OK, here is some further thought. It is somewhat conditioned by what I
have
> done in mutant.
>
> Lets say we have this projectref structure
>
> // project A
> <project>
>
> // project B
> <project>
> <projectref location="A.ant" name="A"/>
>
> //project C
> <project>
> <projectref location="B.ant" name="B"/>
>
>
> In mutant, there will be three, linked execution frames - one for C, one
> for B and one for A. Each execution frame has its own copies of data
> values, task definitions, etc. There are two issues I want to talk
about -
> one if property scoping and the other is antcall.
>
OK, so now let me deal with <ant> and <antcall>. In Ant1 the whole
environment of the caller is passed to the called instance. This is like
the shell environment model in Unix. The interaction of name collisions and
property immutability makes operation of this often unworkable. You can't
really call arbitrary targets in other build files without making sure that
your definition of "src.dir" won't interfere with the other build. The use
of common names such as these exacerbates the problem.
I prefer an explicit param passing model where selected values from the
caller's environment as passed to the called environment. I'd like to know
if there is general agreement about this.
Now consider a scenario where an <antcall> in project C calls a target in
project B
<antcall target="B:compile">
we are calling from an environment with three linked execution frames to
one where there will be two. I assume the two frames will be initialized
normally, with A's values being set, then Bs, then B's overrides being
applied and then overrides from the caller. (This can work in the opposite
order - apply the callers values first (possibly setting values in B and
A), apply B's overrides to A, initialize A (immutability preventing the
override), then initialize B (again immutability preventing the caller's
value being overridden).
So, we could have
<antcall target="B:compile">
<param name="A:build.dir" value="BuildAreaC"/>
<param name="build.dir" value="BuildAreaC"/>
</antcall>
OK, perhaps that is workable. Note that the passing of the whole
environment is no longer really practical since it would not be clear how
to map values from the three frames of the caller into the two frames of
the called target.
Actually, a quick question - should project C only be able to manipulate
values of the projects it directly imports, project B and not the values of
project B's imports, project A. The same goes for the usage of types. In
other words, if project A defines a type <fubar>, can I use it in C as
<B:A:fubar>
or would B have to bring the type into it's namespace for it to be
available to C?
Am I babbling ?
Conor
Re: Scope of Types
Posted by Conor MacNeill <co...@cortexebusiness.com.au>.
> The difference with what you are proposing is that by doing it this way
you
> are not only affecting the values of the properties you are passing, but
> those of all other properties in "B" that use the that property to
construct
> its own values:
>
> <property name="build.file" value="${build.dir}/thefile.txt" />
>
> if override at the end, ${build.file} will get the wrong content with
> rrespect to ${build.dir}.
>
Yep, agreed - I think I got it right in the next post :-)
Conor
RE: Scope of Types
Posted by Jose Alberto Fernandez <j_...@yahoo.com>.
> From: Conor MacNeill [mailto:conor@cortexebusiness.com.au]
>
> From: "Conor MacNeill" <co...@cognet.com.au>
> >
> > Anyway, some further thought is required on this in
> relation to <antcall>
> >
>
> OK, here is some further thought. It is somewhat conditioned
> by what I have
> done in mutant.
>
> Lets say we have this projectref structure
>
> // project A
> <project>
>
> // project B
> <project>
> <projectref location="A.ant" name="A"/>
>
> //project C
> <project>
> <projectref location="B.ant" name="B"/>
>
>
> In mutant, there will be three, linked execution frames - one
> for C, one
> for B and one for A. Each execution frame has its own copies of data
> values, task definitions, etc. There are two issues I want to
> talk about -
> one if property scoping and the other is antcall.
>
> Lets say, project A defines a property
> <property name="build.dir" value="BuildAreaA"/>
>
> I believe B, as the referring project, should be able to
> override this. I
> had envisaged this as
> <property name="A:build.dir" value="BuildAreaB"/>
>
> But that implies that properties (and other data values) are somehow
> mutable. I have thought about a precedence model for this, where an
> referring project has higher priority than the referred
> project. This would
> give a precedence like this
> Commandline -> Project C -> Project B -> project A
>
> This gives some controlled mutability but I'm not sure about
> it - seems
> complex to maintain the precedence of each data value.
>
> I think Jose Alberto will suggest that we supply the
> overriding properties
> as part of the <projectref>, like this.
> <projectref location="A.ant" name="A">
> <param name="build.dir" value="BuildAreaB">
>
> Hmm, I have approached projectref as a parse time operation where the
> project hierarchy is built up in the project model and not an
> execution
> time operation. I guess I can still accommodate that at parse time. I
> wonder when the values would be set. In mutant, before any targets are
> evaluated all the non-target tasks are executed as part of an
> initialization phase - primarily to set up data values. Once this
> initialization is finished, the referring project's overrides could be
> applied.
>
> Thoughts?
>
My thought about <projectref> is that they should be treated quite simillar
to <taskdef> or some of the type definitions we have today. That is, the
call (declaration?) should have access to any properties defined at that
point in the <project> level elements.
So with that in mind, the way I think it should work is that while executing
the initialization phase of "C" when it find <projectref "B"> it will set
the properties in the params of the instantiation and then call the
initialization of "B".
The difference with what you are proposing is that by doing it this way you
are not only affecting the values of the properties you are passing, but
those of all other properties in "B" that use the that property to construct
its own values:
<property name="build.file" value="${build.dir}/thefile.txt" />
if override at the end, ${build.file} will get the wrong content with
rrespect to ${build.dir}.
Jose Alberto
Re: Scope of Types
Posted by Conor MacNeill <co...@cortexebusiness.com.au>.
From: "Conor MacNeill" <co...@cognet.com.au>
>
> Anyway, some further thought is required on this in relation to <antcall>
>
OK, here is some further thought. It is somewhat conditioned by what I have
done in mutant.
Lets say we have this projectref structure
// project A
<project>
// project B
<project>
<projectref location="A.ant" name="A"/>
//project C
<project>
<projectref location="B.ant" name="B"/>
In mutant, there will be three, linked execution frames - one for C, one
for B and one for A. Each execution frame has its own copies of data
values, task definitions, etc. There are two issues I want to talk about -
one if property scoping and the other is antcall.
Lets say, project A defines a property
<property name="build.dir" value="BuildAreaA"/>
I believe B, as the referring project, should be able to override this. I
had envisaged this as
<property name="A:build.dir" value="BuildAreaB"/>
But that implies that properties (and other data values) are somehow
mutable. I have thought about a precedence model for this, where an
referring project has higher priority than the referred project. This would
give a precedence like this
Commandline -> Project C -> Project B -> project A
This gives some controlled mutability but I'm not sure about it - seems
complex to maintain the precedence of each data value.
I think Jose Alberto will suggest that we supply the overriding properties
as part of the <projectref>, like this.
<projectref location="A.ant" name="A">
<param name="build.dir" value="BuildAreaB">
Hmm, I have approached projectref as a parse time operation where the
project hierarchy is built up in the project model and not an execution
time operation. I guess I can still accommodate that at parse time. I
wonder when the values would be set. In mutant, before any targets are
evaluated all the non-target tasks are executed as part of an
initialization phase - primarily to set up data values. Once this
initialization is finished, the referring project's overrides could be
applied.
Thoughts?
I'll deal with the antcall stuff in another email.
Conor
Re: Scope of Types
Posted by Peter Donald <do...@apache.org>.
At 10:06 AM 6/2/01 +1000, Conor MacNeill wrote:
>
>----- Original Message -----
>From: "Peter Donald" <do...@apache.org>
>To: <an...@jakarta.apache.org>
>Sent: Saturday, June 02, 2001 2:58 AM
>Subject: Re: Scope of Types
>
>
>> At 10:23 PM 6/1/01 +1000, Conor MacNeill wrote:
>> >I support what Peter called Flat (although I would have called it
>> >hierarchical :-). I can access a type defined in a project which I have
>> >"imported" with a projectref
>>
>> what is the use of this for a build file writer?
>>
>
>In the outer project I want to define a value of a type defined in the
>imported project so that I can pass a value to that project. What do you
>think?
Even if you pass the instance the receiver does not need to import the
type. The only reason type needs to be imported is when you use it to
designate an instance. For instance a while back I was advocating datatypes
contained by property tag like
<property name="foo">
<blee ... >...</blee>
</property>
In this case it would be required that the type "blee" be imported into
this project file. However if we were to pass the ${foo} instance to
another project who just *used* the property (ie assigned it to attributes
or expanded it in a string) then that other project would not need to
import the type.
thoughts?
Cheers,
Pete
*-----------------------------------------------------*
| "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 |
*-----------------------------------------------------*
Re: Scope of Types
Posted by Conor MacNeill <co...@cortexebusiness.com.au>.
----- Original Message -----
From: "Peter Donald" <do...@apache.org>
To: <an...@jakarta.apache.org>
Sent: Saturday, June 02, 2001 2:58 AM
Subject: Re: Scope of Types
> At 10:23 PM 6/1/01 +1000, Conor MacNeill wrote:
> >I support what Peter called Flat (although I would have called it
> >hierarchical :-). I can access a type defined in a project which I have
> >"imported" with a projectref
>
> what is the use of this for a build file writer?
>
In the outer project I want to define a value of a type defined in the
imported project so that I can pass a value to that project. What do you
think?
Conor
Re: Scope of Types
Posted by Peter Donald <do...@apache.org>.
At 10:23 PM 6/1/01 +1000, Conor MacNeill wrote:
>I support what Peter called Flat (although I would have called it
>hierarchical :-). I can access a type defined in a project which I have
>"imported" with a projectref
what is the use of this for a build file writer?
>(hmm, shame I can't stop overloading the meaning of import :-).
;)
Cheers,
Pete
*-----------------------------------------------------*
| "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 |
*-----------------------------------------------------*
Re: Scope of Types
Posted by Conor MacNeill <co...@cognet.com.au>.
I support what Peter called Flat (although I would have called it
hierarchical :-). I can access a type defined in a project which I have
"imported" with a projectref (hmm, shame I can't stop overloading the
meaning of import :-).
So if I have
<project>
<projectref location="..." name="blah">
I should be able to define a value of a type from that project
<blah:funkyfileset>...
of if blah itself imports another project as fubar, we could access it's
types as
<blah:fubar:strangerFileset>...
(the ":" separator, could be changed - not important for this discussion)
So, basically hierarchical in nature. I can then pass these values into an
antcall to the imported project where it can understand that value. It does
not make much sense to me for me to pass my own types into the imported
projects via an antcall because I can't see how it can understand the type
in any way.
>
> I'm not sure that we can separate the discussion of type scope from
> the discussion of instance scope - at least not completely. If we
> allow an instance of a type to cross build file boundaries, the type
> itself obviously must do so as well.
Well, I think the instance can cross the boundary but on the otherside it
won't be very useful, perhaps only toString'ing it. It is a bit like
passing an instance of a type I have defined into a JDK method. It is only
going to be able to treat as an object (although reflection does allow it
to do some interesting things).
>
> > Hierarchial can introduce far too many ambiguities in a project file
> > resolved according to a context.
>
> Agreed.
>
> Global scope has the disadvantage that you could run into name
> conflicts.
If we have <projectref> I can't see that global is workable for this
reason.
>
> What if you'd allow to import types from a nested namespace into the
> default namespace? Something that is what you call flat with a little
> bit of global added to it?
>
Yes, that would be possible, really just creating a local alias - still not
really global.
Anyway, some further thought is required on this in relation to <antcall>
Conor
Re: Scope of Types
Posted by Stefan Bodewig <bo...@apache.org>.
Peter Donald <do...@apache.org> wrote:
> At 12:17 PM 6/1/01 +0200, Stefan Bodewig wrote:
>>> Flat is theoretically the best example because all definitions are
>>> local. However I guess I am worried about usability.
>>
>>What if you'd allow to import types from a nested namespace into the
>>default namespace? Something that is what you call flat with a
>>little bit of global added to it?
>
> Could you expand? I don't get it ;) Perhaps an XML snippet to
> describe ... ;)
<projectref project="A">
<alias name="fileset" for="A:fileset" />
</projectref>
or something similar.
Stefan
Re: Scope of Types
Posted by Peter Donald <do...@apache.org>.
At 12:17 PM 6/1/01 +0200, Stefan Bodewig wrote:
>> Flat is theoretically the best example because all definitions are
>> local. However I guess I am worried about usability.
>
>What if you'd allow to import types from a nested namespace into the
>default namespace? Something that is what you call flat with a little
>bit of global added to it?
Could you expand? I don't get it ;) Perhaps an XML snippet to describe ...
;)
Cheers,
Pete
*-----------------------------------------------------*
| "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 |
*-----------------------------------------------------*
RE: Scope of Types
Posted by Jose Alberto Fernandez <j_...@yahoo.com>.
> From: Stefan Bodewig [mailto:bodewig@apache.org]
>
> > Flat is theoretically the best example because all definitions are
> > local. However I guess I am worried about usability.
>
> What if you'd allow to import types from a nested namespace into the
> default namespace? Something that is what you call flat with a little
> bit of global added to it?
>
We could have something like:
<projectref name="mod" ... />
<taskdef name="blah" aliasfor="mod->foobar" />
or
<import name="libblah" lib="mod->modlib" />
I do not think we can just use them without redeclaration, unless we use a
different namespace operator:
<mod->foobar ..... /> <!-- This is illegal syntax -->
<mod:foobar .... /> <!-- I think this is fine XML -->
comments?
Jose Alberto
Re: Scope of Types
Posted by Stefan Bodewig <bo...@apache.org>.
Peter Donald <do...@apache.org> wrote:
> I would like to see what people think about the scope of Type
> definitions in Ant2. Types include things like tasks, mappers,
> filesets etc. There has been three different scopes proposed so far;
> flat, hierarchial and global.
>
> Global is the scope that Ant1 uses. Once registered a taskdef can no
> be unregistered.
Not really, it is hierarchical. Types and tasks defined in a subbuild
don't propagate back to the main build.
Instances of types are even worse ATM, properties are hierarchical
while instances of types have build file scope - but we've agreed to
change that.
I'm not sure that we can separate the discussion of type scope from
the discussion of instance scope - at least not completely. If we
allow an instance of a type to cross build file boundaries, the type
itself obviously must do so as well.
> Hierarchial can introduce far too many ambiguities in a project file
> resolved according to a context.
Agreed.
Global scope has the disadvantage that you could run into name
conflicts.
> Flat is theoretically the best example because all definitions are
> local. However I guess I am worried about usability.
What if you'd allow to import types from a nested namespace into the
default namespace? Something that is what you call flat with a little
bit of global added to it?
Stefan