I meant to respond to this earlier, but did not get the chance.
1) use of classpath in an antlib.
I have tested using a classpath within an antlib:
~/.ant/lib/x_call.jar containing:
x/antlib.xml
antlib
typedef resource=x/antlib.xml
classpath path=${user.home}/apps/x/x.jar/
/typedef
/antlib
From: Peter Reilly [mailto:[EMAIL PROTECTED]
I meant to respond to this earlier, but did not get the chance.
1) use of classpath in an antlib.
I have tested using a classpath within an antlib:
~/.ant/lib/x_call.jar containing:
x/antlib.xml
antlib
typedef resource=x/antlib.xml
This things sound like we are using the wrong abstraction here.
typedef/ inside an antlib/ should use the antlib classloader
as the parent for any subsequent classloader.
I do not see why that should cause an infinite recursion.
I feel like we have a conceptual mismatch between antlib the jar
I would agree with you on all points (I think).
Mariano Benitez wrote:
This things sound like we are using the wrong abstraction here.
typedef/ inside an antlib/ should use the antlib classloader
as the parent for any subsequent classloader.
I do not see why that should cause an infinite
Jose Alberto Fernandez wrote:
From: Peter Reilly [mailto:[EMAIL PROTECTED]
I meant to respond to this earlier, but did not get the chance.
1) use of classpath in an antlib.
I have tested using a classpath within an antlib:
~/.ant/lib/x_call.jar containing:
x/antlib.xml
antlib
typedef
From: Peter Reilly [mailto:[EMAIL PROTECTED]
Jose Alberto Fernandez wrote:
This things sound like we are using the wrong abstraction here.
typedef/ inside an antlib/ should use the antlib
classloader as the
parent for any subsequent classloader.
In this case the parent is the
Jose Alberto Fernandez wrote:
From: Peter Reilly [mailto:[EMAIL PROTECTED]
Jose Alberto Fernandez wrote:
This things sound like we are using the wrong abstraction here.
typedef/ inside an antlib/ should use the antlib
classloader as the
parent for any subsequent classloader.
that promotes reusability, etc, etc.
Jose Alberto
-Original Message-
From: Mariano Benitez [mailto:[EMAIL PROTECTED]
Sent: 17 May 2004 13:29
To: Ant Developers List
Subject: Re: antlibs and classloaders #2
This things sound like we are using the wrong abstraction here.
typedef
From: Peter Reilly [mailto:[EMAIL PROTECTED]
Jose Alberto Fernandez wrote:
From: Peter Reilly [mailto:[EMAIL PROTECTED]
In this case the parent is the antlib classloader (it is the default
classloader).
So what happens if the toplevel antlib gets loaded from a different
On Mon, 10 May 2004, Jose Alberto Fernandez
[EMAIL PROTECTED] wrote:
Would the following solve this problem generically?
!--
This task is automatically available for every ANTLIB
and its only function is to force the loading of the library
if necessary. Force the lazy loading.
From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
On Mon, 10 May 2004, Jose Alberto Fernandez
[EMAIL PROTECTED] wrote:
Would the following solve this problem generically?
!--
This task is automatically available for every ANTLIB
and its only function is to force the
Let me get this right.. this task would define the antlib classes the
moment it is invoked, and it should be used on the top level buildfile,
this way the subbuilds/subants/ant/antcall targets have the antlib
already loaded, right?
I explain a bit my build files structure for testing:
we have
From: Mariano Benitez [mailto:[EMAIL PROTECTED]
Let me get this right.. this task would define the antlib classes the
moment it is invoked, and it should be used on the top level
buildfile,
this way the subbuilds/subants/ant/antcall targets have the antlib
already loaded, right?
I
Jose Alberto Fernandez wrote:
From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
On Mon, 10 May 2004, Jose Alberto Fernandez
[EMAIL PROTECTED] wrote:
Would the following solve this problem generically?
!--
This task is automatically available for every ANTLIB
and its only function is to
From: Mariano Benitez [mailto:[EMAIL PROTECTED]
but ... If I call typedef for the same file, with the same
task, same
uri, etc, why it redefine the tasks if they are already defined?
BTW, it could help an unless attribute for typedef, not to
do it again :)
typedef
Mariano Benitez wrote:
another thing, I did the typedef thing because I cannot add
classpath to an antlib definition, so the problems are chained
I hope to get this in for ant 1.6.2.
If I would define antlibs with classpath references directly it would
be better
You would still face the
Peter Reilly wrote:
another thing, I did the typedef thing because I cannot add
classpath to an antlib definition, so the problems are chained
I hope to get this in for ant 1.6.2.
This is still in a definition process, I guess, so I cannot make any
work towards this direction.
You would
From: Mariano Benitez [mailto:[EMAIL PROTECTED]
So, I am thinking of the following workaround for the
complete scope of
the problem:
I create a task antlib that performs would look like this:
antlib property=fuego.antlib.defined
classpath
fileset
This soulds ok, but it could be done
like this:
onceonly
classpath id=fuego.classpath
fileset dir=${fuego.basedir}/lib
include name=fuegoexpress-antlib.jar/
include name=fuegoenterprise-antlib.jar/
include name=fuegoj2ee-antlib.jar/
include
Jose Alberto Fernandez wrote:
Would the following solve this problem generically?
project name=X xmlns:mylib=antlib:my.library.package
!--
This task is automatically available for every ANTLIB
and its only function is to force the loading of the library
if necessary. Force the lazy
I am at the edge of a mental crisis, I need help
Can someone explain how antlib paths and tasks works, I have this
situation that I cannot understand.
I defined this:
project name=fuego.internal.test.include basedir=.
property name=xml.encoding value=ISO-8859-1/
path
Hi Mariano,
I assume you are calling the typedef commands multiple times.
- hence the different antloaders. But you only need to typedef
the types/tasks once.
You should wrap the taskdefs in a macrodef or a target,
and call them once in the master build file before doing
any subant, or ant calls.
but ... If I call typedef for the same file, with the same task, same
uri, etc, why it redefine the tasks if they are already defined?
BTW, it could help an unless attribute for typedef, not to do it again :)
typedef resource=fuego/internal/test/ant/antlib.xml
another thing, I did the typedef thing because I cannot add classpath
to an antlib definition, so the problems are chained
If I would define antlibs with classpath references directly it would be
better
MAriano
Mariano Benitez wrote:
but ... If I call typedef for the same file, with
24 matches
Mail list logo
