> 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 get
t way 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
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.
inside an should use the antlib
classloader as the
parent for any subsequent classloader.
In this c
> From: Peter Reilly [mailto:[EMAIL PROTECTED]
>
> Jose Alberto Fernandez wrote:
>
> >This things sound like we are using the wrong abstraction here.
> > inside an 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]
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
This works fine,
I would agree with you on all points (I think).
Mariano Benitez wrote:
This things sound like we are using the wrong abstraction here.
inside an 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 w
This things sound like we are using the wrong abstraction here.
inside an 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"
with the code, an
> 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
>
>
>
>
>
>
> This w
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
This works fine, but depends on a possible bug in ant
see: bugzilla 28782
http://issues.apache
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?
looks like a reasonable compromise.
The alternative would be a built-in task that
> 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?
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 a
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
>
> On Mon, 10 May 2004, Jose Alberto Fernandez
> <[EMAIL PROTECTED]> wrote:
>
> > Would the following solve this problem generically?
> >
> >
> >
>
> looks like a reasonable compromise.
>
> The alternative would be a built-in task that ta
On Mon, 10 May 2004, Jose Alberto Fernandez
<[EMAIL PROTECTED]> wrote:
> Would the following solve this problem generically?
>
>
>
looks like a reasonable compromise.
The alternative would be a built-in task that takes the antlib URI,
this wouldn't even require any magic taskname.
or eve
Jose Alberto Fernandez wrote:
Would the following solve this problem generically?
The above assumes somehow we manage to define the classpath required
as part of the ANTLIB itself. If not, the task could have the classpath
information.
That sounds like a good idea.
It may however be diffi
This soulds ok, but it could be done
like this:
see:
http://marc.theaimsgroup.com/?l=ant-dev&m=108331661709918&w=2
Peter
Mariano Benitez wrote:
Peter Reilly wrote:
another thing, I did the thing because I cannot add
classpat
> 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 that performs would look like this:
>
>
>
>
>
>
>
>
>
Peter Reilly wrote:
another thing, I did the 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 still face
Mariano Benitez wrote:
another thing, I did the 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 problem.
> 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 :)
> uri="antli
another thing, I did the 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 the same
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 :)
MAriano
Peter Reilly wrote:
Hi Mariano,
I assume you are calling the "typedef
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.
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:
another Jar "fuegocore.jar"
24 matches
Mail list logo
