Thanks Richard, Thomas.
i have done as you suggest, pushing from a merged branch directly to
master. [1] is the result of `mkdir new ; cd new ; curl
https://issues.apache.org/jira/secure/attachment/12932670/brooklyn-ui-angular.tgz
| tar xvz`. [2] is a few minor RAT/license header tweaks needed.
I confirm that `mvn clean install` now works:
* At `brooklyn-ui/` (root) to build the old UI with no errors
* In `brooklyn-ui-new/` to build the new UI with no errors
The next will be a set of linked PRs to replace `/brooklyn-ui/` with
`/brooklyn-ui/new/`, and update all related code and documentation.
Best
Alex
[1]
https://github.com/apache/brooklyn-ui/commit/29927b734a8db268814ea180c1d117858a747c3c
[2]
https://github.com/apache/brooklyn-ui/commit/9b8bb9c156368143219c13ecbdeb5d1ba1e60b3b
On 26/07/2018 11:19, Richard Downer wrote:
Alex,
Agree with Thomas - the code has been [VOTE]ed in so there's no need for a
second stage of review, and pushing a massive PR isn't easy to navigate in
the GitHub UI. So just push straight to master on the Apache git repo.
There's a safety net in that the code is going into a `new` subdirectory so
interested individuals can still conduct a detailed code review.
Thanks
Richard.
On Thu, 26 Jul 2018 at 10:41, Thomas Bouron <[email protected]>
wrote:
Hi Alex.
Great news, I'm super excited to see this land!
I don't think the PR approach makes sense in this context, the code is
completely different from the current code base, there isn't much benefit
or doing a PR and see the differences between the two.
I would push directly IMO.
Best.
On Thu, 26 Jul 2018 at 10:32 Alex Heneveld <
[email protected]>
wrote:
Hi Brooklyners-
I also give a +1 (binding).
With 72h elapsed I declare the VOTE closed and passed.
The [IP-CLEARANCE] also passed as folks will see. I will incorporate
the new code now. I will do this as a PR for visibility and call out
the IP-CLEARANCE process links in that PR, unless anyone thinks a
different approach is more suitable (e.g. pushing directly?).
Best regards
Alex
On 23/07/2018 14:22, Geoff Macartney wrote:
+1 (binding)
Excited to see this go into Brooklyn
On Mon, 23 Jul 2018 at 14:13 Richard Downer <[email protected]>
wrote:
+1 (binding)
Having seen this UI in action I'd be very happy for it to land into
Brooklyn. It's a much more modern-looking, aesthetically-pleasing UI
with
much more extensibility, but at it's core the UI works very similar to
the
old one, so there's very little learning curve for a user moving from
the
old UI to the new.
Richard.
On Mon, 23 Jul 2018 at 10:07, Alex Heneveld <
[email protected]>
wrote:
Hi Brooklyners-
This is a vote on whether to accept the brooklyn-ui-angular
contribution
at [1] once IP clearance is completed.
For background, as previously discussed a new UI based on Angular/JS
has
been offered to the Apache Brooklyn project. The formal grant has
been
completed and is on file -- thank you Cloudsoft and Fujitsu -- and is
currently going through IP Clearance (see prior email to this list)
and
barring obstacles we may have that clearance after 72 hours. The
vote
to accept can occur in parallel with the clearance so that is what we
are doing.
We propose for the code to be added iniitially to a `new/`
subdirectory
in the `brooklyn-ui` repo, once IP clearance is completed and if this
vote is successful. We will then create a set of PRs to replace the
contents at the root with the contents under `new/` and make changes
elsewhere as needed for the project to build, run, and be documented
cleanly. It is proposed that those PRs be reviewed in the usual way
(no
further votes) unless anyone thinks otherwise.
This vote will run for 72 hours.
Best
Alex
[1] https://issues.apache.org/jira/browse/INCUBATOR-214
On 20/07/2018 16:14, Alex Heneveld wrote:
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
--
Thomas Bouron
Senior Software Engineer
*Cloudsoft <https://cloudsoft.io/> *| Bringing Business to the Cloud
GitHub: https://github.com/tbouron
Twitter: https://twitter.com/eltibouron
Need a hand with AWS? Get a Free Consultation.
