ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <dona...@apache.org>
Subject RE: [DISC] details of task library concept
Date Fri, 25 May 2001 03:16:16 GMT
At 01:44 AM 5/25/01 +0100, Jose Alberto Fernandez wrote:
>> These are my ideas
>> 1. Each library will provide a unique name based on the dns
>>
>> <antlib id="com.m64.tasks.fubar">
>>    <taskdef name="foo" .../>
>>    <taskdef name="bar"   />
>> </antlib>
>>
>
>I like it!

me too.

>> 6. XML namespace constructs are not used and are reserved for project
>> references. (I used to use <import> for this in mutant but maybe
>> <projectref> would be better, given the above. Something like this
>>
>> <project name="tomcat">
>>    <projectref location="jasper.xml" name="jasper"/>
>>    <projectref location="catalina.xml" name="cat"/>
>>
>>    <target name="build" depends="jasper:compile, cat:compile"/>
>>        <javac .../>
>>        <jasper:jspc .../>
>>    </target>
>> </project>
>>
>> The above example shows the referencing of projects as
>> originally proposed
>> in AntFarm, without projectpath concept. It also shows the use of the
>> namespace to construct cross-project dependencies and also
>> the use of a
>> namespace to use a task definition from another project. This
>> is what I was
>> getting at when I talked abouyt overloading the namespace
>> concept if we use
>> it for task collision avoidance.

Ick. I don't think I like using namespace in this way. I can handle
naespace for "static" structural aspects (ie indicating task library or
aspect attribute/element) but it can get confusing to use namespace to also
indicate other projects.

>Something like this is what I think is the right implementation for what
>people have refer as <include>. Macro like <include> I feel is a mistake,
>here you have a structured a object being referenced and accessed. I will
>just add the ability to specify properties to use during the instantiation
>of the project reference:
>
>	<projectref name="cat" location="catalina.xml" >
>		<property name="port" value="8080" />
>	</projectref>

nice - what happens when the project is included multiple times ... Do we
assume that it shouldn't be and if it is included multiple times it counts
as multiple projects ? (I like this approach). Or do we do something else?

>Now shall we use the name space for properties also?

Hopefully only those that are explicitly marked as public.


>Finally, I would suggest adding to <project>s a way to specify required
>properties to be suplied by the caller:

as long as they can also accept other ones aswell.

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


Mime
View raw message