Community
Participate
Working Groups
Currently when needing to use a classpath variable or container initializer, it only looks in plugins that already have been activated. This is a problem. If there is a variable or container in the classpath, but the user has not somehow figured out how to active that plugin on their own (which is actually a difficult thing to figure out), the initializer will not be called, and the variable/container will be invalid! On a similiar vein, I think that if there is a classpath variable initializer for a variable, that initializer should be called once per session, like it does for containers, and not only once per workspace lifetime to set the variable. If the plugin decides it needs a classpath variable, it may need to have a different value for that session. For example there may of been an updated plugin installed and it wants to use a new jar in the variable. Currently it can't do that because the initializer will only be called once. If an update occurs the variable is already set and won't be changed. Thanks, Rich Kulp
Just to be clear, I meant it should activate the plugin only if there is an initializer for the desired variable/container in that plugin. I didn't mean to imply activate all of the plugins with initializer extension points and then search for an initializer.
Variable values are cached in between session, thus it will not request an extension point call to awake the plug-in owning the variable, if it was bound previously. This was meant to avoid eager plug-in loading. However, this causes problem in case the plug-in owning the variable would need to bind the variable differently that in the past, as you correctly stated it. We may want to revisit this behavior. For containers, we do not persist container values in between sessions, so each time a container needs to be resolved, its registered initializer is activated; no matter if its declaring plug-in is already loaded or not. What makes you think we do not find all registered initializers ? Do you have steps to reproduce the problem ?
I have Eclipse 2.0.1: This is the code itself, which shows that it only looks in plugins that are already activated: JavaCore.getClasspathVariableInitializer(String variable){ ... IPluginDescriptor plugin = extension.getDeclaringPluginDescriptor(); if (plugin.isPluginActivated()) { ... And the same test is made in JavaCore.getClasspathVariableInitializer(String variable); So it only looks at initializers that are in plugins that are already activated.
You are completely right, will change this asap. Will also likely remove registered variables value caching (in between sessions) as well.
Actually, the plugin is the one defining the extension point (i.e. jdtcore) so it is always activated at this point. So if "(plugin.isPluginActivated())" was always true.
Thanks Jerome for pointing this out. This being said, we still have the issue about persisted CP variable values taking precedence over registered initializers, and we are going to change it. Richard - Do you confirm that this is the only offending behavior you are seeing ?
I got confused, I saw extension.getDeclaringPluginDescriptor() inside the loop, so on a quick glance I thought it was for extensions[i], the current extension, which would be for different plugins. In the position that piece of code is at it is an invarient, it never changes during the loop. It should probably be removed since it is always true. Sounds good about not caching, but removing caching can only be done on variables that have initializers. Those that don't were created in some other way, such as by the user, and should still be cached.
Of course <g>, and we removed the unnecessary activation check as well. The new behavior, wrt caching, is to only consider persisted values for variables which have no registered initializer. This means that even if at some a variable had one, its last value will be preserved if it ends up on a platform where no such initializer is available anymore.
Then I'm satisfied that my requirements will be met. Thanks, Rich
*** Bug 24233 has been marked as a duplicate of this bug. ***
Verified.
