On 1/16/06, RedBugz Software <[EMAIL PROTECTED]> wrote:
>
> On 1/12/06, dan tran <[EMAIL PROTECTED]> wrote:
> >
> > Since Sun JVM/JNI built with mvcs 6.0 service pack3, you have to use the
> > same compiler.
> >
> > But it does not prevent you from using other compilers, however you are
> on
> > your own with this.
>
>
> I didn't realize there was a free version of the MS compilers. I have
> downloaded Visual C++ Toolkit 2003 with msvc compiler (cl 13.10.3077).
I have not tried this free compiler yet.
I
> notice that the docs for the plugin show available msvc providers as msvc,
> msvc6, and msvc2003. The msvc provider comes with the note:
> > Ensure to invoke the environment script provided by MSVC
> I assume this is the vcvars32.bat, but I'm not sure where to invoke it.
if you use msvc provider, you need to invoke vcvars32 or equivalent script
before run mvn.
if you use msvc6 and msvc2003, native plugin will automatically does that
job for you
provided that you place the compliler in the default place. But you can
override it as well
( checkout providerHome field)
It
> doesn't have any affect on the environment where mvn runs the cl command,
> even if invoked before the mvn command. I can certainly change my global
> environment settings to set the PATH, INCLUDE, and LIB variables to the
> same
> values as vcvars32.bat does. Is this the recommended approach? Or is there
> some way to configure mvn to run the cl command with the above settings
> without them being global?
> The msvc2003 provider says:
> > Automatically setup MSVC 2003 environment
> I'm not sure what that means and which one (msvc vs msvc2003) I should
> use.
>
> Also, do you add a runtime dependency from the jni-java module to the
> > > jni-native module? The Java changes far more than the native code, so
> > most
> > > of the time we'll just be pulling it from the repo.
> >
> >
> > Not sure what you mean by this, i thought transitive dependency will
> take
> > care of that.
>
>
> I was trying to call the native method from my test cases in
> test-jni-java/src/test/com...jni/AppTest.java. That's not crucial though
> if
> there's no easy way to get the native lib on the path for test cases
> (other
> than the system PATH of course). But I assume you're saying that when I
> create my client, say test-jni-client module with some code that has a
> dependency on test-jni-java, it will automatically pull in the native lib
> and put it in the jar for me so it will load, or do I still have to deal
> with the manual setup of getting the .dll file on the system path, etc.?
you will need to place your junit test in your dll project, but you must do
some
processing to copy the dll to the ${basedir} before forking the test.
I am waiting for a surefire test to allow user to add additioal env var
before forking the test.
So that we dont have to move file around.
Just trying to figure out a simple and repeatable way to build this project
> with the minimum of system dependencies, so any tips on how your projects
> are configured would be welcome.
I just checked in a toy project, under native-maven-plugin/src/it. Not
complete thou
Also, just FYI, the example pom.xml is missing the closing
> </plugin></plugins> at the end of the <build> section. Thanks for adding
> the
> dependency section. That does clear some things up. My actual project will
> require 1 external .dll with 2 header files. Would you recommend these be
> placed in the repo and linked as dependencies, or just included in the
> <sources> section? We don't use them for any other projects, so I normally
> just include them with the source.
There is no best way.
1. Place the dll/lib in remote repo, but .h files are under scm
and have maven to do pull down .lib and link it directly.
2. Place the full assembly of dll/lib and include files in repo
at run time unpack them, and have the link option to link them
directly.
I have done both in my production.
thanks,
> Logan
>
>
