Community
Participate
Working Groups
This is originally an Eclipse Project proposal, but initial discussion showed that it might be a good fit to integrate directly into Debug... :) We have (at SSI Schaefer) some IDE extensions that we want to open to the public, and one of them is something called Launch Groups. Basically it's something really simple. It introduces a new launch configuration type that allows to add multiple other launch configurations (also groups recursively ;)) into that group. Each launch configuration can be configured with some additional properties to control the behavior of the group when launching (e.g. wait a certain time after launching, wait for specific console output after launching, etc. before the group proceeds to the next launch). This little tool turned out very handy, and we'd like to contribute that code if there is interest. We are aware that there is something similar in CDT already - but CDT is somewhat the wrong direction for Java devs ;) I have no idea whether it would be possible to merge the two, and I'd love to explore possibilities here later on. Please give some feedback, and if positive, I'd prepare an initial contribution to debug on Gerrit (maybe also think about how you'd like to have bundles named, etc.). I'll just need some guidance on how to properly integrate the new bundles (build, features, update sites, ...).
maybe some pictures help understanding what this is about :) [1] https://drive.google.com/open?id=0B05h8C3gLt38OG0xbVROTzZpcEU [2] https://drive.google.com/open?id=0B05h8C3gLt38VC1rM281bGpIaGM
I'm fine pursuing this, but we definitely need to get CDT on board. See also bug 221141 for another understanding of launch groups.
Yes, the CDT already has the same concept. I don't have much experience with it though. I do agree that whatever the end result, it should be in the platform debug.
The intention of cdt launch groups was to move them to platform debug at some point. We just never did it. It does not have any cdt specific code whatsoever. I just don't know about UI part of it. Because now if you pull platform.debug.ui you will automatically get this launch config if we move it there. This is current user docs for it http://help.eclipse.org/mars/index.jsp?topic=%2Forg.eclipse.cdt.debug.application.doc%2Freference%2Fcdt_u_run_dbg_launch_group.htm
Yep, from the looks it's pretty much the same thing - we just never knew about the CDT one (we implemented ours ~5-7 years ago). AFAICT the only thing that's different is that we have the possibility to wait for a certain console output after launching, and CDT has a little bit of a nicer UI. I really don't care which code is the base for the new feature in debug. Somebody decide, and I will try to contribute what's missing for us, or the whole feature from our code base. @CDT guys: is your code somehow coupled to CDT? Ours is currently more or less dependency free. we have: org.eclipse.ui, org.eclipse.core.runtime, org.eclipse.debug.core, org.eclipse.debug.ui, org.eclipse.jdt.launching I'd have to clean up the code a little, and re-brand it, but other than that it would be your's to take :)
I'd be happy to see a merger of the two implemented in the platform debug and get the best of both worlds. Feel free to take what you need of the CDT code. Once it's in the platform, we can remove CDT's. I'm guessing this won't happen until the next Eclipse release next June since we're already into the release candidate cycle for Neon, so we have lots of time.
> org.eclipse.jdt.launching > Cannot use jdt
(In reply to Elena Laskavaia from comment #7) > > org.eclipse.jdt.launching > > > > Cannot use jdt Right, unless that part is in JDT Debug and not referenced/required in Platform Debug.
(In reply to Doug Schaefer from comment #6) > I'd be happy to see a merger of the two implemented in the platform debug > and get the best of both worlds. Feel free to take what you need of the CDT > code. Markus, would you do that work?
(In reply to Elena Laskavaia from comment #7) > > org.eclipse.jdt.launching > > > > Cannot use jdt interesting, it seems it's a dead dependency anyway, now that i wanted to check the reason :D
(In reply to Dani Megert from comment #9) > (In reply to Doug Schaefer from comment #6) > > I'd be happy to see a merger of the two implemented in the platform debug > > and get the best of both worlds. Feel free to take what you need of the CDT > > code. > > Markus, would you do that work? I can at least try. I proposed this a separate project, so there is some time reserved for me working on it. I'll try to come up with something usable :) Could you guys just point me to a) the source of the CDT piece b) to the place where I should put the end-result (naming suggestions?) That way I won't have to search for long and won't run off in completely wrong directions :)
(In reply to Markus Duft from comment #11) > (In reply to Dani Megert from comment #9) > > (In reply to Doug Schaefer from comment #6) > > > I'd be happy to see a merger of the two implemented in the platform debug > > > and get the best of both worlds. Feel free to take what you need of the CDT > > > code. > > > > Markus, would you do that work? > > I can at least try. I proposed this a separate project, so there is some > time reserved for me working on it. I'll try to come up with something > usable :) > > Could you guys just point me to > a) the source of the CDT piece > b) to the place where I should put the end-result (naming suggestions?) How is the feature called in CDT? Also "groups"? If not yet done, the code needs to be split into core and ui parts. It will go into the 'org.eclipse.debug.core' and 'org.eclipse.debug.ui' plug-in, following the usual naming conventions, i.e. we only need to find a suitable sub-package name. But this is really just a refactoring at the end. Nothing to worry too much about.
OK, I'll somehow merge the best of the two. I found at least two tiny things we need that are not there in the CDT version. The CDT version in turn is a lot more compact (may it be good or not ;)) thus easier to put into platform.debug. However BOTH implementations insist on opening MessageDialog's from the actual LaunchDelegate. I would have liked to put the actual delegate into core, and only the UI into ui. How do others handle this? Are delegates allowed to open UI? Should they just throw an Exception?
Ah, I just discovered IStatusHandler. Would that be the correct way to decouple?
(In reply to Markus Duft from comment #14) > Ah, I just discovered IStatusHandler. Would that be the correct way to > decouple? Yes, IStatusHandler can be used.
OK. I'm making some progress already :D I have the CDT version in platform.debug now. I split it up in core and ui, and it works. I'd just have a question to the CDT devs :) Is there any special reason why the group is not using the supplied launch mode but rather memorizes a launch mode per launch element? I do see some possible benefit, but the UI defaults to ignore everything and launch in run mode, which I find suboptimal. If at all, i'd default to using whatever the group is launched with (i.e. if i press debug MyGroup all elements are launched debugable) instead of defaulting to "run" (or whatever - "run" is the current default). Objections? I'd also like to push what I have so far to do a first plausibility check on the code before I start adding fetures from our implementation :) The code is mostly copied and torn apart directly from CDT. Should I push as a draft and invite... whom? Or as a public change?
New Gerrit change created: https://git.eclipse.org/r/72511
You can add me to the review (but I am not platform debug committer). But drafts are waste of time afaik. The it has mode per launch is because sometimes you want associate group mode with individual launch and sometimes you want a static mode. Lets consider client/server and you only care about client. You bind server to always launch in run mode, and you bind client to the parent (group) launch mode. You when you launch this group in debug mode it debugs a client, but not a server. Also since we support ALL configurations, some of them may have modes which is not default (i.e. not run/debug) in this case they only way to launch it properly is to use a launch type specific mode not trying to override with unsupported parent mode (and to do that you need UI to associate in a first place).
Icons can be attached to the bug as an attachment.
Created attachment 261711 [details] proposed launch group icon This is the icon I put in right now - tell me if there are objections.
May I ask for a round of review for the moved code? After this is rather clear (and maybe only waiting for a CQ - necessary? already created?) I would prepare a second commit (or more) that introduces the additional features that are now missing for us.
Thanks Markus, I will be reviewing it shortly. We will need a CQ for this change. I will create the CQ after the review and verification. For CQ I will need following information (can be emailed) - 1. company/institution contributor represents 2. phone number
Markus, I have not looked at the similar CDT implementaion yet, but some quick questions after trying the gerrit patch : 1. How do we create recursive launch groups ? 2. Even in one launch group, the Post launch actions might be different , so what is the basic purpose of grouping them ?
(In reply to Sarika Sinha from comment #23) > Markus, > I have not looked at the similar CDT implementaion yet, but some quick > questions after trying the gerrit patch : Feature wise I tried to leave everything as is. I did change the UI a little bit (mostly cleanup). > 1. How do we create recursive launch groups ? You can add a group to a group. At the moment it is possible to add the group to itself. We probably should filter the group itself from the list. Need to check what can be done there. > 2. Even in one launch group, the Post launch actions might be different , so > what is the basic purpose of grouping them ? You can configure the action per entry in the group, means every item in the group has a distinct action. Did you see something suspicious?
(In reply to Markus Duft from comment #24) Yes, we should filter the same Launch group or any group which contains the same Launch Group. No, nothing suspicious. Thanks for the clarification. I see two differences from CDT Launch groups: 1. Addition of "Inherit" mode - does it mean, mode will change if we change in the original launch configuration ? 2. Removed the check box "Use Default mode when launching" from the Add/Edit dialog.
(In reply to Sarika Sinha from comment #25) > (In reply to Markus Duft from comment #24) > Yes, we should filter the same Launch group or any group which contains the > same Launch Group. > > No, nothing suspicious. Thanks for the clarification. > > I see two differences from CDT Launch groups: > 1. Addition of "Inherit" mode - does it mean, mode will change if we change > in the original launch configuration ? > 2. Removed the check box "Use Default mode when launching" from the Add/Edit > dialog. Both actually deal with the same thing. Both steer what should be happening when i run a group vs. when i debug a group. For the launch groups that our company has, the mode is always "inherit" (i.e. if i run a group all items are run, if i debug a group all items are debugged). This must be the default IMHO to avoid confusion. But i very much like the idea to be able to set certain items in the group to never debug even if i debug the group. Thus the way it is now. In the CDT version I found it confusing to have this split upon two distinct settings. I could configure to debug but please use default mode, which essentially means to ignore what i'm setting ;) I found it much easier to understand if i can choose run, debug or use whatever was chosen.
(In reply to Markus Duft from comment #26) > > Both actually deal with the same thing. Both steer what should be happening > when i run a group vs. when i debug a group. For the launch groups that our > company has, the mode is always "inherit" (i.e. if i run a group all items > are run, if i debug a group all items are debugged). This must be the > default IMHO to avoid confusion. But i very much like the idea to be able to > set certain items in the group to never debug even if i debug the group. > Thus the way it is now. In the CDT version I found it confusing to have this > split upon two distinct settings. I could configure to debug but please use > default mode, which essentially means to ignore what i'm setting ;) I found > it much easier to understand if i can choose run, debug or use whatever was > chosen. It will be good to get views from CDT people for this change(is it ok for them?) and also it will be good to have some mechanism, so that existing Launch groups of CDT works as expected after these changes in Platform Debug.
I agree, CDT folks should have the chance to vote :) Existing CDT groups will for sure not work, as the launch configuration type id changed, thus they will simply not be recognized... The same holds true for our company internal launch groups, since it has a different type id (and format). For us it'd be OK to re-create the groups once to migrate to platform.debug types. How about the CDT users?
Sorry I am not sure what we (CDT) suppose to look at? We need to preserve inherit vs specific mode since its a only way to do what you want (see comment 18). As far as UI goes to select this is a matter of personal preferences.
Yes, the mode selection is as powerful as the CDT version, just a tiny little bit different to use :) Regarding keeping existing launch group configurations alive: it would be rather easy to "migrate" them by changing the type string in the .launch file (using a script or manually). However IMHO it would not be an option to keep a type name with "cdt" in it - it should really be a platform.debug specific type name. So IMHO, the version on Gerrit is still what I would want to get in :)
Yes ID has to change to platform debug one. We are prepared to write a migration delegate (although its sucks that this is not invoked automatically)
I am not sure what you change in UI, can you attach a new screenshot please?
Created attachment 262805 [details] New (slightly refactored) UI Sure. The screenshot show the slightly modified selection. Mode and "default override" are no longer separate as they are mutual exclusive anyhow. This way it is more clear for the user IMHO. Also inherit is the default now, as I feel that this is what is most intuitive (click run and it runs, click debug and it debugs). Tell me what you think :)
While tinkering with it again, i found some small "problems" with "wait for termination". When waiting for termination of the very first launch config, the group will terminate when the first launch terminates (as it is the last alive child). I'll be fixing this one and push another patch set :)
OK, I'm satisfied with the quality of the initial contribution :) Once this is in, I will contribute a few more things from our integration, but apart from a single feature I would already rather use the one from platform.debug now - it's quite cool :)
In CDT the drop down also controlled what launch configs are shown (to be picked). That is why "Use default" was a checkbox. I am not sure if you select inherit what launch config are shown for the user? Because not all launch config are available for any give mode, i.e. run.
(In reply to Elena Laskavaia from comment #36) > In CDT the drop down also controlled what launch configs are shown (to be > picked). That is why "Use default" was a checkbox. > > I am not sure if you select inherit what launch config are shown for the > user? > Because not all launch config are available for any give mode, i.e. run. @Markus, Do you want to respond to this ?
Oh, sorry, i missed your question! (In reply to Elena Laskavaia from comment #36) > In CDT the drop down also controlled what launch configs are shown (to be > picked). That is why "Use default" was a checkbox. Yes, I can understand that motivation, but this also does not make too much sense IMHO. I could tick the checkbox and expect that it will inherit the mode but it will fail at launch time if the mode is not supported. This is the same with the inherit in the drop-down (now). Actually, both ways of doing it can be a little misleading (still I think this is one of the most important features :)). > > I am not sure if you select inherit what launch config are shown for the > user? All are shown. We cannot determine which mode will be chosen by the user in the future, so it is impossible to filter. Still, also with the checkbox you have the exact same problem. The user selects "debug", chooses a launch config, ticks "default" and runs in "profile" mode; potentially this bails out if the config does not support profile. Either way, it is impossible to guard against a flawed selection. Best we could do (that I could imagine) is display a warning. And I'm not sure if this is a good idea... > Because not all launch config are available for any give mode, i.e. run. Yep. See above.
It has been quite a while now again :) Any chance to proceed on this one?
(In reply to Markus Duft from comment #39) > It has been quite a while now again :) Any chance to proceed on this one? We need a go ahead from CDT.
back to inherited mode - in CDT we use it without problems with inherited mode for years, I think its important feature, if we just want to copy what we have in CDT I don't understand why not to copy this one as well. If lc does not support standard modes users should not be picking 'inherit'. Most lc do support all.
(In reply to Elena Laskavaia from comment #41) > back to inherited mode - in CDT we use it without problems with inherited > mode for years, I think its important feature, if we just want to copy what > we have in CDT I don't understand why not to copy this one as well. If lc > does not support standard modes users should not be picking 'inherit'. Most > lc do support all. Yes, but as I said: it is there. It works the same. The /only/ difference is that you /either/ select inherit /or/ another mode. That's just a UX thing that confused me when I used the CDT launch groups - I wanted to "fix" it on the way, make it a version that I find more understandable from a users perspective. Otherwise you can choose a mode that is ignored anyway if inherit is ticked. This way it is more clear that it is either inherit or the others. Does that make sense? If you really insist on the checkbox (which I honestly can't understand ;)), I will put it back in. I'd just really ask you to think about the different possible configuration scenarios and what the user would expect from that. Is there one that I missed?
Ok, I sorry I did not re-read the whole thing, the way it was done the original launch mode was acted as filter on what you see. Since 'inherit' is not a proper mode I am not sure what you will be filtering on. Do you see only 'run' configurations in this case?
(In reply to Elena Laskavaia from comment #43) > Ok, I sorry I did not re-read the whole thing, the way it was done the > original > launch mode was acted as filter on what you see. Since 'inherit' is not a > proper mode I am not sure what you will be filtering on. Do you see only > 'run' configurations in this case? You are right - the filtering is a little bit different now, yet more intuitive I think: Every mode filters as it did before, except 'inherit', which does not filter at all. I think this is perfectly fine, as 'inherit' can not tell you which launch configurations will run in which mode fine. All together I hope for MOST users this is a corner case anyway (?).
(In reply to Markus Duft from comment #44) > (In reply to Elena Laskavaia from comment #43) > > Ok, I sorry I did not re-read the whole thing, the way it was done the > > original > > launch mode was acted as filter on what you see. Since 'inherit' is not a > > proper mode I am not sure what you will be filtering on. Do you see only > > 'run' configurations in this case? > > You are right - the filtering is a little bit different now, yet more > intuitive I think: Every mode filters as it did before, except 'inherit', > which does not filter at all. I think this is perfectly fine, as 'inherit' > can not tell you which launch configurations will run in which mode fine. > All together I hope for MOST users this is a corner case anyway (?). That is perfect then. I already put +1 on review so just up to committer to push it
Created CQ12281 https://dev.eclipse.org/ipzilla/show_bug.cgi?id=12281
@Duft, We will need 2x png and svg file for group_obj image.
(In reply to Sarika Sinha from comment #47) > @Duft, > We will need 2x png and svg file for group_obj image. Phew, that's a tough one :D I don't actually have the sources of this icon anymore, and it vanished somehow in history... Maybe we need a new/different/remade icon for it - is there some official source that such icons should/can come from? Or should I exercise my inkscape skills? :D
(In reply to Markus Duft from comment #48) > Or should I exercise my inkscape skills? :D Adding Matthias Becker, who has demonstrated excellent inkscape skills in the past. :-) @Matthias, could you help with a redraw of the new icon?
(In reply to Sarika Sinha from comment #47) > @Duft, > We will need 2x png and svg file for group_obj image. Is this the icon from the CDS implementation?
(In reply to Matthias Becker from comment #50) > (In reply to Sarika Sinha from comment #47) > > @Duft, > > We will need 2x png and svg file for group_obj image. > > Is this the icon from the CDS implementation? Unfortunately not. It's the one from our implementation - and to be honest, I have no idea where this icon came from. It might have been taken from some Eclipse project in the past, but I cannot tell. Actually I don't really mind if the icon looks completely different. It should just express well, that this is a group of launch configurations. The CDT icon was a little misleading IMHO
CDT icon was pretty random since we don't have any graphic designers, if you can come up with something professional that would be great
CQ is approved, can we get the icon so that it can be delivered for M4 ?
New Gerrit change created: https://git.eclipse.org/r/85738
(In reply to Sarika Sinha from comment #53) > CQ is approved, can we get the icon so that it can be delivered for M4 ? See my gerrit change on the images repo. I have redrawn the PNG as SVG. The green color is slightly different to match the color of all the other "Run" icons in the platform. In addtionn the position and the size of the blue shapes is a bit different as it did allign them on exact pixel borders to make the icons as crisp as possible.
(In reply to Matthias Becker from comment #55) > (In reply to Sarika Sinha from comment #53) > > CQ is approved, can we get the icon so that it can be delivered for M4 ? > > See my gerrit change on the images repo. > I have redrawn the PNG as SVG. The green color is slightly different to > match the color of all the other "Run" icons in the platform. > In addtionn the position and the size of the blue shapes is a bit different > as it did allign them on exact pixel borders to make the icons as crisp as > possible. The icon looks better than ever ;) I have no experience with the SVG icons, etc. - where do I have to put which icon to be OK - or can somebody do it for me? Next time I'll know then :)
(In reply to Markus Duft from comment #56) > The icon looks better than ever ;) > > I have no experience with the SVG icons, etc. - where do I have to put which > icon to be OK - or can somebody do it for me? Next time I'll know then :) Thank you. Just grab the .png and the @2x.png from my change and replace your old icon in the debug ui repo with them. As the name did not change you don't need to change anything in the code. Depending on the screen resolution the platform takes either the "normal" png or the "@2x" png.
(In reply to Matthias Becker from comment #57) > (In reply to Markus Duft from comment #56) > > The icon looks better than ever ;) > > > > I have no experience with the SVG icons, etc. - where do I have to put which > > icon to be OK - or can somebody do it for me? Next time I'll know then :) > > Thank you. > Just grab the .png and the @2x.png from my change and replace your old icon > in the debug ui repo with them. > > As the name did not change you don't need to change anything in the code. > Depending on the screen resolution the platform takes either the "normal" > png or the "@2x" png. Ah, thanks, as easy as that - well then the new patchset is incoming :D
(In reply to Markus Duft from comment #24) > (In reply to Sarika Sinha from comment #23) > > > 1. How do we create recursive launch groups ? > > You can add a group to a group. At the moment it is possible to add the > group to itself. We probably should filter the group itself from the list. > Need to check what can be done there. > > Markus, It still allows to add itself, I thought it was fixed.
(In reply to Sarika Sinha from comment #59) > (In reply to Markus Duft from comment #24) > > (In reply to Sarika Sinha from comment #23) > > > > > 1. How do we create recursive launch groups ? > > > > You can add a group to a group. At the moment it is possible to add the > > group to itself. We probably should filter the group itself from the list. > > Need to check what can be done there. > > > > > Markus, It still allows to add itself, I thought it was fixed. Yes it is still possible. It will tell you that a cycle was detected when you run the group - the original behavior. I'm already planning on some follow up changes improving this commit a little bit, should I change behavior with this or the next commit? Or not change at all (I think it is "good enough" as is, but we can make it even a little more intelligent :D)?
(In reply to Markus Duft from comment #60) > > Yes it is still possible. It will tell you that a cycle was detected when > you run the group - the original behavior. I'm already planning on some > follow up changes improving this commit a little bit, should I change > behavior with this or the next commit? Or not change at all (I think it is > "good enough" as is, but we can make it even a little more intelligent :D)? It will be good to release the changes in one milestone as we don't want the users to be confused. If it is not very taxing, I will go for intelligence !!
(In reply to Sarika Sinha from comment #61) > (In reply to Markus Duft from comment #60) > > > > Yes it is still possible. It will tell you that a cycle was detected when > > you run the group - the original behavior. I'm already planning on some > > follow up changes improving this commit a little bit, should I change > > behavior with this or the next commit? Or not change at all (I think it is > > "good enough" as is, but we can make it even a little more intelligent :D)? > > It will be good to release the changes in one milestone as we don't want the > users to be confused. If it is not very taxing, I will go for intelligence !! OK, I added validation. It is no longer possible to add (or later on change to, by editing) the own group.
I have already had the time to prepare my follow up changes on top of the initial commit: [1] and [2]. I did not wire them to this bug (yet) - should I? They are actually not /really/ related to the initial request, but only additions to it. [1] https://git.eclipse.org/r/#/c/85754/ [2] https://git.eclipse.org/r/#/c/85765/
(In reply to Markus Duft from comment #63) > I have already had the time to prepare my follow up changes on top of the > initial commit: [1] and [2]. I did not wire them to this bug (yet) - should > I? They are actually not /really/ related to the initial request, but only > additions to it. > > [1] https://git.eclipse.org/r/#/c/85754/ > [2] https://git.eclipse.org/r/#/c/85765/ We can create 2 different bugs, We can target them for M5 as well.
(In reply to Sarika Sinha from comment #64) > > We can create 2 different bugs, We can target them for M5 as well. Is it a must to have bugs for it? It's "just additional features" :)
(In reply to Markus Duft from comment #65) > (In reply to Sarika Sinha from comment #64) > > > > We can create 2 different bugs, We can target them for M5 as well. > > Is it a must to have bugs for it? It's "just additional features" :) We are very late in M4, so please create one bug and attach new gerrits to that.
(In reply to Markus Duft from comment #62) > (In reply to Sarika Sinha from comment #61) > > (In reply to Markus Duft from comment #60) > > > > > > Yes it is still possible. It will tell you that a cycle was detected when > > > you run the group - the original behavior. I'm already planning on some > > > follow up changes improving this commit a little bit, should I change > > > behavior with this or the next commit? Or not change at all (I think it is > > > "good enough" as is, but we can make it even a little more intelligent :D)? > > > > It will be good to release the changes in one milestone as we don't want the > > users to be confused. If it is not very taxing, I will go for intelligence !! > > OK, I added validation. It is no longer possible to add (or later on change > to, by editing) the own group. Is it possible to remove the group itself from the Tree rather than showing the message after the selection ?
(In reply to Sarika Sinha from comment #67) > > Is it possible to remove the group itself from the Tree rather than showing > the message after the selection ? I always tend to say "everything is possible, it's just software" :) It should be, it's just more effort to get the filtering right. I'll take a look.
Gerrit change https://git.eclipse.org/r/72511 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.debug.git/commit/?id=97be8772a897b47a48b2d4b6ef33b46811408b7f
Thanks Markus for all the effort!!! Will need the details to add Help and N&N content. @Lars, Can you help in releasing the images to platform ui ?
Thanks to all of you, who helped (and put considerable effort into this too) :) If you point me to where I can put something (or where to mail it to), I can put together a small N&N.
(In reply to Markus Duft from comment #71) > Thanks to all of you, who helped (and put considerable effort into this too) > :) > > If you point me to where I can put something (or where to mail it to), I can > put together a small N&N. www.eclipse.org/eclipse/news.git You add a gerrit patch for this and I can release it.
(In reply to Sarika Sinha from comment #72) > www.eclipse.org/eclipse/news.git > > You add a gerrit patch for this and I can release it. OK, I will put it there. Is it feasible to review and merge the other two improvement commits before M4? I could include description for them then... The commits are not exactly huge, so...
(In reply to Sarika Sinha from comment #70) > > @Lars, Can you help in releasing the images to platform ui ? Ping !!!
Gerrit change https://git.eclipse.org/r/85738 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.images.git/commit/?id=3bcadc8367013b60c641504042dccf09b566e99b
(In reply to Sarika Sinha from comment #74) > Ping !!! I released the images change.
Please add to the N&N M4.
Thanks Lars!! N&N on the way. Verified using Eclipse SDK Version: Oxygen (4.7) Build id: I20161204-2000
N&N added http://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/commit/?id=32542f5317e363ef746423df26249350f65bfe3c
*** Bug 39900 has been marked as a duplicate of this bug. ***
Thank you for your work on this bug. It's very useful to us.
(In reply to Leo Ufimtsev from comment #81) > Thank you for your work on this bug. It's very useful to us. Thanks Leo. Nice to also get some kudos from time to time :-)
*** Bug 438951 has been marked as a duplicate of this bug. ***
