Re: antlibs and classloaders #2
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 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 path, 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 path) 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
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 import file=${basedir}/include/xml/ to define stuff at the module
level, and a import file=${basedir}/server-include.xml/ for global
tests runs.
Up to this moment I need to define the tasks in boths includes using
typedef uri= loaderref=... classpathref=.../ because I
cannot pass classpath to antlibs. I also added in both includes an
ifnotisset property=antlibs.define//notthen...the typedef
stuff. /if 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
if 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 antlibresolve 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?
!--
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.
--
mylib:antlibresolve/
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.
antlibresolve uri=.../ or even antlibresolve prefix=.../.
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:
antlibresolve prefix=mylib/
or
antlibresolve mylib:ns=ignored value /
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
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 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 antlib that performs would look like this:
antlib property=fuego.antlib.defined
classpath
fileset dir=${fuego.basedir}/lib
include name=fuegoexpress-antlib.jar/
include name=fuegoenterprise-antlib.jar/
include name=fuegoj2ee-antlib.jar/
include name=fuego-test-antlib.jar/
/fileset
/classpath
typedef package=fuego.tools.ant.enterprise/
typedef package=fuego.tools.ant.express/
typedef resource=fuego/tools/ant/j2ee/antlib.xml/
typedef resource=fuego/internal/test/ant/myFile.xml/
/antlib
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]
antlibs and classloaders #2
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 id=fuego.internal.test.antlibs.path
fileset dir=${fuego.basedir}/lib
include name=fuegoexpress-antlib.jar/
include name=fuegoenterprise-antlib.jar/
include name=fuegoj2ee-antlib.jar/
include name=fuego-test-antlib.jar/
/fileset
/path
typedef resource=fuego/internal/test/ant/antlib.xml
uri=antlib:fuego.internal.test.ant
loaderRef=fuego.internal.test
classpathref=fuego.internal.test.antlibs.path/
typedef resource=fuego/tools/ant/enterprise/antlib.xml
uri=antlib:fuego.tools.ant.enterprise loaderRef=fuego.internal.test
classpathref=fuego.internal.test.antlibs.path/
typedef resource=fuego/tools/ant/express/antlib.xml
uri=antlib:fuego.tools.ant.express
loaderRef=fuego.internal.test
classpathref=fuego.internal.test.antlibs.path/
typedef resource=fuego/tools/ant/j2ee/antlib.xml
uri=antlib:fuego.tools.ant.j2ee
loaderRef=fuego.internal.test
classpathref=fuego.internal.test.antlibs.path/
/project
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]
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 :)
typedef resource=fuego/internal/test/ant/antlib.xml
uri=antlib:fuego.internal.test.ant
loaderRef=fuego.internal.test
classpathref=fuego.internal.test.antlibs.path unless=defined/
property name=defined value=true/
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:
project name=fuego.internal.test.include basedir=.
property name=xml.encoding value=ISO-8859-1/
path id=fuego.internal.test.antlibs.path
fileset dir=${fuego.basedir}/lib
include name=fuegoexpress-antlib.jar/
include name=fuegoenterprise-antlib.jar/
include name=fuegoj2ee-antlib.jar/
include name=fuego-test-antlib.jar/
/fileset
/path
typedef resource=fuego/internal/test/ant/antlib.xml
uri=antlib:fuego.internal.test.ant
loaderRef=fuego.internal.test
classpathref=fuego.internal.test.antlibs.path/
typedef resource=fuego/tools/ant/enterprise/antlib.xml
uri=antlib:fuego.tools.ant.enterprise
loaderRef=fuego.internal.test
classpathref=fuego.internal.test.antlibs.path/
typedef resource=fuego/tools/ant/express/antlib.xml
uri=antlib:fuego.tools.ant.express
loaderRef=fuego.internal.test
classpathref=fuego.internal.test.antlibs.path/
typedef resource=fuego/tools/ant/j2ee/antlib.xml
uri=antlib:fuego.tools.ant.j2ee
loaderRef=fuego.internal.test
classpathref=fuego.internal.test.antlibs.path/
/project
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
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 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
uri=antlib:fuego.internal.test.ant
loaderRef=fuego.internal.test
classpathref=fuego.internal.test.antlibs.path unless=defined/
property name=defined value=true/
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:
project name=fuego.internal.test.include basedir=.
property name=xml.encoding value=ISO-8859-1/
path id=fuego.internal.test.antlibs.path
fileset dir=${fuego.basedir}/lib
include name=fuegoexpress-antlib.jar/
include name=fuegoenterprise-antlib.jar/
include name=fuegoj2ee-antlib.jar/
include name=fuego-test-antlib.jar/
/fileset
/path
typedef resource=fuego/internal/test/ant/antlib.xml
uri=antlib:fuego.internal.test.ant
loaderRef=fuego.internal.test
classpathref=fuego.internal.test.antlibs.path/
typedef resource=fuego/tools/ant/enterprise/antlib.xml
uri=antlib:fuego.tools.ant.enterprise
loaderRef=fuego.internal.test
classpathref=fuego.internal.test.antlibs.path/
typedef resource=fuego/tools/ant/express/antlib.xml
uri=antlib:fuego.tools.ant.express
loaderRef=fuego.internal.test
classpathref=fuego.internal.test.antlibs.path/
typedef resource=fuego/tools/ant/j2ee/antlib.xml
uri=antlib:fuego.tools.ant.j2ee
loaderRef=fuego.internal.test
classpathref=fuego.internal.test.antlibs.path/
/project
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]
when are tasks instances no longer referenced?
I want to know if a task instance created lifes for the complete build or it is no longer referenced once it has been executed. The problem I have is that some tasks allocate a lot of memory, so I need to know if I have to do something manually or I just leave the gc to remove my instance. THX, MAriano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: when are tasks instances no longer referenced?
I have no ID in the task. [EMAIL PROTECTED] wrote: A task can be executed multiple times - via Ants API. echo id=theEchoHello/echo script language=javascript ![CDATA[ theEcho.perform(); theEcho.perform(); ]]/script If a task has an ID its reference is stored in the projects reference table (I don´t know what happens if it has no ID). Jan -Original Message- From: Mariano Benitez [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 05, 2004 5:03 PM To: Ant Developers List Subject: when are tasks instances no longer referenced? I want to know if a task instance created lifes for the complete build or it is no longer referenced once it has been executed. The problem I have is that some tasks allocate a lot of memory, so I need to know if I have to do something manually or I just leave the gc to remove my instance. THX, 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: antlib and classloaders
The only problem with this is that the user build script needs to set the correct property before the antlib is activated. Which I think it is not much to ask. I have a conceptual problem of usability on an antlib written like this, remember, in the broader sense, the antlib is written by a third party for the usage of unrelated users in unrelated projects. Having a classpath in there, constricts the user of the library to follow whichever layout criteria the third-party decides. Which does not seem to be right. The context in which I say this is: I have a big application (www.fuego.com) that provides ant tasks to perform most of its admin operation, it is a requirement to have the application installed and then define a property fuego.basedir that tells where the app is installed. The main problem is that I cannot bundle all the required files to use the application in a single antlib, it would be extremely big and hard to update/patch/etc. without lots of manual intervention. My intention is to minimize the manual steps to have a fuego antlib working, so the xmlns:fuego=antlib:fuego.tools.ant was great. Using an include.xml file is a good workaround but that implies that on every build besides the xml namespace they need to do one more step, that is a 100% increase in the number or changes they need to run fuego. :) I guess that most big application might follow this kind of path, having a small antlib file, and refer to the dependencies that are in the application install dir. I completely agree that for most basic/optional (core) tasks would include all the dependencies in the antlib, but for a big app it is not possible. I guess my case is the one for tasks that are bundled in other applications. For example, if the Tomcat guys bundle their tasks with them, why should you copy all the jasper stuff to an antlib instead of reference them from the antlib.xml MAriano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What do you think about a classloader task ?
+1 Rainer Noack wrote: Hi Ant developers, After taskdef supports the loaderref attribute, I've written a task that is able to a) append classpath entries to existing classloaders, b) explicitely create classloaders, c) put the actual path of a classloader into a property and d) log a simple report about the currently classloaders. Currently it supports URLClassLoader and AntClassLoader. It is designed to simply support custom extensions for any arbitrary ClassLoader. I've posted it some time ago - a little rash (sorry) - to this list. However, as classpathes can completely managed from inside the build.xml, this task has helped in several projects 1. to avoid the need to either change Ant's default installation by adding or removing jars to or from Ant's lib dir or manage the classpath in the launching script and 2. to avoid classpath-problems with custom tasks (especially if they should - for whatever reason - be used as jars in the same buildfile as they were created). b) and c) can be used to easily sync other task's classpathes and d) was helpful to debug some classpath problems and understand classloader behaviour ;-) When I found a similar Classloader task in Ant's CVS (originally from Costin Manolache), I was wondering that it was never advanced and released. IMHO, a classloader task would be a pretty helpfull extension to the existing alternatives for some usage. Are there reasons for not releasing it? I would be grateful for a short annotation (found nothing in the list archive). Otherwise, I would be proud to contribute the task to Ant if you find it helpful too. Regards (and excuse me for the long mail), Rainer P.S. Adding this task to the external task list is dissatisfying IMHO, as it shoots the major advantage (1.) down. - 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]
import task from a resource
In order to solve a problem related to classloaders, I need to bundle an include file (include.xml) so I can define the task in a classpath different from the antlib classpath. At this moment the only way is to put the file in the FS, but it would be very convenient to obtain that import from a resource in the antlib jar. I can implement this and provide the patch, is this valid or am I talking nonsense. MAriano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: import task from a resource
there was a long thread with this issue, you can check it , the last
mail is below:
bottomline is that I cannot put a lot of jars in the antlib directory
(-lib ...) and I need them for the tasks, so we come out with this solution.
MAriano
--
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: [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]
Matt Benson wrote:
--- Mariano Benitez [EMAIL PROTECTED] wrote:
In order to solve a problem related to classloaders,
I need to bundle an
include file (include.xml) so I can define the task
in a classpath
different from the antlib classpath.
[SNIP]
I can implement this and provide the patch, is this
valid or am I
talking nonsense.
I don't know, couldn't you just use a separate antlib?
-Matt
__
Do you Yahoo!?
Yahoo! Finance Tax Center - File online. File on time.
http://taxes.yahoo.com/filing.html
-
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: import task from a resource
that is way too much, I wanted a simpler solution FOR ME, not for the import task. Anyway, the basedir attribute, isn't inherited from the importing build? MAriano Dominique Devienne wrote: From: Mariano Benitez [mailto:[EMAIL PROTECTED] In order to solve a problem related to classloaders, I need to bundle an include file (include.xml) so I can define the task in a classpath different from the antlib classpath. At this moment the only way is to put the file in the FS, but it would be very convenient to obtain that import from a resource in the antlib jar. I can implement this and provide the patch, is this valid or am I talking nonsense. This was considered during the discussions on import, but didn't make it, I don't recall why. Maybe had to do with keeping import simple, and problems extracting the basedir of the imported file!? You can always get the URL before import. Oops, you need a custom resource: protocol handler for that... I posted one, but it requires additional setup so the JVM knows about it. You can always write a little script to dump the URL on disk before the import still. --DD - 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: import task from a resource
if you mean this: quote Imported files are treated as they are present in the main buildfile. This makes it easy to understand, but it makes it impossible for them to reference files and resources relative to their path. Because of this, for every imported file, Ant adds a property that contains the path to the imported buildfile. With this path, the imported buildfile can keep resources and be able to reference them relative to its position. I can live without it, I mean, if you import a file from a resource, don't add the ant.imported.file property that and make all references to the original basedir. MAriano Matt Benson wrote: --- Mariano Benitez [EMAIL PROTECTED] wrote: that is way too much, I wanted a simpler solution FOR ME, not for the import task. Anyway, the basedir attribute, isn't inherited from the importing build? No, see import's manual page... -Matt __ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html - 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: taskdefs inside an antlib and their classpath
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: [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]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: taskdefs inside an antlib and their classpath
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: taskdefs inside an antlib and their classpath
the problem is that they cannot be relative :( the situation is: to be honest, I was trying to lock the application jars by not leaving them in the antlib classpath and using the classpath element in the taskdef to load them on demand. I can live with it, no big problem. The only real bug would be that the taskdef do not throw any warning when it is ignoring the taskdef classpath, loaderref, etc. In this case I would suggest that taskdef logs a warning or fails if you defined extra classpath inside an antlib. MAriano Jose Alberto Fernandez wrote: Your antlib definitions live inside some Jar (yes?) Then you could use the Class-Path attribute of the Manifest to point to the additional jars. Al long as the addresses are relative all should work fine and the classloader will do the right thing. Would that work for you? Jose Alberto -Original Message- From: Mariano Benitez [mailto:[EMAIL PROTECTED] Sent: 05 March 2004 18:22 To: Ant Developers List Subject: Re: taskdefs inside an antlib and their classpath 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: [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: patch for JUnitTask extension
--- src/main/org/apache/tools/ant/types/CommandlineJava.java2004-02-11
15:27:15.0 -0300
+++
/opt/java/ant/apache-ant-1.6.0/src/main/org/apache/tools/ant/types/CommandlineJava.java
2004-02-11 15:08:41.0 -0300
@@ -432,7 +432,7 @@
* Get the VM command parameters, including memory settings
* @return
*/
-private Commandline getActualVMCommand() {
+protected Commandline getActualVMCommand() {
Commandline actualVMCommand = (Commandline) vmCommand.clone();
if (maxMemory != null) {
if (vmVersion.startsWith(1.1)) {
@@ -567,7 +567,7 @@
*
* @since Ant 1.6
*/
-private boolean haveClasspath() {
+protected boolean haveClasspath() {
Path fullClasspath = classpath != null
? classpath.concatSystemClasspath(ignore) : null;
return fullClasspath != null
@@ -584,7 +584,7 @@
*
* @since Ant 1.6
*/
-private boolean haveBootclasspath(boolean log) {
+protected boolean haveBootclasspath(boolean log) {
if (bootclasspath != null
bootclasspath.toString().trim().length() 0) {
--- src/main/org/apache/tools/ant/taskdefs/optional/junit/JUnitTask.java
2004-02-11 15:27:15.0 -0300
+++
/opt/java/ant/apache-ant-1.6.0/src/main/org/apache/tools/ant/taskdefs/optional/junit/JUnitTask.java
2004-02-11 14:43:03.0 -0300
@@ -123,7 +123,7 @@
*/
public class JUnitTask extends Task {
-private CommandlineJava commandline = new CommandlineJava();
+private CommandlineJava commandline;
private Vector tests = new Vector();
private Vector batchTests = new Vector();
private Vector formatters = new Vector();
@@ -338,7 +338,7 @@
* @since Ant 1.2
*/
public void setMaxmemory(String max) {
-commandline.setMaxmemory(max);
+getCommandline().setMaxmemory(max);
}
/**
@@ -352,7 +352,7 @@
* @since Ant 1.2
*/
public void setJvm(String value) {
-commandline.setVm(value);
+getCommandline().setVm(value);
}
/**
@@ -365,7 +365,7 @@
* @since Ant 1.2
*/
public Commandline.Argument createJvmarg() {
-return commandline.createVmArgument();
+return getCommandline().createVmArgument();
}
/**
@@ -390,7 +390,7 @@
*/
public void addSysproperty(Environment.Variable sysp) {
-commandline.addSysproperty(sysp);
+getCommandline().addSysproperty(sysp);
}
/**
@@ -405,7 +405,7 @@
// see bugzilla report 21684
String testString = sysp.getContent();
getProject().log(sysproperty added : + testString,
Project.MSG_DEBUG);
-commandline.addSysproperty(sysp);
+getCommandline().addSysproperty(sysp);
}
/**
@@ -419,7 +419,7 @@
* @since Ant 1.6
*/
public void addSyspropertyset(PropertySet sysp) {
-commandline.addSyspropertyset(sysp);
+getCommandline().addSyspropertyset(sysp);
}
/**
@@ -429,7 +429,7 @@
* @since Ant 1.2
*/
public Path createClasspath() {
-return commandline.createClasspath(getProject()).createPath();
+return getCommandline().createClasspath(getProject()).createPath();
}
/**
@@ -438,7 +438,7 @@
* @since Ant 1.6
*/
public Path createBootclasspath() {
-return commandline.createBootclasspath(getProject()).createPath();
+return getCommandline().createBootclasspath(getProject()).createPath();
}
/**
@@ -532,10 +532,10 @@
* @param asserts assertion set
*/
public void addAssertions(Assertions asserts) {
-if (commandline.getAssertions() != null) {
+if (getCommandline().getAssertions() != null) {
throw new BuildException(Only one assertion declaration is
allowed);
}
-commandline.setAssertions(asserts);
+getCommandline().setAssertions(asserts);
}
/**
@@ -557,7 +557,7 @@
* @since Ant 1.2
*/
public JUnitTask() throws Exception {
-commandline
+getCommandline()
.setClassname(org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner);
}
@@ -675,7 +675,7 @@
log(Permissions ignored when running in forked mode!,
Project.MSG_WARN);
}
-CommandlineJava cmd = (CommandlineJava) commandline.clone();
+CommandlineJava cmd = (CommandlineJava) getCommandline().clone();
cmd.setClassname(org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner);
cmd.createArgument().setValue(test.getName());
@@ -903,13 +903,13 @@
+ the same VM., Project.MSG_WARN);
}
-if (commandline.getBootclasspath() != null) {
+if (getCommandline().getBootclasspath() != null) {
log(bootclasspath is ignored if running in the same VM.,
Project.MSG_WARN);
}
invoking targets with subant
does subant run/defines/whatever the top level properties of the invoked buildfile: I have a subant that call test0 on dir1/build.xml, that target depends on properties defined at the top level in that same buildfile, but when it is invoked with subant it fails because the top level properties where not defined. Is that an expected behaviour or a bug? If that is how you designed it is very problematic since I cannot know which properties I defined at each buildfile level to define it in the invoker one. MAriano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: invoking targets with subant
forget it, my fault, I wrote a task that invokes junittask, and forgot to add the propertyset. :) MAriano Mariano Benitez wrote: does subant run/defines/whatever the top level properties of the invoked buildfile: I have a subant that call test0 on dir1/build.xml, that target depends on properties defined at the top level in that same buildfile, but when it is invoked with subant it fails because the top level properties where not defined. Is that an expected behaviour or a bug? If that is how you designed it is very problematic since I cannot know which properties I defined at each buildfile level to define it in the invoker one. 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: DO NOT REPLY [Bug 27007] - subant task fails even if failonerror=false
+1, it makes things very much clear [EMAIL PROTECTED] wrote: DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27007. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27007 subant task fails even if failonerror=false --- Additional Comments From [EMAIL PROTECTED] 2004-02-17 17:21 --- I really think that we are solving here the wrong problem. IMHO, the bug here is not with subant, which as a task to execute targets should decide what to do based on BuildException. To me the problem here is that the core code that executes tasks ANY tasks, should catch any unhandle exception, e, and throw a corresponding BuildException(e) in its place. The point is that the invariant of the execution engine should be either to finish succesfully, or to throw a BuildException, anything else is a bug in CORE. - 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: delete task for antlib jars
I meant an option to delete, not altering the default behaviour, If you are sure you are using that file, delete it on exit explicitly. MAriano Stefan Bodewig wrote: On Fri, 13 Feb 2004, Mariano Benitez [EMAIL PROTECTED] wrote: that is why it makes more sense to me to define it as deleteOnExit, But what do we display to the user here? Failed to delete but we will try again after Ant has finished - please check whether the file is still there after that, if so, the build has failed. Unless you set quiet to true, failing to delete a file is supposed to break the build. I don't see how we can predict that the failure is non-critical, whether deleteOnExit will work or not. Stefan - 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: delete task for antlib jars
are you ok that I send you the patch? shall I create a bug in bugzilla for this? MAriano Stefan Bodewig wrote: On Mon, 16 Feb 2004, Mariano Benitez [EMAIL PROTECTED] wrote: I meant an option to delete, not altering the default behaviour, If you are sure you are using that file, delete it on exit explicitly. Works for me. Stefan - 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: delete task for antlib jars
have to look at the java documentation and give it a try, if you want I can try it with different scenarios, adding testCases would be too much for me, I have enough with the ones I need for my own product :) MAriano Peter Reilly wrote: Mariano Benitez wrote: are you ok that I send you the patch? shall I create a bug in bugzilla for this? MAriano Stefan Bodewig wrote: On Mon, 16 Feb 2004, Mariano Benitez [EMAIL PROTECTED] wrote: I meant an option to delete, not altering the default behaviour, If you are sure you are using that file, delete it on exit explicitly. Will this work recursivly? I.e. when deleteing a directory 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]
delete task for antlib jars
Hi! I am using antlibs, and I face the normal problem in windows of not being able of deleting the file while it is used. I know this discussion must have probably taken place, I could not just find it :( Has there been any attempt to use File.deleteOnExit() as an option for the task? or another task? MAriano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ant -projecthelp
I'm sorry, forgot it only shows the ones with description :) MAriano [EMAIL PROTECTED] wrote: Yes and it does. An imported buildfile is part of your buildfile. So why not showing? Jan -Original Message- From: Mariano Benitez [mailto:[EMAIL PROTECTED] Sent: Friday, February 13, 2004 12:12 AM To: Ant Developers List Subject: ant -projecthelp should it include the targets of imported builds? 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: delete task for antlib jars
that is why it makes more sense to me to define it as deleteOnExit, and not mess with trying to unload an antlib when I don't want it anymore. MAriano Dominique Devienne wrote: From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED] Why does the antlib file or JAR would stay open beyond loading the classes and reading the antlib.xml? Maybe what is needed here, is a way to tell ALL AntClassLoaders to please close their open files (JARS) and reopen if needed later. After all, keeping the JARs open is just an optimization. Well, after reading the antlib.xml, sure you could close the JAR, but once a URLClassLoader from the JDK starts using classes from the JAR (and most likely even before that), that JAR will stay open so it's not swapped under the JVM. I know for sure the Linux JVM memory-maps those JARs in the process address space, and it's very possible the Windows VM does something similar (thus the lock on the JAR file). I'm not sure Ant wants to go into the business of writing some custom ClassLoader that would not exhibit this 'standard' behavior of SUN's JDKs... --DD - 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: import task and the file attribute
that is ok, it is just that I normally have the same basedir for all
builds to always do the same kind of file usages,
(${basedir}/src/${module}).
It was just a question, it is ok, and I've read the note, but I wanted
the reason, that's all.
MAriano
Stefan Bodewig wrote:
On Wed, 11 Feb 2004, Mariano Benitez [EMAIL PROTECTED] wrote:
Why the file attribute of the import task is not considering files
relative to the basedir?
This is because you may use import in a file that itself gets
imported and then basedir would be that of the outer-most project
and not the one of the file you are looking at.
See this note from the manual
,
| Important: We have not finalized how relative file references will be
| resolved in deep/complex build hierarchies -such as what happens when
| an imported file imports another file. Use absolute references for
| enhanced build file stability, especially in the imported files.
`
which is no longer completely true since we are bound by backwards
compatibility after we've released 1.6.
use import file=${ant.file.pepe}/../include.xml/
instead of
project name=pepe basedir=..
import file=include.xml/
Stefan
-
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]
are antlib taskdefs case sensitive?
I defined in my antlib.xml taskdef=directorySchema and in the build I used fuego:directoryschema it failed saying it did not find task directoryschema, while if I put the correct case, it works, that is ok? MAriano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ant -projecthelp
should it include the targets of imported builds? MAriano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: can I change junit runner main class
This sounds simple to do inside the task, simply change
private CommandlineJava commandline = new CommandlineJava();
to
private CommandlineJava commandline = newCommandlineJava();
with
protected CommandlineJava newCommandlineJava() {
return new CommandlineJava();
}
basically since you are defining the commandLine className in the
contructor, it would not be much different to defining the commandLine
in the contructor
like
public JUnitTask() throws Exception {
createCommandlineJava();
commandline
.setClassname(org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner);
}
ultimately you could replace direct usages of the commandline variable
by an accessor, so I just need to override the accessor. Whatever you
decide, any of these options solve my problem.
I could upload a patch to bugzilla if you need to, but the change is
simple enough.
While we are at it, we may as well review the JUnitTask to see whether
we should change some other things, now that we'd consider subclassing
the task something we expect to happen.
I must make clear (I think I have already done so) that the usage we
need of JUnit is quite unique (bah, I guess), since we need to launch
java with a minimal classpath and inside our main class create a
classloader where the real main class gets executed.
As you can imagine this applies to forked tests only.
My experience tells me that for forked tests, you get a lot of control
if you can extends CommandlineJava to build the command you require,
that way you can adapt the attributes of the task to whatever you need
to execute.
I guess that by having executeAsForked and executeInVM as private do
not let much space to extension, but I think they do not have many
things that are exendable, may be by splitting some part of
execute(JUnitTest test) to separate the setting of the dirs (first 2
ifs) from the execution, and also split the last part where you decide
if to fail or not based on the result, leaving just this piece for
extension:
// execute the test and get the return code
int exitValue = JUnitTestRunner.ERRORS;
boolean wasKilled = false;
if (!test.getFork()) {
exitValue = executeInVM(test);
} else {
ExecuteWatchdog watchdog = createWatchdog();
exitValue = executeAsForked(test, watchdog);
// null watchdog means no timeout, you'd better not check
with null
if (watchdog != null) {
wasKilled = watchdog.killedProcess();
}
}
this would help to extend the way you execute the tests.
This is the analysis I can make, please consider it not thorough cause I
cannot dedicate a lot of time to this (I'm just trying to migrate the
version of ant in my company!)
Cheers,
MAriano
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: can I change junit runner main class
I am facing an issue extending CommandlineJava, there are some methods and attributes that are private, they are: getActualVMCommand() sysproperties haveBootClasspath haveClasspath bootclasspath javacommand vmcommand I will create accessor for the attributes and make the private methods protected, if you are ok with it. MAriano Stefan Bodewig wrote: On Wed, 11 Feb 2004, Mariano Benitez [EMAIL PROTECTED] wrote: ultimately you could replace direct usages of the commandline variable by an accessor, so I just need to override the accessor. Sounds like the cleanest solution. I could upload a patch to bugzilla if you need to, but the change is simple enough. It might save me a few minutes, maybe not. Do as you want but don't blame me if I forget about it 8-) Stefan - 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]
patch for JUnitTask extension
This is the patch for JUnitTask and CommandlineJava to make them extensible.
The main change in CommandlineJava is that some methods were made
protected and in JUnitTask replace the direct usage of commandline for
an accessor, this way they can both be extended to provide custom
commandline implementations.
The diff was against the 1.6.0 WC, I guess the versions are just the
same, If you want me to diff them against the CVS version shout me. :)
MAriano
--- src/main/org/apache/tools/ant/types/CommandlineJava.java2004-02-11
15:27:15.0 -0300
+++
/opt/java/ant/apache-ant-1.6.0/src/main/org/apache/tools/ant/types/CommandlineJava.java
2004-02-11 15:08:41.0 -0300
@@ -383,6 +383,7 @@
final ListIterator listIterator = commands.listIterator();
//fill it
addCommandsToList(listIterator);
+
//convert to an array
return (String[]) commands.toArray(new String[0]);
}
@@ -395,6 +396,7 @@
private void addCommandsToList(final ListIterator listIterator) {
//create the command to run Java, including user specified options
getActualVMCommand().addCommandToList(listIterator);
+
// properties are part of the vm options...
sysProperties.addDefinitionsToList(listIterator);
//boot classpath
@@ -469,7 +471,7 @@
* Get the VM command parameters, including memory settings
* @return
*/
-private Commandline getActualVMCommand() {
+protected Commandline getActualVMCommand() {
Commandline actualVMCommand = (Commandline) vmCommand.clone();
if (maxMemory != null) {
if (vmVersion.startsWith(1.1)) {
@@ -604,7 +606,7 @@
*
* @since Ant 1.6
*/
-private boolean haveClasspath() {
+protected boolean haveClasspath() {
Path fullClasspath = classpath != null
? classpath.concatSystemClasspath(ignore) : null;
return fullClasspath != null
@@ -621,7 +623,7 @@
*
* @since Ant 1.6
*/
-private boolean haveBootclasspath(boolean log) {
+protected boolean haveBootclasspath(boolean log) {
if (bootclasspath != null
bootclasspath.toString().trim().length() 0) {
--- src/main/org/apache/tools/ant/taskdefs/optional/junit/JUnitTask.java
2004-02-11 15:27:15.0 -0300
+++
/opt/java/ant/apache-ant-1.6.0/src/main/org/apache/tools/ant/taskdefs/optional/junit/JUnitTask.java
2004-02-11 14:43:03.0 -0300
@@ -160,7 +160,7 @@
*/
public class JUnitTask extends Task {
-private CommandlineJava commandline = new CommandlineJava();
+private CommandlineJava commandline;
private Vector tests = new Vector();
private Vector batchTests = new Vector();
private Vector formatters = new Vector();
@@ -375,7 +375,7 @@
* @since Ant 1.2
*/
public void setMaxmemory(String max) {
-commandline.setMaxmemory(max);
+getCommandline().setMaxmemory(max);
}
/**
@@ -389,7 +389,7 @@
* @since Ant 1.2
*/
public void setJvm(String value) {
-commandline.setVm(value);
+getCommandline().setVm(value);
}
/**
@@ -402,7 +402,7 @@
* @since Ant 1.2
*/
public Commandline.Argument createJvmarg() {
-return commandline.createVmArgument();
+return getCommandline().createVmArgument();
}
/**
@@ -427,7 +427,7 @@
*/
public void addSysproperty(Environment.Variable sysp) {
-commandline.addSysproperty(sysp);
+getCommandline().addSysproperty(sysp);
}
/**
@@ -442,7 +442,7 @@
// see bugzilla report 21684
String testString = sysp.getContent();
getProject().log(sysproperty added : + testString,
Project.MSG_DEBUG);
-commandline.addSysproperty(sysp);
+getCommandline().addSysproperty(sysp);
}
/**
@@ -456,7 +456,7 @@
* @since Ant 1.6
*/
public void addSyspropertyset(PropertySet sysp) {
-commandline.addSyspropertyset(sysp);
+getCommandline().addSyspropertyset(sysp);
}
/**
@@ -466,7 +466,7 @@
* @since Ant 1.2
*/
public Path createClasspath() {
-return commandline.createClasspath(getProject()).createPath();
+return getCommandline().createClasspath(getProject()).createPath();
}
/**
@@ -475,7 +475,7 @@
* @since Ant 1.6
*/
public Path createBootclasspath() {
-return commandline.createBootclasspath(getProject()).createPath();
+return getCommandline().createBootclasspath(getProject()).createPath();
}
/**
@@ -569,10 +569,10 @@
* @param asserts assertion set
*/
public void addAssertions(Assertions asserts) {
-if (commandline.getAssertions() != null) {
+if (getCommandline().getAssertions() != null) {
throw new BuildException(Only one assertion declaration is
allowed);
}
-
import task and the file attribute
Why the file attribute of the import task is not considering files relative to the basedir? I had project name=pepe basedir=.. import file=include.xml/ this should include the file in .., not in the current directory, as it is in all other tasks. Any reason why it is that way? MAriano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: can I change junit runner main class
another option would be to let people extend CommandLineJava and overwrite the method getCommandLine() to change the arguments, so I can customize my command line while you maintain the contract of JUnitRunner. I think I will move in this direction since not only I need to change the main class, but also make the classpath an argument of the main class and not a java argument, for example: java -classpath whatever.jar JUnitTestRunner blah to java -jar /path/myJar.jar -classpath whatever.jar JUnitTestRunner blah MAriano Mariano Benitez wrote: I assume that your class understands all the command line arguments Ant's testrunner uses and passes them along. How would your class deal with new arguments we add? My class is just a bootstrap that do some classloading stuff regarding my application and then invokes the main class (JUnitRunner) with the parameteres it received in the first place. The main problem with opening up access to the test runner class is just that. As soon as we do it, we run the risk of breaking other people's builds when we change the protocol between the task and the test runner. There is no danger now, as we always know the main class that gets invoked. I agree 100% with you on this, it is just that I need to take control before the main class is executed, actually I build a classloader where the main class (Runner) is loaded and executed. I know this is a quite unique situation but I just wanted to expose my case to see if it is so unique that is ok that I handle it myself only. I have patched JUnitTask to specify another main class that I built that ultimately call JUnitRunner as usual. 1) leave junit forked=true jvm=launcher and have launcher script change the command line Ugly but portable accross Ant versions. I have scripts since they always have problems with different OS, etc, that was the first option, but I end up having 3 bash processes wrapping java. 2) patch junit to allow me to put a boot class 3) extend junit (the problem is that JUnitTask.executeAsForked and commandline are private, so I should patch the task anyway) what you can do to support extension of JUnit is to leave a hook to alter the commandline, this way I can do whatever I need directly before invoking the runner. You could just leave a method protected so I can extend it and alter the command line in a custom task. Thanks a lot for the attention, 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]
can I change junit runner main class
Hi! I've been around having this situation and I need advice on how to make this work in 1.6. I have had to custom patch a couple of classes in 1.5.x to make it work, but now I'd like to see if I can do it without patching. We use JUnit tasks extensively in our instalation, and we have to boot the tests classes with a specific launcher class (much like it is done now in Ant 1.6). This class receives the main class, initializes some classloaders, and launches the other main application. The problem is that I cannot simulate this using JUnit with fork, because I cannot change the main class and use mine instead. I have made a bash script thatsplits Java options from class arguments and puts my boot class in the middle, but there are always problems with shell scripts. My request is for advice on what option to take, I see at least a couple of them: 1) leave junit forked=true jvm=launcher and have launcher script change the command line 2) patch junit to allow me to put a boot class 3) extend junit (the problem is that JUnitTask.executeAsForked and commandline are private, so I should patch the task anyway) Thanks for your attention. MAriano BEnitez Fuego Labs. Buenos Aires - Argentina www.fuego.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 24697] New: - The JUnit plugin forks once for each test suite
is this an optional flag? we are using consiusly this feature, and we need that each suite forks. [EMAIL PROTECTED] wrote: DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24697. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24697 The JUnit plugin forks once for each test suite Summary: The JUnit plugin forks once for each test suite Product: Ant Version: 1.5.3 Platform: Other OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Optional Tasks AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I have patched the ant's 1.5.3 JUnit task to fork only once and then run all test suites. When the number of test suites is quite large this makes a huge difference. - 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]
Problem with custom build listener
I have the following problem: I have a custom task defined via a taskdef task with a custom classpath. Inside the execute() method of that task I create a custom build events listener. The problem is that in the method taskFinished of the listener, the ant class loader attempts to load a class, and since it is already in a logging mode, it fails with this error: ile:/w/r4-5/local/tests/conf/utils.xml:120: Listener attempted to access System.out - infinite loop terminated AAA:Class org.apache.tools.ant.Main loaded from parent loader the AAA: message is that I changed the project.java to show in the exception the message it was trying to log. If you think this is a bug, then I will report it and follow the normal procedures. Thanks, MAriano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: adding success failure to subant
I completely desire that, for long nested builds for regression testing makes life really easy to just send a build to run, and if fails, no problem, keep going to the next build. MAriano Steve Loughran wrote: I think I posted this last week, but it got lost 1. What do people think about adding the ability to set properties if a subant or ant call failed/succeeded. This lets me do complex things in cruise control. 2. How best to do it? Here is one example implementation subant antfile=driver/ target=build succeeded=driver.built failoneerror=false/ target name=test-driver depends=driverif=driver.built subant antfile=driver/ target=test succeeded=driver.tested failoneerror=false/ /target target name=app depends=driver if=driver.built subant antfile=app/ succeeded=app.built failoneerror=false/ /target target name=test-app depends=app if=app.built subant antfile=app/ succeeded=app.built failoneerror=false/ /target - 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: adding success failure to subant
Mariano Benitez wrote: it is VERY java oriented to use try/catch to implement this, and I would rather use the way it is implemented in the rest of the ant tasks, like javadoc, junit, etc. it is very simple also to change the value of haltonerror to true/false, instead of ignoring a catch. Although I evaluated the try/catch solution, I still want this feature to be included. Anyway, is there any philosophical objection why this should not be included, does it go against some rule? just curious... MAriano Jose Alberto Fernandez wrote: This can be achieved with the trycatch/ task from antcontrib. Take a look at it. I think it is becoming time for some of this very useful and generic tasks to make its way into CORE. What do people think? What antcontrib people think? Jose Alberto -Original Message- From: Mariano Benitez [mailto:[EMAIL PROTECTED] Sent: 11 June 2003 00:35 To: Ant Developers List Subject: Re: adding success failure to subant I completely desire that, for long nested builds for regression testing makes life really easy to just send a build to run, and if fails, no problem, keep going to the next build. MAriano Steve Loughran wrote: I think I posted this last week, but it got lost 1. What do people think about adding the ability to set properties if a subant or ant call failed/succeeded. This lets me do complex things in cruise control. 2. How best to do it? Here is one example implementation subant antfile=driver/ target=build succeeded=driver.built failoneerror=false/ target name=test-driver depends=driverif=driver.built subant antfile=driver/ target=test succeeded=driver.tested failoneerror=false/ /target target name=app depends=driver if=driver.built subant antfile=app/ succeeded=app.built failoneerror=false/ /target target name=test-app depends=app if=app.built subant antfile=app/ succeeded=app.built failoneerror=false/ /target - 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]
usage question - junit
Hi everybody!
The test environment of the tool we develop consist of 20+ build
files (one for each module) and growing fast. All of the with 1 or 2 or
more junit invocations, and all of them must follow some conventions:
1) formatter
2) haltonerror
3) maxmemory
4) timeouts
5) jvm (we hacked junit because the JUnitRunner must run inside an
app wrapper of our own and changing the executable was not enough)
6) fork
7) FYI the inheritAntProperties=true is another hack to pass the
ant environment to the junit runner (I know it is done in 1.6, but right
now we are in 1.5.3)
this is a sample invocation:
junit printsummary=yes fork=yes jvm=fuego
maxmemory=256m dir=${build.dir} showoutput=on
inheritAntProperties=true
haltonfailure=false failureproperty=test-basic.failure
haltonerror=false errorproperty=test-basic.error
classpath refid=junit.class.path/
formatter classname=${junit.formatter.classname}
extension=.xml/
!-- tests that will be run --
test name=fuego.directory.test.SchemaCreationTest
todir=${run.dir} /
/junit
Now, I just want to gather opinions regarding the following: would it be
better for this case to be able to specify most of these things a
properties instead of having to type a really long junit tast each time?
I mean, you know copy/paste programming is error prone and is really
difficult to maintain, let's say I want to raise maxmemory to 512m, I
should have to change ALL the junit invocations (ok, I've got global
search/replace, but it's also error prone)
It would be really easy to read something like this:
junit dir=${build.dir}
classpath refid=junit.class.path/
test name=fuego.directory.test.SchemaCreationTest
todir=${run.dir} /
/junit
and have the rest of static definitions taken from properties I define
somewhere else globally. I do not mean to remove the attributes, I just
would like a way to overwrite default values in case they are not
defined in the task.
Well, I just want opinions, and if there are good practices the ant
group is promoting in either direction I would really like to hear them.
Thanks for your time,
MAriano
Fuego Labs.
www.fuego.com
how to set a property with a regexp
I have the following problem:
I have a fileset that I want to convert to the manifest classpath. so
this is what I do:
1) pathconvert
property name=lib.dir.sep
value=${basedir}${file.separator}lib${file.separator}/
pathconvert refid=project.class.path
property=manifest.class.path pathsep=
map from=${lib.dir.sep} to=/
/pathconvert
echo message=${manifest.class.path}/
2) the problem comes when trying to make this work fine on both win with
cygnus and unix.
the paths in the fileset comes with the path separator of the target
os, so I change my map so that reflect that.
the problem is that if the fileset contains another subdirectory
like lib/tomcat/catalina.jar, the result of the mapping is different on
each platform,
in unix is tomcat/catalina.jar and in windows is
tomcat\catalina.jar
3) now, how can I set another property but replacing ${file.separator}
with /?
any suggestions are appreciated!
MAriano
invoke another target/buildfile and continue even if the invoked target failed
are there any plans to implement this. it would be really cool to have this feature, we can use it for the long test runs when you are stacked when some module build fails, the entire build fails. Of course we have workarounded it, but it would greatly simplify long test builds. All I'm asking is a haltonerror and errorproperty attributes for the ant and antcall targets. Regards, Mariano
