Most of the times I download and compile a release (something even us Java developers still do on occasion :P), the first thing that is required is changing into a directory, which is true with the proton-c releases. Changing down 2 directories doesnt sound overly taxing to me, and proton-c seems like a fairly obvious directory to change into if I want to compile the C version of proton and dont find a makefile/src dir in the initial version directory.
That said, looking at the 0.3 proton-c source tar I notice that it is already more complex than a simple export of the proton-c subdir in the repo, since the contents of the two dont match directly. As there is already some processing going on somewhere (release.sh), it is really that complex to export two extra directories from the top level into the release tar instead of the one extra that is being done already? Robbie On 21 January 2013 17:55, Rafael Schloming <r...@alum.mit.edu> wrote: > 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 >
