On 1/12/06, RedBugz Software <[EMAIL PROTECTED]> wrote:
>
> 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 :).
Put his in your native's pom.xml
<profiles>
<profile>
<id>add-windows-86-module</id>
<activation>
<property>
<name>platform</name>
<value>windows-x86</value>
</property>
</activation>
<modules>
<module>windows-x86</module>
</modules>
</profile>
<profile>
<id>add-redhat-x86-r3-module</id>
<activation>
<property>
<name>platform</name>
<value>redhat-x86-r3</value>
</property>
</activation>
<modules>
<module>redhat-x86-r3</module>
</modules>
</profile>
<profile>
<id>add-aix-ppc-module</id>
<activation>
<property>
<name>platform</name>
<value>aix-ppc</value>
</property>
</activation>
<modules>
<module>aix-ppc</module>
</modules>
</profile>
</profiles>
then you must pass in -Dplatform=windows-x86|aix-ppc, etc
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.
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.
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.
thanks,
> Logan
>
>
