ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rob Oxspring" <roxspr...@yahoo.com>
Subject RE: [DISC] details of task library concept
Date Fri, 25 May 2001 01:42:30 GMT
> -----Original Message-----
> From: Jose Alberto Fernandez [mailto:j_a_fernandez@yahoo.com]
> Sent: Friday, May 25, 2001 1:45 AM
> To: ant-dev@jakarta.apache.org
> Subject: RE: [DISC] details of task library concept
>
>
> > From: Conor MacNeill [mailto:conor@cortexebusiness.com.au]
> >
> > > >Not all tasks, but all libraries. In particular, if you think
> > > that not all
> > > >installations will have all libraries. Like with the "import"
> > > statement in
> > > >Java, explicitly mentioning dependencies is best.
> > >
> > > I agree - wanna convince everyone else ? ;)
> > >
> > > >> namespaces.
> > > >
> > > >How are you going to assign the name spaces? I hope the
> > writer of the
> > > >buildfile has a say on what names to use.
> > >
> > > Haven't been discussed enough but my assumption is something like.
> > >
> > > Namepsace+default prefix defined by library writer however
> > > library user can
> > > overide prefix (but not namespace).
> >
> > I have been thinking about this a little and it is
> > interesting. I think for
> > task name collision avoidance we can perhaps use the Java
> > model with a few
> > mod cons.
> >
> > 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!
>
> > 2. Projects must declare the tasks they are going to use -
> > similar to a Java
> > import statement
> >
> >    <import lib="com.m64.tasks.fubar">
> >
> > would import all tasks in this library
> >
> >    <import lib="com.m64.tasks.fubar" task="foo"/>
> >
> > would import just the foo task definition and
> >
> >    <import lib="com.m64.tasks.fubar" task="foo" alias="echo"/>
> >
> > would import foo and make it available as the <echo> task.
> >
>
> I would only add the ability to specify the location of the library, for
> those cases in which the library resides outside of the ANT installation.
>
> And of course my mantra of being able to specify a classpath to include in
> that of the library :-)
>
> So the full syntax would be:
>
> 	<import lib="com.m64.task.fubar" task="foo"
> 		location="${basedir}/tools/m64.tsk" >
> 		<classpath .... />
> 	</import>
>
> That I think would give a quite powerful abstraction.
>
> > 3. Certain tasks would be automatically imported in the same way as
> > Java.lang.* is in Java. This would include most of the
> > current core tasks, I
> > guess.
> >
>
> It should be just the core. Or more exactly, the library lib="ant.core".
>
> > 4. I don't think any local prefixes should be used as it
> > would make build
> > files too tied to the local setup - better to stick to global
> > identifiers.
> >
> > 5. certain parts of the identifier namespace would be
> > reserved to ant - i.e.
> > ant.*
> >
> > 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.
> >
> > Thoughts?
>
> 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>
>
> Now, here all the targets share the same dependency graph, as oppose to
> <antcall> which does not. And properties defined inside the <projectref>
> should be visible in the main project. Now shall we use the name space for
> properties also?
>
> 	<copy dir="${cat:buildFiles} .... />

(Obviously, but just in case) This access will have to be restricted by the
scoping rules when they are decided.

>
> where ${buildfiles} is a property defined in "catalina.xml".
>
> Finally, I would suggest adding to <project>s a way to specify required
> properties to be suplied by the caller:
>
> 	<project name="..." ...>
> 		<require name="port" />

This doesn't rest well personally but, assuming project level tasks, it
looks like a simple task that could be knocked together in five minutes and
wouldn't have to be core.

> 		...
> 	</project>
>
> where <require> will fail if there is no property defined with
> that name. It
> works like a parameter declaration.
>
> Jose Alberto

It all look great to me, and to help get a hold of the bigger picture i've
tried to flesh out the example a bit, including the ant/log/doc aspects that
Peter is plugging.  The only problem being that I'm already getting an
overload of ':'s - these can't be changed at the XML level, but maybe a
switch to '#'s or similar would add an extra level of clarity for the
ant-level references?

<project name="tomcat">
   <import lib="ant.net" task="ftp"/>

   <projectref location="jasper.xml" name="jasper"/>
   <projectref location="catalina.xml" name="cat"/>

   <target name="build" depends="jasper#compile, cat#compile"
doc:description="Glues jasper and catalina together"/>
       <javac dest="${build}" log:level="verbose" ant:failonerror="false"/>
       <jasper#jspc .../>
       <zip file="tomcat.zip" src="${build}"/>
       <ftp ant:classloader="" server="jakarta.apache.org"
dest="/tomcat/src" src="${build}"/>
   </target>

</project>

I would like to see examples with a little more meat on them, in particular
how the ant/antcall tasks fit in - presumably the same multi-project
dependancy graph would be used by the antcall task, so could all 'ant' tasks
be dropped and replaced by 'antcall' and a 'projectref'?

Rob


Mime
View raw message