You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ant.apache.org by "Adam R. B. Jack" <aj...@trysybase.com> on 2003/12/02 19:19:25 UTC
Forking JUnit (was Re: Ant not passing System values to JUnit task)
Sorry, but this caught my eye & reminded me of this issue that exists on
Gump's that run (typically on Linux) without an X server available. I
believe it is a known JDK issue:
[junit] Testcase:
testBitmapJPEG(org.krysalis.barcode.cli.CommandLineTestCase): Caused an
ERROR
[junit] Can't connect to X11 window server using ':0.0' as the value of
the DISPLAY variable.
[junit] java.lang.InternalError: Can't connect to X11 window server
using ':0.0' as the value of the DISPLAY variable.
[junit] at sun.awt.X11GraphicsEnvironment.initDisplay(Native Method)
[junit] at
sun.awt.X11GraphicsEnvironment.<clinit>(X11GraphicsEnvironment.java:134)
[junit] at java.lang.Class.forName0(Native Method)
[junit] at java.lang.Class.forName(Class.java:141)
[junit] at
java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(GraphicsEnvironment
.java:62)
[junit]
So, I attempt to work around it by passing -Djava.awt.headless=true:
java -Djava.awt.headless=true
-Xbootclasspath/p:/data/gump/xml-xerces2/java/build/xercesImpl.jar:/
data/gump/xml-xerces2/java/build/xmlParserAPIs.jar:/data/gump/xml-xalan/java
/build/xalan-unbundled.jar:/data/gump/xml-commons/java/external/build/xml-ap
is.jar
org.apache.tools.ant.Main -debug -Dbuild.sysclasspath=only -DDATE_STAMP=2003
1202
gump However when the called ant script forks (I assume) a junit
run, the same error comes
back.http://lsd.student.utwente.nl/gump/krysalis-barcode/work/build_krysalis
-barcode_krysalis-barcode.html
Does Ant have any control over the way the forked JVM is created? Is there
any way to influence this without expecting the user to write script changes
& rely upon 'environment portal' scripts?
Thanks in advance.
regards,
Adam
----- Original Message -----
From: "Peter Reilly" <pe...@corvil.com>
To: "Ant Users List" <us...@ant.apache.org>
Sent: Tuesday, December 02, 2003 10:24 AM
Subject: Re: Ant not passing System values to JUnit task
> Your build script did not come thu.
>
> However
> setting -Dx=y on the ant.bat or ant shell script does *not* set a
> system property.
> It sets an ant property.
>
> To set the system property in the for the <junit> task, you need to
> use the nested element <sysproperty>.
>
> <junit>
> <sysproperty key="active.level" value="${active.level}"/>
> <test name="my.test.TestCase"/>
> </junit>
>
> Peter
>
> Dubois, Jeff wrote:
>
> >When doing an Ant build of my project (see attached myBuild.xml script)
It
> >appears that ant is not passing System variables/values when executing
the
> >JUnit task. I am on Windows using Ant 1.5.3.
> >
> >For my JUnit test cases to succeed I need a VM/System variable called
> >"active.level" set to "dev".. When executing Ant (via a batch file) I
pass
> >in the value of "active.level" via a "-Dactive.level=dev" argument on the
> >command line.
> >In my ant script I echo out the value of "active.level" and indeed it is
set
> >to "dev" (see runUnitTest target in attached script).
> >
> >However, when I run the Unit test, this "active.level" variable is no
longer
> >set. I verified this by printing out the value of "active.level" in one
of
> >the Java test cases that get run.
> > The code I use is:
> > System.out.println( "active.level is: " +
> >System.getProperty("active.level"));
> >The corresponding output when run through ant is:
> > [junit] active.level is: null
> >By default are not all System variables supposed to be passed to the
JUnit
> >task?
> >
> >Thanks!
> > Jeff
> >
> >
> > <<myBuild.xml>>
> >
> >
> >
> >------------------------------------------------------------------------
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
> >For additional commands, e-mail: user-help@ant.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
> For additional commands, e-mail: user-help@ant.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org
Re: Forking JUnit (was Re: Ant not passing System values to JUnit task)
Posted by Stefan Bodewig <bo...@apache.org>.
On Wed, 3 Dec 2003, Adam R. B. Jack <aj...@trysybase.com> wrote:
> if one starts a JVM one way with certain settings ought not that be
> 'the default VM' that they wish for their environment, and ought not
> 'forked' JVMs match it?
In theory I agree - just that it's pretty hard to do (in particular to
do right). CLASSPATH, Ant 1.6's -lib switch that means we are running
a more complex classloader setup, system properties, bootclasspath
settings, ...
> Heck, even including which JVM implementation.
I think we already do that, i.e. the JVM implementation running Ant is
the default for a new VM, but you can choose a different onw with the
vm attribute.
> I guess it is debatable, but (from where I stand right now) I
> believe that the argument for this default behaviour, is
> strong.
"backwards compatibility". We can only enable it optionally IMHO.
In Ant 1.6 using <syspropertyset> in <junit> or <java> will give you
the same set of system properties in the forked VM, so we have that.
> It isn't just a Gump thing, is it?
Gump wants to enable the copying of system properties without having
to change the build file, that's why I suggested a magic property on
top of <syspropertyset>.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org
Re: Forking JUnit (was Re: Ant not passing System values to JUnit task)
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
> > Is there any way to influence this without expecting the user to
> > write script changes & rely upon 'environment portal' scripts?
>
> No. The syspropertyset in 1.6 (see my previous mail in the original
> thread) would work - but the user still has to add it manually.
>
> We might be able to introduce some magic property for Gump and
> friends, but don't hold your breath. I live in the outer west of
> Germany and prefer red whine over beer, in case you want to bribe me
> ;-)
I'm not discounting the bribe ;-), but a thought occur to me...
Isn't this a bug/weakness in Ant due to a weakness in design of the JVM?
Meaning if one starts a JVM one way with certain settings ought not that be
'the default VM' that they wish for their environment, and ought not
'forked' JVMs match it? (I know it isn't that simple) Heck, even including
which JVM implementation. I guess it is debatable, but (from where I stand
right now) I believe that the argument for this default behaviour, is
strong. Folks could override the behaviour when they chose.
If the JVM doesn't support it, it is hard to blame ant for not, I know. But
I wonder, ought it be explored? It isn't just a Gump thing, is it?
regards
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org
Re: Forking JUnit (was Re: Ant not passing System values to JUnit task)
Posted by Stefan Bodewig <bo...@apache.org>.
On Tue, 2 Dec 2003, Adam R. B. Jack <aj...@trysybase.com> wrote:
> Sorry, but this caught my eye & reminded me of this issue that
> exists on Gump's that run (typically on Linux) without an X server
> available. I believe it is a known JDK issue:
Somewhat, yes.
AWT in JDK < 1.4 doesn't work in headless (i.e. without an X server
running) on Unix like systems at all. The traditional solution is to
run Xvfb.
JDK 1.4 introduced java.awt.headless in Sun's VMs (what you are using
in your invocation). I'd expect it to work in IBM's as well, but I'm
not sure - even less so for Apple's VM that doesn't really work unless
the user running the Java VM is logged in at the console at all.
> Does Ant have any control over the way the forked JVM is created?
Yes.
> Is there any way to influence this without expecting the user to
> write script changes & rely upon 'environment portal' scripts?
No. The syspropertyset in 1.6 (see my previous mail in the original
thread) would work - but the user still has to add it manually.
We might be able to introduce some magic property for Gump and
friends, but don't hold your breath. I live in the outer west of
Germany and prefer red whine over beer, in case you want to bribe me
;-)
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org