Community
Participate
Working Groups
With the Eclipse 3.0 RC2 (06/11) driver, when running the runtime workbench, the "Clear configuration area before launching" checkbox under the Configuration tab is off by default (it was on by default for previous drivers). So for the unsuspecting user, if they add a new package to the workspace, for example, it would not be picked up when they run the runtime workbench and this would result in error when that they try to call that class. I think that checkbox should be set back to on by default (because the novice user might not know that's the place to change). For the more advance user, if they know about this checkbox and want to get the performance improvement of runtimne workbench startup, they could check it on manually.
Checking the "Clear configuration area" by default would be a horrible default for more than one reason: 1. The configuration tab is for advanced users only. That is why, it is placed fourth. Therefore, unsuspecting novice, or any users for that matter who don't care about configuration, should not pay the penalty of a hefty startup time, because of something that is unbenownst to them that is PDE doing implicitly behind their back. 2. The configuration area not only contains runtime cache, but users can also save preferences in the configuration area. We have seen examples where people were puzzled for days why their preferences were being wiped out from one invocation to the next. 3. As a general good application behavior, things should not be deleted by default. When we're speaking about the launcher, the option to clear the workspace data is also turned off by default, so we should be consistent with this sensible behavior. So, this request is never going to happen. As for >"if they add a new package to the workspace, for >example, it would not be picked up when they run the runtime workbench and >this would result in error when that they try to call that class." I'm not sure what you need by package. maybe you meant plugin? If so, this should/would never happen. If it does, then it would be a serious bug and please open a separate bug report with a reproducible scenario.
"I'm not sure what you need by package" should have read: "I'm not sure what you mean by package"
The scenario that failed was the following: 1. I resynchronized with CVS and a new Java package with 2 classes were introduced in one of the plugins that's in the workspace. 2. I launched the runtime workbench with the default using the Eclipse3.0RC2 driver (i.e. clear config area check box is off). 3. When I run our wizard which calls that class XXX, I got the error: "Unhandled event for XXX" 4. If I tried launching the runtime-workbench again with "Clear configuration area before launching" checked, the runtime-workbench takes longer to start up but the "Unhandled event" error does not happen anymore. The above made me think that not checking "Clear configuration area" would cause new Java packages to not be picked up. If that's not the case, this might just be a bug that should be fixed. Would other changes in the workspace, e.g. changing target platform, adding/removing plugins, changing plugin.xml be respected when that check-box is off? If so, then I understand your argument about leaving "Clear configuration area" uncheck as default. I am just concern that if certain changes in the workspace is not respected when that check box is off, the novice user would be left to puzzle over what went wrong. Then my second question is, what does that check box really do and when should the user have it on (and suffer the performance penalty)?
>Would other changes in the workspace, e.g. changing target platform, >adding/removing plugins, changing plugin.xml be respected when that check-box >is off? Yes. This is the expected behavior. >what does that check box really do? It clears the configuration area, all preferences stored in it, all runtime cache and all other data cached by other plugins. >when should the user have it on (and suffer the performance penalty)? To the average user, NEVER. If you're a developer whose code writes to the config area and every once in a while you need to clear what you write, then you could use it for that purpose. Please try your scenario that fails again. This time, after it fails, do not check the "Clear config area" button. Instead, add "-clean" to the Program arguments field on the first tab of the launcher. If the problem goes away on the launch that has the clean arg, then this is a runtime caching issue. In which case, we'll reopen and move it to that component.
Further to Wassim's comment 4, Eclipse keeps several caches of information in the configuration area. Under normal operation, these caches are updated as the result of various API calls (e.g., installBundle(), ...). In a development scenario, developers need to change code and plugin definitions in the development environment and then run. What we are dealing with here is the trade off between speed of startup for the target and simplicity for the developer. - checking the clear box just deletes the configuration area (period). This wipes out ALL configuration data -- caches, preferences, ... Startup is slower as all this information must be reconstructed. - using -clean does a surgical deletion of runtime caches (and whatever else other plugins choose to do when -clean is specified). This typically retains configuration preferences and so call "user" data in the configuration area. Startup is again slower because the runtime cache information must be rebuilt. - using -dev (added automatically by PDE to specify the class path additions) causes the runtime to "check" its caches for consistency and discard anything found to be stale. Startup time is slower depending on how much is found to be stale. So, why doesn't -dev just fix all the problems? Well, because the cost of checking ALL of the data that goes into the caches is prohibitive. The mechanism would have to maintain and scan timestamps for all the packages in each plugin as well as the plugin.xml and associated files. It is computing this information (for the generation of the manifest.mf files) that causes the startup time to be slower when running with -clean or the check box checked. In a sense this situation is temporary. As we move forward we expect more an more plugins to have manifest.mf files. As such, the runtime will not need to generate them, they will not get out of sync and all of this becomes moot. We are not there yet in terms of the plugins or the tooling.
Jeff, if adding a new package to the plugin causes problems upon restart, then 1. I'm surprised this problem has not bee hit yet. Maybe because Eclipse developers are creating new classes in their old packages and not creating new ones. 2. This is a simple self-hosting scenario that we can't let slide for 3.0 at a time when most users don't have a manifest.mf. We have to do something, but I'm not sure why. I think we both agree that PDE implicitly adding -clean to the program args should be a last resort, which is looking attractive to me all of a sudden.
I found another similar scenario that's broken when I do not specify "-clean" or check "Clear Configuration area": I moved a preference page extension from the plugin.xml of Plugin X to Plugin Y: <page name="%PREFERENCE_CATEGORY_PROJECT_TOPOLOGY" category="com.ibm.etools.webservice.ui.preferences.name" class="com.ibm.etools.webservice.ui.preferences.ProjectTopologyPreferencePage" id="com.ibm.etools.webservice.ui.preferences.ProjectTopologyPreferencePage"> </page> I also moved the string PREFERENCE_CATEGORY_PROJECT_TOPOLOGY from the plugin.properties of Plugin X to Plugin Y. When I launched the runtime-workbench with the default ("Clear Configuration Area" set to off), I got "PREFERENCE_CATEGORY_PROJECT_TOPOLOGY" where I expected the label for the prefence to show up. I then rerun the scenario but put "-clean" in the program argument field. This time, the string that had moved from one plugin.properties to another is showing up properly. This might be yet another scenario that should work and just need to get fix. I'm getting more concern of what kind of changes in the workspace is not getting picked up when "Clear Configuration Area" is set to off. I would recommend more thorough testing with common self-hosting scenarios (e.g. adding/removing plugins, changing plugin dependencies, adding/removing extensions points and extensions, adding/removing packages, to name a few) to make sure that the changes the users made in the workspace is being taken into account when launching runtime-workbench with "Clear configuration area" set to off by default (which is a change of behaviour from previous releases). Then a decision can be made to whether to change the default or not.
Jeff, I share Kathy's concern. Maybe there are a whole bunch of problems that were not exposed when the default was to clear the configuration. and now they are. If it's too prohibitive for the runtime to invest in determining when/what to recompute/clear during self-hosting scenarios, then the only option might be to add -clean to the program args. This will slow performance, but will not delete any config area preferences etc., and more importantly, self-hosting will go back to normal.
This is not expected and we cannot reproduce the problem. I verified that when moving an extension from one plugin to another when using a stock launch config and not clearing the config area, both the source and destination plugins are removed from the state by the framework. When the ExtensionRegistry comes up it notices that its cache is out of sync with the state (since things were rmoved from the state) so the cache is tossed. The update configurator then notices that the two plugins should be installed but are not and installs them. This results in the two plugins being added to the registry and their plugin.xml files being parsed. On parsing we agressively translate the plugin.xml %foo values reading directly from the plugin.properties files. Can you see anything in here that does not match your scenario? Question: I noticed in comment 7 the string you see in the UI is not noted as starting with '%'. In the case that a key is not found in the properties file it appears that the "translated" value returned does have a % as the first char. Is this just a typo or are you really not seeing the leading %. Speaking to the more general issue of when to use -clean etc, yes, this is a challenge. The change to not clearing the config area is very recent and was a surprise to us. There are very real performance benefits to doing this but it pushes to the fore the issues of cache consistency. Converting the plugins every time is fine for small to modest targets but as we have seen with other bug reports, if the target has 500+ plugins, this is laborious and wasteful. The summary: - the option should turned ON by default (i.e., the configuration area should be cleared for every run). This is slower but more correct. - There should be a tip/trick describing how/why/when to change the setting. - going forward PDE should manage the generated manifest so that only one copy of the manifest is generated (as opposed to the current one per plugin per launch configuration) - PDE can generate the manifests for the target or binary plugins and cache them as they will not change - PDE can monitor changes to the code an either agressively regen the manifests or simply mark them as dirty (i.e., delete them from the central cache) as things change. - The net effect of these PDE changes is that running with the check box off becomes safer as the manifests are correctly regen'd when code changes occur. Moving to PDE for consideration. As I noted above, we are unable to reproduce the problem identified in comment 7. Please open a separate bug in Equinox if you can identify problems with our steps or if you can supply plugins and steps which demonstrate the problem.
>the option should turned ON by default (i.e., the configuration area should >be cleared for every run). This is slower but more correct. Jeff, I don't see this one happening because, as I pointed out before, this will clear the whole configuration area including preferences, without the user knowing. This is not a hyothetical scenario, we have seen people puzzled as to what happened to the preferences. What I can see happening, and I do prefer at this point, is upon the creation of a new launch configuration, when we initialized the program args with -ws, - os, etc., we also add -clean. This is more surgical, will only affect startup time for the user, but will not compromise the self-hosting experience in any way. If adding -clean on the program args field of the launch configurtaion solves the caching issues that we have seen, then please give it a +1 for RC3.
+1 for -clean automatically inserted on the args line. +1 for a tip/trick entry to describe how people with large targets can improve launch performance.
One other thing for Kathy, is it possible that the plugins you are talking about have MANIFEST.MF files in them?
>Question: I noticed in comment 7 the string you see in the UI is not noted as >starting with '%'. In the case that a key is not found in the properties file >it appears that the "translated" value returned does have a % as the first >char. Is this just a typo or are you really not seeing the leading %. Yes, I see %XXX being the untranslated values. I just imply you guys know what I mean by just the key showing up, the the translated string. >One other thing for Kathy, is it possible that the plugins you are talking >about have MANIFEST.MF files in them? No. My plugins do not have MANIFEST.MF in them. Actually, I tried to isolate the problem with plugin.properties changes not being picked up a bit more, it can be reproduced as a simple scenario as: 1. Change a string in the plugin.properties from X to Y. 2. Launch the runtime-workbench with "Clear Configuration Area" set to the default of off and DO NOT specify "-clean". 3. When you go to a label (in my case a preference string), it's still showing X when I expected it to have changed to Y. 4. Exit runtime-workbench. 5. Relaunch runtime-workbench with "-clean" in program argument. 6. Now I see the string properly showing Y.
This is the build id of the Eclipse3.0RC2 (06/11) driver I was using: Version: 3.0.0 Build id: 200406111814
Done. -clean is now added to the Program args field for every new runtime workbench/PDE Junit launch configuration or shortcut. If the target platform is 2.x based, then no -clean is added. Will add a section to the Tips and Tricks section during documentation week.
Re comment 14, if you are just changing a properties file then yes, the change will NOT be picked up. This is different from the original case where you changed the plugin.xml and plugin.properties files for the two plugins at the same time. Again, this is a matter of caching and checking. The registry is highly cached. We could consider when running in with -dev letting this imply eclipse.noRegistryCache=true (aka -noRegistryCache) as well as osgi.checkConfiguration=true or something similar. This starts to get into -clean territory in that rebuilding the registry is a real cost (you have to parse all the plugin.xml files and link the structures). The overhead of maintaining the informatoin needed to do the cache coherence checking ALL the time and then actually doing the checking is some of the time is likely not worth the effort. I will talk around the above idea for tossing the registry cache if in dev mode. As mentioned before, there are many opportunities for PDE to monitor and maintain state such that we get both correctness and quick launches (or at least that launch delays are proportional to the amount of change done).
Verified.
