You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Mariano Benitez <ma...@fuegolabs.com> on 2004/03/05 16:37:03 UTC
taskdefs inside an antlib and their classpath
Hi!
Is it possible to define another classpath for a task definition
inside an antlib?
I've read the Definer class and if it is inside an antlib, it uses that
classloader instead of creating a new one with the additional jars.
Is this desired behaviour? if it is, you should log a warning saying
that whatever you define as classpath in an antlib.xml is not considered.
Otherwise, I will report the bug :)
MAriano
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: taskdefs inside an antlib and their classpath
Posted by Peter Reilly <pe...@corvil.com>.
Mariano Benitez wrote:
> do you imply here that when you use <typedef> with an already defined
> uri, being that an antlib uri, that it will add those definitions to
> the antlib uri?
Yes, this is the way it works.
For example:
<typedef name="myhello" classname="tasks.MyHello" classpathref="my.classes"
uri="antlib:org.apache.tools.ant"/>
is the same as:
<typedef name="myhello" classname="tasks.MyHello" classpathref="my.classes" />
and:
<project xmlns:ac="antlib:net.sf.antcontrib">
<path id="my.classes" path="classes"/>
<!-- test new task for ant-contrib -->
<typedef name="hello" classname="tasks.MyHello" classpathref="my.classes"
uri="antlib:net.sf.antcontrib"/>
<ac:for param="letter" list="a,b,c,d">
<ac:sequential>
<ac:hello letter="@{letter}"/>
</ac:sequential>
</ac:for>
Peter
>
> in your sample you are adding definitions to the antlib you are
> defining there, is that correct?
Just having the name "antlib:[package]" is a shortcut to ant to tell it
to do:
<typedef resource="[package to dirname]/antlib.xml"
uri="antlib:[package]" onerror="ignore"/>
i.e. ant will try to load the antlib.xml resource[s] at package dir
name, but not be worried if none
exist.
Peter
>
> MAriano
>
> Peter Reilly wrote:
>
>> Hi Mariano,
>> You are right that one can specify the classpath within an antlib,
>> and it is incorrectly silently ignored.
>>
>> There would be a problem with using properties as one would need
>> to be very carefull to specify them before the antlib auto reading
>> is triggered.
>>
>> With the current ant implementation you can achieve most of what you
>> want
>> by using an <typedef/> with the resource and uri attributes, and hide
>> this
>> in an imported file:
>>
>> <project xmlns:nytask="antlib:net.sf.nytasker">
>> <property name="nytasker.dir"
>> location="${user.home}/apps/nytasker/dist"/>
>> <import file="${nytasker.dir}/nytasker.xml"/>
>> <nytask:jmessage message="Press Yes to continue"/>
>> </project>
>>
>>
>> Where nytasker.xml looks something like this:
>>
>> <project name="nytasker">
>> <typedef resource="net/sf/nytasker/antlib.xml"
>> uri="antlib:net.sf.nytasker">
>> <classpath>
>> <fileset dir="${nytasker.dir}/lib" includes="*.jar"/>
>> </classpath>
>> </typedef>
>> </project>
>>
>> Peter
>>
>>
>> Mariano Benitez wrote:
>>
>>> would it be very crazy to add a classpath atlibdefinition that would
>>> add jars to the antlib classpath instead of getting ALL the jars
>>> from a directory.
>>>
>>> My problem is that I would like to keep only the task definitions in
>>> the antlib directory and the other dependent jars in a common lib
>>> directory with other jars that should not be loaded by the antlib
>>> class loader. Besides, the files location is defined based on
>>> properties, I cannot know that location when ant starts.
>>>
>>> I will investigate a bit on that to see if it is easy to implement
>>> another antlibdefinition class for this.
>>>
>>> MAriano
>>>
>>> Mariano Benitez wrote:
>>>
>>>> Hi!
>>>>
>>>> Is it possible to define another classpath for a task definition
>>>> inside an antlib?
>>>>
>>>> I've read the Definer class and if it is inside an antlib, it uses
>>>> that classloader instead of creating a new one with the additional
>>>> jars.
>>>>
>>>> Is this desired behaviour? if it is, you should log a warning
>>>> saying that whatever you define as classpath in an antlib.xml is
>>>> not considered.
>>>>
>>>> Otherwise, I will report the bug :)
>>>>
>>>> MAriano
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
>>>> For additional commands, e-mail: dev-help@ant.apache.org
>>>
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
>>> For additional commands, e-mail: dev-help@ant.apache.org
>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
>> For additional commands, e-mail: dev-help@ant.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: taskdefs inside an antlib and their classpath
Posted by Mariano Benitez <ma...@fuegolabs.com>.
do you imply here that when you use <typedef> with an already defined
uri, being that an antlib uri, that it will add those definitions to the
antlib uri?
in your sample you are adding definitions to the antlib you are defining
there, is that correct?
MAriano
Peter Reilly wrote:
> Hi Mariano,
> You are right that one can specify the classpath within an antlib,
> and it is incorrectly silently ignored.
>
> There would be a problem with using properties as one would need
> to be very carefull to specify them before the antlib auto reading
> is triggered.
>
> With the current ant implementation you can achieve most of what you want
> by using an <typedef/> with the resource and uri attributes, and hide
> this
> in an imported file:
>
> <project xmlns:nytask="antlib:net.sf.nytasker">
> <property name="nytasker.dir"
> location="${user.home}/apps/nytasker/dist"/>
> <import file="${nytasker.dir}/nytasker.xml"/>
> <nytask:jmessage message="Press Yes to continue"/>
> </project>
>
>
> Where nytasker.xml looks something like this:
>
> <project name="nytasker">
> <typedef resource="net/sf/nytasker/antlib.xml"
> uri="antlib:net.sf.nytasker">
> <classpath>
> <fileset dir="${nytasker.dir}/lib" includes="*.jar"/>
> </classpath>
> </typedef>
> </project>
>
> Peter
>
>
> Mariano Benitez wrote:
>
>> would it be very crazy to add a classpath atlibdefinition that would
>> add jars to the antlib classpath instead of getting ALL the jars from
>> a directory.
>>
>> My problem is that I would like to keep only the task definitions in
>> the antlib directory and the other dependent jars in a common lib
>> directory with other jars that should not be loaded by the antlib
>> class loader. Besides, the files location is defined based on
>> properties, I cannot know that location when ant starts.
>>
>> I will investigate a bit on that to see if it is easy to implement
>> another antlibdefinition class for this.
>>
>> MAriano
>>
>> Mariano Benitez wrote:
>>
>>> Hi!
>>>
>>> Is it possible to define another classpath for a task definition
>>> inside an antlib?
>>>
>>> I've read the Definer class and if it is inside an antlib, it uses
>>> that classloader instead of creating a new one with the additional
>>> jars.
>>>
>>> Is this desired behaviour? if it is, you should log a warning saying
>>> that whatever you define as classpath in an antlib.xml is not
>>> considered.
>>>
>>> Otherwise, I will report the bug :)
>>>
>>> MAriano
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
>>> For additional commands, e-mail: dev-help@ant.apache.org
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
>> For additional commands, e-mail: dev-help@ant.apache.org
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: taskdefs inside an antlib and their classpath
Posted by Peter Reilly <pe...@corvil.com>.
Hi Mariano,
You are right that one can specify the classpath within an antlib,
and it is incorrectly silently ignored.
There would be a problem with using properties as one would need
to be very carefull to specify them before the antlib auto reading
is triggered.
With the current ant implementation you can achieve most of what you want
by using an <typedef/> with the resource and uri attributes, and hide this
in an imported file:
<project xmlns:nytask="antlib:net.sf.nytasker">
<property name="nytasker.dir" location="${user.home}/apps/nytasker/dist"/>
<import file="${nytasker.dir}/nytasker.xml"/>
<nytask:jmessage message="Press Yes to continue"/>
</project>
Where nytasker.xml looks something like this:
<project name="nytasker">
<typedef resource="net/sf/nytasker/antlib.xml"
uri="antlib:net.sf.nytasker">
<classpath>
<fileset dir="${nytasker.dir}/lib" includes="*.jar"/>
</classpath>
</typedef>
</project>
Peter
Mariano Benitez wrote:
> would it be very crazy to add a classpath atlibdefinition that would
> add jars to the antlib classpath instead of getting ALL the jars from
> a directory.
>
> My problem is that I would like to keep only the task definitions in
> the antlib directory and the other dependent jars in a common lib
> directory with other jars that should not be loaded by the antlib
> class loader. Besides, the files location is defined based on
> properties, I cannot know that location when ant starts.
>
> I will investigate a bit on that to see if it is easy to implement
> another antlibdefinition class for this.
>
> MAriano
>
> Mariano Benitez wrote:
>
>> Hi!
>>
>> Is it possible to define another classpath for a task definition
>> inside an antlib?
>>
>> I've read the Definer class and if it is inside an antlib, it uses
>> that classloader instead of creating a new one with the additional jars.
>>
>> Is this desired behaviour? if it is, you should log a warning saying
>> that whatever you define as classpath in an antlib.xml is not
>> considered.
>>
>> Otherwise, I will report the bug :)
>>
>> MAriano
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
>> For additional commands, e-mail: dev-help@ant.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: taskdefs inside an antlib and their classpath
Posted by Mariano Benitez <ma...@fuegolabs.com>.
would it be very crazy to add a classpath atlibdefinition that would add
jars to the antlib classpath instead of getting ALL the jars from a
directory.
My problem is that I would like to keep only the task definitions in the
antlib directory and the other dependent jars in a common lib directory
with other jars that should not be loaded by the antlib class loader.
Besides, the files location is defined based on properties, I cannot
know that location when ant starts.
I will investigate a bit on that to see if it is easy to implement
another antlibdefinition class for this.
MAriano
Mariano Benitez wrote:
> Hi!
>
> Is it possible to define another classpath for a task definition
> inside an antlib?
>
> I've read the Definer class and if it is inside an antlib, it uses
> that classloader instead of creating a new one with the additional jars.
>
> Is this desired behaviour? if it is, you should log a warning saying
> that whatever you define as classpath in an antlib.xml is not considered.
>
> Otherwise, I will report the bug :)
>
> MAriano
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org