Re: NameSpace & antlib was (Re: polymorphism)

[peter reilly <pe...@corvil.com>]

On Wednesday 30 April 2003 18:28, Costin Manolache wrote:
> peter reilly wrote:
> > I think that agreement is very close.
> >
> > What about this proposal:
> >
> > The current types and tasks properties files may be combined
> > into a antdef.xml file of the form:
> > <antdef>
> >     <taskdef name="acme" classname="org.acme.Acme"
> >                   onerror="fail/report/ignore"/>
> >      ...
> >      ...
> > </antdef>
>
> What is the "onerror" ? We don't have it in the normal taskdef ( or do we ?

The concept was introduced in the ant lib proposal.

I propose to add it to Definer (and hence to typedef and taskdef). This
is to allow the use-case of optional tasks. Currently all the types/tasks in
ant core are in-fact optional, in that if they cannot be loaded, ant proceeds
as normal. This was done to allow optional tasks to be defined (script etc),
but the side effect is that all the tasks are optional.

This feature does not exist with thirdparty ant extensions. For example
if ant-contrib wanted to add new  tasks depending on bsf.jar,
users of ant-contrib.jar would need to have bsf.jar (or taskdef the
optional tasks indivually).

> IMO we should recommend and use <typedef> - with tasks as a particular
> case of types. If they extend Task - everything fine, if not
>
>  <typedef name="acme" classname="org.acme.Acme"
> adapter="org.apache.tools.ant.TaskAdapter" /> or the equivalent
>  <taskdef .... />

I did not want to make proposals for these type of changes are part
of the antdef/lib  dicussion as they are complely independent.

>
> > Definer (in the form of <typedef/> or <taskdef/>) can use
> > this either as a file or as a resource.
> > <typedef antdef=".../ant-contrib.xml" classpath="${ant-contrib.jar}"/>
>
> That's a point where I feel we still need more work.

My explaination is a bit lacking here. I meant to say that typedef would
treat the antdef.xml file in the same way as it deals with property files.
It makes to assumation as to the location or name of the file and it can be
a resource.
<typedef antdeffile="c:/mysource/src/this_is_a_test_definition_file.xml" />

or
<typedef antdefresource="net/sf/antcontrib/antdef.xml"
              classpath="${ant-contrib.jar"}/>

packaging of the definition file - location in a jar file,
use by xml namespace or by a <antlib/> task is a separate issue,
and should be done by separate code.

>
> I can accept META-INF/antlib.xml, even if I preffer /my/package/antlib.xml,
> with "my.package" used as the name of the antlib ( explicitely or in the
> namespace ).
>
> > or
> > <typedef antdefresource="net/sf/antcontrib/antdef.xml" classpath="..."/>
> > or
> > <typedef antdefresource="net/sf/antcontrib/antdef.xml" />
> > (if antcontib-xyz.jar is in ${ant.home}/lib").
>
> Or in some path that is added to <loader> ( which I'll try to document this
> weekend - I have few days off, changing jobs ).
>
> > For convienance the antdef.xml may be placed a known place in the
> > meta directory of jar by the <antjar/> task.
> > The <antlib/> task (extending Definer), knows about this
> > known location and can then do.
>
> I think the major question to answer first is if it'll be META-INF
> or package ( and impliciltey if libs are discovered automatically
> or loaded explicitely ).
>
> Based on this answer - a lot changes.

I do not think a lot changes. The basic mechanism
of defining the definiation file and the loading of the file are
relativly independent of the packaging of the definition file.

I have tried to write the code so that each feature is
not dependent on the implemtation of the other features.

My code uses a modified ProjectHelper2 to load
a arbitarary ant task from a URL. The contents
of the defintion file is thus controlled by the normal
ant task class patterns.

> > I have code (which uses a lot of the ideas from the antlib proposal)
> > that implements the above. I will try to get it in a form ready
> > for upload to-nite.

I ran out of time last night, I will do this at the weekend.

Peter

Re: NameSpace & antlib was (Re: polymorphism)

[peter reilly <pe...@corvil.com>]

Replying to myself ;-)

On Thursday 01 May 2003 09:55, peter reilly wrote:
>
> The concept was introduced in the ant lib proposal.
>
> I propose to add it to Definer (and hence to typedef and taskdef). This
> is to allow the use-case of optional tasks. Currently all the types/tasks
> in ant core are in-fact optional, in that if they cannot be loaded, ant
> proceeds as normal. This was done to allow optional tasks to be defined
> (script etc), but the side effect is that all the tasks are optional.
>
> This feature does not exist with thirdparty ant extensions. For example
> if ant-contrib wanted to add new  tasks depending on bsf.jar,
> users of ant-contrib.jar would need to have bsf.jar (or taskdef the
> optional tasks indivually).

Looking at costin's explaination of ComponentHelper
http://www.webweavertech.com/costin/archives/cat_ant.html
this may not be necessary.
Or the fail/warn value of onerror could load the class at definition time
and the ignore value could delay the loading until tag resolution
time.

As a side issue, I am a bit concerned about the startup time of
ant slowing down as a result of processing an xml file at startup.

Peter