Hi All-
The codebase for the UI is staged for review here:
https://github.com/ahgittin/brooklyn-ui/tree/new-ui-for-review/new
We have created the ip-clearance record [1] to track steps and the legal
grant is in process (as per [2]). We will call for an [IP CLEARANCE] at
general@incubator once those are completed, and then we will look for a
vote here. If you have any comments on the code or on the process in
the meantime please let me know.
Best
Alex
[1]
http://svn.apache.org/viewvc/incubator/public/trunk/content/ip-clearance/brooklyn-ui-angular.xml?view=markup
[2]
https://incubator.apache.org/ip-clearance/ip-clearance-template.html#form-filling
On 28/05/2018 12:46, Alex Heneveld 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
