Not so sure surefire is even that clever. I bet it doesn't set system properties at all for the new process it spawns (the default is "once").
Kalle On Wed, Nov 5, 2008 at 2:39 PM, Craig L Russell <[EMAIL PROTECTED]>wrote: > So, I think I know what the problem is. > > If you use the system properties approach in maven: > <plugin> > <groupId>org.apache.maven.plugins</groupId> > <artifactId>maven-surefire-plugin</artifactId> > <configuration> > <systemProperties> > <property> > <name>java.library.path</name> > > <value>/Users/clr/ndb/clusterj/trunk/clusterj/target/classes/.libs</value> > </property> > </systemProperties> > </configuration> > </plugin> > > the surefire plugin starts the vm and then modifies the system properties > before passing control to the junit test classes. This is too late for the > vm, which needs to have the java.library.path set up at the time the vm is > initialized. Hence the error message java.lang.UnsatisfiedLinkError: no ndbj > in java.library.path. > > I'm also guessing that the ant <sysproperty> tag works differently, by > converting the contents to the equivalent -D option while starting the vm. > Hence the difference in behavior. > > Problem solved. > > Thanks everyone, > > Craig > > This is how we set the java.library.path for surefire, works fine for us: >> <plugin> >> <groupId>org.apache.maven.plugins</groupId> >> <artifactId>maven-surefire-plugin</artifactId> >> <configuration> >> <forkMode>once</forkMode> >> <workingDirectory>target</workingDirectory> >> <argLine>-Djava.library.path=lib</argLine> >> Kalle >> >> Craig L Russell > Architect, Sun Java Enterprise System http://db.apache.org/jdo > 408 276-5638 mailto:[EMAIL PROTECTED] > P.S. A good JDO? O, Gasp! > >
