Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 307750

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 ToolsAssignee: 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:
Description Flags
Team project set to reproduce none

Description Martin Oberhuber CLA 2010-03-31 11:42:16 EDT
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.
Comment 1 Olivier Thomann CLA 2010-03-31 11:43:57 EDT
I'll take a look.
Comment 2 Olivier Thomann CLA 2010-04-07 11:31:47 EDT
I cannot reproduce with I20100406-1034.
Martin, could you please give it a try?

Thanks.
Comment 3 Martin Oberhuber CLA 2010-04-07 12:00:47 EDT
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?
Comment 4 Olivier Thomann CLA 2010-04-07 17:37:17 EDT
I am retrieving the 3.5.1 SDK to double-check it.
Comment 5 Olivier Thomann CLA 2010-04-07 18:01:15 EDT
Would it be possible for you to isolate the problem in a small workspace?
I still cannot reproduce the failure.
Comment 6 Olivier Thomann CLA 2010-04-08 13:45:21 EDT
Without further details, I will close as WORKSFORME.
Comment 7 Martin Oberhuber CLA 2010-04-08 15:52:59 EDT
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"
Comment 8 Olivier Thomann CLA 2010-04-09 10:33:08 EDT
I tried those steps and for some reason I don't get the @since tags errors.
Something else must be different.
Comment 9 Olivier Thomann CLA 2010-04-09 10:33:37 EDT
When you have the pb, do you still get it after a full build ?
Comment 10 Martin Oberhuber CLA 2010-04-09 11:16:16 EDT
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.
Comment 11 Martin Oberhuber CLA 2010-04-09 11:17:26 EDT
One option to try reproduce might be repeatedly changing the baseline:
   .../eclipse/plugins , APPLY , OK
   .../eclpse , APPLY, OK
   .../eclipse/plugins, APPLY, OK

   ...
Comment 12 Olivier Thomann CLA 2010-04-15 14:20:23 EDT
I tried that many times without luck.
Do you still get it using this week I-build ?
Comment 13 Martin Oberhuber CLA 2010-04-16 11:33:59 EDT
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.
Comment 14 Martin Oberhuber CLA 2010-04-23 10:56:56 EDT
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.
Comment 15 Olivier Thomann CLA 2010-04-26 15:06:10 EDT
If only I could reproduce it. Right now I cannot, so I doubt I can actually fix it for M7.
Comment 16 Olivier Thomann CLA 2010-04-26 15:07:09 EDT
Removing target milestone as long as I cannot reproduce and therefore fix this problem.
Comment 17 Martin Oberhuber CLA 2010-04-27 01:03:32 EDT
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).
Comment 18 Martin Oberhuber CLA 2010-04-27 01:05:12 EDT
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?
Comment 19 Olivier Thomann CLA 2010-04-27 09:12:27 EDT
(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.
Comment 20 Olivier Thomann CLA 2010-04-28 13:04:55 EDT
If you could zip up your workspace and tell me what you do to get the error, this would definitely help.
Comment 21 Olivier Thomann CLA 2010-06-25 13:49:57 EDT
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.
Comment 22 Olivier Thomann CLA 2010-07-14 09:43:09 EDT
I could never reproduce. Closing as WORKSFORME.
Reopen if you get it again in 3.7 cycle.
Comment 23 Martin Oberhuber CLA 2011-01-31 12:27:36 EST
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"
Comment 24 Martin Oberhuber CLA 2011-01-31 12:33:47 EST
This time, the problem remains after a clean rebuild.
Comment 25 Olivier Thomann CLA 2011-02-25 13:36:50 EST
Ankur, I didn't have time to look at this one. Could you please take a look?
Thanks.
Comment 26 Dani Megert CLA 2014-12-17 05:24:53 EST
I got the same problem. The reason it happens is when an existing package is newly marked as x-internal.
Comment 27 Dani Megert CLA 2014-12-17 05:41:26 EST
(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
Comment 28 Dani Megert CLA 2014-12-17 09:13:04 EST
(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).
Comment 29 Eclipse Genie CLA 2019-09-18 10:24:02 EDT
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.