Community
Participate
Working Groups
Created attachment 131698 [details] Patch for default behaviour of "Validate" Personally I would find it much better if the default for a run configuration would have the flag "Validate plug-in automatically prio to launching" set. I believe the performance overhead is minimal and this would help to prevent lots and lots of stupid errors. Patch attached.
I'm mixed on this as it comes up frequently. In the past, we have not had this as the default because if you have a large target (think of a large IBM RAD-like product), launching would take significantly longer. However, in most cases, I don't think this is a problem. We should revisit this in 3.6
Chris: I also think is is easier for the expert who develops RAD-like products to turn it off then for the new developer starter to find this setting and to turn it on.
(In reply to comment #2) > Chris: I also think is is easier for the expert who develops RAD-like products > to turn it off then for the new developer starter to find this setting and to > turn it on. That assumes you have experts building on top of RAD-like products which isn't always the case :) First impressions are important, when self-hosting is really slow it leaves a bad taste in people's mouth. It's just something we have to balance.
(In reply to comment #0) > Created an attachment (id=131698) [details] > Patch for default behaviour of "Validate" > > Personally I would find it much better if the default for a run configuration > would have the flag "Validate plug-in automatically prio to launching" set. > > I believe the performance overhead is minimal and this would help to prevent > lots and lots of stupid errors. > > Patch attached. > I agree. How about some sort of visual cue somewhere to indicate the state of the option w/o digging through windows? Of course, then there is the risk of visual clutter, as people add their favorite problematic option for display. -m
Removing M2 milestone
@Curtis: I believe this bug is similar to https://bugs.eclipse.org/bugs/show_bug.cgi?id=284704 Do you have an opinion on this proposed change?
(In reply to comment #6) > Do you have an opinion on this proposed change? My vote would be against this change. My target and workspace included a large number of bundles which may not validate correctly but do not affect my self hosting scenarios. For example, if I validate one of my current launch configs it fails because of a p2 testing bundle that I do not directly interact with. I know RCP developers are much more interested in the feature because they are far more careful when crafting targets. My targets may include far more bundles than I am actually using/extending.
Good point. Thanks for the explanation.
Removing milestone.
I agree with this bug. Comment 7 is about a more experienced setup in which it's simple to disable the option. For normal users it's better to warn by default like we do when there are e.g. open files. Optionally, the dialog that reports validation issues could have a "Don't validate again" checkbox which would then uncheck the option in the launch config.
I personally also would like to see this change (I mainly do RCP development).
(In reply to comment #10) > Optionally, the dialog that reports validation issues could have a "Don't > validate again" checkbox which would then uncheck the option in the launch > config. I will support this enhancement if this is added.
I concur with Chris.
Some notes for this change (additional flag): Requires adjustment of PluginStatusDialog from package org.eclipse.pde.internal.ui.launcher and of method handleValidate() from AbstractLauncherTab
Update: I adjusted the dialog and is this dialog is called via the "Validate Plug-ins" button I update also the launch configuration The Dialog is also used in displayValidationError of PluginValidationStatusHandler. Does anyone have a tip how can I update the launch configuration from displayValidationError?
Created attachment 154623 [details] PluginStatusDialog_patch.txt This is the first attempt to bring this field on the dialog.
Created attachment 154624 [details] AbstractPluginBlock patch This will get the selection from the dialog and update the launch configuration if you are in the launch configuration dialog.
The update of the launch configuration during "normal" launch of the application is not included in the patches. Not sure how to do this, see comment 15.
there are pros and cons. I would offer the following: - let it turned off because of the performance issue but then - the stack trace/exception should give a hint that you should turn on the option temporarily or resolve the dependencies and then turn it off again. it that possible ? I think it is especially important that it works with and inital setup as it is a bit frustrating for a user if he gets an application launch error always or often in the first place ;-)
Removing milestone as feature freeze has passed.
This should get fixed.
Would be great to have this in Eclipse 4.2. I deliver frequently Eclipse plug-in and RCP trainings and this is the number one issue new people face and get frustrated about.
(In reply to comment #22) > Would be great to have this in Eclipse 4.2. > > I deliver frequently Eclipse plug-in and RCP trainings and this is the number > one issue new people face and get frustrated about. I looked at the patches. - Depending on the JRE, one has always validation issues when starting an 'Eclipse Application' (the SDK in my case). Hence, people might want to have validation disabled when creating new launch configs. - The change in the dialog is not needed (people can read the launch config dialog). - When launching, the validation dialog must have a checkbox: [ ] Do not show this dialog again (see comment 10). - The validation dialog needs better wording. It's not 100% clear what happens when I click 'OK'. I know, it's not directly related to this RFE, but if the dialog is seen more often, it also needs more love ;-). We should add a preference to the 'Plug-in Development' preference page and use that one when creating a new launch config. The launch dialog should have a link that points to the preference. Some comments mentioned a performance impact without providing any data. We have to measure the performance impact in order to decide whether it will be OK to enable the new preference by default. Lars, I'm willing to accept a patch implementing the above comments and review it for 3.8.
@Dani: You increasing the scope of this request. ;-) I personally think an additional preference would be overdesign. Eclipse is already full of settings which normal user never see / change. The expert will not create new launch configs every day. Are you ok with a patch without the preference setting? If yes, what would be the timeline for this?
(In reply to comment #24) > @Dani: You increasing the scope of this request. ;-) > > I personally think an additional preference would be overdesign. Eclipse is > already full of settings which normal user never see / change. The expert will > not create new launch configs every day. > > Are you ok with a patch without the preference setting? It depends on the performance numbers/impact. > If yes, what would be the timeline for this? Since no API is involved we can target M7.
@Dani: sounds good, thanks. I try to draft something up in the next weeks. What would be your proposed way to measuring the performance impact?
(In reply to comment #26) > @Dani: sounds good, thanks. I try to draft something up in the next weeks. > > What would be your proposed way to measuring the performance impact? I would create an 'Eclipse Application' launch config that starts the SDK and measure inside LaunchPluginValidator. I suspect that the performance hit will be small.
(In reply to comment #27) > I would create an 'Eclipse Application' launch config that starts the SDK and > measure inside LaunchPluginValidator. I suspect that the performance hit will > be small. If you happen to have a larger target platform to test against I would also compare performance of that launch. Our launcher (and launch config tab) performance is typically only a noticeable issue when starting >1000 plug-ins. The performance of the dependency validator is probably O(n^2). If we don't have a preference, should we consider turning off validate before launch for new JUnit Plug-in launch configs? It's more common for me to create new launch configs to run a certain subset of tests.
> If we don't have a preference, should we consider turning off validate before > launch for new JUnit Plug-in launch configs? I'd say no. I don't want to introduce different behavior for normal and test runs.
My current schedule is really tight. I might not be able to deliver a patch for this release.
With the recent improvements in the OSGi error messages by Tom Watson, I'm OK with the current behavior. Marking my own bug as WONTFIX.
Reopening this. Enabling this will new starters with platform development and (without yet measuring it), I cannot really tell a difference for this setting for platform UI. Measurements are still planned, just have not been done yet.
New Gerrit change created: https://git.eclipse.org/r/81573
+ 1 for merging this. I´d rather be informed if some plugins would not be started due to missing dependencies. Lots of our customers come accross the problem not having validated their run configurations and therefore missing some plugins during runtime, which leads to a bad user experience! Especially for new users. And in case everything´s resolved the validation doesn´t seem to really harm and it won´t bother the user with a dialog or anything else, but gives feedback when appropriate.
I tested the patch with various workspaces and on my human stopwatch, I cannot note a different in starttime. If there are no objections against this patch, I plan to merge it early next week.
New Gerrit change created: https://git.eclipse.org/r/81792
Gerrit change https://git.eclipse.org/r/81573 was merged to [master]. Commit: http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?id=19c6d8cfc0ee0a07eb9675a97441ceeda8d97d30
Gerrit change https://git.eclipse.org/r/81792 was merged to [master]. Commit: http://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/commit/?id=add257d9e7e0332552eaca89e408fcc9070f73d8
New Gerrit change created: https://git.eclipse.org/r/83182
(In reply to Eclipse Genie from comment #39) > New Gerrit change created: https://git.eclipse.org/r/83182 Please ignore. That was a mistake.
New Gerrit change created: https://git.eclipse.org/r/83867
New Gerrit change created: https://git.eclipse.org/r/83866
New Gerrit change created: https://git.eclipse.org/r/83868
New Gerrit change created: https://git.eclipse.org/r/83869
Gerrit change https://git.eclipse.org/r/83868 was merged to [R4_6_maintenance]. Commit: http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?id=fbb9d01a54426c29e8edbb15ab276d4219e6465e
Gerrit change https://git.eclipse.org/r/83869 was merged to [R4_6_maintenance]. Commit: http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?id=5858922a53d528b980e34ad039ceb7af4b7c45e6
Accidently pushed directly via Git http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?h=R4_6_maintenance&id=d87e3d2e42a35cee9b2eb51340cf99bbeaad211d http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?h=R4_6_maintenance&id=ab5662075d22dccdbe9c3cc7b8189163b0985c34
I think we should wait for its effects ( performance ? ) in 4.7 before hurrying this in 4.6.2.
(In reply to Vikas Chandra from comment #48) > I think we should wait for its effects ( performance ? ) in 4.7 before > hurrying this in 4.6.2. PMC approved to backport.
> PMC approved to backport. Do you have any concrete data of performance impact?
(In reply to Vikas Chandra from comment #50) > > PMC approved to backport. > > Do you have any concrete data of performance impact? I could not note a difference in startup, see https://bugs.eclipse.org/bugs/show_bug.cgi?id=272076#c35. I did not update the data as it was the same plus some random noise by me operating a stop watch.
verified on Version: Neon.2 (4.6.2) Build id: M20161110-0200
Automatic validation doesn't work for the first launch via "Debug As > Eclipse Application", see bug 512528.
