Seeing log output when running tests with AntUnit
Hello, I've been trying to use AntUnit and cannot see a way to view the typical Ant output of the Ant targets being tested. The only output is that which AntUnit generates, describing the tests executed, etc. If a test fails it is important to view the log of the steps that happened. Can anyone suggest how AntUnit is expected to be used to access this logging information? Thanks paul
RE: Seeing log output when running tests with AntUnit
>It's being saved to a log where you can make assertions about >output text, using assertion, which >itself uses the the condition How would I print the content of that log? >Maybe we could tweak antunit also print the buffer on an >assertion failure, but generally I just run the target by hand >when I want to see the output. My issue is that from the test target I get this output: [antunit] Target: test-foo caused an ERROR [antunit] at line 9, column 15 [antunit] Message: condition satisfied [antunit] took 0.031 sec The test has a complex condition in it, it would be useful to get more output on what the condition evaluation is. paul >-Original Message- >From: ext Steve Loughran [mailto:[EMAIL PROTECTED] >Sent: Monday, June 04, 2007 4:44 AM >To: Ant Developers List >Subject: Re: Seeing log output when running tests with AntUnit > >[EMAIL PROTECTED] wrote: >> Hello, >> >> I've been trying to use AntUnit and cannot see a way to view the >> typical Ant output of the Ant targets being tested. The only >output is >> that which AntUnit generates, describing the tests executed, >etc. If a >> test fails it is important to view the log of the steps that >happened. >> >> Can anyone suggest how AntUnit is expected to be used to access this >> logging information? >> >> Thanks >> >> paul >> > >It's being saved to a log where you can make assertions about >output text, using assertion, which >itself uses the the condition > >Maybe we could tweak antunit also print the buffer on an >assertion failure, but generally I just run the target by hand >when I want to see the output. > > >-steve > >- >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]
Should ScriptRunner call terminate() on the BSFManager?
Hi, We've recently integrated Jepp (http://jepp.sourceforge.net/) into our use of Ant via the BSF engine. This is very useful because we use Python for scripting quite a lot and it allows Python code to be used in full while also allowing access to Java objects. This has resulted in a Java OOM error, which I suspect is due to this integration change. There is a comment in the Jepp usage instructions that close() must be called on the Jep objects. This is done inside the terminate() method of the BSFJepEngine, which is called by the BSFManager on all engines. However I cannot see anywhere where BSFManager.terminate() is called inside ScriptRunner or elsewhere inside Ant. Should terminate() be called by ScriptRunner(), perhaps in the finally section in the executeScript method? thanks paul
RE: Should ScriptRunner call terminate() on the BSFManager?
Do I need to do anything to follow up on this? How to ensure this fix gets into a future release? thanks paul >-Original Message- >From: ext Peter Reilly [mailto:[EMAIL PROTECTED] >Sent: Tuesday, March 25, 2008 3:52 PM >To: Ant Developers List >Subject: Re: Should ScriptRunner call terminate() on the BSFManager? > >On Tue, Mar 25, 2008 at 8:59 PM, Paul King <[EMAIL PROTECTED]> wrote: >> >> [EMAIL PROTECTED] wrote: >> > Hi, >> > >> > We've recently integrated Jepp >(http://jepp.sourceforge.net/) into >> our > use of Ant via the BSF engine. This is very useful because we >> use Python > for scripting quite a lot and it allows Python code to >> be used in full > while also allowing access to Java objects. >> > >> > This has resulted in a Java OOM error, which I suspect is due to >> this > integration change. There is a comment in the Jepp usage >> instructions > that close() must be called on the Jep objects. This >> is done inside the > terminate() method of the >BSFJepEngine, which is >> called by the > BSFManager on all engines. However I cannot see >> anywhere where > BSFManager.terminate() is called inside >ScriptRunner >> or elsewhere inside > Ant. Should terminate() be called by >> ScriptRunner(), perhaps in the > finally section in the >executeScript method? > >Just had a quick look, > we should call the terminate method - it is part of the life >cycle that > we missed. > >Looking at some of the languages: > beanshell does not use the terminate method > jruby does > rhino does not > groovy does not > jython does not > netrexx does not > jacl does not > >so it is not surprising that we missed this. > >The odd thing is that javax.scripting does not seem to have a >corresponding method and the jruby javax.script engine calls >the terminate for each invoke method. > > >> >> Others will be more familiar with the ScriptRunnerXXX >classes than me >> but in WebTest, its Script task has a keep flag. This might be a >> useful concept to have here. Basically the flag allows you to >> distinguish between scenarios where you want the binding retained >> across tasks (and hence in the scenario above I suspect you don't >> want terminate() called) and the case where you want a fresh >> manager/runner for each run. Again, I haven't done a complete >> analysis of what gets called where in Ant at the moment. >Just noting >> an important use case for WebTest which I know is in use in >the field in many places. > >It should be possible to modify the scripting code in such a >way that will not affect people that use the code. > > >Peter >> >> Paul. >> P.S. For those that aren't aware, WebTest is an Ant extension for >> testing web applications. >> >> >- >> 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]
Performance of fileset related operations with a large number of files
Hello, I have been trialling Ant as a driver for a large scale build execution. The preparation before the build involves copying and unzipping >100,000 files spread across >20,000 directories. When using Ant's built in copy task with filesets selecting large parts of these files, a long time is spent building the list of files to copy, which also takes a lot of memory. This is my understanding of how Ant works with filesets after browsing the source. Is there any way to avoid this high memory usage and time spent building a list? Has there ever been any consideration of refactoring the way Ant processes filesets and similar constructs such that each selected file is processed once read in an iterative fashion, rather than building a complete list and then processing? thanks paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
# character causes problem parsing -lib paths
Hello, I have found that if I specify a -lib option with a path that contains a hash "#" character, it cannot find the libraries. Without the # character in the path they can be picked up fine. This is not easily avoided in our environment, as we use Synergy for SCM, which defaults to using # in the path when checking out projects. This can be changed, but that is not desirable. Is this a known bug? Does anyone know of any workarounds? Many thanks paul
RE: # character causes problem parsing -lib paths
Hi Peter, >I have made a change to ant SVN to fix this. So if I wanted to get a version of Ant with it fixed I could check it out from SVN? Is there any bug fix release schedule for Ant? I'm wondering because there has not been a new release for some time. cheers paul >-Original Message- >From: ext Peter Reilly [mailto:[EMAIL PROTECTED] >Sent: 19 April 2006 03:52 >To: Ant Developers List >Subject: Re: # character causes problem parsing -lib paths > >I have just checked. >This is a problem - the ant launcher code does some conversion >of file names to URLs. The '#' character is not converted The >only work-around (at the moment) is to use symbolic links. >I have made a change to ant SVN to fix this. > >Peter > >On 4/19/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: >> >> Hello, >> >> I have found that if I specify a -lib option with a path >that contains >> a hash "#" character, it cannot find the libraries. Without the # >> character in the path they can be picked up fine. >> >> This is not easily avoided in our environment, as we use Synergy for >> SCM, which defaults to using # in the path when checking out >projects. >> This can be changed, but that is not desirable. >> >> Is this a known bug? Does anyone know of any workarounds? >> >> Many thanks >> >> paul >> >> > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: # character causes problem parsing -lib paths
Hello, I have tested an SVN snapshot of Ant with the fix in for parsing # in the path. It works using Java 1.4.2 but not Java 1.3.1. My understanding is that 1.3 is intended to be supported for Ant 1.7 based on this page http://wiki.apache.org/ant/Ant17/Planning. Is it possible to test this functionality using 1.3? thanks paul >-Original Message- >From: ext Peter Reilly [mailto:[EMAIL PROTECTED] >Sent: Wednesday, April 19, 2006 3:52 AM >To: Ant Developers List >Subject: Re: # character causes problem parsing -lib paths > >I have just checked. >This is a problem - the ant launcher code does some conversion >of file names to URLs. The '#' character is not converted The >only work-around (at the moment) is to use symbolic links. >I have made a change to ant SVN to fix this. > >Peter > >On 4/19/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: >> >> Hello, >> >> I have found that if I specify a -lib option with a path >that contains >> a hash "#" character, it cannot find the libraries. Without the # >> character in the path they can be picked up fine. >> >> This is not easily avoided in our environment, as we use Synergy for >> SCM, which defaults to using # in the path when checking out >projects. >> This can be changed, but that is not desirable. >> >> Is this a known bug? Does anyone know of any workarounds? >> >> Many thanks >> >> paul >> >> > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
using multiple properties in the 'if' and 'unless' conditions
Hello, Has the possibility of adding multiple conditions to the target 'if' and 'unless' attributes ever been considered? Are there any reasons why this change would be a bad idea? cheers paul
conditional attributes for arg and env elements
Hello, Would it be possible to add if and unless attributes to the env and arg elements used in exec, in the same way that include and exclude elements have? This would make the use of exec more flexible. A problem that I currently have is that a script being called from Ant will check the environment variables. The idea is that it behaves in a similar way to Ant, in that the behaviour will change depending on whether a environment property is defined. But I cannot see how to do this with Ant as elements cannot be conditionally defined. If an element is added with a given name, that env variable will exist in the execution environment even if the value is an empty string. Any suggestions on alternative approaches are appreciated. This could be done with XSLT but I would rather not introduce that level of complexity. paul
