[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: New Angular UI for Brooklyn [DISCUSS]

+1 Non-binding

On Mon, May 28, 2018 at 12:46 PM, Alex Heneveld <
alex.heneveld@xxxxxxxxxxxxxxxxx> wrote:

> Dear Brooklyners,
> Our users at Fujitsu, UShareSoft, and Cloudsoft have generously sponsored
> the contribution of a new UI for Apache Brooklyn.  This is based on the
> previously-proprietary Cloudsoft AMP UI, for those of you familiar with
> that.
> The proposed newly contributed UI has all the functionality of the
> existing UI including an inspector, groovy console, and online REST docs.
> It is much more recent (angular, webpack), modular, easy to develop
> against, and lovely to look at, and so would be a great contribution based
> solely on that.
> But even better, it provides a lot of new features:
> *  A visual blueprint composer:  drag-and-drop elements from the catalog
> onto a canvas, with a bi-directional YAML editor
> * More live activity update:  a kilt view for activities, tailing output
> from SSH commands
> * A bundle-oriented catalog:  with search, bundle- or type- view, delete
> bundles
> * An extensible, skinnable, and reusable modular architecture: embed
> angular directives and components from this project in others, build a
> branded version of the UI, and/or add your own modules (e.g. to accompany
> specific blueprints)
> The last point in particular I think will be very valuable:  it will allow
> people to use Brooklyn in many more good ways!  There are plans to make the
> Composer embeddable and able to work with other input libraries (think e.g.
> of pointing it at a Docker repo or an image catalog), and with widgets for
> configuring items, all ultimately generating Brooklyn blueprints.
> Note that this is proposed to replace the existing UI, and as we have
> already deprecated the non-OSGi build, it is proposed to make this
> compatible only with the OSGi build.
> It is also worth pointing out that the main authors on this UI are already
> Brooklyn contributors, so there is enough experience among active project
> members to maintain, explain, and extend this.
> Assuming this proposal finds favour, we will open a repo for review
> purposes (but it will not be a merged via PR, with the actual contribution
> to come via the IP clearance process [1]), followed by associated PRs in
> other projects so that everything works seamlessly (which as minor changes
> to existing code is more suited to PRs than the IP clearance process).
> Specifically we will:
> * Ensure it builds and runs with the new UI in place of the old (note
> below on the Karaf switch)
> * Ensure all tests are passing (esp UI tests)
> * Ensure there are effective dev/test pathways and that documentation is
> updated (in particular for testing the UI and with the UI; this should be
> much simpler as the new UI can run separately, point at a REST endpoint,
> and can do incremental updates for UI code changes made while running!)
> * Ensure we have IP clearance, license, and are duly diligent in the
> approval (as this is a large contribution we recognise this will need
> special attention)
> Are there any objections at this point, or any suggestions for other tasks
> we should do to ensure its smooth integration?  Note that this is purely
> advisory at this stage but we would very much appreciate early sight of any
> potential obstacles.
> Once the above list is complete we will commence the IP clearance process
> including formal vote.
> Best,
> Alex
> [1] https://incubator.apache.org/ip-clearance/ip-clearance-template.html

Duncan Johnston-Watt
CEO, Blockchain Technology Partners <http://blockchaintp.com/>

Twitter: @duncanjw <https://twitter.com/duncanjw>
Mob: +44 777 190 2653 <+44%207771%20902653>
LinkedIn: https://linkedin.com/in/duncanjohnstonwatt