Community
Participate
Working Groups
Re-implement the servers view in Common Navigator to allow users to add children underneath their server objects / types, icons for certain selections, etc. This enhancement would depend on an enhancement in Common Navigator: bug 243824, which would allow columns in the common viewer.
Created attachment 110729 [details] Patches to CNF and wst.server.ui This is an initial dry run set of patches to see how feasible such a transition would be. Almost all features are re-implemented.
Thanks for the contribution Rob! Angel has been looking into this and testing patches, so I'm assigning to him for now.
X-referencing to Bug 247934. Perhaps the servers view should not be multi-column at all...
Angel: I'd like to cross-reference a patch I've made related to both this bug and Bug 247934. It's a common-navigator based Server's view similar to a previous patch of mine here but without the 3 columns (as the 3 columns could wait for ever for common navigator framework to apply my patches). Bug 247934 suggests a server's view optimized for horizontal orientation.
Created attachment 115001 [details] Different patch suggesting only 1 column This is a patch to wst.server.ui which requires no patch to Common Navigator, but uses only one column.
In the most recent patch, some piece of code may want to be included on startup to ensure that the decorators are enabled from the beginning.
I suggest that we create a plugin to contain the new servers view. We can then drop this code contribution into it and start improving it to make sure all the existing and the new use cases are taken care of. Once it's good enough we can drop the existing servers view and start using the new one in the WTP perspectives. That should ensure smooth transition. DTP can start playing around with the new view in parallel. Tim and Angel, As I mentioned earlier in an e-mail to wtp-dev, this could easily live in either server tools or common in the short term. If you guys are swamped and need help moving this along, I can get this setup in the common project and handle contributions from Rob. It sounds like he is pretty excited to work on this, so I want to enable him to do that as soon as possible.
Forgot to mention in the last e-mail. There are two pieces to this. The common servers view and the extensions that show WTP servers in the view. Obviously only the common part can go into the WTP Common Project, but it's the part that we would be sharing with DTP and others.
Konstantine, You caught in the middle of reviewing Rob's contribution :). I want to get the new view in 3.1M3 so that we can start trying it out, iron out any missing feature and get some feedback on it.
Sweet! Could you make sure that the common parts are separate from the WTP server extensions so that DTP can easily re-use?
The common portion itself would actually be extremely minimal. I mean, seriously extremely minimal ;) It'd basically be an empty view that declares itself a common navigator view. There'd be seriously almost nothing else in it. All actions (toolbar, context menu), content providers / label providers, decorators, etc, would all be added by the extending plugins (DTP, server tools). It'd almost be nothing more than a stub. It'd be pretty much an empty plugin with 0 class files and a bit of xml in the plugin.xml just to declare the view exists and it is of type "CommonNavigator". The rest would be up to the extenders
I totally agree with Comment #11. It would be very minimal, just the view declaration, and we would then just bind the appropriate content extensions to that in the appropriate DTP or WTP plug-ins, so when those plug-ins were available and the view was open, the content and actions would appear. We should have some general guidelines about how we handle the view toolbar, drop-down, and pop-up menus in the context of this shared view however, or the toolbar/drop-down for the view will be a mess if we just try to throw everything in both views at it simultaneously. Anybody have any rough thoughts on how that might work? If we go beyond WTP/DTP it gets even hairier.
Re: 12: I would suggest that if one of your tree nodes is not selected, you get no items in the toolbar, however when an item you contribute *is* selected, you may add whatever you want for the duration. For context menus, perhaps if your item is selected you can add whatever you want to it, and if your item is not selected you can contribute just one top-level menu item which could expand with other actions. The top-level items could sit at the top of the context menu with a separator and then whoever "owns" the selection could add whatever they want below the selection. Of course in this fashion it'd be nothing more than convention and violators would be frowned upon but not forbidden... unless we added API / extension points to our specific view to enforce these restrictions.
(In reply to comment #13) > I would suggest that if one of your tree nodes is not selected, you get no > items in the toolbar, however when an item you contribute *is* selected, you > may add whatever you want for the duration. This is an interesting concept. I don't believe I've ever seen any view toolbars that work like this. The Editor framework and top-level toolbars definitely do, but I've not seen a view that works like this. Can you point to any particular examples that work this way? > For context menus, perhaps if your item is selected you can add whatever you > want to it, and if your item is not selected you can contribute just one > top-level menu item which could expand with other actions. This may be tough. Each (WTP or DTP) contributor probably has their own method/madness for contributing these menus. If we want to simply use the content/action providers as-is (in DTP's case), reorganizing the menus wouldn't be extremely difficult, just an inconvenience. Maintaining two different sets of context menus for the same information might provide some challenges also.
> The common portion itself would actually be extremely minimal. I mean, > seriously extremely minimal ;) It'd basically be an empty view that declares > itself a common navigator view. There'd be seriously almost nothing else in it. Nothing wrong with that, that I can see. :) I imagine it will start out pretty minimal, but over time be enhanced to contain more and more shared code that would make it easier for people to plugin into this view and make the additions more consistent.
>>I imagine it will start out pretty minimal, but over time be enhanced to contain more and more shared code that would make it easier for people to plugin into this view and make the additions more consistent. Perhaps, but Project Explorer is also based on common navigator and has pretty much been the RI for a while. I suspect most of these changes have already been pushed up into CommonNavigator API. (Of course I have noticed plenty of CNF deficiencies which I'd like to eventually push patches to). The question really is whether we want to be a little more restrictive than Project Explorer / CNF in general, enforcing a specific UI which will force extenders to conform to whatever conventions we decide on. >>This is an interesting concept. I don't believe I've ever seen any view toolbars that work like this. The Editor framework and top-level toolbars definitely do, but I've not seen a view that works like this. Can you point to any particular examples that work this way? Nope, sure can't! But just consider me a maverick... (or someone who has no respect for entrenched patterns and is willing to break with the past)... The fact is we're dealing with limited real estate here, and it seems more than fair to say "when its YOUR turn, you have the floor". Of course if the view only had one item in it (a server) and you wanted to add a dtp connection... well, if the selection is the server, not only would you not have the floor, but you'd be effectively shut out entirely... which is no good. This is why I suggested the top-level addition of your category "Database Actions" / "Server Actions" leading to your full context menu. This really wouldn't be *that* difficult for DTP to meld into. Instead of contributing 10 actions directly to the IMenuManager passed in, they'd just add a child menu manager first and then all their children (in the same order, whatever they want) to their child instead. Now take whatever I say with a grain of salt ;) I have no formal UI training and I'm not sure if this is desirable or not. I'm just trying to think of ways to manage unlimited wants vs limited means =]
Just wanted to let everyone know that I just blogged about this effort. It will get picked up by Planet Eclipse pretty soon and hopefully we will get other projects interested in this. http://lt-rider.blogspot.com/2008/10/common-servers-view-for-eclipse.html
Another alternative for dealing with the action context issue is to contribute static "App Servers" and "Databases" nodes which group their related items beneath them. That always gives user something obvious to click on when they want to create a new item of particular type. If we wanted to get real fancy, we could even add filtering so that users can remove content that they don't care about at that moment.
> Perhaps, but Project Explorer is also based on common navigator and has pretty > much been the RI for a while. I suspect most of these changes have already been > pushed up into CommonNavigator API. (Of course I have noticed plenty of CNF > deficiencies which I'd like to eventually push patches to). What is "RI"? I am so behind on my acronyms. > The question really is whether we want to be a little more restrictive than > Project Explorer / CNF in general, enforcing a specific UI which will force > extenders to conform to whatever conventions we decide on. Yep. I expect that this is exactly what we would end up doing. A complete free-for-all would hurt view's usability. We wouldn't want database guys to call their add action "Add..." while app server guys call their add action "Add Server...". At least the top level (or two if we go with static type nodes) should be pretty orderly. After that, it can be a free-for-all.
RI is reference implementation ;) Anyway, the way I see it is, given the following view: |- Server1 |- Database1 If the user right-clicks (or selects) Server1, the toolbar would only have actions from Server1 (as well as the common navigator actions that are required) and the context menu would look as follows: |- Database Actions -> New Database Connection, Import Database Connection, etc |- Soa Actions -> (any soa actions in a sub menu) --------------------- |- Start Server |- Stop Server |- Add / Remove Deployable Resource |- etc etc etc If the user right-clicks or selects Database1, |- Server Actions |- Soa Actions ---------------- |- New Database |- Import Database |- etc etc We could either do this by convention or mandate it via API (but that would require customizing our instance of the view rather than using the standard Common Navigator) Anyway, this is how I envision organizing the context menu.
Also, (as per previous comment), if the view is empty (no servers, no database connections, no soa content), then the context menu would look like the following: |- Server Actions |- Database Actions |- Soa Actions ---------------- <blank>
Just thinking out loud here... If we don't have category nodes, how will the list of items in the view be ordered? Would it be strictly alphabetic or by content type then alphabetic? The thing I like about category nodes is that if I am not working with my webservices and app servers at the moment and only care about databases, I can collapse those other nodes and reduce the view down to what's relevant.
The nodes are ordered by the extension points. Basically, each extension point (content / label provider, or in CNF they're called contentNavigator) get to declare what priority they are. There's about 7 or so ratings from lowest to highest. That's the order they iterate through the content providers. (just checked: lowest, lower, low, normal, high, higher, highest). I feel that this should be API instead of xml and the user should be able to re-order the content and have it saved in the memento, but that's an argument for another bug ;) I'd also like to say I'm a big fan of category nodes and think that they definitely belong. It keeps things nice and tidy.
Well, we could structure this view's API to require categories and to limit extenders' control regarding the relative placement of categories to prevent extenders from jockying for position. The initial order of categories would be alphabetical by labels and we could allow user to re-arrange as they see fit.
I'm not sure if there's an API for this, but if there is, we can add a tab to the "Available Customizations" dialog, which is accessed by the pull-down in the top-right corner of the view. Pulldown -> Customize View... opens a dialog with two tabs currently: Filters (1) and Content (2). We could maybe add a third for content-weight. I do want to point out one of the problems with Common Navigator is just that a few parts of it are rough around the edge and require a slightly better API (or in some cases an API period)... but I'm sure this will be good overall as if we get any good examples we can help drive CNF forward.
Angel: Maybe it'd be better if we got this set up in its own plugin first before changing the current servers view and working my patch into the main servers plugin. That way we can have both views in a few builds at the same time before you're forced to remove it from the regular server's view. There seem to be a lot of good ideas here for additional API restrictions / enhancements and it'd be good to have a place to play with that that's not mucking around with your HEAD (ha! get it? ... ok)
A lot of good ideas, indeed. Call me a control freak, but I like the idea of having my own instance of a view. So if we go with a CNF based approach and anyone can contribute whatever they want, our first commandments should be 'thy shall not show anything but Servers' :). Changing the View's toolbar doesn't conform with eclipse guidelines, as far as I am aware of, so -1 to that idea. For the context menu, I think we can find a common ground for all servers. Without putting too much effort on thinking and I can't think of a different layout than what is already there, so I would suggest to stick(for now) with what is already there: New -> (Sub menu) Open Show In -> ------- Copy Paste Delete Rename -------- set of top level actions for the selected element -------- Properties
Angel: You're not a control freak. I've just been mixing this bug with the "WTP / DTP Collaboration" discussion and not keeping a clean separation between the two. Konstantin: Is there a bugzilla created specifically for the collaboration view, where any service / connection type (server, database, etc) can contribute itself? Or have we all just been trying to 100% steal the Servers view? =] This bug here should be reserved for servertools' own personal conversion to a common-navigator based view (and, as Angel said, contain *only* servers and server-related actions). Most of my previous comments would be more accurately put on this other bug (if it exists yet)
To be clear, I think the scope of this bug is to convert Servers View into a Common Navigator framework and that's all. However, doing so will make it (much) easier for the Servers View to contribute its content to OTHER views (such as the DTP/WTP collab view mentioned) later on... or for adopters to allow further information to go beneath a server that is relevant to that server. So discussion of the universal service / connection / server view should go elsewhere.
I understand that that was the initial scope of this bug, but scopes change which is why this bug got x-referenced in thie discussion. It's important to establish whether we are creating two views or one. One of the outcomes of the review of the Java EE perspective is that it could benefit from reducing the number of views. Consolidation of app servers and database views into a single view was brought up since that's the approach that our competition has adopted a while ago and I haven't heard any stated arguments against that approach. Assuming the combined Servers view is flexible enough to allow the user to tweak it by filtering things out, collapsing categories, re-arranging categories, what would the use case be for dedicated App Servers and Database views? What would be the user profile that would benefit by that? If the Java EE perspective is changed to use the common view, would anyone even use the dedicated App Servers view? Unless we come up with convincing arguments for having separate views, I propose we change the direction of this bug from "converting servers view to use CNF" to "creating common and flexible servers view based on CNF to replace existing servers view".
I understand that that was the initial scope of this bug, but scopes should stay flexible as new requirements come in. This bug bug got x-referenced in the discussion to create a shared view, so here we are. It's important to establish whether we are creating two views or one. One of the outcomes of the review of the Java EE perspective is that it could benefit from reducing the number of views. Consolidation of app servers and database views into a single view was brought up since that's the approach that our competition has adopted a while ago and I haven't heard any stated arguments against that approach. Assuming the combined Servers view is flexible enough to allow the user to tweak it by filtering things out, collapsing categories, re-arranging categories, what would the use case be for dedicated App Servers and Database views? What would be the user profile that would benefit by that? If the Java EE perspective is changed to use the common view, would anyone even use the dedicated App Servers view? Unless we come up with convincing arguments for having separate views, I propose we change the direction of this bug from "converting servers view to use CNF" to "creating common and flexible servers view based on CNF to replace existing servers view".
I think a "one stop shopping" view might be great in e4, but we may want to do baby steps to get there and convert the Servers view to the CNF for 3.5. Ultimately, this would probably come down to PMC votes for each component wanting to contribute to the universal view. But I think there are still cases where we'd only want one type of "server" to be displayed at a time (similar to how the Servers & Database views work today). From a RCP application standpoint, I see the allure of having a single view. But among the many perspectives between WTP & DTP, I doubt that DTP users are going to need to see app servers and whatnot in their view. If WTP wants a universal view that includes WTP+DTP+whatever else, then that's great. DTP will definitely contribute. But forcing the universal view across the board isn't a good option IMHO.
I surely hope that we don't need to wait for e4 to make the improvement of creating a shared view. The point is not to force any project to the common view. The idea is to encourage as many as possible to contribute, but the decision of whether to eliminate any existing views is something that every project has to make on it's own. So there are really two questions: 1. For WTP, if we do create a shared view, does it still make sense to have a dedicated app servers view? 2. For DTP, if we do create a shared view, does it still make sense to have a dedicated databases view? It sounds like you have a usecase with the DTP perspective. I would argue that databases don't exist in isolation, but that's a question to debate on the DTP newsgroup and/or mailing list.
I think we should create a shared view immediately and whoever wants (WTP, DTP) can add to it at their leisure. And they may or may not remove their own dedicated views, also at their leisure. Which is why I think we need a second bug and this is not the appropriate place for this. This specific bug is simply to convert the current servers view into a CNF view. A new bug should be created dedicated to creating and finding a home for a shared view and developing an API for that view for restrictions, context menus, etc. Then, once an API is developed for this shared view (or as its being developed) individual components can begin contributing to the view. And in the longer term, once that view becomes successful and accepted by users, the contributors can begin to phase out their own views. The Package Explorer wasn't removed right after Project Explorer was added. It takes time to make sure the integration works before you start phasing other things out. First and foremost we need a home for a shared view, an API, discussion on restrictions, etc, and this should in no way restrict or impose upon servertools and what they've got going right now. We need a new bug ;)
I still think it's important to settle the question of whether having a dedicated App Servers View is interesting in the long term before we proceed further. If the answer to the above question is no, then I would think it would make more sense to concentrate work directly on the shared view and app server contributions to it. The new view would exist in parallel to the current app servers view (in it's current form). Once the new view is stable, we would add it to the Java EE perspective and remove app servers view from the perspective. The existing app servers view would either be kept for backwards compatibility (seems to be a pattern with other projects) or just removed outright. I guess what I am saying is that the effort put towards re-tooling the existing app servers view to use CNF only make sense is if we have the use cases for a dedicated app servers view going forward (besides backwards compatibility). BTW, the reason that Package Explorer is still used in the Java Perspective has more to do with inter-project politics than technical matters. I hope we can avoid falling into that trap. :)
I couldn't resist making a comment on this even though I'm not really involved in any capacity. First of all, I would like to say that, as a committer, I really hate it when my bugs for a particular task get hijacked for some larger, much longer range task. If I was the one pushing for a shared view, I would condense the conversation within this bug into a wiki page so it is more consumable for people who are just joining the conversation and I would then log a separate bug as requested (but that's just what I would do). In regards to a common server view, I would be interested to know what people think they would be gaining from such a view. I would claim that it certainly will not be usability since a view that is dedicated to a particular task will certainly be more usable then a view that is general to a wider range of tasks. A simple example of this is the use of toolbar and menu items that has been discussed in previous comments. A dedicated view is the easiest way to present a clean set of toolbar and menu items to the user. One could claim that these can all be overcome but it is not clear to me that it can be done in a way that doesn't adversely affect usability. That's not to say that there isn't a benefit to having CNF bindings for different server types. Having CNF bindings for different server types would allow different server types to appear inside a single view when the tasks associated with the servers are similar. In essence, the Project Explorer is designed for the task of managing a local workspace that contains different types of content. I can see that the tasks associated with DTP and WTP may be similar so perhaps there is benefit from having a view share between WTP and DTP. The only way to know for sure would be to sketch out the various scenarios for a shared view to see if a shared view has any benefit from a usability standpoint (i.e. I haven't seen any justification for a shared view other than the desire to have less views). In regards to the statement in comment 35 that the continued existence of the Packages view is political, while that may be part of it, I would also claim it is also related to usability (i.e. switching to the Project Explorer would result in loss of usability). I must admit that I am not a user of the Project Explorer. However, I am going to give it a try simply because of you statement. So far, in the 10 minutes I've used it, I've encountered what I consider a bug switching the view into Working Set mode (i.e. required a separate step of enabling working sets before it worked) and have also noticed that there are two menus that deal with Flat vs. Hierarchical display: one for Folder and one for Packages. The two items are in different places in the View menu and, as far as I can tell, the Folder Presentation doesn't work but it is also possible that it does work but is just not relevant to the task of working with Java projects.
> I couldn't resist making a comment on this even though I'm not really involved > in any capacity. First of all, I would like to say that, as a committer, I > really hate it when my bugs for a particular task get hijacked for some > larger, much longer range task. If I was the one pushing for a shared view, I > would condense the conversation within this bug into a wiki page so it is more > consumable for people who are just joining the conversation and I would then > log a separate bug as requested (but that's just what I would do). Not that simple. The ultimate question that needs answering is whether the original reason for this bug still makes sense in the context of a common servers view. If it doesn't (my position), then I see little sense in creating a new bug since this one would just get closed as Won't Fix and it has a lot of interesting content. > In regards to a common server view, I would be interested to know what people > think they would be gaining from such a view. I would claim that it certainly > will not be usability since a view that is dedicated to a particular task will > certainly be more usable then a view that is general to a wider range of > tasks. Actually, improving usability is the ultimate goal. You have considered only one aspect of usability. Consider these as well: 1. Most development efforts span many tool sets. Consider a web app developer who stores app data in a database and works in a team environment where app source is stored in CVS. That's three separate views that user has to find place for on their screen. Since everything can't fit at once, you start stacking views on top of each other. Less is visible when you need it. Usability drops. Eclipse approach to managing the massive amounts of views is perspectives, but the usability of perspectives is a hotly debated topic in many UX circles. The user behavior studies that I've seen have shown that users don't typically switch back-n-forth between perspectives. The more typical behavior is to start with the perspectives that best represents the current needs and modify it as you go along. 2. It is very typical to have one app server, one database, one source control server, etc. The point here is that in real user scenario, these individual views are sparsely populated and screen real-estate taken up by these views when they are on top is under-utilized. 3. A common servers view provides consistent user experience and leverages the knowledge user has accumulated as they move to new tool kits in Eclipse. If one day, the developer needs to switch from CVS to SVN, they already know how to setup an SVN connection. No need to hunt for another view or learn how that view works. The general problem of leveraging user's existing knowledge is one of the reasons why IDEs took off in the first place. So, while I wouldn't argue that it is hard for a general-purpose view to match the usability of UI built for a specific task, we can certainly come close enough and once you consider the complete usability picture, the improvement to user experience is pretty dramatic. I believe that better usability is the primary reason that most of Eclipse competitors have been using combined Servers / Services views for quite a while now. The primary reason that we have so many separate views at Eclipse has more to do with how difficult it is for projects to collaborate on a shared view rather than an actual belief that usability of shared views is better.
I think I see a "if we are doing this we might as well do this other change" effect. There is two similar but different requests on this bug and I would like to keep them separate. Enhancement #1 (and also original enhancement request) Moving the current 'Servers view' to comply with CNF, should be seen as a single enhancement request from an adopter. Enhancement #2 Creating/moving the "Servers view" to a new plugin so that it can extended by other projects, such as DTP. As a committer to the current 'Servers view', I would like to narrow down the focus of this bug to the changes required to make the current 'Server view' comply with CNF. Both enhancement (#1 and #2) should not be mixed, as we could potentially be holding improvements that an adopter might be waiting for. I don't want to make any adopters wait for enhancement #1, but if the originator (or anyone CCed) is not in need of a CNF 'Server view', then I suggest we close this bug as 'Won't fix' and open new one to continue the discussion of the new common 'Servers view' (also based on CNF). In addition, Michael makes a very important point. For easier consumption of the proposed common WTP/DTP Servers view we should create a wiki and summaries the discussion for the common WTP/DTP Servers view. So to summaries: - This bug will concentrate on changes required to make the current 'Servers viw' CNF compliant. - In the event that NO adopter is in need of this CNF changes, I will close this bug as 'Won't fix' and move this request to a the wiki of the proposed common WTP/DTP Servers view. - A wiki should be created so that we can capture all the requirements for the proposed common WTP/DTP Servers view.
> I think I see a "if we are doing this we might as well do this other change" > effect. Not quite. I was attempting to get us talking about use cases. We ended up talking about process instead. Too bad. If we don't understand and agree on the use cases before proceeding on either one of these enhancements, then there is risk that unnecessary work happens and/or that the broader enhancement that would bring bigger benefit doesn't get attention. In any case, I see that it's pointless to keep debating this point. I opened another enhancement request to track common servers view. A wiki is not well-suited for this stage in the process as it works better for documenting what has already been designed rather than discussing what should be built. Bug 252239 formally tracks the Common Servers View.
Angel: I was wondering how integration of my patch was going and if / when it would be scheduled. Any concerns you have feel free to share.
Working away.. I got a little side tracked with the whole Common View proposal.. but I am back into it. My intention is to get it into M3.
just a note: Make sure in ServerContentProvider.dispose() you remove all listeners. Otherwise, if the user closes the view and opens it again, the decorator thread will fail to launch (as currently coded, unless you've changed it).
I will keep this one in mind.
Ops.. this bug was targeting 3.0M3 and not 3.1M3. I didn't realize that 3.1M3 was coming to an end. I will retarget this one to 3.1M4, and check in the changes as soon that I have as soon as M4 is open.
Created attachment 116849 [details] v0.1 I made some modification to the labels, and to ensure that the action menu shows up when there is no selection.
Code released into 3.1M4.
I haven't completed all the changes that I wanted for the new Servers view. Once M4 is done I will be closing this bug and consider any further bugs, new bugs. Which will require a new bugzilla. Until then we will be using this bug to track changes and missing behaviour from the current proposed view. New bugs found during the smoke test build: .1- In the "Show View" dialog there is no description given to the Servers view .2- When hovering over the title of the view "Servers (proposed)" there is an error in the tooltip being displayed "Error: no label provider for R/" .3- The State and Status do not show by default .4- The default filter provide doesn't follow Eclipse guidelines (is working opposite to the guidelines: when the filter is enabled the content that is supposed to be hidden is showing. .5 The state "starting..." doesn't look pretty due to the animation. This text should be replaced with a static 'non animated' text and the animation should be transferred to an Icon. .6- Double clicking on the Server opens the editor, and collapses the node. .7- The Sync button doesn't do anything
I have resolved most of the items that I pointed out in my previous comment. But there is still things left that we will work as bugs, a separate bug will be open for each of this item. > .5- We have switched the icon that each server shows to use the old 'State' icon as this one had already the animation built in. > .7- The Sync button should be hidden until an adopter implement/extend its functionality. > .8- Code cleanup
*** Bug 222588 has been marked as a duplicate of this bug. ***
(In reply to comment #49) This is an Invalid comment, please ignore.
*** Bug 247934 has been marked as a duplicate of this bug. ***
New Gerrit change created: https://git.eclipse.org/r/108707
New Gerrit change created: https://git.eclipse.org/r/108705
New Gerrit change created: https://git.eclipse.org/r/108702
