On Tue, Jan 22, 2013 at 4:22 AM, Rob Godfrey <rob.j.godf...@gmail.com>wrote:
> 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
> > > 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
> > 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?
Again that's not really the same. If the Java API where on a separate
(staggered) release cycle and the dependency was on a specific version,
then that would be the same, but for what we're discussing, it really
isn't. Proton and the cpp broker live under different trunks and
branch/release separately, as far as I know this is not what you're
proposing for the Java API, it is to live under the same trunk and
> 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.
You can call it religious if you like, but I don't think there is anything
invalid about wanting to keep a simple mapping between release artifacts
and proton developer environment. In the past we have had quite direct
experience of exactly this factor contributing to very poor out of the box
experience for users. Correct me if I'm wrong, but I believe you yourself
have actually advocated (or at least agreed with) this position in the past.
That said, I don't think I'm asking for us to be entirely inflexible in
that regard. There really are two opposing concerns here, one being the
user experience for our release artifacts, and the other being the
convenience of the development process for proton developers. All I'm
asking is that we recognize that there is a real tradeoff and be willing to
explore options that might preserve user experience albeit at a hopefully
minor cost to developer convenience. For any other aspect of software
engineering this would be a no-brainer, you start from the user
requirements/user experience and work your way backwards to the simplest
solution that achieves this, however this proposal and the related
requirements JIRA make zero mention of any *user* requirements merely
developer requirements. This may be ok for Java where all your users will
get stuff via jars and the source tarball is mostly a formality, but for C
the situation is different.