RE: antlibs and classloaders #2
> 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 > >classloader (because I defined classpaths and such). Would the > > inside pick-up that as the classloader? Or would > it pickup > >some default one? > > > > > > > Currently it would use the default ant classloader. > That, to me, is wrong. While inside an antlib, you are in the context of that antlib and hence you need to have access to all classes defined by it. > >>>I do not see why that should cause an infinite recursion. > >>> > >>> > >>> > >>> > >>The problem is that the >>resource="net/.../antlib.xml"> >>path="cpptasks.jar"/> in the antlib will pick up > >>the antlib.xml resoure that contains >>resource="net/.../antlib.xml"> > >>task which will pick up ., > >> > >>This does not happen with the current ant code, as the >>resource="net/.../antlib.xml"> > >> > >>task will not see the antlib.xml resource in the parent classloader. > >> > >>Another way to work-around this is for the typedef to use a thread > >>specific stack to check > >>for recursive loading of xml resources. > >>This probally should be done in any case: > >> > >>recursive.xml > >> > >> > >> > >> > >> > >>build.xml: > >> > >> > >> > >> > >> > >> > > > >What is the difference between this and what we do for > s. In > >both cases we need to make sure we do not go into an > infinite loop. It > >should not matter whether the XML is an import fragment or an > >antlib.xml > > > > > Yes, that that the point!. > > A warning should be issued and the antlib should not be loaded again. > Agreed. Jose Alberto > Peter > > > - > 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]
RE: antlibs and classloaders #2
Mariano, I also agree with you and what you are saying. However I think we have several different parts of the proposal that are too loose and hence allow to break this general concept as you put it. For example we have: 1) The jars containing the antlig code (which is defined by a classpath or classloader) 2) The URI for the antlib, which can be specified implicitely with an antlib:uri or explicitly with the uri parameter of typedef. Using typedef, you can load several antlibs to the same namespace and such. 3) antlib.xml file or resource which contains the XML definitions of the tasks and types. Now, all this things can be used in a systemetic way to achieve your goals (I think), but they can be used to act in a quite different way and bringing all kinds of problems. So, are our objectives just the suggested user patterns for ANTLIBs or are they mandatory behaviour of antlibs. Depending on what we want, it will change the way we teach people how to write effective reusable antlibs. As oppose to "only will work on my machine" kind of antlibs. This is what I do not think we have a clear understanding. How are people to use all this moving parts in a consistent 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 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, and antlib "the resource with the XML definitions". We are > >not treating them in a symetric way or as a unit. And hence > we are get > >into all this conflicting behaviour. > > > > > > I would like to pick from here and try to describe my > understanding of > the concepts. > > Antlib: I see this as a a definition of tasks within a namespace that > involves all the jars required to resolve the execution of > the tasks. To > put it plainly, I see it as the antlib.xml with a classpath. > So for me that defines completely the antlib and the > extra classpath > should be added to the antlib classpath. > > Also, for me is accidental that the antlibs should be > located in the > $ANT_HOME/lib or in a -lib , actually the antlib > definition should > start from the antlib.xml, wherever it is, and then create a > classloader > based on the antlib definition. > > For the special case were the antlib jars are located in the base > ant classpath ($ANT_HOME/lib or -lib ) I would not > allow adding a > classpath since the antlib should be completely contained within the > base ant classpath, only when the antlib jars are outside I > would allow > defining an extra classpath. > > Also, defining antlibs in either way (being inside base ant > classpath or outside) should behave the same way, they should be > idempotent, meaning that once they are defined, they should not be > overriden, I understand that it is not wise to use the same uri for > different antlibs, the user should always try to pick unique > names for > the antlibs, otherwise we go back to a single namespace. > > This is my understanding of antlibs, it is probably out of synch with > what you envision on this, but I wanted to let you know what > I thought > antlibs were about. > > My 2 cents. > MAriano > > - > 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]
Re: antlibs and classloaders #2
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 case the parent is the antlib classloader (it is the default classloader). So what happens if the toplevel antlib gets loaded from a different classloader (because I defined classpaths and such). Would the inside pick-up that as the classloader? Or would it pickup some default one? Currently it would use the default ant classloader. I do not see why that should cause an infinite recursion. The problem is that thein the antlib will pick up the antlib.xml resoure that contains task which will pick up ., This does not happen with the current ant code, as the task will not see the antlib.xml resource in the parent classloader. Another way to work-around this is for the typedef to use a thread specific stack to check for recursive loading of xml resources. This probally should be done in any case: recursive.xml build.xml: What is the difference between this and what we do for s. In both cases we need to make sure we do not go into an infinite loop. It should not matter whether the XML is an import fragment or an antlib.xml Yes, that that the point!. A warning should be issued and the antlib should not be loaded again. Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: antlibs and classloaders #2
> 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 antlib classloader (it is the default > classloader). > So what happens if the toplevel antlib gets loaded from a different classloader (because I defined classpaths and such). Would the inside pick-up that as the classloader? Or would it pickup some default one? > >I do not see why that should cause an infinite recursion. > > > > > The problem is that the resource="net/.../antlib.xml"> path="cpptasks.jar"/> in the antlib will pick up > the antlib.xml resoure that contains resource="net/.../antlib.xml"> > task which will pick up ., > > This does not happen with the current ant code, as the resource="net/.../antlib.xml"> > > task will not see the antlib.xml resource in the parent classloader. > > Another way to work-around this is for the typedef to use a thread > specific stack to check > for recursive loading of xml resources. > This probally should be done in any case: > > recursive.xml > > > > > > build.xml: > > > > What is the difference between this and what we do for s. In both cases we need to make sure we do not go into an infinite loop. It should not matter whether the XML is an import fragment or an antlib.xml Jose Alberto > > Peter > > > - > 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]
Re: antlibs and classloaders #2
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, but depends on a possible bug in ant
see: bugzilla 28782
http://issues.apache.org/bugzilla/show_bug.cgi?id=28782
The problem is that the typedef in the antlib should pick up
two antlib.xml resources, the one in
"${user.home}/apps/x/x.jar" and the one in x_call.jar
(itself). This will should cause no-ending recursion.
The bug means that this does no happen - the resources in the
parent classloader are currently not visible to the child
classloaders.
If the bug is fixed, an infinite recursion will happen.
This could be stopped by typedef checking if it has already
been executed. This can be done by using "user" properties -
but this will pollute the property names, or by exending
(again) Project to have a map of objects that gets copied to
its child projects. Using non-user properties or references
will not work as <*ant*> tasks can stop the non-user
properties and references being copied to the child
processes. Using a static map in typedef will not work as
sibling projects will incorrectly interact.
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 antlib classloader (it is the default
classloader).
I do not see why that should cause an infinite recursion.
The problem is that the
in
the antlib will pick up the antlib.xml resoure that contains
task which will pick up .,
This does not happen with the current ant code, as the
task will not see the antlib.xml resource in the parent classloader.
Another way to work-around this is for the typedef to use a thread
specific stack to check
for recursive loading of xml resources.
This probally should be done in any case:
recursive.xml
build.xml:
Peter
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: antlibs and classloaders #2
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 we have a conceptual mismatch between antlib "the jar" with the code, and antlib "the resource with the XML definitions". We are not treating them in a symetric way or as a unit. And hence we are get into all this conflicting behaviour. I would like to pick from here and try to describe my understanding of the concepts. Antlib: I see this as a a definition of tasks within a namespace that involves all the jars required to resolve the execution of the tasks. To put it plainly, I see it as the antlib.xml with a classpath. This classpath could be defined by a task. So for me that defines completely the antlib and the extra classpath should be added to the antlib classpath. Also, for me is accidental that the antlibs should be located in the $ANT_HOME/lib or in a -lib , actually the antlib definition should start from the antlib.xml, wherever it is, and then create a classloader based on the antlib definition. For the special case were the antlib jars are located in the base ant classpath ($ANT_HOME/lib or -lib ) I would not allow adding a classpath since the antlib should be completely contained within the base ant classpath, only when the antlib jars are outside I would allow defining an extra classpath. Also, defining antlibs in either way (being inside base ant classpath or outside) should behave the same way, they should be idempotent, meaning that once they are defined, they should not be overriden, I understand that it is not wise to use the same uri for different antlibs, the user should always try to pick unique names for the antlibs, otherwise we go back to a single namespace. One antlib may "resolve" other antlibs if antlibresolve was an allowed task in an antlib. Peter This is my understanding of antlibs, it is probably out of synch with what you envision on this, but I wanted to let you know what I thought antlibs were about. My 2 cents. MAriano - 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]
Re: antlibs and classloaders #2
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, and antlib "the resource with the XML definitions". We are not treating them in a symetric way or as a unit. And hence we are get into all this conflicting behaviour. I would like to pick from here and try to describe my understanding of the concepts. Antlib: I see this as a a definition of tasks within a namespace that involves all the jars required to resolve the execution of the tasks. To put it plainly, I see it as the antlib.xml with a classpath. So for me that defines completely the antlib and the extra classpath should be added to the antlib classpath. Also, for me is accidental that the antlibs should be located in the $ANT_HOME/lib or in a -lib , actually the antlib definition should start from the antlib.xml, wherever it is, and then create a classloader based on the antlib definition. For the special case were the antlib jars are located in the base ant classpath ($ANT_HOME/lib or -lib ) I would not allow adding a classpath since the antlib should be completely contained within the base ant classpath, only when the antlib jars are outside I would allow defining an extra classpath. Also, defining antlibs in either way (being inside base ant classpath or outside) should behave the same way, they should be idempotent, meaning that once they are defined, they should not be overriden, I understand that it is not wise to use the same uri for different antlibs, the user should always try to pick unique names for the antlibs, otherwise we go back to a single namespace. This is my understanding of antlibs, it is probably out of synch with what you envision on this, but I wanted to let you know what I thought antlibs were about. My 2 cents. MAriano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: antlibs and classloaders #2
> 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, but depends on a possible bug in ant
> see: bugzilla 28782
>
> http://issues.apache.org/bugzilla/show_bug.cgi?id=28782
>
> The problem is that the typedef in the antlib should pick up
> two antlib.xml resources, the one in
> "${user.home}/apps/x/x.jar" and the one in x_call.jar
> (itself). This will should cause no-ending recursion.
>
> The bug means that this does no happen - the resources in the
> parent classloader are currently not visible to the child
> classloaders.
>
> If the bug is fixed, an infinite recursion will happen.
> This could be stopped by typedef checking if it has already
> been executed. This can be done by using "user" properties -
> but this will pollute the property names, or by exending
> (again) Project to have a map of objects that gets copied to
> its child projects. Using non-user properties or references
> will not work as <*ant*> tasks can stop the non-user
> properties and references being copied to the child
> processes. Using a static map in typedef will not work as
> sibling projects will incorrectly interact.
>
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, and antlib "the resource with the XML definitions".
We are not treating them in a symetric way or as a unit. And
hence we are get into all this conflicting behaviour.
> 2) antlibresolve
> I like the idea of antlibresolve:
>
>
>
>
> This would use ComponentHelper#checkedNamespaces to see
> if the antlib has been resolved or not, which means that
> it can be called many times without a problems.
>
>
> Using:
>
> .
> .
>
>
>
>
>
> May be considered as a short-hand (antlibresolve is now a
> reserved name and may not be used as a task/type in an antlib).
>
You are right, but I like it since it reduces the amount of retyping
of long URIs that we would have otherwise. As, how to treat such
"reserve word", is to be automatically added by as a
predefined
task of all namespaces.
>
> However:
>
>
>
> is very problematic. - for example the antlibresolve may be in a
> macrodef:
>
> ...
>
>
> ...
>
>
>
>
I see the problems...
Jose Alberto
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: antlibs and classloaders #2
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.org/bugzilla/show_bug.cgi?id=28782
The problem is that the typedef in the antlib should pick up
two antlib.xml resources, the one in "${user.home}/apps/x/x.jar"
and the one in x_call.jar (itself). This will should
cause no-ending recursion.
The bug means that this does no happen - the resources in the parent
classloader are currently not visible to the child classloaders.
If the bug is fixed, an infinite recursion will happen.
This could be stopped by typedef checking if it has already been
executed. This can be done by using "user" properties - but this
will pollute the property names, or by exending (again) Project to
have a map of objects that gets copied to its child projects. Using
non-user properties or references will not work as <*ant*> tasks can
stop the non-user properties and references being copied to the
child processes. Using a static map in typedef will not work as
sibling projects will incorrectly interact.
2) antlibresolve
I like the idea of antlibresolve:
This would use ComponentHelper#checkedNamespaces to see
if the antlib has been resolved or not, which means that
it can be called many times without a problems.
Using:
.
.
May be considered as a short-hand (antlibresolve is now a reserved
name and may not be used as a task/type in an antlib).
However:
is very problematic. - for example the antlibresolve may be in a
macrodef:
...
...
Peter
Jose Alberto Fernandez wrote:
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 explain a bit my build files structure for testing:
[snip...]
Up to this moment I need to define the tasks in boths includes using
because I
cannot pass classpath to antlibs. I also added in both includes an
...the typedef
stuff. to do this only once for all the builds.
I use a lot of subant, antcall, ants and it is very difficult
to control
in all the builds that the do use inheritall="true", since
otherwise the
would not find the property and redefine the tasks.
Here I would advocate to have the new condition
that I mentioned before. Which will not rely on inheritAll
but will look at the definintion dictionalries directly.
Could you put this structure as it would be in 1.6.2 with the
antlibresolve and antlib classpath, at least what you imagine
it might be?
I like the solution, as long as it does not
redefine the
tasks, or at least there is an option not to do so. Would it
be possible
to add to typedef that possibility?
the only thing it does is make sure the antlib URI
gets processed. As if you were calling task in the space of the antlib.
Actually on the incarnation as
it would have been a noop task whose only side-effect is causing the
loading of the antlib. If you call it 20 times it would only load
the antlib the first time, like any other task would.
(humm this may be still the best solution, just make every antlib define
this task).
How to deal with your classloaders, that is a different thing
completely.
- Is it possible to define them inside the antlib (or are they buildfile
dependent)?
- I had proposed in the past a naming convention to associate a
classpath/loader
with a particular URI. But all this is just open talk at the moment.
- Maybe can do some of this, but then its definition is
not as clean
as one would want.
Jose Alberto
Thanks for the help on this matter.
MAriano
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 takes the
antlib URI, this wouldn't even require any magic taskname.
or even .
I have no problem, one way or another, as long as I do not
have to type
the whole URI again ;-) This is why I want to use the NS prefix
instead. Is there an way for the task to get the information needed
(the URI)?
Since a lot of this is resolved by the parser (prefix-->uri)
mapping, I
was trying to make sure we do not get bog by the design. So
as long as
we can get the info necessary by just saying:
or
In this second, we get the URI from "ns" attribute which is in that
space. the implementation could use the new NS aware
features that were
added recently.
Jose Alberto
Re: antlibs and classloaders #2
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 takes the antlib URI, this wouldn't even require any magic taskname. or even . I have no problem, one way or another, as long as I do not have to type the whole URI again ;-) This is why I want to use the NS prefix instead. Is there an way for the task to get the information needed (the URI)? Since a lot of this is resolved by the parser (prefix-->uri) mapping, I was trying to make sure we do not get bog by the design. So as long as we can get the info necessary by just saying: This is not currently possible. The prefix->uri mapping is only retained for the element names and the tag names (using the NS dynamic con (The ant-type attribute is the only exception, but this is implemented by a horrid cludge, the parser "knows" about "ant-type" and substitutes the value in). or In this second, we get the URI from "ns" attribute which is in that space. the implementation could use the new NS aware features that were added recently. I assume you mean the NS aware dymanic configurator patch. The second form of the antlibresolve task could use to implement the "antlib:ns" style attribute, but it feels like a cludge. Peter Jose Alberto - 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]
RE: antlibs and classloaders #2
> 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 explain a bit my build files structure for testing: > [snip...] > > Up to this moment I need to define the tasks in boths includes using > because I > cannot pass classpath to antlibs. I also added in both includes an > ...the typedef > stuff. to do this only once for all the builds. > I use a lot of subant, antcall, ants and it is very difficult > to control > in all the builds that the do use inheritall="true", since > otherwise the > would not find the property and redefine the tasks. > Here I would advocate to have the new condition that I mentioned before. Which will not rely on inheritAll but will look at the definintion dictionalries directly. > Could you put this structure as it would be in 1.6.2 with the > antlibresolve and antlib classpath, at least what you imagine > it might be? > > I like the solution, as long as it does not > redefine the > tasks, or at least there is an option not to do so. Would it > be possible > to add to typedef that possibility? > the only thing it does is make sure the antlib URI gets processed. As if you were calling task in the space of the antlib. Actually on the incarnation as it would have been a noop task whose only side-effect is causing the loading of the antlib. If you call it 20 times it would only load the antlib the first time, like any other task would. (humm this may be still the best solution, just make every antlib define this task). How to deal with your classloaders, that is a different thing completely. - Is it possible to define them inside the antlib (or are they buildfile dependent)? - I had proposed in the past a naming convention to associate a classpath/loader with a particular URI. But all this is just open talk at the moment. - Maybe can do some of this, but then its definition is not as clean as one would want. Jose Alberto > Thanks for the help on this matter. > > MAriano > > 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 takes the > >>antlib URI, this wouldn't even require any magic taskname. > >> > >> or even . > >> > >> > > > >I have no problem, one way or another, as long as I do not > have to type > >the whole URI again ;-) This is why I want to use the NS prefix > >instead. Is there an way for the task to get the information needed > >(the URI)? > > > >Since a lot of this is resolved by the parser (prefix-->uri) > mapping, I > >was trying to make sure we do not get bog by the design. So > as long as > >we can get the info necessary by just saying: > > > > > > > >or > > > > > > > >In this second, we get the URI from "ns" attribute which is in that > >space. the implementation could use the new NS aware > features that were > >added recently. > > > >Jose Alberto > > > >- > >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] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: antlibs and classloaders #2
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 local/tests directory were all tests modules reside (20+), we have a build.xml at the top level for global cleans builds, runs, etc, and at the module dir, anothere build.xml for single module runs. I use an to define stuff at the module level, and a for global tests runs. Up to this moment I need to define the tasks in boths includes using because I cannot pass classpath to antlibs. I also added in both includes an ...the typedef stuff. to do this only once for all the builds. I use a lot of subant, antcall, ants and it is very difficult to control in all the builds that the do use inheritall="true", since otherwise the would not find the property and redefine the tasks. Could you put this structure as it would be in 1.6.2 with the antlibresolve and antlib classpath, at least what you imagine it might be? I like the solution, as long as it does not redefine the tasks, or at least there is an option not to do so. Would it be possible to add to typedef that possibility? Thanks for the help on this matter. MAriano 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 takes the antlib URI, this wouldn't even require any magic taskname. or even . I have no problem, one way or another, as long as I do not have to type the whole URI again ;-) This is why I want to use the NS prefix instead. Is there an way for the task to get the information needed (the URI)? Since a lot of this is resolved by the parser (prefix-->uri) mapping, I was trying to make sure we do not get bog by the design. So as long as we can get the info necessary by just saying: or In this second, we get the URI from "ns" attribute which is in that space. the implementation could use the new NS aware features that were added recently. Jose Alberto - 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]
RE: antlibs and classloaders #2
> 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 takes the > antlib URI, this wouldn't even require any magic taskname. > > or even . I have no problem, one way or another, as long as I do not have to type the whole URI again ;-) This is why I want to use the NS prefix instead. Is there an way for the task to get the information needed (the URI)? Since a lot of this is resolved by the parser (prefix-->uri) mapping, I was trying to make sure we do not get bog by the design. So as long as we can get the info necessary by just saying: or In this second, we get the URI from "ns" attribute which is in that space. the implementation could use the new NS aware features that were added recently. Jose Alberto - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: antlibs and classloaders #2
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 even . Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: antlibs and classloaders #2
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 difficult to remember to do this. The only difference will be the speed of the build. Peter This looks much better than calling some task from the antlib with doggie parameters. What do people think? Jose Alberto - 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]
Re: antlibs and classloaders #2
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 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 the problem. The antlib: namespace automatic loading of tasks/types is only triggered if a task or type from the namespace is used. From what you said I understand that the antlib definition is lazy and done from the current ant and descendents, not for the whole ant script, this is why if the usage of an antlib task is inside subants, then for each one another classloader is created. That's why if I define it in the top level ant it applies for all subants. 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: Here I would check with the property, and if not set define a classloader with that classpath and define the antlibs in that loader, just what I do in the import file, but inside a task. I can put this task in the ant -lib path, and use it in the import files. What do you think? MAriano - 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]
RE: antlibs and classloaders #2
> 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: > > > > > > > > > > > > > > > > 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. This looks much better than calling some task from the antlib with doggie parameters. What do people think? Jose Alberto - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: antlibs and classloaders #2
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 the problem. The antlib: namespace automatic loading of tasks/types is only triggered if a task or type from the namespace is used. From what you said I understand that the antlib definition is lazy and done from the current ant and descendents, not for the whole ant script, this is why if the usage of an antlib task is inside subants, then for each one another classloader is created. That's why if I define it in the top level ant it applies for all subants. 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: Here I would check with the property, and if not set define a classloader with that classpath and define the antlibs in that loader, just what I do in the import file, but inside a task. I can put this task in the ant -lib path, and use it in the import files. What do you think? MAriano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: antlibs and classloaders #2
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.
The antlib: namespace automatic loading of tasks/types is only triggered
if a task or type from
the namespace is used.
for example if you have a master.xml file:
and each of the projects had:
...
Each of the subprojects would trigger the task defs for the cpptasks namespace.
The way to work around this would be to do:
Peter
MAriano
Mariano Benitez wrote:
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" 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.
Peter
Mariano Benitez wrote:
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" is in the classpath manifest of those
jars, inside the fuegocore jar there is a clas "Loader".
When I am executing one of the tasks in the antlib I do this.
Inside an Utils.class static method:
task.log("[LOADERS] Loader Class [" +
Loader.class.hashCode() + "/" + Loader.class.getClassLoader() + "]");
task.log("[LOADERS] Utils Class [" + Utils.class.hashCode()
+ "/" + Utils.class.getClassLoader() + "]");
and this is the result I get when I run this multiple times in the
same ant run.
[t:testsetup] [LOADERS] Loader Class
[6597453/[EMAIL PROTECTED]
[t:testsetup] [LOADERS] Utils Class
[19551658/[EMAIL PROTECTED]
[t:testsetup] [LOADERS] Loader Class
[6597453/[EMAIL PROTECTED]
[t:testsetup] [LOADERS] Utils Class
[10520143/[EMAIL PROTECTED]
[t:testsetup] [LOADERS] Loader Class
[6597453/[EMAIL PROTECTED]
[t:testsetup] [LOADERS] Utils Class
[28623319/[EMAIL PROTECTED]
the thing is: WHY THE LOADER CLASS IS ALWAYS THE SAME WHILE THE
UTILS CLASS IS ALWAYS IN DIFFERENT ANT CLASSLOADERS!!!
Also, If I put a static {} block in the Loader class it is invoked
many times, not only one as it should, being the same class the one
being returned.
Please help, I cannot understand what is causing this and the
side-effect is that I get OutOfMemory errors when I run nightly
batch tests.
Everything is appreciated.
MAriano
-
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]
-
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: antlibs and classloaders #2
> 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="antlib:fuego.internal.test.ant"
> loaderRef="fuego.internal.test"
> classpathref="fuego.internal.test.antlibs.path" unless="defined"/>
>
>
I would advocate for a new condition:
Which is true for "uri" if there are things already defined in that uri;
and for "name" if there is a definition already associated with that
name
(in te particular NS). This should include all kinds of definitions
typedefs, macros, selectors, mappers, etc. We should add a "role"
also once that issue is sorted out.
Jose Alberto
> MAriano
>
> Peter Reilly wrote:
>
> > 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.
> >
> > Peter
> >
> > Mariano Benitez wrote:
> >
> >> 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:
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> >> uri="antlib:fuego.internal.test.ant"
> >> loaderRef="fuego.internal.test"
> >> classpathref="fuego.internal.test.antlibs.path"/>
> >> >> uri="antlib:fuego.tools.ant.enterprise"
> >> loaderRef="fuego.internal.test"
> >> classpathref="fuego.internal.test.antlibs.path"/>
> >> >> uri="antlib:fuego.tools.ant.express"
> >> loaderRef="fuego.internal.test"
> >> classpathref="fuego.internal.test.antlibs.path"/>
> >> >> uri="antlib:fuego.tools.ant.j2ee"
> >> loaderRef="fuego.internal.test"
> >> classpathref="fuego.internal.test.antlibs.path"/>
> >>
> >>
> >> another Jar "fuegocore.jar" is in the classpath manifest of those
> >> jars, inside the fuegocore jar there is a clas "Loader".
> >>
> >> When I am executing one of the tasks in the antlib I do this.
> >>
> >> Inside an Utils.class static method:
> >>task.log("[LOADERS] Loader Class [" +
> Loader.class.hashCode()
> >> + "/" + Loader.class.getClassLoader() + "]");
> >>task.log("[LOADERS] Utils Class [" +
> Utils.class.hashCode() +
> >> "/" + Utils.class.getClassLoader() + "]");
> >>
> >> and this is the result I get when I run this multiple times in the
> >> same ant run.
> >>
> >> [t:testsetup] [LOADERS] Loader Class
> >> [6597453/[EMAIL PROTECTED]
> >> [t:testsetup] [LOADERS] Utils Class
> >> [19551658/[EMAIL PROTECTED]
> >>
> >> [t:testsetup] [LOADERS] Loader Class
> >> [6597453/[EMAIL PROTECTED]
> >> [t:testsetup] [LOADERS] Utils Class
> >> [10520143/[EMAIL PROTECTED]
> >>
> >> [t:testsetup] [LOADERS] Loader Class
> >> [6597453/[EMAIL PROTECTED]
> >> [t:testsetup] [LOADERS] Utils Class
> >> [28623319/[EMAIL PROTECTED]
> >>
> >>
> >>
> >> the thing is: WHY THE LOADER CLASS IS ALWAYS THE SAME
> WHILE THE UTILS
> >> CLASS IS ALWAYS IN DIFFERENT ANT CLASSLOADERS!!!
> >>
> >> Also, If I put a static {} block in the Loader class it is invoked
> >> many times, not only one as it should, being the same
> class the one
> >> being returned.
> >>
> >> Please help, I cannot understand what is causing this and the
> >> side-effect is that I get OutOfMemory errors when I run
> nightly batch
> >> tests.
> >>
> >>
> >> Everything is appreciated.
> >>
> >> MAriano
> >>
> >>
> -
> >> 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]
> >
>
> -
> 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]
Re: antlibs and classloaders #2
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 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" 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.
Peter
Mariano Benitez wrote:
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" is in the classpath manifest of those
jars, inside the fuegocore jar there is a clas "Loader".
When I am executing one of the tasks in the antlib I do this.
Inside an Utils.class static method:
task.log("[LOADERS] Loader Class [" +
Loader.class.hashCode() + "/" + Loader.class.getClassLoader() + "]");
task.log("[LOADERS] Utils Class [" + Utils.class.hashCode()
+ "/" + Utils.class.getClassLoader() + "]");
and this is the result I get when I run this multiple times in the
same ant run.
[t:testsetup] [LOADERS] Loader Class
[6597453/[EMAIL PROTECTED]
[t:testsetup] [LOADERS] Utils Class
[19551658/[EMAIL PROTECTED]
[t:testsetup] [LOADERS] Loader Class
[6597453/[EMAIL PROTECTED]
[t:testsetup] [LOADERS] Utils Class
[10520143/[EMAIL PROTECTED]
[t:testsetup] [LOADERS] Loader Class
[6597453/[EMAIL PROTECTED]
[t:testsetup] [LOADERS] Utils Class
[28623319/[EMAIL PROTECTED]
the thing is: WHY THE LOADER CLASS IS ALWAYS THE SAME WHILE THE
UTILS CLASS IS ALWAYS IN DIFFERENT ANT CLASSLOADERS!!!
Also, If I put a static {} block in the Loader class it is invoked
many times, not only one as it should, being the same class the one
being returned.
Please help, I cannot understand what is causing this and the
side-effect is that I get OutOfMemory errors when I run nightly
batch tests.
Everything is appreciated.
MAriano
-
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]
-
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]
Re: antlibs and classloaders #2
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" 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.
Peter
Mariano Benitez wrote:
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" is in the classpath manifest of those
jars, inside the fuegocore jar there is a clas "Loader".
When I am executing one of the tasks in the antlib I do this.
Inside an Utils.class static method:
task.log("[LOADERS] Loader Class [" + Loader.class.hashCode()
+ "/" + Loader.class.getClassLoader() + "]");
task.log("[LOADERS] Utils Class [" + Utils.class.hashCode() +
"/" + Utils.class.getClassLoader() + "]");
and this is the result I get when I run this multiple times in the
same ant run.
[t:testsetup] [LOADERS] Loader Class
[6597453/[EMAIL PROTECTED]
[t:testsetup] [LOADERS] Utils Class
[19551658/[EMAIL PROTECTED]
[t:testsetup] [LOADERS] Loader Class
[6597453/[EMAIL PROTECTED]
[t:testsetup] [LOADERS] Utils Class
[10520143/[EMAIL PROTECTED]
[t:testsetup] [LOADERS] Loader Class
[6597453/[EMAIL PROTECTED]
[t:testsetup] [LOADERS] Utils Class
[28623319/[EMAIL PROTECTED]
the thing is: WHY THE LOADER CLASS IS ALWAYS THE SAME WHILE THE UTILS
CLASS IS ALWAYS IN DIFFERENT ANT CLASSLOADERS!!!
Also, If I put a static {} block in the Loader class it is invoked
many times, not only one as it should, being the same class the one
being returned.
Please help, I cannot understand what is causing this and the
side-effect is that I get OutOfMemory errors when I run nightly batch
tests.
Everything is appreciated.
MAriano
-
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: antlibs and classloaders #2
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.
Peter
Mariano Benitez wrote:
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" is in the classpath manifest of those
jars, inside the fuegocore jar there is a clas "Loader".
When I am executing one of the tasks in the antlib I do this.
Inside an Utils.class static method:
task.log("[LOADERS] Loader Class [" + Loader.class.hashCode()
+ "/" + Loader.class.getClassLoader() + "]");
task.log("[LOADERS] Utils Class [" + Utils.class.hashCode() +
"/" + Utils.class.getClassLoader() + "]");
and this is the result I get when I run this multiple times in the
same ant run.
[t:testsetup] [LOADERS] Loader Class
[6597453/[EMAIL PROTECTED]
[t:testsetup] [LOADERS] Utils Class
[19551658/[EMAIL PROTECTED]
[t:testsetup] [LOADERS] Loader Class
[6597453/[EMAIL PROTECTED]
[t:testsetup] [LOADERS] Utils Class
[10520143/[EMAIL PROTECTED]
[t:testsetup] [LOADERS] Loader Class
[6597453/[EMAIL PROTECTED]
[t:testsetup] [LOADERS] Utils Class
[28623319/[EMAIL PROTECTED]
the thing is: WHY THE LOADER CLASS IS ALWAYS THE SAME WHILE THE UTILS
CLASS IS ALWAYS IN DIFFERENT ANT CLASSLOADERS!!!
Also, If I put a static {} block in the Loader class it is invoked
many times, not only one as it should, being the same class the one
being returned.
Please help, I cannot understand what is causing this and the
side-effect is that I get OutOfMemory errors when I run nightly batch
tests.
Everything is appreciated.
MAriano
-
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]
