Community
Participate
Working Groups
At present, bundle com.acme can contribute extensions only to its own namespace (i.e. qualified names of all of its extension points will be "com.acme.ABC"). While this is generally seems to be a good practice, this behavior is likely too restrictive in the long run. The specific use case in which this became a problem for me was the "old" bundle that was split into several "new" bundles. To maintain backward compatibility, however, all extensions points had to be left in the "old" bundle - even as they clearly should be declared now by other newly created bundles. I think it would be nice to remove this restriction.
For eRCP we would like to have a smaller org.eclipse.ui plugin that has fewer graphics and only a subset of extension points. However, producing a plugin with the same symbolic name but different content does not seem like a good practice since the two plugins could potentially be confused. The problem is that Extension Points are known by their "plugin symbolic name" + "extension name". Thus, Extensions Points can not be provided by another plugin and still be found.
<extension-point />
Oops, sorry about that - literally lost my internet service for a bit. 'Meant to post: It seems to me that the resolution of this issue is to create a means to gracefully decouple the implicit dependency between an extension-point name and the plugin name. I.E. right now, the 'fully-qualified' name of an extension point is derived using the declaring plugin id. If anything, that seems only necessary as a developer convenience. One solution to me seems to be to modify the schema for <extension-point> slightly. I can think of three options: 1) Add an optional attribute that indicates that the id attribute is fully-qualified already. Example: <extension-point id="com.acme.coolpoint" fully-qualified="true" ... /> 2) Add an optional attribute that allows you to specify the namespace qualifier seperately. If not specified, uses the declaring plugin id. Example: <extension-point id="coolpoint" namespace="com.acme" ... /> 3) Allow a different attribute for specifying the id that is always interpreted as fully-qualified. Example: <extension-point symbolic-name="com.acme.coolpoint" ..../> None of these should break existing stuff. Personnally, I prefer options (2) or (3). To fully address all the issues, it would also be a good thing to start to allow specifying an optional version and match rule attributes in the <extension-point> as well as in the <extension> declarations.
alternatively, we can just remove the restriction that the id attribute be a simple identifier. We currently have checks that look to see if there are '.'s and spank you if you do. Relaxing that should be close to sufficient.
But would just relaxing that constraint result in a fully-qualified specification independent of the declaring plugin? Or would that just result in a fully-qualified ID of "<plugin id>.<my.id.with.dots>" ? Would you just make it implicit that 'if there are periods in the id, then assume it is fully-qualified' ? I don't personally like implicit behavior like that very much. I would much prefer an explicit model.
To me, it seems that Jeff's approach fits better in the picture we have today. There is already an instance where we add namespace to the "simple" name if it doesn't have dots (if extension doesn't provide qualified name for the extension point, the current namespace is added). More importantly, IExtensionPoint has methods getSimpleIdentifier() and getUniqueIdentifier() that internally presume that SimpleId is the portion of the UniqueId after the last "." which contradicts suggestion (1). Internally, we only store UniqueID so there is no advantage to explicitly separating namespace portion of the Id from the "simple" Id (suggestion (2)) - only UniqueID is necessary, but not the way it was formed. Let me rewrite the Jeff's suggestion in a more specific manner: - if extension point ID has no ".", it is assumed that it implicitly belongs the namespace of the provider - if extension point ID has ".", the portion after the last "." is assumed to be a "simple" ID and the rest is the namespace This change should fit will into existing functionality. Logically, at present only "simple" ID can be specified (and it should not contain dots). With this change implemented, it will be possible to specify either a "fully qualified" ID - should you decide to do it. Note, however, that Javadoc for the APIs IExtensionPoint.getSimpleIdentifier() and IExtensionPoint.getUniqueIdentifier() would have to be modified as scope of uniqueness conditions on IDs will be slightly altered (not affecting any practical use cases).
regarding comment #6 ]More importantly, IExtensionPoint has methods getSimpleIdentifier() and ]getUniqueIdentifier() that internally presume that SimpleId is the portion of ]the UniqueId after the last "." which contradicts suggestion (1). I understand that this is what it is doing. But that behavior is purely in the implementation ("internally presume") and is not explicitely part of the API. Functionally, there is no reason that the simple name could not be stored internally separate of the namespace. If it was, that would remove the arbitrariness of the use of the last "." to define the simple name. And if it was, that would not change the api behavior right now in any way. I am mainly advocating that api's should have an explicit, parametrically complete form, even if you also allow forms that result in implicit, default behaviors. Implicit behavior is just plain bad and always bites folks that depend on it. The only thing that is impacted by my suggestion above is that the 'getSimpleIdentifier()' would need to be implemented differently internally (by storing the simple identifier separate of the namespace) _OR_ explicitely defined as only returning the portion of the fully-qualified name to the right of the last "." (even if that is not the complete simple name). Note that from a performance viewpoint, storing the namespace and the simple identifier separately does not really take up more memory, especially if you intern() (pool) the namespace string (in which case it should take less).
Regarding comment #7: The "Implicit behavior is just plain bad" is quite a strong statement. In fact, "implicit behavior" is the way we (humans) think and how pretty much all things are done. What was the last time you specified how CPU registers are used in the a = b + c ? When you are asked to pick up some milk on the way home, is you reaction an example of implicit behavior? (And I hope we are differentiating here the "implicit" and "undocumented" behavior.)
your are right - it was a strong statement. Probably stronger than I meant. To be more specific, I believe API signatures should be as explicit as possible. Yes they should be documented. But even documented behavior should avoid being dependent on contextual nuances that aren't readily specifiable in the parameters. Yes, it is a useful programming convenience to povide an overload that defaults one or more parameters to their most common values, but it should always be possible to express them explicitely and completely. Obviously, I'm not saying you have to break things all the way down to discrete bits in the signature. That would be silly. I don't want to get into a big philosophical debate here, though. I'm just expressing my opinion that explicit, parametrically complete signatures are a good thing.
Just to be clear, the registry API purely reflects the content of XML markup. The nature of that markup is defined in the schema for the plugin manifest file. See http://help.eclipse.org/help31/topic/org.eclipse.platform.doc.isv/reference/misc/plugin_manifest.html In there the id attribute is clearly and explicitly specified to "id - simple id token, unique within this plug-in. The token cannot contain dot (.) or whitespace. " getSimpleIdentifier() is a straigth accessor to the id attribute (from the point of view of the user). getUniqueIdentifier() is a helper function that concatenates the two (from the user point of view). The intenal implementation details are not exposed so the id maybe one or many strings. There does not seem to be any usecase for allowing the result of getSimpleIdentifier() to return a string that includes '.'. As such, we have two similar options for solving the problem at hand. <extnesion id="org.example.foo" > or <extension id="foo" namespace="org.example"> I don;t feel particularly strong about one or the other. Defining the simple id of the element as unambiguously the last element of the potentially dotted id string is bascially equivalent to relative paths in java.io.File. This is widely understood and accepted. Having said that, that apporach may be slightly more prone to misuse where people needlessly spec the fully qualified value in the "id" attribute and then plugin renaming etc is harder. The (weak) premise here is that people are less likely to spec an additional attribute. Now, having said that, the id="org.example.foo" approach would be easier for us to implement and the tooling may well just need to have some checks removed. We should consult with Wassim to see how this kind of change would affect PDE.
I like the story outlined in comment 6 and then repeated in comment 10. No new attributes are necessary. Comment 10 however has typos in it. The <extension> elements should be <extension-point> elements. Once the fully-qualified id approach is implemented, PDE would have to modify its validation of extension points. Right now, we slap you with a warning if the id contains a dot. We will relax it so that if there is a dot, we split the id into two tokens: 1. everything up until the last dot is assumed to be a plug-in id. We would flag it if it denotes a non-existing plug-in 2. everything from the last dot until the dot must be a simple id as per the plugin.dtd. Incidentally, extension point search will have to modified also to account for the new format.
actaully I meant <extension> elements. I was just incomplete wrt the point attribute etc. In any event, both <extension> and <extension-point> elements have id attributes that are affected by this change.
Uncle. I can live with this solution. 'Not what I'd call ideal, and I don't really understand what barriers might be in the way of doing it the way I suggested. However, I am more interested in there being any sort of solution than arguing over the api semantics. However arbitrary it might be, I can live without periods in my simple identifiers. :-)
re: comment#11 You wrote: ] 1. everything up until the last dot is assumed to be a plug-in id. We would ] flag it if it denotes a non-existing plug-in Shouldn't this be: 1. everything up until the last dot is assumed to the extension-registry namespace identifier. This may or may not match an existing plugin id. In other words, remove the requirement that the namespace corresponds to an existing plugin id. To force this to match an existing plugin id would defeat the purpose of this enhancement request. In other words, it should be possible to publish extension points and consume extensions to those points without having to be tied to specific plugins being present in the runtime.
re comment 14. What you are suggesting requires less work for PDE, which I certainly don't mind. But what if you have a typo in the plug-in id? good luck trying to catch it with the naked eye.
Well, I guess that means that in your <extension-point> declaration you will have declared a distinct namespace. :-) This is only a problem when the <extensions> don't line-up because they might not have the same typo in their point="" declarations. But technically right now, couldn't the latter have typos in them so that they don't match a (correctly) declared point -> How do we currently flag that error (Which in terms of N order, is more likely to occur.)? Both situations really just mean one has to have appropriate diagnostic tools available such as easily being able to see in a runtime how many extension contributions there are for each extension-point or that an extension contribution is dangling because there is no matching extension-point.
After some more discussion we decided to do it by using the approach proposed in the comments 4, 6, and 10. The changes on the registry side should be available in a day or two. In addition to the registry changes, some changes on the PDE side will be needed to make this capability fully available: a) New extension point / new extension wizard - make a warning if the "namespace" portion of the Id is not in the workspace. b) plugin.xml editor - same as (a), would need a new warning c) [maybe later?] update registry view - it is going to show a view based on namespace rather than on contributor - may be we could have two views there (one view organized by bundles and another view organized by namespaces)? From my viewpoint, items (a) and (b) would be highly desirable; item (c) would be nice to have, but it can be added later. Note that in this approach (a) and (b) would present warnings, not errors if the referred bundle is not available in the workspace or target. Let me know if you'd like me to create a separate enhancement request(s) for PDE portions.
Thanks Oleg. This all seems reasonable. Once the runtime changes are in HEAD, please open separate bug reports against PDE.
Created attachment 33511 [details] Patch for the org.eclipse.equinox.registry and org.eclipse.core.tests.runtime The patch allows registry to support namespace separation as described in the comments above. The fully qualified IDs are supported for extension points and extensions. On a technical note, a new registry cache table is created and maintained to index registry contents by namespace to facilitate efficient retrieval from the registry. The new table occupies about 6K of the disk space for Eclipse SDK. Performance for the "-clean" startup of the Eclipse SDK decreases by about 1% with this patch. Performance of the warm startup with "Welcome" screen remains unchanged. Performance of the warm startup with the registry viewer open remains unchanged as well. Two new tests are added to the JUnits.
The first thing to notice with this new support is that this scheme no guarantees the uniqueness of extension and extension-point across the registry (for example I can now define in a plug-in P1 an extension "X", and in a plugin P2 an extension named "P1.x"). This may also break the wrong but possible assumptions that some users could have been making regarding the fact that the namespace of an extension / extension-point is the symbolic name of the bundle that contained the xml markup. So one question now is to know whether or not we need a getContributor() API on the registry objects? Reviewing the code I discovered two bugs: - IConfigurationElement.getNamespace() returns the name of the entity that contained the XML. Instead it should return the namespace of the extension that contains it. - The recording of the delta for extension is not done against the correct namespace, nor is the value returned. See ExtensionRegistry.recordChange(XPT, EXT, kind). This particular case will have to be captured in a test case as it is too nasty. Other points: - Contribution.getNamespace() no longer has a meaning. We should remove it. At a first glance all calls seems to be discardable. - RegistryIndex as a classname is confusing. - See we gain anything in creating a common super-class to extension and extension point? - Is it possible to have the code that removes elements from the index of namespaces in symmetrical place to the code that deals with the add. - Make sure that there is no concurrent modification of the registry index / registry index children objects. - Need to see how big the namespace index grows on large configurations
On the subject of getContributor(): this is the area that is not well exposed at present. Currently, it is expected that registry implementers would override RegistryStrategy and provide RegistryStrategy.getNamespace() which is actually expected to return a contributor name based on the contributor Id. Probably, it would be better to start explicitly exposing contributors and keeping a table of {ContributorId, ContributorName} around. We could create a public class RegistryContributor that would have the following public APIs: static RegistryContributor registerContributor(String id, String name) static boolean unregisterContributor(String id) static RegistryContributor findContributor(String id) String getName() If we proceed with this change: - We could make RegistryContributor rather than ContributorId an argument for IExtensionRegistry#addContribution() - We can remove RegistryStrategy#getNamespace() - We provide more logical and complete picture to the non-OSGi users. (Notes: on the implementation side, we will need to add another registry cache table to store RegistryContributors; also, I'd like to clean up the way contributorId and contributorNames are stored by registry elements).
Regarding concerns expressed in the comment #20: 1. No guarantees the uniqueness of extension and extension-point across the registry Yes, that's true. I would like to add that, strictly speaking, that is the same situation that we have today - uniqueness of IDs for the extensions and extension points is implied, but never actually verified. Today you can create two extensions or extension points with the same IDs in a plugin.xml (if you so desire :-)). The behavior for extension point is that the last extension point is effectively pushes out the first extension point (or in more details: both extension points exist in the cache, but only the last one appears in the extension point table). For the extensions, both extensions would exist in the cache, but attempt to retrieve the extension by ID would result in the first extension returned. This behavior (for better or for worse :-)) is not modified by this patch. That said, the change proposed in this enhancement, promotes this situation form the rank of "ridiculous" to the rank of "unwize" :-) and, therefore, might be addressed. I would prefer not to bloat this patch (it is rather complicated as it is), but create a separate bug saying "Provide checks and feedback to detect duplicate IDs of extensions and extension points". 2. Adding getContributor() Yes, I agree that this is the logical step. - Details in the comment #21. As above, I would prefer to have a separate enhancement request and separate patch for this to avoid bloating the current patch. 3. Bug in IConfigurationElement.getNamespace() Yes, I will fix it. 4. Bug in recording of the delta for extension Actually, this is the way it works today. Listeners are expected to listen to the extension point namespace, not to the namespaces of the individual extensions. 5. Contribution.getNamespace() no longer has a meaning Yes, I'll remove it 6. RegistryIndex as a classname is confusing I could rename it to RegistryIndexElement (let me know if you have a better name in mind) 7. Creating a common super-class to extension and extension point Yes - in general, but I didn't want to include it in this patch (same goes for the Contribution cleanup). I'd suggest doing it later as it won't affect APIs or behavior. 8. No concurrent modification of the registry index / registry index children objects That should be the case. Let me know if there is any specific place that causes concerns. 9 Need to see how big the namespace index grows on large configurations In a fairly large existing application the contribution table size is 27K or 0.8% of the cache size. The new namespace index table should be about the same size so, I'd say, it is reasonably small.
We had a discussion with Pascal around the getContributor() and I'd like to capture some ideas from it (this superceeds proposal in the comment #20). First, why is it necessary to create getContributor() APIs. The existing IExtensionPoint, IExtension, and IConfigurationElement interfaces have "getNamespace()" method. However, from the API description and from the patterns it is used, the "getNamespace()" is mostly used to get a contributor for the registry element. While there was no difference between contributor name and namespace name in the past, once this patch is applied the two names become unrelated. The immediate solution to this is to say that "getNamespace()" functions contiue to return contributor name and becomes deprecated. Instead, we introduce two new mathods: getContributor() and getNamespaceName(). However, now we need a way to get the contributor name (i.e. "org.eclipse.runtime") while, in fact, we store only the contributor ID in the cache (i.e. "12"). So, we need a cache table that records pairs of {contributor id; contributor name}. Moreover, at this point of design, we might explicitly describe how to get a contributor (the present picture is certainly not clear). There would be two ways to get a contributor: 1. The getContributor() method on the IExtension/ IExtensionPoint/ IConfigurationElement would return RegistryContributor for that element. The RegistryContributor would have a method "getName()" returning the contributor name ("org.eclipse.runtime"). 2. IExtensionRegistry.findOrCreateContributor(Object) would register a contributor based on the Object passed in and the information supplied by the RegistryStrategy. Most likely, Object's package name will be used by the default registry implementation and Object's Bundle will be used by OSGi implementation. The RegistryContributor will be used as an argument to the IExtensionRegistry.addContribution() replacing "String contributorId". While there still a few details to be ironed out (i.e. how to unregister contributor), this approach seems to make sense. To recap, the plan is to create an explicit "RegistryContributor" object that could be obtained from abother registry object or from the registry itself; we will store a table of {contributor id, contributor name} in the cache; we will create new methods on the IExtension/ IExtensionPoint / IConfigurationElement explicitly providing namespace names and contributors; and we will adjust RegistryStrategy to provide a means of registering contributors.
Created attachment 34445 [details] Patch for the namespace separation The patch updates the first patch and adds getContributor() and related functionality as described in the comments above. The patch affects the following bundles: org.eclipse.core.contenttype org.eclipse.core.runtime org.eclipse.core.runtime.compatibility.registry org.eclipse.core.tests.runtime org.eclipse.equinox.preferences org.eclipse.equinox.registry The nice thing is that changes in this patch finally provide us with an explanation for what is the registry contributor and where do we get it from. As a consequence, RegistryStrategy becomes more logical.
Review: IConfigurationElement.getNamespaceName() is a very good name but might need some improvement <g> What about getRegistryNamespace()? Why is IRegistryContribor not called IContributor IRegistryContributor: - Do not talk about the registry strategy in the doc. Clients are not supposed to know. - Is the relation getHostId() / getId() the same than bundle / fragment? - if so, why is it exposed here? - I think the distinction between host / fragment should not be made available on the registry contributor - RegistryContributor needs to be SPI since registrystrategies have to create it. If made SPI make it final. - Why does it not go into the cache with extension and extension points? It is the same kind of object. IExtensionRegistry - Do we want to have a way to not throw an exception if the contributorid can't be determined? - Do we want getcontributors() to allow people to find about all the contributors - Change getNamespaces() to return all the namespaces contributed - Do we want getExtensionPoints(contributor) and getExtensions(contributor). The question here is how much do we want to expose the contributors and not only show the registry namespace Contribution - Don't declare a variable in the middle of a class (defaultNamespace) - Since newContributions / formerContributions contains the contributor ids. Do we still need the contributors table? ExtensionParser - the variable named namespace is confusing TableReader - change the version of the cache IPluginDescriptor - What is returned by getExtension / getExtensionPoint? Should we fix it?
+1 on 'getRegistryNamespace()' rather than 'getNamespaceName()' :-)
Created attachment 34613 [details] Patch for the namespace separation III The updated patch that addresses concerns above. The patch affects the following bundles: org.eclipse.core.contenttype org.eclipse.core.runtime org.eclipse.core.runtime.compatibility.registry org.eclipse.core.tests.runtime org.eclipse.equinox.preferences org.eclipse.equinox.registry
The patch contains changes to the org.eclipse.test.registry project. 1). does this project exist or is it new? 2). are we allowed to create a project in this namespace or do we have to use org.eclipse.equinox.test.registry?
Regarding comment # 28: sorry, my mistake. Those are the changes for the JUnits for the "simple" registry that currently reside in the local CVS. The JUnits will be added to the core runtime JUnits in the future. Please ignore those changes for now.
Created attachment 34672 [details] Patch for the namespace separation IV Created patch that is the same as above plus addresses the following concerns: - getRegistryNamespace() sounds too broad. Perhaps relate this to the other get*Identifier methods. Something like getIdentifierNamespace(). This fits nicely with the story told in the getUniqueIdentifier Javadoc (ie.., the unique identifier is the simple identifier plus the namespace). That is, the namespace is the namespace of the identifier. => renamed to getNamespaceIndetifier() to fit into existing getUniqueIdentifier() and getSimpleIdentifier(). - the ContributorFactories should be API (rather than SPI no)? Clients of add() have to use that => made ContributorFactories a provisional APIs - ContributorFactory: is it actualy needed? Seems like it wouldn't do anthing since all you get is the toString of the object. Consider removing. In any event, the Javadoc is too strong. If we keep it, perhaps change is name to ContributorFactoryBasic or something so it does not appear to be a parent of any other contributor factory. Is there a related strategy that would use tihs contributor factory? => This might simplify a life of somebody who just warnt to use a simple registry (or add a contributor not based on an OSGi bundle to the Eclipse registry). Renamed to ContributorFactorySimple. - I'm still unclear on the value of RegistryUtils. Seems like the set and get could be on RegistryFactory and callers of the create could just call the constructor. => Merged methods into the RegistryFactory, marked individual methods as provisional. - RegistryStrategy.createEE() takes a RegistryContributor rather than an IContributor. Seems to only use it for error reporting. Could this be IContributor.getName()? The OSGi createEE() could use getName() as well as it is just looking up a bundle. => Yes, I think we need this - IContributor provides only a name that might not be unique; while RegistryContributor has getId() that needs to be unique. The difference is probably not essential for the existig OSGi implementation, but makes much more sense in a general case. - RegistryContributor still has the notions of host and ids and names. Do we still need this? I thought we were able to reduce down to just the name (or at most name and id). Actually, should this class be part of the SPI? => Yes and yes: the IContributor (API) has just a getName(), but RegistryContributor (SPI) has all four fields. Service providers might need to create RegistryContributors on their own. In general, we expose IContributor with limited functionality to everybody and RegistryContributor with more extended functionality to Service Providers. - RegistryIndexChildren : there is an EMPTY_ARRAY constant yet everwhere the code checks for null to indicate no children. Why not just put the empty array in the children slot and remove all the null checks? Note that unlinkChild does not handle the case where you remove the last child consistently. This leaves an empty array in children. - In linkChildren the if() condition (and the true/false code) should be flipped to be a positive test - in unlinkChildren() avoid the continue by testing for != -1 => Fixed - RegistyIndexElement and RegistryIndexChildren are not particularly compelling names. => Sorry, but that's the best I can think of. Any suggestions are welcome :-).
Created attachment 34686 [details] Namespace separation patch V Same patch as above but with updated copies of the IExtension and IExtensionPoint in the registry compatibility fragment - thanks DJ! The patch affects the following bundles: org.eclipse.core.contenttype org.eclipse.core.runtime org.eclipse.core.runtime.compatibility.registry org.eclipse.core.tests.runtime org.eclipse.equinox.preferences org.eclipse.equinox.registry
Created attachment 34733 [details] Last namespace patch with some changes The attached patch contains some changes (mostly renaming) that DJ and I have done. We have not released the code because of errors while running the tests. To reproduce: remove the jobs tests from the AutomatedTests class and run. You will get: junit.framework.AssertionFailedError at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.assertTrue(Assert.java:20) at junit.framework.Assert.assertNotNull(Assert.java:220) at junit.framework.Assert.assertNotNull(Assert.java:213) at org.eclipse.core.tests.internal.registry.ExtensionRegistryStaticTest.testExtensionPoint(ExtensionRegistryStaticTest.java:43) at org.eclipse.core.tests.internal.registry.ExtensionRegistryStaticTest.testBFromCache(ExtensionRegistryStaticTest.java:63) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:478) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:344) at org.eclipse.pde.internal.junit.runtime.RemotePluginTestRunner.main(RemotePluginTestRunner.java:57) at org.eclipse.pde.internal.junit.runtime.CoreTestApplication.run(CoreTestApplication.java:24) at org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformActivator.java:99) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:92) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:68) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:374) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:169) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.eclipse.core.launcher.Main.invokeFramework(Main.java:338) at org.eclipse.core.launcher.Main.basicRun(Main.java:282) at org.eclipse.core.launcher.Main.run(Main.java:977) at org.eclipse.core.launcher.Main.main(Main.java:952) and org.osgi.framework.BundleException: Bundle "NonSingleton" version "1.0.0" has already been installed from: file:/D:/dev/runtime/org.eclipse.core.tests.runtime/Plugin_Testing/registry/testB/2/ at org.eclipse.osgi.framework.internal.core.Framework.createAndVerifyBundle(Framework.java:557) at org.eclipse.osgi.framework.internal.core.Framework.installWorkerPrivileged(Framework.java:824) at org.eclipse.osgi.framework.internal.core.Framework$1.run(Framework.java:709) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.framework.internal.core.Framework.installWorker(Framework.java:790) at org.eclipse.osgi.framework.internal.core.Framework.installBundle(Framework.java:704) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.installBundle(BundleContextImpl.java:202) at org.eclipse.core.tests.harness.BundleTestingHelper.installBundle(BundleTestingHelper.java:45) at org.eclipse.core.tests.harness.BundleTestingHelper.installBundle(BundleTestingHelper.java:38) at org.eclipse.core.tests.internal.registry.ExtensionRegistryStaticTest.testNonSingletonBundle(ExtensionRegistryStaticTest.java:304) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:478) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:344) at org.eclipse.pde.internal.junit.runtime.RemotePluginTestRunner.main(RemotePluginTestRunner.java:57) at org.eclipse.pde.internal.junit.runtime.CoreTestApplication.run(CoreTestApplication.java:24) at org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformActivator.java:99) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:92) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:68) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:374) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:169) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.eclipse.core.launcher.Main.invokeFramework(Main.java:338) at org.eclipse.core.launcher.Main.basicRun(Main.java:282) at org.eclipse.core.launcher.Main.run(Main.java:977) at org.eclipse.core.launcher.Main.main(Main.java:952)
Created attachment 34735 [details] update to the updated patch Updated patch using the standard template to express experimental API.
I just tried eclipse-SDK-I20060215-0800-win32.zip and I am getting those errors right away, without the patch applied. (Needed to comment out the Jobs tests for the errors to show up).
It seems that we get the same test failures when runing against HEAD with the Jobs tests disabled. Oleg and I have run the runtime tests several times (with the Jobs tests enabled) and we've had not problems. I will open a new bug report for the test failures with jobs disabled. The latest patch has been released to HEAD and tagged for the midnight build.
The test failures were unrelated to this change. See bug 128138.
Important: As of the Eclipse 3.2 M5a build, to use this new namespace support, you must increment the Eclipse version tag in your plugin or fragment xml to be 3.2. <?eclipse version="3.2"?> See bug 128866 for details.
*** Bug 78952 has been marked as a duplicate of this bug. ***
Gerrit change https://git.eclipse.org/r/c/equinox/rt.equinox.bundles/+/171571 was merged to [master]. Commit: http://git.eclipse.org/c/equinox/rt.equinox.bundles.git/commit/?id=f6d40224153ea9561afbf7f5fc2e2e330029d0e8
