I would echo some of Robs points (since he beat me to saying them msyelf :) ) and add some of my own.
I also dont see a need to check out proton-c or proton-j in isolation, if the tests for both of them sit a level up then thats what people should be grabbing in my mind. Duplicating code sounds fishy to start with, but doing so given the apparent real need to check out the common parent directory seems easily questionable. One possible adjustment I might suggest (but dont personally see the need for) would be that if the compile requirement for maven to generate the proton-api jar used by the C tree to build the JNI bindings is considered unworkable for some, if its just a simple jar it could also be built with CMake for the C build, leaving Maven to do it for the Java build. I'm not sure how such developers would be planning to run the common test suite that still needed Maven though. If we are releasing the C and Java components at the same time, and the tests sit at the top level, why does there need to be two source tars? We had this discussion with regards to the various Qpid clients and brokers some time ago and the agreed (but never fully implemented, we still have subset source tars) outcome was that we should do away with the component-specific source tars and only have the one main source tar which is actually 'the release' in terms of the project, with e.g Java binaries being separate complementary things. If we did just have a single source artifact to consitutate the full release and either we or some third party then wanted to build a c-only source artifact for some reason, that could of course still be done by simply processing the contents of the repository or single 'the release' tar appropriately. E.g, the 'individual component' source releases in Qpid arent simple svn exports, they contain different parts of the tree bundled into a tar, which is I guess ok because they are not actually 'the release'. Robbie On 21 January 2013 12:10, Rob Godfrey <rob.j.godf...@gmail.com> wrote: > > > > > > This results in something that is quite awkward for the C build. For > one > > > thing I'm not sure an svn export of the proton-c directory would be > > > considered releasable under this scheme as it would include the java > > > binding, but not the source code necessary to build it, and apache > policy > > > requires releases to include full source code. Regardless it would no > > > longer be a useful/sensible artifact to end-users since they couldn't > > > actually build the java binding. > > > > > > > > This seems a slightly odd position to take. The artefact doesn't include > the entire source to python, ruby, openssl, etc. If the dependencies for > these are not present then the relevant parts of the tree are not built. > The same is true in this proposal with respect to the java binding... > there is a dependency on the Java API being installed in order to build the > JNI bindings within the C build. > > > I must admit I remain bemused by the idea that trying to maintain two > copies of the Java API in the source tree makes any kind of sense. > > I think we are contorting ourselves and adding potentially huge > complication to our build/development process in order to try to satisfy a > number of somewhat arbitrary "requirements" that are being imposed on the > directory structure. > > Personally I don't perceive there to be an actually need to allow checking > out of only part of the Proton tree. Indeed I would wish to strongly > discourage the sort of silo-d attitude that checking out only Java or only > C would imply. > > Moreover, while I see that it is advantageous to be able to release > "source" packages directly as svn exports from points in the tree... I > don't find this so compelling that I would break fundamental tenets of > source control is expected to be used. > > Personally, given that our current plan is to release all of Proton at the > same time, I'm not sure what would be wrong with simply shipping a single > source tarball of the entire directory structure. People who wish to build > from source would thus be able to build whatever they so desired. > > -- Rob >
