On Mon, Jan 21, 2013 at 8:03 AM, Robbie Gemmell <robbie.gemm...@gmail.com>wrote:
> 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. > I'm not sure I can answer this in a way that will be satisfying to you as the answer is based a lot on C development standards where source tarballs play a much more active role as a means to distribute software than in the Java world where everything is distributed via binaries. But I'll try by saying that having a C project where you can't simply untar it and do one of <src>/configure && make or cmake <src> && make is a bit like having a Java project that doesn't use maven or ant. I'm aware we could have cmake at the top level alongside a pom.xml, and some third entry script that invokes both for system tests and the like, and while I would encourage that for proton developers, it is imposing a very complex set of entry points onto our users. I can see that this might impact Java users less as they may care less about src distros, but it is far from an ideal release artifact for C users. As for producing a C tarball by post processing a large source tarball, it's simply something I would prefer to avoid given that there are alternatives as having a complex mapping from source control to release artifact is in my experience quite bad for the health of a project. It means developers are more detached from what their users experience "out of the box". --Rafael
