>> I do see your point here. In this case the only dependency would be >> the jar file that bundles the Qpid API. >> And in the Java side there will be no dependency on a build artefact. >> (On the other hand an argument could be made that, the Qpid API jar is >> also a build artefact, all though a pretty lame one at that). > > > No, I think it *is* a build artefact. However as it is an explicit public > API it provides an obvious interface to depend on. (This is much more like > the JMS clients dependency on the JMS interface).
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. 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 ? That way the java code will live on the java source tree and generated code is done during the java build, so we don't need to shuffle deps out of band. Rajith --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
