Community
Participate
Working Groups
I20101130-0900 Steps to reproduce: 1) open a new workspace. 2) setup the api baseline to the 3.6 SDK 3) import org.eclipse.osgi from HEAD I get the following errors from API tooling. All errors appear to be on interfaces that are marked as @noimplement. There are two cases. 1) Many of the org.osgi interfaces got marked with @noimplement because OSGi decided to utilize the API tooling tags to describe the intention of the interface. I'm not sure if API tooling is complaining because we added this new tag. 2) Also notice there are errors on org.eclipse.osgi.service.resolver.BundleDescription which was marked with @noimplement in 3.6. This seems like an incorrect error to me. Description Resource Path Location Type The interface java.lang.Comparable adds method compareTo(T) to org.osgi.framework.Bundle that is not tagged as @noimplement Bundle.java /org.eclipse.osgi/osgi/src/org/osgi/framework line 79 Compatibility Problem The interface java.lang.Comparable adds method compareTo(T) to org.osgi.framework.launch.Framework that is not tagged as @noimplement Framework.java /org.eclipse.osgi/osgi/src/org/osgi/framework/launch line 40 Compatibility Problem The interface org.osgi.framework.BundleReference adds method getBundle() to org.eclipse.osgi.service.resolver.BundleDescription that is not tagged as @noimplement BundleDescription.java /org.eclipse.osgi/core/adaptor/org/eclipse/osgi/service/resolver line 26 Compatibility Problem The interface org.osgi.framework.wiring.BundleRevision adds method getSymbolicName() to org.eclipse.osgi.service.resolver.BundleDescription that is not tagged as @noimplement BundleDescription.java /org.eclipse.osgi/core/adaptor/org/eclipse/osgi/service/resolver line 26 Compatibility Problem The major version should be incremented in version 3.7.0.qualifier, since API breakage occurred since version 3.6.0.v20100517 MANIFEST.MF /org.eclipse.osgi/META-INF line 75 Version Numbering Problem The method org.osgi.framework.Bundle.adapt(Class<A>) in an interface that is intended to be implemented has been added Bundle.java /org.eclipse.osgi/osgi/src/org/osgi/framework line 1264 Compatibility Problem The method org.osgi.framework.Bundle.getDataFile(String) in an interface that is intended to be implemented has been added Bundle.java /org.eclipse.osgi/osgi/src/org/osgi/framework line 1290 Compatibility Problem The method org.osgi.framework.BundleContext.getBundle(String) in an interface that is intended to be implemented has been added BundleContext.java /org.eclipse.osgi/osgi/src/org/osgi/framework line 875 Compatibility Problem The method org.osgi.framework.BundleContext.getServiceReference(Class<S>) in an interface that is intended to be implemented has been added BundleContext.java /org.eclipse.osgi/osgi/src/org/osgi/framework line 662 Compatibility Problem The method org.osgi.framework.BundleContext.getServiceReferences(Class<S>, String) in an interface that is intended to be implemented has been added BundleContext.java /org.eclipse.osgi/osgi/src/org/osgi/framework line 718 Compatibility Problem The method org.osgi.framework.BundleContext.registerService(Class<S>, S, Dictionary<String,?>) in an interface that is intended to be implemented has been added BundleContext.java /org.eclipse.osgi/osgi/src/org/osgi/framework line 491 Compatibility Problem The method org.osgi.framework.Filter.matches(Map<String,?>) in an interface that is intended to be implemented has been added Filter.java /org.eclipse.osgi/osgi/src/org/osgi/framework line 135 Compatibility Problem
I'll investigate once done with JDT issues.
I also saw this first on a Mac, but since I didn't see it in my main workspace under Windows 7 (and I still don't see it there), I thought it was a setup issue. But now I can also reproduce on Windows 7 (with steps from comment 0).
There are several things I would like to clarify. org.osgi.framework.BundleContext, org.osgi.framework.Bundle and org.osgi.framework.launch.Framework were not tagged with @noimplement in 3.6.0. Is this right? The error: The interface java.lang.Comparable adds method compareTo(T) to org.osgi.framework.Bundle that is not tagged as @noimplement actually makes sense since you added the Comparable interface to the Bundle class. So you add the compareTo(..) method as an API of the Bundle interface. That interface was not tagged as @noimplement in 3.6.0. So 3.6.0 implementors would be broken since they don't provide the compareTo(..) method. Same apply for the error reported against org.osgi.framework.launch.Framework since it inherits the compareTo(..) method from Bundle. The two methods org.osgi.framework.Bundle.adapt(Class<A>) and org.osgi.framework.Bundle.getDataFile(String) have been added to the bundle interface. Again since this interface was not tagged as @noimplement for 3.6.0, it would be a breakage to users that implemented it in 3.6.0. Same explanation applies for the type org.osgi.framework.BundleContext. The methods getBundle(String), getServiceReference(Class<S>), getServiceReferences(Class<S>, String) and registerService(Class<S>, S, Dictionary<String,?>) have been added to an interface not tagged as @noimplement in 3.6.0. I still need to investigate the two failures reported against org.eclipse.osgi.service.resolver.BundleDescription: - The interface org.osgi.framework.BundleReference adds method getBundle() to org.eclipse.osgi.service.resolver.BundleDescription that is not tagged as @noimplement - The interface org.osgi.framework.wiring.BundleRevision adds method getSymbolicName() to org.eclipse.osgi.service.resolver.BundleDescription that is not tagged as @noimplement Tom, do you agree with the fact that only the last two errors are suspicious, but I would say all others are expected.
(In reply to comment #3) > Tom, do you agree with the fact that only the last two errors are suspicious, > but I would say all others are expected. So there is a check to see if @noimplement was added since the base line? And if @noimplement was added then any additions that break compatibility for implementing clients are flagged also? If this is true then I agree, only the last to errors seems suspicious and I should add a compatibility problem filter for the org.osgi.* packages since OSGi decided to add the appropriate @noimplement tags for R4.3.
(In reply to comment #3) > > The error: > The interface java.lang.Comparable adds method compareTo(T) to > org.osgi.framework.Bundle that is not tagged as @noimplement > actually makes sense since you added the Comparable interface to the Bundle > class. So you add the compareTo(..) method as an API of the Bundle interface. > > That interface was not tagged as @noimplement in 3.6.0. So 3.6.0 implementors > would be broken since they don't provide the compareTo(..) method. > > Same apply for the error reported against org.osgi.framework.launch.Framework > since it inherits the compareTo(..) method from Bundle. > > The two methods org.osgi.framework.Bundle.adapt(Class<A>) and > org.osgi.framework.Bundle.getDataFile(String) have been added to the bundle > interface. Again since this interface was not tagged as @noimplement for 3.6.0, > it would be a breakage to users that implemented it in 3.6.0. > > Same explanation applies for the type org.osgi.framework.BundleContext. > The methods getBundle(String), getServiceReference(Class<S>), > getServiceReferences(Class<S>, String) and registerService(Class<S>, S, > Dictionary<String,?>) have been added to an interface not tagged as > @noimplement in 3.6.0. I would expect to see these errors as well, one error for the new restrictions and subsequent errors for any member (method / field) additions / changes.
(In reply to comment #5) > I would expect to see these errors as well, one error for the new restrictions > and subsequent errors for any member (method / field) additions / changes. There were errors for the added restriction, but org.eclipse.osgi has already filters for these errors. This should be enough to also hide the other errors.
(In reply to comment #5) > I would expect to see these errors as well, one error for the new restrictions > and subsequent errors for any member (method / field) additions / changes. I understand now. I had added a problem filter for the addition of the @noimplement tags added to the org.osgi.* classes. What confused me is I recently started seeing new errors about member (method / field) additions / changes to these org.osgi.* classes when I was not before. The errors on BundleDescription still look incorrect to me.
(In reply to comment #7) > The errors on BundleDescription still look incorrect to me. I am looking at these ones.
(In reply to comment #6) > There were errors for the added restriction, but org.eclipse.osgi has already > filters for these errors. This should be enough to also hide the other errors. This means I should use the current restrictions instead of the baseline's restrictions when new methods are added. I'll investigate this to make sure we don't miss any errors doing that. Right now the current behavior is acceptable except for the last two errors in BundleDescription.
Patch under test. Targeting M5.
Created attachment 184801 [details] Proposed fix + regression tests This patch removes secondary errors and fixes the two errors in BundleDescription.
Michael, could you please verify? I am having some errors running the tests, but I believe this is related to some errors while deleting resources and not directly related to this patch.
Released for 3.7M5. Michael, please verify.
looks good.
*** Bug 332840 has been marked as a duplicate of this bug. ***
