This is fantastic news, congrats to all involved !! On Thu, Jul 26, 2018 at 11:54 AM Alex Heneveld < [email protected]> wrote:
> > 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. > >> > >
