| Summary: | API Tooling reports missing or wrong @since tags on non-API ("x-internal") classes | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] PDE | Reporter: | Martin Oberhuber <mober.at+eclipse> | ||||
| Component: | API Tools | Assignee: | PDE API Tools Inbox <pde-apitools-inbox> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | |||||
| Severity: | minor | ||||||
| Priority: | P3 | CC: | daniel_megert, darin.eclipse, Olivier_Thomann, Szymon.Brandys, Vikas.Chandra | ||||
| Version: | 3.6 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Whiteboard: | stalebug | ||||||
| Attachments: |
|
||||||
I'll take a look. I cannot reproduce with I20100406-1034. Martin, could you please give it a try? Thanks. I still see this with I20100406-1034 on WinXP in my Workspace, after a clean rebuild of o.e.core.resources HEAD. As mentioned my baseline is Eclipse-3.5.1 SDK ... perhaps there's an issue with this baseline not properly identifying "internal" packages or reporting too much in its .api_description files? I am retrieving the 3.5.1 SDK to double-check it. Would it be possible for you to isolate the problem in a small workspace? I still cannot reproduce the failure. Without further details, I will close as WORKSFORME. Created attachment 164278 [details]
Team project set to reproduce
Ok, so I reproduced this with I20100406-1034 with a fresh empty workspace.
I'm not exactly sure which of the steps below are actually must-haves to trigger the problem; the problem wasn't there when I initially imported the team project set and started editing, but it manifested when I changed the API baseline to include both plugins and features.
1. Launch I20100406-1034
2. Preferences > API Baselines : Enter D:/eclipse351/eclipse/plugins
3. Import attached team project set
4. (maybe) edit core.internal.resources/SaveManager.java, adding a constant
5. (maybe) edit core.resources/IProject, adding method bar() with @since
6. (maybe) edit core.internal.resources/Project, adding impl of bar()
7. Preferences > API Baselines : Switch to "D:/eclipse351/eclipse"
I tried those steps and for some reason I don't get the @since tags errors. Something else must be different. When you have the pb, do you still get it after a full build ? Interesting... in this new workspace, the errors are gone after the clean rebuild. In my old workspace, the errors remained even through clean rebuild with M6; now with I20100406-1034, they are gone there as well after the clean rebuild. So... looks like current state is that there must be some odd condition triggering the issue when changing the baseline, but the error is not persistent. Which makes the issue minor IMO. One option to try reproduce might be repeatedly changing the baseline: .../eclipse/plugins , APPLY , OK .../eclpse , APPLY, OK .../eclipse/plugins, APPLY, OK ... I tried that many times without luck. Do you still get it using this week I-build ? Cannot reproduce any more with I20100414-1200, with none of my workspaces. I also notice that the "full build" seems a lot faster now, when I hit Apply in the Preferences after changing a baseline. So I assume something has been changed in this area which fixed the issue. Will reopen in case I ever see it again. The problem is back, with I20100422-1310 . I had upgraded to the new I-build, re-using the existing workspace. The upgrade forced me to create a new target platform based on the running platform (I have several addons like CDT pulled into my Eclipse via *.link files). It took several iterations until everything built clean again (there were build path errors). At some point the build path errors were resolved, but API Tooling now keeps indicating "missing @since tags" on "internal" packages in core.resources. A clean build doesn't resolve the problem - markers are removed but then return again. Let me know what I can do to help diagnosing the issue. If only I could reproduce it. Right now I cannot, so I doubt I can actually fix it for M7. Removing target milestone as long as I cannot reproduce and therefore fix this problem. I could try debug this if you can give any hints what to look for. Or I zip up my entire workspace for you. Or I start a remote debugging session and have you connect remotely (not sure how well JDWP protocol works with high latencies). My feeling is that this is related to changing the target platform underneath an existing workspace. Where is the information that something is "x-internal" taken from ... the target platform, the workspace or the API baseline? (In reply to comment #18) > My feeling is that this is related to changing the target platform underneath > an existing workspace. Where is the information that something is "x-internal" > taken from ... the target platform, the workspace or the API baseline? If this is the case, then this should be a bug in PDE/UI. API tooling is using the target platform information. If the target platform is not properly initialized, then we might end up with wrong errors. If you could zip up your workspace and tell me what you do to get the error, this would definitely help. I could never reproduce this one so unless this is reproducable and I can get access to a test case to reproduce it, I'll close as WORKSFORME. I could never reproduce. Closing as WORKSFORME. Reopen if you get it again in 3.7 cycle. Just seen again with 3.7m5.
Here's exactly what I did:
1. Launch 3.7m4 on a fresh empty workspace.
2. Set API Baseline to C:\Eclipse\361\eclipse\plugins
3. Get following projects from HEAD:
org.eclipse.core.resources
org.eclipse.core.tests.harness
org.eclipse.core.tests.resources
org.eclipse.test
org.eclipse.test.performance
org.eclipse.test.performance.data
org.eclipse.test.performance.win32
4. Observe a build error in core.resources (needs core.runtime 3.7.0)
5. Launch 3.7m5 (fresh empty config area)
6. Open the workspace
--> API Tooling reports "Missing @since tag" on o.e.core.internal.dtree"
This time, the problem remains after a clean rebuild. Ankur, I didn't have time to look at this one. Could you please take a look? Thanks. I got the same problem. The reason it happens is when an existing package is newly marked as x-internal. (In reply to Dani Megert from comment #26) > I got the same problem. The reason it happens is when an existing package is > newly marked as x-internal. Test Case: 1. clone http://git.eclipse.org/c/equinox/rt.equinox.p2.git/ 2. import 'org.eclipse.equinox.p2.ui' 3. add 4.4.1 as API baseline ==> at the moment you get an unexpected error regarding wrong @since tag in StringMatcher. Once bug 454845 is fixed, you have to remove the workaround/problem filter: 4. select the project in the 'Package Explorer' 5. context menu > Plug-in Tools > Remove API Tools Problem Filters... 6. remove the one for StringMatcher ==> unexpected error regarding wrong @since tag in StringMatcher (In reply to Dani Megert from comment #26) (In reply to Dani Megert from comment #27) Please ignore those comments. What I saw was caused by something else (see bug 454845 comment 7 for details). 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. |
Build ID: I20100312-1448 (3.6m6) on WinXP SP2 Steps to reproduce: 1. Launch Eclipse 3.6m6 2. Import org.eclipse.core.resources project 3. In Preferences, specify Eclipse-3.5.1 SDK as baseline --> Missing @since tags are reported on a number of classes which are not API because their package is marked x-internal in the Manifest. For instance: Description Resource Path Location Type Missing @since tag on org.eclipse.core.internal.resources.FilterDescription FilterDescription.java /org.eclipse.core.resources/src/org/eclipse/core/internal/resources line 23 @since tag problem This issue is pretty annoying because the error markers obscure real compilation errors. On the other hand, I do not want to turn off error reporting on missing @since tags completely, because there are some API packages that I want the API Tooling to report errors on.