On 22 January 2013 13:47, Rafael Schloming <r...@alum.mit.edu> wrote:
> 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 > > 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? > > > > 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 > branch/release together. > > The point was that the source code doesn't need to be in the same tarball let alone the same subdirectory in source control. If one considers that the Java API is a dependency then whether it is released concurrently or not with the JNI binding is moot. I've already said that it is preferable to have the source within the same tarball for the source release, but if needs be then I can live with the strict dependency view of things. > > > > > 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. I actually think there are three perspectives here. The user experience of our release artefacts, the committer experience of working on the checkedout codebase, and the release manager view of preparing the release aretfacts from the source control. > 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. I think the issue here is that if you take a rigid view of how the release artefacts correspond to the source repo directories then you impose different trade-offs compared to not imposing those constraints. I'd be very happy with a solution that provided source tarballs with exactly what the users need to build, and having the source tree having everything in exactly once, if the cost was that the release process had a little more processing in it. Frankly if the source tarballs were constructed by taking a cut at the top level of proton (rather than at -j or -c) and irrelevant parts were simply pruned, then I don't (personally) see a big issue. > 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. > > The proposed solution in the JIRA implies that in order to build the JNI binding then the builder would need to "install" the Java API (in the same way that they would need to "install" Java, Python, etc). This is a slightly greater burden on the end user who is building the binding, and one which I would wish to avoid. However the fact of having a dependency for a certain part of the build does not seem out of line with the rest of the process which a user would have to go through. If the Java API were not present then the JNI binding would simply be skipped in the build. As above, I personally prefer having the API code available in the source tarball, but if the only way to do this would be to have two copies of the source code checked in (even if there were some scripts to try to keep the copies in sync), I would choose to omit the source from the tar and go with the strict dependency. -- Rob > --Rafael >
