I've actually just found a limitation of the "happens to work" approach, which is that it stops (quite understandably) at the first space in the existing java.library.path value.
Which given MS's predilection for C:\Program Files\... is generally well before the end, and so causes problems for some of the guys on my team. Now obviously they can re-order things in their path and change the values to Progra~1 etc, but it would be good to have a "proper" solution to this. Can anyone suggest what we could pass via maven.junit.jvmargs to achieve what we need? thanks James -----Original Message----- From: Dion Gillard [mailto:[EMAIL PROTECTED] Sent: 15 July 2004 00:25 To: Maven Users List; [EMAIL PROTECTED] Subject: Re: RC4 to 1.0 problems Reading the test plugin, I can't see how the value tacked on the end would work. You might also try passing something into the JVM via maven.junit.jvmargs On Wed, 14 Jul 2004 23:39:15 +1000, J. Matthew Pryor <[EMAIL PROTECTED]> wrote: > I have a multiproject that uses the same syntax to fork junit using > JNI & DLLs i.e. > > # we need to make the DLL available on the PATH > # we need to tack a bogus path on to the end here > # as there seems to be a maven bug that mucks up the properties > otherwise > maven.junit.sysproperties=java.library.path=${maven.repo.local}/${pom.artifa > ctDirectory}/native${path.separator}${basedir}/bogus > > So I have no idea about why the documentation says otherwise but this > syntax above has been working for me since rc1 > > I migrated to 1.0 today and I can run : > > maven multiproject:goal -Dgoal=test > > So using the syntax above, multiproject:test still finds the JNI DLLs > in question > > The only noticeable differences seem to be > > 1. We place the DLLs into the local repository (with a postGoal) 2. > The ${path.separator}${basedir}/bogus at the end of the > java.library.path > > I have not tested recently if that bogus path still is needed, and I > never really investigated why it was needed, it just scratched my itch > at the time > > Hope that helps > Matthew > > > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, July 14, 2004 10:09 PM > > To: [EMAIL PROTECTED] > > Subject: RE: RC4 to 1.0 problems > > > > Yes, but the point is I need the value of the system property to be > > different to what is currently passed. > > > > So whilst it does seem to contradict the documentation the > > maven.junit.sysproperties=java.library.path=XXXX > > > > approach does actually work and set the path as required (using a > > simple no-inheritance project) > > > > James > > > > -----Original Message----- > > From: Carlos Sanchez [mailto:[EMAIL PROTECTED] > > Sent: 14 July 2004 12:43 > > To: 'Maven Users List' > > Subject: RE: RC4 to 1.0 problems > > > > > > Hi, > > > > Not sure but I think you don't need none of those two lines. System > > properties (at least many of them) are already passed. > > > > Regards > > > > Carlos Sanchez > > A Coru�a, Spain > > > > Oness Project > > http://oness.sourceforge.net > > > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] > > > Sent: Wednesday, July 14, 2004 1:26 PM > > > To: [EMAIL PROTECTED] > > > Subject: RE: RC4 to 1.0 problems > > > > > > I see - I was just going with a solution someone submitted to the > > > list for the JNI path problem. > > > > > > So what would the correct syntax be in this case? For arbitrary > > > user properties the example on that page makes sense, but when > > > it's a fundamental system property (like > > > java.library.path) then surely it won't be picked up from my > > > project.properties? > > > > > > Certainly when I try this it doesn't work: > > > > > > maven.junit.sysproperties=java.library.path > > > java.library.path=${maven.tcw.path} > > > > > > James > > > > > > > > > -----Original Message----- > > > From: Dion Gillard [mailto:[EMAIL PROTECTED] > > > Sent: 14 July 2004 12:02 > > > To: Maven Users List > > > Subject: Re: RC4 to 1.0 problems > > > > > > > > > On Wed, 14 Jul 2004 11:20:19 +0100, > > > [EMAIL PROTECTED] <[EMAIL PROTECTED]> > > > wrote: > > > > > > > A: > > > > > > > > > maven.tcw.path=${basedir}/../../../../Release/bin;${java.library.pat > > h} > > > > ;${bas > > > > edir}/bobbins > > > > maven.junit.fork=true > > > > maven.junit.sysproperties=java.library.path=${maven.tcw.path} > > > > > > maven.junit.sysproperties is a list of the names of properties to > > > pass, not the names and values. See > > > http://maven.apache.org/reference/plugins/test/properties.html > > > > > > > > > > B: (Extends A, somewhere else in the file system, hence > > the need to > > > > redefine the property value) > > > > > > > > > maven.tcw.path=${basedir}/../../../../../fo_tcw_core/Release/bin;${b > > as > > > > edir}/ > > > > ../../../../Release/bin;${java.library.path};${basedir}/bobbins > > > > > > > > C: (Extends B, is in subdirectory of B) > > > > <nothing> > > > > > > > > Now under RC4 the tests run fine, whether I run them from B > > > using the > > > > reactor, or from C on it's own > > > > > > > > But under 1.0 the tests only work when run inside C. > > > Running via the > > > > reactor fails. Having amended the code to spit out > > > java.library.path, > > > > in the case where it runs under the reactor then it's just > > > set to my > > > > standard windows path, i.e. the maven.junit.sysproperties > > > doesn't seem > > > > to have taken effect > > > > > > -- > > > http://www.multitask.com.au/people/dion/ > > > > > > > > -------------------------------------------------------------------- > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > -------------------------------------------------------------- > > > ---------- > > > For more information about Barclays Capital, please > > > visit our web site at http://www.barcap.com. > > > > > > > > > Internet communications are not secure and therefore the Barclays > > > Group does not accept legal responsibility for the contents of > > > this message. Although the Barclays Group operates anti-virus > > programmes, > > > it does not accept responsibility for any damage whatsoever that > > > is caused by viruses being passed. Any views or opinions > > presented are > > > solely those of the author and do not necessarily represent those > > > of the Barclays Group. Replies to this email may be monitored by > > > the Barclays > > > Group for operational or business reasons. > > > > > > -------------------------------------------------------------- > > > ---------- > > > > > > > > > > > -------------------------------------------------------------------- > > - > > > 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] > > -- http://www.multitask.com.au/people/dion/ --------------------------------------------------------------------- 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]
