Hi,
>You need to do a <typedef> and not a <taskdef> to define the new type.
I am already using a typedef.
As in my original email:
<target name="autoservice.taskdef" depends="autoservice.compile">
<typedef name="autoservice" classname="ag.tools.ant.AutoService"
classpath="${autoservice.classes}"/>
</target>
<target name="jar" depends="autoservice.taskdef,project.compile">
<jar destfile="${build.dir}">
<fileset dir="${src.dir}"/>
<autoservice type="ag.core.AGApp" classpath="${build.dir}"/>
</jar>
</target>
Any more ideas?
Thanks, John
2008/9/11 Peter Reilly <[EMAIL PROTECTED]>
> You need to do a <typedef> and not a <taskdef> to define the new type.
>
> Looking at the code:
>
> Jar: public void addConfiguredService(Service service) {}
>
> the new type should work.
>
> The reason that <taskdef> does not work is that the Sevice class does
> not extend Task
> and using <taskdef> will cause ant to use a proxy class, which will
> not match the addConfigured signature.
>
>
> Peter
>
>
> On Thu, Sep 11, 2008 at 1:03 PM, John5342 <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > Thanks for the reply.
> >
> >>Does it produce a classpath??
> >>
> >>What do you expect should the jar task do with the element?
> >
> > I explained in my first email but will clarify.
> >
> > My aim is to create an enhanced service element for the jar task. I
> > subclassed the Service class because i know the jar task already knows
> what
> > to do with the service element. My AutoService subclass then has an extra
> > attribute (naed classpath) that AutoService will search for possible
> > providers. For each provider AutoService finds I am simply calling
> > Service.addConfiguredProvider().
> >
> > From what i understand from documentation is that with a few exceptions
> with
> > type conversion (such as String to Path and such) elements cause the
> > appropriate type (known from taskdef and typedef) to be constructed and
> > added to the first addXX function that can handle the type. My hope was
> that
> > since AutoService is a subclass of Service (and therefore looks and acts
> the
> > same from the jar tasks point of view) everything would just work.
> >
> > Have i misunderstood how ant works?
> >
> > Is there a way around this?
> >
> > Is the best way to just create a specialised jar task instead?
> >
> > Is easy enough to create a new jar task instead but my approach if it
> works
> > just seemed cleaner.
> >
> >
> > And in case it makes any difference:
> >>What i understood:
> >>You created a task called autoservice.
> > Service from which i inherit doesnt actually implement Task so doesnt
> seem
> > to be a task as such.
> >
> > Thanks, John
> >
> > 2008/9/11 Knuplesch, Juergen <[EMAIL PROTECTED]>
> >
> >> Hello,
> >>
> >>
> >> The error you get tells simply, that your created task is not an allowed
> >> subelement of the jar-task.
> >> You run into a syntax error.
> >> It is not possible to change the jar task (or any other task) by adding
> >> your own tasks as subelements.
> >>
> >> Probably you have to write your own jar-task, that will understand your
> >> subelement.
> >>
> >> What i understood:
> >> You created a task called autoservice.
> >>
> >> What does this task do?
> >> Does it produce a classpath??
> >>
> >> What do you expect should the jar task do with the element?
> >>
> >> Tell us and then you will get probably some hints to do what you want.
> >>
> >> Then you have to write your own Ant-Task doing the stuff you want.
> >>
> >> --
> >> Jürgen Knuplesch
> >>
> >> -----Ursprüngliche Nachricht-----
> >> Von: John5342 [mailto:[EMAIL PROTECTED]
> >> Gesendet: Mittwoch, 10. September 2008 20:08
> >> An: user@ant.apache.org
> >> Betreff: Custom element for jar task.
> >>
> >> Hi,
> >>
> >> I have a rapidly evolving project which contains a large and varying
> number
> >> of service providers. I was hoping to create to create a more
> specialized
> >> version of the service element that automatically scans for providers in
> a
> >> give classpath but have run into some trouble asuming what i want to do
> is
> >> even possible.
> >>
> >> I started off by subclassing org.apache.tools.ant.types.spi.Service
> which
> >> provides the current service element and added setClassPath() and some
> lgic
> >> to automatically scan the given classpath for any classes implementing
> the
> >> the given type and add add appropriate providers to Service. I then
> added
> >> the following to my build.xml:
> >>
> >> <target name="autoservice.taskdef" depends="autoservice.compile">
> >> <typedef name="autoservice" classname="ag.tools.ant.AutoService"
> >> classpath="${autoservice.classes}"/>
> >> </target>
> >>
> >> <target name="jar" depends="autoservice.taskdef,project.compile">
> >> <jar destfile="${build.dir}">
> >> <fileset dir="${src.dir}"/>
> >> <autoservice type="ag.core.AGApp" classpath="${build.dir}"/>
> >> </jar>
> >> </target>
> >>
> >>
> >> autoservice.taskdef runs fine but when i get to the jar target i get the
> >> following error:
> >>
> >> /Projects/ag/build.xml:103: jar doesn't support the nested "autoservice"
> >> element.
> >>
> >> Is what i am trying to do even possible? and if so any ideas where to go
> >> from here?
> >>
> >> Thanks, John
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
