On 1/12/06, dan tran <[EMAIL PROTECTED]> wrote: > > On 1/12/06, RedBugz Software <[EMAIL PROTECTED]> wrote: > > I don't see from the documentation where I specify the classpath. I > > cheated > > and added an additional className entry: > > <classNames> > > <className>test-jni-java/target/classes</className> > > <className>HelloWorld</className> > > </classNames> > > classname is wrong, it just be java format com.xuy.classname > > Will fix up the example to be clearer.
OK. HelloWorld.java is actually in the default package (just as the JNI tutorial does it), but I moved it into a package to be more consistent with how our final project will be done. I also noticed that adding the dependency to test-jni-java seems to have added the correct classpath entry to the generated command line. > Finally, while I'm compiling on Windows for now (MinGW gcc), I'll need to > > compile on Linux and Solaris eventually. I don't see how one sets this > up > > to > > run on the appropriate platform, since win32 is specified in the POM > > itself. > > For each platform, your will need to create a project for native compile > > root > jni-java > native > pom.xml <--- use profile to trigger native build depending on os > src <------ put all your common native source here > win32 > linux > .... Got it. We don't have any platform-specific code, so we should just be able to use profiles to generate the appropriate .dll/.so out of our native/src dir and place it in the appropriate platform output directory, right? I've never used profiles before, I'll take a look at them, but if you happen to have an example handy, that would be great :). I never tested with MinGW gcc, but accouding to Sun, you need msvc 6.0 to to > do JNI stuff Do you happen to have a reference for this? I've seen notes from several people generating JNI DLLs using MinGW/Cygwin. There are some issues you have to deal with, but they seem to think it works. I'd be curious to know if there's a more supported approach. 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. thanks, Logan
