Community
Participate
Working Groups
Build Identifier: I20100312-1448 Hi, I'm testing the Eclipse API Tools and for that purpose I have created two plug-in projects in my workspace, the second one being a variation of the "original" first project, with Java binary compatibility problems introduced (e.g. changing class to be final). After exporting the first project as deployable plug-in, and creating a baseline from it that is set as the default baseline, API Tools recompiles all projects and correctly reports the compatibility problems I introduced in the second project. All of these problem reports and error markers also appear in the first project however, that is identical to the baseline. There seems to be an error that causes these markers to appear in the original baseline project. Reproducible: Always
Btw. it is clear that the markers are simply being projected onto the original project, and are not actually meant to be there, as the line numbers and text area correspond to the real problems in the second project. So I guess the error has nothing to do with detection, but is rather a simple GUI oversight somewhere. Both projects have the same plug-in id of course. So if API Tools applies the problem markers solely based on the plug-in id, without distinguishing between different projects, that could be the problem.
After updating Eclipse to latest build (I20100429-1549) the behavior of API Tools is even more erratic. 1. Exporting the first project and setting it as default baseline now only reports a fraction of the incompatibilities in the second project (and duplicates them as before in first project). 2. Performing a "Project->Clean" on both projects leaves the first project with the incomplete incompatibilities of the first step, and puts an "The type xxxxxx has been removed from pluginxxx" Compatibility Problem in every type of the second project. This leads me to the conclusion that having the baseline plug-in open as a project in the workspace confuses the API Tools and leads to all kinds of strange behavior. True enough, closing the first project, removing and re-creating the baseline and cleaning the second project now reports the incompatibilities in the second project correctly.
Created attachment 168740 [details] Fix for multiple workspace projects with same plugin id The core of this problem is in ApiBaselineManager: Set ids = DependencyManager.getSelfandDependencies(PluginRegistry.getWorkspaceModels(), null); "PluginRegistry.getWorkspaceModels()" returns an array of plug-in projects in the workspace. If there is more than one workspace project for a plugin-id these are "lost" when DependencyManager.getSelfandDependencies(...) assembles them into a Set. Still, API Tools iterates over all Tooling-enabled Workspace projects but then reads the single model from the set, which in reality is the API model of only one of those projects. This causes the confusion and errors with problem markers. The supplied patch fixes this by performing API analysis only on the first project encountered and putting a "WARNING" Problem marker with the following message on all other projects with the same plugin-id: "There is more than one workspace project for the plug-in id: [id]. This is discouraged at the moment as API Tools can only perform API analysis on one of these projects."
You are not supposed to have two bundles with the same id at the same time in your workspace. Could you please explain how you are setting up your baseline?
Hi Olivier, I have three projects in my workspace: 1. API_Old - Plugin project that provides an API by exporting all packages 2. API_New - The "same" plugin project as API_Old with binary incompatible changes introduced 3. API_Client - a standard Java project that I use to access the compiled binaries of API_Old/API_New I create the baseline by exporting "API_Old" as "deployable plug-ins and fragments" and then setting the exported plugin as default baseline. Now, after recompiling compatibility errors appear in API_New (correctly) and API_Old (incorrectly, as this is the actual baseline project). Cleaning these projects leads to more erratic behaviour. All of this happens because of the way API Tools iterates through workspace projects when compiling but mixes up API_Old and API_New because they have the same plugin id. I admit that it is unusual to have more than one project of the same plugin-id in the workspace, but I think it is not entirely out of the question for testing purposes or for people with special needs that need to work with multiple versions. My proposed patch is far from an ideal solution, but at least it prevents mixing up projects by having API Tools check only the first workspace project with a certain plugin id, and it displays warning markers to make the user aware of the problem.
Created attachment 169319 [details] example projects These are the projects mentioned in the above comment, plus a test project I created to test the binaries. (Call JUnit test once with client.jar + apiold.jar and once with client.jar + apinew.jar in classpath. First should all pass, latter should all fail)
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
This bug has been marked as stalebug a while ago without any further interaction. If this report is still relevant for the current release, please reopen and remove the stalebug whiteboard flag.
This bug was marked as stalebug a while ago. Marking as worksforme. If this report is still relevant for the current release, please reopen and remove the stalebug whiteboard tag.
