Re: New Angular UI for Brooklyn [DISCUSS]
+1 exciting news
On Mon, 28 May 2018, 13:25 Duncan Johnston-Watt, <duncan@xxxxxxxxxxxxxxxx>
> +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
> > 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
> > people to use Brooklyn in many more good ways! There are plans to make
> > Composer embeddable and able to work with other input libraries (think
> > of pointing it at a Docker repo or an image catalog), and with widgets
> > 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
> > 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
> > to come via the IP clearance process ), followed by associated PRs in
> > other projects so that everything works seamlessly (which as minor
> > 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
> > 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
> > potential obstacles.
> > Once the above list is complete we will commence the IP clearance process
> > including formal vote.
> > Best,
> > Alex
> >  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