On 21 January 2013 15:11, Rafael Schloming <r...@alum.mit.edu> wrote:
> On Mon, Jan 21, 2013 at 7:10 AM, 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. > > > > The problem isn't with not including the source code to external > dependencies (i.e. Java in your analogy), the problem is with the fact that > all of the Java binding (the API and the JNI implementation of it) is > developed within the qpid project, and the artifact would not include all > of it. The apache release policy is quite clear on this front: > > "The Apache Software Foundation produces open source software. All releases > are in the form of the source materials needed to make changes to the > software being released. In some cases, binary/bytecode packages are also > produced as a convenience to users that might not have the appropriate > tools to build a compiled version of the source. In all such cases, the > binary/bytecode package must have the same version number as the source > release and may only add binary/bytecode files that are the result of > compiling that version of the source code release." > > Producing an artifact that has source code for impls, but not source for > the interfaces would quite clearly constitute an artifact that didn't > include all the source materials needed to make changes. > > Ummm... it's a dependency... you're familiar with those, yeah? The same way that the Qpid JMS clients depend on a JMS API jar, for which the source is readily available from another source. The JNI binding would build if the dependency was installed. The same way I believe the SSL code in the core of proton-c builds if the dependency for it is installed. > 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. > > > > You're arguing against a straw man here. Nobody has proposed "copying" the > API the way you keep describing it. The original solution implemented on > the JNI branch was to have the API in two places at once via svn externals. > This isn't in "two places"... it's very clearly in "one place" in the repository, with another place "linking" to it, through a rather inelegant manner. Having said that, the externals solution is not a particularly pleasant solution and was only put in place because of the "requirement" to be able to check out from a subdirectory of proton. Having further considered the matter, my feeling is that it is better to re-examine the need to be able to check out just a single subdirectory of the proton tree. > This however does violate one of the "fundamental tenants of source > control" as you put it since it fundamentally loses track of what version > of the API source goes with what version of the implementation source. > Umm... no it doesn't. Again... I'm not pushing for svn:externals but if you insist on the "each subdirectory must be provide able to be independently checked out" then I think svn:externals is a better solution than the copy. The original svn:externals proposal makes it very clear that the version of the Java API code that the JNI binding works with must be the same as that which the Java impl works with. The externals is to a sibling directory within the same project. So long as you consider the proton project as a whole then it is never unclear as to which version you should be using. Only in w orld where the Java and C versions are not progressed with a common API does this become a problem. If you do not believe the two should have a common API then I think we need to have a wider discussion (since we've been working pretty hard until now to keep the APIs in sync). > Branching the API into two places and putting the necessary scripts in > place to enforce that the C version of that branch is a read only copy of > the Java version is simply another way to achieve exactly what is currently > It's not a branch though... not in way in which the term is normally recognised. There is no concurrent development going on here. There should be only one API. In the same way that for a given release you don;t have a separate set of .h files for the Ruby binding and for the Python binding. > proposed on the JNI branch without the problems associated with svn > externals. I'm honestly somewhat befuddled why there is such vehement > resistance to even exploring it. > > > > 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. > > > > We've been quite clear from the beginning of the project on why exactly we > want to produce C and Java release tarballs that are simple, familiar, and > easy to consume within their respective development communities. > > These can be produced, per Robbie's comment... Having these be produced in a way that is slightly more involved than a simple svn export seems like a reasonable step to me if we are trading this off against having a development process which requires running scripts and merging every time we make a change to the Java API. So... how do we move forward? Other than myself, Rafi, Keith, Robbie and Phil is there anyone else who wants to volunteer an opinion? -- Rob
