Maybe something like this way to set a system property (which allows setting
the XSL transformer factory) could work for you.
<!--
'Major hack.' Stolen from the Latka plugin.jelly.
-->
${systemScope.setProperty('javax.xml.transform.TransformerFactory','org.apac
he.xalan.processor.TransformerFactoryImpl')}
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> Sent: Friday, July 16, 2004 1:10 PM
> To: [EMAIL PROTECTED]
> Subject: RE: RC4 to 1.0 problems
>
> Sadly that doesn't seem to work. Obviously setting the
> user/system windows path outside of Maven does the trick, but
> that relies on:
> a). Each developer knowing to do that
> b). if you're working on 2 streams on the same box the dlls
> need to be compatible, otherwise you have to switch your path
> each time you build.
>
> Hence my attempts to get Maven to manage the path using a dir
> relative to basedir, which will point to the right dll every time
>
> Any other ideas?
>
> James
>
> -----Original Message-----
> From: J. Matthew Pryor [mailto:[EMAIL PROTECTED]
> Sent: 15 July 2004 22:57
> To: 'Maven Users List'
> Subject: RE: RC4 to 1.0 problems
>
>
> There also appears to be : maven.junit.envvars
>
> So on Windows if you added you path to the PATH env var that
> might work
> since the JVM will add PATH to java.library.path I think
>
> jmp
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]
> > Sent: Friday, July 16, 2004 2:12 AM
> > To: [EMAIL PROTECTED]
> > Subject: RE: RC4 to 1.0 problems
> >
> > 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]
> >
>
>
> ---------------------------------------------------------------------
> 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]
