ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan.Mate...@rzf.fin-nrw.de
Subject AW: new Task subclass
Date Fri, 23 Jul 2004 06:54:42 GMT
> > I'm not sure it should be done via References, but I
> > agree that it
> > should be easy to do - and possible to do from
> > within the build file.
> > The examples we have in the sandbox all combine a
> > PropertyHelper with
> > a task that installs it.  This works and would look
> > like
> > 
> > <taskdef name="myph"
> > classname="my.PropertyHelperInstallingTask"/>
> > <myph/>
> 
> Doesn't that seem like extra work?  I feel it is
> counter-intuitive to say "all you have to do is extend
> PropertyHelper, OH YEAH and your custom class has to
> also install itself or you can write an entirely
> separate installer."  If Ant keeps track of the
> current PropertyHelper (which it does) with a
> reference, then it is The Way We Do Things Around Here
> to assign a different object to that reference and
> everything just WORKS.  That's what I think, anyway.

Why not a core task?

<installph classname="my.PropertyHelper" classpathref="my.classpath"/>
(or nested classpath).


Some time ago I read something about a missing plugin structure in Ant ...
I think 
- structure is there
- maybe not good enough documented / published
- sometimes not easy enough to use (like the PropertyHelper in the current
version)
- auto discoverage is not there (like Eclipse PlugIns; simply drop your
AntLib into
  a directory and its available by its default namespace <antlib
defaultns="antcontrib"/>)
  <project><antcontrib:if>...                   possibility
  <project xmlns:ac="antlib:..."><ac:if>...     current


Jan

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message