I was asking about the following scenario: User has an arbitrary plugin project which obviously depends on o.e.osgi. I'm not speaking of building o.e.osgi, but about consuming.
In the workspace s/he has references to o.e.osgi as jar with source attachment. When the user browses / inspects types from o.e.osgi, JDT uses the jar plus its source attachment in order to present javadoc hovers and such. Behind the scenes javadoc computation uses the sources and compiles them on the fly in order to provide semantic, rather than syntactic information. The problem is: this in-memory compilation of attached sources fails due to unresolved references to an annotation type "ProviderType". Normally, JDT's javadoc hovers would know the fully qualified name of any annotations and even support navigation to the type. For ProviderType this is not possible, because that name cannot be resolved. Still worse, for the javadoc of any API method that mentions another type which in turn is annotated as @ProviderType this transitive lookup fails, causing JDT to abort this compilation because obviously our classpath is incorrect. Hence semantic information for javadoc hovers may just be unavailable for affected elements. BTW, when I classified ProviderType as API, I certainly wasn't implying "runtime" API. These things are compile time API, just like @NonNull (which, too, has retention CLASS). If an API exposes annotations, the declaration for that annotation must be visible for compilation of client source. If the annotation would be relevant only while compiling o.e.osgi itself, then I would deem a retention SOURCE much more suitable. By saying "CLASS" you are making this annotation *visible* to *compilation* of client sources, but you are not telling, what the annotation is. In terms of API Tools this should be considered as an API leak. But these are semantic issues, not relevant to the tooling problem at hand. IMHO, either the source attachment is incomplete or the bundle must declare a dependency on the artifact containing the annotation declaration. The question is: how do you advise JDT to perform its on-the-fly compilation while working on a client project depending on o.e.osgi, which is available as jar + source attachment? Currently, JDT concludes that the source attachment of o.e.osgi is broken. best, Stephan On 05/07/2015 02:43 PM, BJ Hargrave wrote:
> From: Stephan Herrmann <[email protected]> > I've observed, that JDT has problems working with class file > plus source attachment of org.osgi.framework.Bundle et al. > Reason: when compiling the attached sources we can't find > the annotation type org.osgi.annotation.versioning.ProviderType. > I see that Equinox has the corresponding jar in its git repo, > but the deployed org.eclipse.osgi doesn't seem to contain any > hint on where this type could be found. So you issue is that the org.eclipse.osgi jar file does not contain the annotation classes? If you are compiling the OSGi sources in the org.eclipse.osgi repo, you can get the annotations jar from the git repo too. I don't believe any of the Equinox source uses the OSGi versioning annotations. > > Now, if the annotation had retention SOURCE, one might argue > that after compilation the annotation no longer exists > (which would still create a challenge for the compiler to > find that the annotation we don't find is missing for a good > reason - for detecting the SOURCE retention we would need to > find the annotation in the first place). > > With a CLASS retention, however, this annotation should IMHO > be considered part of the API and without a dependency this > makes it a secret clause as part of the public API, mhhh... No. CLASS retention is not part of the runtime API since such annotations are not visible at runtime. They are visible at tool time such as when bnd packages bundles and uses information from the versioning annotations. Therefore the tools need access to the annotation types (which they will make sure they have). You also need access to compile the classes and the source repo provides the annotations in jar form. > > Am I misreading something? Any suggestions how the compiler > can cope with this fatal error on a published artifact? I am not entirely clear on what you are doing here. Perhaps you can explain in more detail. > > Who is supposed to use the information about this annotation? Tools like bnd. They advise tools about the package version and whether types in the package are provider or consumer role. See the OSGi Semantic Versioning paper for more information on these roles. http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf > How does that instance get access to the annotation definition? The tool must of course have knowledge of the semantic meaning of the annotations. Since the tool is not loading the classes (and they are CLASS retention), the tools processes the class file' bytecodes. > > FYI, the problem occurs when JDT/UI functionality requests > the resolved types of methods in the given interface. -- *BJ Hargrave* Senior Technical Staff Member, IBM OSGi Fellow and CTO of the _OSGi Alliance_ <http://www.osgi.org/>_ [email protected]_ <mailto:[email protected]> office: +1 386 848 1781 mobile: +1 386 848 3788 _______________________________________________ equinox-dev mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________ equinox-dev mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/equinox-dev
