Community
Participate
Working Groups
I am often bitten by the problem of copying a plugin project to another one with a different name for the project, but forgetting to change the name in the manifest. So there are two plugin projects with the same name. It will get odd errors because it's picking a different one than I expect to bind to. It should give an error when referring from one plugin to another and there are multiple instances of the other open with the same name. Another possible check might be to have an optional check for the case where the project name and plugin name differ. This would catch the errors as soon as the project was copied.
(In reply to comment #0) > I am often bitten by the problem of copying a plugin project to another one > with a different name for the project, but forgetting to change the name in the > manifest. So there are two plugin projects with the same name. It will get > odd errors because it's picking a different one than I expect to bind to. It > should give an error when referring from one plugin to another and there are > multiple instances of the other open with the same name. > You can have multiple plug-ins with the same name and different version. This could be two projects or a combination of the workspace and target. When requiring another bundle you should be using a version range. If you follow the OSGi versioning rules, PDE will select a plug-in that is supported. > Another possible check might be to have an optional check for the case where > the project name and plugin name differ. This would catch the errors as soon > as the project was copied. PDE does not require that the project name and symbolic name match. I don't see us adding even an optional setting to check this. Marking as WONTFIX. Your use case is highly unusual and any solution would end up being a rarely used preference.
I agree with what you have written except for the case of two plugins with the same version and same name (which is exactly my case) which you did not address. Surely PDE can issue a warning in this case, rather than just arbitrarily picking one?
I guess I could see there being a check for that. It would only check that duplicates exist in workspace plug-ins.
(In reply to comment #3) > I guess I could see there being a check for that. It would only check that > duplicates exist in workspace plug-ins. Perfect, I think that will save some people trouble.
*** Bug 321059 has been marked as a duplicate of this bug. ***
I was just unwittingly stung by this....I could have saved 14.8 minutes not having to figure out what the problem was.
Created attachment 175349 [details] Improves validation dialog for singletons
The attached patch has been committed to HEAD. It improves the validation dialog's ability to handle multiple singletons by displaying the locations of the singletons. I added support to the validation dialog for nested statuses (multistatuses) and fixed some logic that would duplicate the displayed errors. I'm closing this as FIXED, even though it doesn't completely cover the original request. For supporting errors for multiple singletons in the workspace, please use bug 312321.
Verified in I20100804-0100
