brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Svetoslav Neykov" <svetoslav.ney...@cloudsoftcorp.com>
Subject RE: Breakfast with the mentors
Date Wed, 26 Nov 2014 18:23:12 GMT
Hi Richard,

> the loss of copy-to-clipboard
I believe this functionality has been added as a workaround to the disappearing selection
problem. Currently the sensors tab is updated constantly with the latest state coming from
the server. Updating the html clears any selection in it. It's possible to rewrite this code
so it changes only items which are really updated, avoiding the need for this component.

> some of the tests being skipped.
I don't mind the tests being skipped, but don't really like the release-as-a-subset-of-repository
idea. What do you think of the approach to move the test jar files as external projects? It's
the same as depending on testng for example. They can still live in the brooklyn repo as sources.

Svet.

-----Original Message-----
From: Richard Downer [mailto:richard@apache.org] 
Sent: Wednesday, November 26, 2014 7:40 PM
To: Brooklyn dev
Subject: Re: Breakfast with the mentors

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