You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Jose Alberto Fernandez <ja...@cellectivity.com> on 2004/04/01 13:37:13 UTC
antlib and classloaders
Hi, I have been giving some thought on ways to solve this nagging
issue of needing to put antlib jars on the lib directory.
We hear over and over people wanting to keep their third party
libraries out of -lib because they are only for an specific project.
As I see it, our road block has been how to tell in succinct way in the
buildfile that when loading the namespace "antlib:foo.bar" you should
use this or that classpath or classloader.
A simple solution could be to achieve this by name association:
- When ANT tries to find and load the resource for "antlib:foo.bar"
it will first look for a reference named "foo.bar" representing
a classloader (or classpath?). If an object of the correct type is
found, then this classloader will be user for resolving and loadding
the antlib, otherwise the default classloader will be use, as it is
today.
So with this in place, one could write things like:
<project name="x" xmlns:lib="antlib:foo.bar">
<classpath id="foo.bar">.....</classpath>
<lib:mytask ..../> <!-- The antlib loaded using the classloader for
"foo.bar" -->
</project>
Before jumping on a code proposal, does this sound a the right or good
solution? Does this cover enough of the use cases?
Let me know what you people think.
Jose Aberto
Re: antlib and classloaders
Posted by Peter Reilly <pe...@corvil.com>.
Hi,
This sounds nice but does it save that much on
<project name="x" xmlns:lib="antlib:foo.bar">
<typedef resource="foo/bar/antlib.xml" uri="antlib:foo.bar">
<classpath>.....</classpath>
</typedef>
<lib:mytask ..../> <!-- The antlib loaded using the classloader for
"foo.bar" -->
</project>
Peter
Jose Alberto Fernandez wrote:
>Hi, I have been giving some thought on ways to solve this nagging
>issue of needing to put antlib jars on the lib directory.
>
>We hear over and over people wanting to keep their third party
>libraries out of -lib because they are only for an specific project.
>
>As I see it, our road block has been how to tell in succinct way in the
>buildfile that when loading the namespace "antlib:foo.bar" you should
>use this or that classpath or classloader.
>
>A simple solution could be to achieve this by name association:
>
>- When ANT tries to find and load the resource for "antlib:foo.bar"
>it will first look for a reference named "foo.bar" representing
>a classloader (or classpath?). If an object of the correct type is
>found, then this classloader will be user for resolving and loadding
>the antlib, otherwise the default classloader will be use, as it is
>today.
>
>So with this in place, one could write things like:
>
><project name="x" xmlns:lib="antlib:foo.bar">
>
> <classpath id="foo.bar">.....</classpath>
>
> <lib:mytask ..../> <!-- The antlib loaded using the classloader for
>"foo.bar" -->
>
></project>
>
>Before jumping on a code proposal, does this sound a the right or good
>solution? Does this cover enough of the use cases?
>
>Let me know what you people think.
>
>Jose Aberto
>
>
>
>
>
>
>------------------------------------------------------------------------
>
>---------------------------------------------------------------------
>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: antlib and classloaders
Posted by Peter Reilly <pe...@corvil.com>.
Mariano's original question was why
was classpath ignored in an antlib definition.
<antlib>
<typedef name="task" classname="org.mytasks.Task" loaderref="mytasks.ref">
<classpath>
<fileset dir="${env.MY_TASKS_HOME}/lib" includes="**/*.jar"/>
</classpath>
<typedef name="task2" classname="org.mytasks.Task2" loaderref="mytasks.ref"/>
</antlib>
This could be supported easily in the current code base.
-i.e. if an typedef/taskdef in an antlib sets the classpath, this classpath will be used instead
of the antlibdefinition classpath.
The only problem with this is that the user build script needs to set the correct property
before the antlib is activated.
Peter
Mariano Benitez wrote:
> I have this issue in mind:
>
> Since I need to provide antlibs to my customers, I would like them to
> have to manually configure as less as possible, that means that the
> previous way of saying -b <myapp>/antlib was quite cool.
>
> The problem is that I do need to control the classloader where the
> tasks are loaded, because I cannot copy the whole list of jars in my
> app to the antlib classpath. Maybe by just copying ONE jar to antlib
> is just fine, and inside the antlib.xml control the classloading.
> Maybe only making the antlib.xml file available in the ant base
> classpath would be another way.
>
> Following your proposal, inside my antlib.xml I would define the
> classpath for the antlib itself, leaving all configuration inside
> there, and not having to manually define a classpath outside the
> antlib. I know this can be achieved by using an <import> task, that is
> the solution I will implement in 1.6.1, but having all the
> classloading issues inside the antlib file itself is more simple for
> the user of the antlib. Also reduces the main ant classpath.
>
> Well, those are my 2 cents, hope is clear, antlibs are great and I
> would like them to keep evolving and making it better.
>
> MAriano
>
> Jose Alberto Fernandez wrote:
>
>> Hi, I have been giving some thought on ways to solve this nagging
>> issue of needing to put antlib jars on the lib directory.
>>
>> We hear over and over people wanting to keep their third party
>> libraries out of -lib because they are only for an specific project.
>>
>> As I see it, our road block has been how to tell in succinct way in the
>> buildfile that when loading the namespace "antlib:foo.bar" you should
>> use this or that classpath or classloader.
>> A simple solution could be to achieve this by name association:
>>
>> - When ANT tries to find and load the resource for "antlib:foo.bar"
>> it will first look for a reference named "foo.bar" representing
>> a classloader (or classpath?). If an object of the correct type is
>> found, then this classloader will be user for resolving and loadding
>> the antlib, otherwise the default classloader will be use, as it is
>> today.
>>
>> So with this in place, one could write things like:
>>
>> <project name="x" xmlns:lib="antlib:foo.bar">
>>
>> <classpath id="foo.bar">.....</classpath>
>>
>> <lib:mytask ..../> <!-- The antlib loaded using the classloader for
>> "foo.bar" -->
>>
>> </project>
>>
>> Before jumping on a code proposal, does this sound a the right or good
>> solution? Does this cover enough of the use cases?
>>
>> Let me know what you people think.
>>
>> Jose Aberto
>>
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> ---------------------------------------------------------------------
>> 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: antlib and classloaders
Posted by Mariano Benitez <ma...@fuegolabs.com>.
I have this issue in mind:
Since I need to provide antlibs to my customers, I would like them to
have to manually configure as less as possible, that means that the
previous way of saying -b <myapp>/antlib was quite cool.
The problem is that I do need to control the classloader where the tasks
are loaded, because I cannot copy the whole list of jars in my app to
the antlib classpath. Maybe by just copying ONE jar to antlib is just
fine, and inside the antlib.xml control the classloading. Maybe only
making the antlib.xml file available in the ant base classpath would be
another way.
Following your proposal, inside my antlib.xml I would define the
classpath for the antlib itself, leaving all configuration inside there,
and not having to manually define a classpath outside the antlib. I know
this can be achieved by using an <import> task, that is the solution I
will implement in 1.6.1, but having all the classloading issues inside
the antlib file itself is more simple for the user of the antlib. Also
reduces the main ant classpath.
Well, those are my 2 cents, hope is clear, antlibs are great and I would
like them to keep evolving and making it better.
MAriano
Jose Alberto Fernandez wrote:
>Hi, I have been giving some thought on ways to solve this nagging
>issue of needing to put antlib jars on the lib directory.
>
>We hear over and over people wanting to keep their third party
>libraries out of -lib because they are only for an specific project.
>
>As I see it, our road block has been how to tell in succinct way in the
>buildfile that when loading the namespace "antlib:foo.bar" you should
>use this or that classpath or classloader.
>
>A simple solution could be to achieve this by name association:
>
>- When ANT tries to find and load the resource for "antlib:foo.bar"
>it will first look for a reference named "foo.bar" representing
>a classloader (or classpath?). If an object of the correct type is
>found, then this classloader will be user for resolving and loadding
>the antlib, otherwise the default classloader will be use, as it is
>today.
>
>So with this in place, one could write things like:
>
><project name="x" xmlns:lib="antlib:foo.bar">
>
> <classpath id="foo.bar">.....</classpath>
>
> <lib:mytask ..../> <!-- The antlib loaded using the classloader for
>"foo.bar" -->
>
></project>
>
>Before jumping on a code proposal, does this sound a the right or good
>solution? Does this cover enough of the use cases?
>
>Let me know what you people think.
>
>Jose Aberto
>
>
>
>
>
>
>------------------------------------------------------------------------
>
>---------------------------------------------------------------------
>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: antlib and classloaders
Posted by didge <di...@foundrylogic.com>.
How about just supporting an equivalent of an LD_LIBRARY_PATH for antlibs,
called ANTLIB_PATH or some such?
didge
> -----Original Message-----
> From: Matt Benson [mailto:gudnabrsam@yahoo.com]
> Sent: Thursday, April 01, 2004 1:58 PM
> To: Ant Developers List
> Subject: Re: antlib and classloaders
>
>
> I'm not sure I followed your suggestion. As far as
> allowing a way to automagically include stuff without
> adding it to the base installation, Antoine added the
> -lib option and Conor extended it to pull all jars
> from directories on (looks like) a path-style argument
> specified with that option (as well as including the
> directories themselves). So now I can store lots of
> antlib.xml files right on the filesystem, say under
> $HOME/.ant/lib in multiple package structures, set
> ANT_ARGS to include "-lib $HOME/.ant/lib" and voila!
> I can now modify commonly-used antlibs all I want.
>
> Now we can conceive of auto-installers that modify
> $HOME/.antrc to append -lib options to ANT_ARGS to
> point to 3rd-party stuff... since windows systems are
> less likely to use shared Ant installations, Un*x is
> the most useful place for this stuff.
>
> -Matt
>
> --- Jose Alberto Fernandez <ja...@cellectivity.com>
> wrote:
> >
> > Hi, I have been giving some thought on ways to solve
> > this nagging
> > issue of needing to put antlib jars on the lib
> > directory.
> >
> > We hear over and over people wanting to keep their
> > third party
> > libraries out of -lib because they are only for an
> > specific project.
> >
> > As I see it, our road block has been how to tell in
> > succinct way in the
> > buildfile that when loading the namespace
> > "antlib:foo.bar" you should
> > use this or that classpath or classloader.
> >
> > A simple solution could be to achieve this by name
> > association:
> >
> > - When ANT tries to find and load the resource for
> > "antlib:foo.bar"
> > it will first look for a reference named "foo.bar"
> > representing
> > a classloader (or classpath?). If an object of the
> > correct type is
> > found, then this classloader will be user for
> > resolving and loadding
> > the antlib, otherwise the default classloader will
> > be use, as it is
> > today.
> >
> > So with this in place, one could write things like:
> >
> > <project name="x" xmlns:lib="antlib:foo.bar">
> >
> > <classpath id="foo.bar">.....</classpath>
> >
> > <lib:mytask ..../> <!-- The antlib loaded using
> > the classloader for
> > "foo.bar" -->
> >
> > </project>
> >
> > Before jumping on a code proposal, does this sound a
> > the right or good
> > solution? Does this cover enough of the use cases?
> >
> > Let me know what you people think.
> >
> > Jose Aberto
> >
> >
> >
> >
> > >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > dev-unsubscribe@ant.apache.org
> > For additional commands, e-mail:
> dev-help@ant.apache.org
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Small Business $15K Web Design Giveaway
> http://promotions.yahoo.com/design_giveaway/
>
> ---------------------------------------------------------------------
> 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: antlib and classloaders
Posted by Matt Benson <gu...@yahoo.com>.
I'm not sure I followed your suggestion. As far as
allowing a way to automagically include stuff without
adding it to the base installation, Antoine added the
-lib option and Conor extended it to pull all jars
from directories on (looks like) a path-style argument
specified with that option (as well as including the
directories themselves). So now I can store lots of
antlib.xml files right on the filesystem, say under
$HOME/.ant/lib in multiple package structures, set
ANT_ARGS to include "-lib $HOME/.ant/lib" and voila!
I can now modify commonly-used antlibs all I want.
Now we can conceive of auto-installers that modify
$HOME/.antrc to append -lib options to ANT_ARGS to
point to 3rd-party stuff... since windows systems are
less likely to use shared Ant installations, Un*x is
the most useful place for this stuff.
-Matt
--- Jose Alberto Fernandez <ja...@cellectivity.com>
wrote:
>
> Hi, I have been giving some thought on ways to solve
> this nagging
> issue of needing to put antlib jars on the lib
> directory.
>
> We hear over and over people wanting to keep their
> third party
> libraries out of -lib because they are only for an
> specific project.
>
> As I see it, our road block has been how to tell in
> succinct way in the
> buildfile that when loading the namespace
> "antlib:foo.bar" you should
> use this or that classpath or classloader.
>
> A simple solution could be to achieve this by name
> association:
>
> - When ANT tries to find and load the resource for
> "antlib:foo.bar"
> it will first look for a reference named "foo.bar"
> representing
> a classloader (or classpath?). If an object of the
> correct type is
> found, then this classloader will be user for
> resolving and loadding
> the antlib, otherwise the default classloader will
> be use, as it is
> today.
>
> So with this in place, one could write things like:
>
> <project name="x" xmlns:lib="antlib:foo.bar">
>
> <classpath id="foo.bar">.....</classpath>
>
> <lib:mytask ..../> <!-- The antlib loaded using
> the classloader for
> "foo.bar" -->
>
> </project>
>
> Before jumping on a code proposal, does this sound a
> the right or good
> solution? Does this cover enough of the use cases?
>
> Let me know what you people think.
>
> Jose Aberto
>
>
>
>
> >
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> dev-unsubscribe@ant.apache.org
> For additional commands, e-mail:
dev-help@ant.apache.org
__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway
http://promotions.yahoo.com/design_giveaway/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org