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
> 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