[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [equinox-dev] dependency on org.osgi.annotation?
|
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 <stephan.herrmann@xxxxxxxxx>
> 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/>_
__hargrave@xxxxxx.com_ <mailto:hargrave@xxxxxxxxxx>
office: +1 386 848 1781
mobile: +1 386 848 3788
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev
