I thought I understood this when I first
read it ... but have just discovered I did not. So ... am hoping to ask
some clarifying questions, and get some specific help "migrating".
1. When you said upgrade development
environment, I now see you literally meant upgrade development environment.
(I'd assumed you meant "target", even though you did say development
While the reasons why this is required
is an interesting academic question, my urgent question is why do would
our batch "builds" contain a compile error, after upgrading to
pre-req the 02/07 base eclipse?
# 11 Feb 2006 18:23:15
# Eclipse Java Compiler 0.619, pre-3.2.0
milestone-3, Copyright IBM Corp 2000, 2005. All rights reserved.
1. ERROR in /shared/webtools/build-wtp-I/workdir/plugins/org.eclipse.wst.xml.core/src/org/eclipse/wst/xml/core/internal/commentelement/impl/CommentElementConfiguration.java
(at line 176)
The method getDeclaringPluginDescriptor()
is undefined for the type IExtension
To fix these compile errors I assume
we either have to
A. upgrade the PDE Builder that is part
of the Eclipse releng basebuilder plugin? (which is a bit disturbing in
general, but especially that there was no "warning" communicated
about that), or
B. fix code to no longer use the deprecated
2. Assuming an appropriate response
is B. to no longer use the deprecated method getDeclaringPluginDescriptor(),
I have some specific use-cases to verify and request assistance for.
A. A number of our uses are for a pattern
pluginId = extension.getDeclaringPluginDescriptor().getUniqueIdentifier();
Can these be fixed
with a simple change to
pluginId = extension.getNamespace(); ?
While we might be able
to replace some of these patterns, eventually, with bundle.loadClass(classname),
I do not think we can in all cases.
For example, I think in
some cases, we really need the classloader, for example, to "give"
it to Xerces framework so it knows what classloader to use.
So, how can we now get
the plugin's classloader?
Is that equivalent
Thanks in advance for your help,
Oleg Besedin <obesedin@xxxxxxxxxx> Sent by: eclipse-dev-bounces@xxxxxxxxxxx
02/03/2006 02:20 PM
Please respond to
"General development mailing list of the Eclipse project." <eclipse-dev@xxxxxxxxxxx>
[eclipse-dev] heads-up on the upcoming
change in the Eclipse registry
Please ignore this message unless one the following applies to your code:
your code is using IExtension.getDeclaringPluginDescriptor()
you adopted org.eclipse.equinox.registry.*
interfaces introduced in M4
In M4 we refactored Eclipse registry in a stand-alone module. As a part
of the process, new registry interfaces were created in the org.eclipse.equinox.registry
package. Due to the complications in insuring backward compatibility, we
are now forced to revert the package name (i.e., rename the org.eclipse.equinox.registry
package to org.eclipse.core.runtime). However be reassured that all the
new APIs and the facility to create your own registries have been kept
around. Further, the registry functionality is still in the new org.eclipse.equinox.registry
At present we are in the process of finalizing the changes and expect updated
code to be available in the next I-build (February 7).
If your code is using IExtension.getDeclaringPluginDescriptor()
Make sure you use the new I-build for
the development. In the current build the error message "The method
getDeclaringPluginDescriptor() is undefined" will show up. (In the
next I-build PDE has been updated to address this issue)
Note that getDeclaringPluginDescriptor()
methods are deprecated
The change does not affect binary backward
If you adopted org.eclipse.equinox.registry.*
methods introduced in M4:
Make sure you use the new I-build for
Load your code, notice the compilation
Reorganize your imports (imports will
be changed from org.eclipse.equinox.registry.* to org.eclipse.core.runtime.*)
Oleg Besedin _______________________________________________
eclipse-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit