Thank you for taking an interest.
Our tests have always been forked and I do want to avoid hacks, which is why
I am coming to this forum.
This is what I have so far ( lib.package contains all shared objects ):
<property name="junit.lib.path" value="${java.library.path}${path.separator
}${lib.package}" />
<junit failureproperty="junit.failed"
fork="true"
includeAntRuntime="true"
dir="${basedir}"
showoutput="true">
<classpath>
<path refid="test.classpath"/>
</classpath>
<!-- we now reset java.library.path to something specific to this
project -->
<sysproperty key="java.library.path" path="${junit.lib.path}"/>
<!--
However, it doesn't seem to work under Linux. Native libraries
needed
by Java are loaded correctly but other native libraries needed by
native libraries loaded by Java cannot be found
None of the following worked (aside from not being platform
independent)
<sysproperty key="LD_LIBRARY_PATH" path="${junit.lib.path}"/>
<env key="LD_LIBRARY_PATH" path="${junit.lib.path}" />
<env key="LD_LIBRARY_PATH" path="${env.LD_LIBRARY_PATH}${path.separator
}${lib.package}" />
<env key="LD_LIBRARY_PATH" path="${env.LD_LIBRARY_PATH}${path.separator
}${lib.package}" />
the following also works on Windows if you also remove the sysproperty
above, however this
is not platform independent and should be avoided
<env key="PATH" path="${junit.lib.path}" />
-->
<formatter type="xml"/>
<formatter type="plain"/>
<batchtest todir="${testresults.dir}">
<fileset dir="${src.test}">
<include name="**/*Test*.java"/>
</fileset>
</batchtest>
</junit>
On 14/06/06, Dominique Devienne <[EMAIL PROTECTED]> wrote:
> Presumably you are running <junit> forked? I think you also need to make
> sure that your path and library search path includes the existing env
> variables.
Mostly likely not. The only "right" solution is to <junit fork="true">.
> > Am I going to be forced to look into a nominated directory and preload
> > anything that matches *.so before invoking a non-forked JVM for the
unit
> > tests?
That would be a hack, and even then you'd have to load them in the
proper dependency order. I had a too-clever colleague use such an
approach to work around a similar issue in WebStart, but it's very
brittle, and very hacky.
It's not a matter of using LoadLibraryEx or not, since *nix in general
does not allow you to alter the library loading path of an existing
process.
So just fork your tests ;-) --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
