ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <j_a_fernan...@yahoo.com>
Subject RE: [DISC] details of task library concept
Date Fri, 25 May 2001 05:16:16 GMT
> From: Peter Donald [mailto:donaldp@apache.org]
>
>
> 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.
>

Well this are not really XML name-spaces, since they are on the attribute
values. Not the attribute names. In any case, if we are going to include
things in one another we will need to have a name dereferencing operator. In
this case is ":" but it could have been anything else ( "^" "->" "!" ).


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

That is a good point. I was thinking still in terms of <include> where
everything is visible because you just cut&pasted the stuff. But you are
right, in this model we can incorporate some more controlled visibility
declarations.

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

Yes. The point is to allow the build to fail early if you miss needed
configuration.

Jose Alberto

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