On 21 January 2013 18:05, Rafael Schloming <r...@alum.mit.edu> wrote:
> On Mon, Jan 21, 2013 at 9:33 AM, Rob Godfrey <rob.j.godf...@gmail.com > >wrote: > > > 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. > > > > That's not really a proper analogy. Again the JMS interfaces are defined > outside of qpid. We don't release them, and we depend only on a well > defined version of them, we don't share a release cycle with them. If the > JMS API was something that we developed/defined right alongside the impl > and was part of the same release process, we would certainly not be allowed > to release without the source. > > This "releasing without the source" is a complete red herring and you know it. The source is released in whichever scheme we settle upon. If you want an example of dependencies within the qpid project, how did the AMQP 1.0 work on the C++ broker get released for 0.20? Did all the proton source get released with the C++ Broker / client? In the future are you expecting every part of the Qpid project which depends on proton to include its full source? If yes then how is the source tree going to work - is everything to be a subdirectory of proton-c? I agree that having the source for the version of the Java API included in the source release bundle is advantageous. But if the collective decision is that we have taken a religious position that the source tarballs can only be svn exports of subdirectories of our source tree, then my preference would be to use separated dependencies over duplication in the repository. Personally I would think that having a more flexible policy on constructing the release source tarballs would make a lot more sense. -- Rob > --Rafael >
