brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Downer <rich...@apache.org>
Subject Re: Breakfast with the mentors
Date Wed, 26 Nov 2014 17:40:15 GMT
As a follow-up to this I've been looking at excluding binary files
from our source release.

There's two main types of binary file, that I have seen:

JARs/WARs used as test resources (mostly; see below)
ZeroClipboard.swf

For ZeroClipboard, I've verified that omitting this file breaks
copy-to-clipboard (unsurprisingly) but does not appear to break
anything else in the Brooklyn UI. I haven't verified the docs build
(the other place where ZeroClipboard is used) but I have no reason to
believe that it is different.

For the JARs/WARs used as test resources: TestNG has something called
"SkipException", and if test code throws this exception or a
derivative, then the test is marked as "skipped" - not passed, not
failed. So I have submitted a PR which modifies tests that rely on
these resources to safely test if the resource is present before using
it. The side effect of this is that someone who downloads the source
bundle and runs all the integration and live tests will be
disappointed to discover that they are only running a subset of the
tests. However I believe that this is going to be a very small group;
integration and live tests are generally run by developers on the
bleeding-edge code who are using Git and therefore have the binary
resources; and Jenkins CI, which is also using Git and has the binary
resources.

The only other resource is the cassandra-multicloud-snitch.jar file,
which is optional anyway and had to be explicitly added by the user to
the configuration.

So, in summary, the most inconvenient effect of forcefully deleting
binaries from the source release, is the loss of copy-to-clipboard
from the Brooklyn web UI, and some of the tests being skipped.

Can we live with these limitations for today? Are we happy to continue
with a release with these limitations (and hopefully revisit them
later)?

The pull request is at https://github.com/apache/incubator-brooklyn/pull/365.

Richard.


On 19 November 2014 at 08:12, Richard Downer <richard@apache.org> wrote:
> Good morning all,
>
> While at ApacheCon we had the opportunity to bring together some of
> our mentors and get f2f feedback about our release candidate. We had
> David Nalley and Chip Childers at the table with myself and Andrew
> Kennedy.
>
> The good news is that David and Chip are generally happy with the way
> we are progressing. The licensing issues we have had with
> configuration files are on a good track and they are happy that we
> have this in hand.
>
> However they still have serious concerns about binaries in the build,
> and are pushing back against our JARs in the build even if they
> contain their own source code. There are also a couple of SWF files -
> I haven't check but I'm 99% certain that they are the "copy to
> clipboard" support for examples in the docs and sensor values in the
> Brooklyn UI.
>
> One interesting snippet that was suggested is that the source release
> can be a *subset* of our Git tree. So we could potentially simply
> exclude the test *.jar and *.war, and modify our tests to gracefully
> disable themselves if the resource is not available. So the tests in
> Git would be comprehensive, and the source release would be a subset.
> That is a bit of a stop-gap measure, however, so the preferred option
> would still be to have the resources built from source in the course
> of a normal build, and remove the jars completely.
>
> The clipboard thing is a bit awkward. The ideal solution would be to
> replace with an alternative that is pure-HTML/JS. A stop-gap measure
> would be to make this an optional part of the build - we exclude it
> from the source release (disabling copy-to-clipboard) but allow the
> user to supply their own copy of the file.
>
> There was also some discussion about how to handle cases where we need
> to patch our upstream dependencies. I'll let Andrew write up that
> part, but the short form is that a fork is the least favourable
> option, but there are other options, such as copying the source file
> (accounting for license, of course) into Brooklyn, or checking out and
> building a specific Git commit ID as part of our own build process.
> Depending on -SNAPSHOT versions is not disallowed but is of course
> risky.
>
> Thanks again to Chip and David for making time for us this morning,
> and please reply if I've misinterpreted anything. I'd have bought you
> a beer, but I felt that for a breakfast meeting it perhaps wasn't
> appropriate.
>
> Cheers
> Richard.

Mime
View raw message