On Fri, Jun 22, 2012 at 11:16 AM, Gordon Sim <[email protected]> wrote: > On 06/22/2012 03:26 PM, Rajith Attapattu wrote: >> >> Actually the cpp binding implementation, in addition to the jni code, >> depends on common code and utility classes (for message codecs etc..). >> So I was not correct when I said the only dependency is the public API >> jar. > > > That is indeed a significant complication to the picture. > >> Then it's going to be no different from the current situation, infact >> a bit worse as the common code, utility classes can change quite >> frequently. >> The JNI jar is less volatile compared to the above. So the lesser of >> the two evils. >> >> To me the ideal solution seems to be, where the swig files (for the >> java side) are placed on the java tree and the code is generated >> during the java build. >> Unfortunately this would be a bit difficult... but not impossible. >> We currently rely on the spec file being in a particular location. >> Similarly we could rely on the location of the include files and the >> qpid.i file >> What do you think ? > > > So what jars would be produced? Would the JNI wrapper and API implementation > that used that be included in the qpid-client jar? Or would it be split out?
The jni stuff will be bundled into the same jar that contains the cpp implementation as well. Very roughly I was thinking along the following lines for future client jars. Not sure what the rest of java folks think about this. qpid-client-api-<version>.jar --> API interfaces qpid-client-jms-<version>.jar --> JMS implementation qpid-client-<version>.jar --> Pure java implementation qpid-client-cpp<version>.jar --> cpp binding implementation (will contain the jni classes as well) qpid-comon-io-<version>.jar --> containing the various IO implmentations (java.io, nio ..etc) > > > --------------------------------------------------------------------- > 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]
