On Thu, Jun 21, 2012 at 11:46 AM, Gordon Sim <[email protected]> wrote: > On 06/21/2012 03:54 PM, Rajith Attapattu wrote: >> >> On Thu, Jun 21, 2012 at 10:32 AM, Gordon Sim <[email protected]> wrote: >>> >>> On 06/21/2012 03:25 PM, Rajith Attapattu wrote: >>>> >>>> >>>> Does the above answer your questions sufficiently ? >>> >>> >>> >>> Yes, but I still don't understand why you need to check the built jar >>> into >>> svn. >> >> >> How else would I make it available on the Java side? >> The API impl on the java side needs this jar file to compile successfully. > > > Whats the rationale for the current split? The module on the c++ side generates the shared lib and the jar file containing the jni code.
The Java side has the concrete implementation and relies only on the generated jni code. Since the C++ header files rarely change, the JNI files are very stable too. Therefore I thought the best way to bridge the two sides is by including the jar (which contains the jni code) file on the Java side as a dependency like we do for the jms interfaces. This also allows each side (c++ and java source trees) to be totally independent and unaware of each other. > > Why don't you include that impl in the bindings code and jar itself? What is the advantage of doing so? I want to better understand what you meant here before trying to respond. Did you mean you want the CMake build to pull in the impl from the java side and bundle that into the jar file that is created ? > If/when there are other implementations of the API, then the API itself > would want to live in the Java tree. You could have your JNI based impl > depend on that jar of course (i.e. the API possibly including some plugin > framework for impls). > > > --------------------------------------------------------------------- > 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]
