Re: [equinox-dev] dependency on org.osgi.annotation?
Sorry to go back to square one, but can someone describe what the issue is when these types are not available to jdt projects? I know we are still able to compile against the org.osgi.framework packages contained in equinox because we do it every build just fine. So what fails exactly? Is it javadoc hover help and linking? or some other function in JDT? Do other projects that import the org.osgi.framework package really need the org.osgi.annotation package on their classpath to compile?I'm wondering if the most simple solution would be to include the org.osgi.annotation.versioning class files in the org.eclipse.osgi jar but not to export them. This should allow the annotations to be found in the binary and source jars and then JDT should be able to find them, right? Is there really a need to export this package?Tom-equinox-dev-boun...@eclipse.org wrote: -To: Equinox development mailing list equinox-dev@eclipse.orgFrom: Markus Keller <markus_kel...@ch.ibm.com>Sent by: equinox-dev-boun...@eclipse.orgDate: 05/11/2015 11:07AMCc: equinox-dev-boun...@eclipse.orgSubject: Re: [equinox-dev] dependency on org.osgi.annotation? I don't mind having this discussion here, but to be honest it seems more appropriate to have the discussion in a PDE forum or bug report where a PDE committer or contributer is monitoring and may be able to do the PDE work necessary. If such a bug is opened can you please post it here?No new bug required. Just continue inhttps://bugs.eclipse.org/bugs/show_bug.cgi?id=436469Markus___equinox-dev mailing listequinox-dev@eclipse.orgTo change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] dependency on org.osgi.annotation?
On 05/09/2015 09:05 PM, Neil Bartlett wrote: I find *that* comment totally inappropriate. Only one thing to add from my side: Any opinions which I expressed in this thread, are the personal opinions of me as an individual committer, nothing indicative of the position of any group, team or company. Stephan ___ equinox-dev mailing list equinox-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] dependency on org.osgi.annotation?
The problem is this would not be automatic. I think there likely would need to be some way for a jar to indicate the package is compile time only API, perhaps with a separate header in the manifest. Then PDE can detect the compile time only packages and offer them to be added to project classpaths if needed. This would be similar to how it offers to use Import-Package (or Require-Bundle) when it detects runtime classes are missing.Tom-equinox-dev-boun...@eclipse.org wrote: -To: Equinox development mailing list equinox-dev@eclipse.orgFrom: Tom Schindl <tom.schi...@bestsolution.at>Sent by: equinox-dev-boun...@eclipse.orgDate: 05/09/2015 01:51AMSubject: Re: [equinox-dev] dependency on org.osgi.annotation?PDE can have compile time dependencies in its build.properties but naturally build.properties is not part of the final jar TomVon meinem iPhone gesendet Am 09.05.2015 um 00:52 schrieb Stephan Herrmann stephan.herrm...@berlin.de: I'm not responding to any of that religious anti-PDE flame war which is totally inappropriate in this discussion. On 05/08/2015 10:21 AM, BJ Hargrave wrote: Well I suggest that (1) JDT not have a fatal error here since the goal is not to generate a class file Sounds like the obvious way to go, sure. Just note that reporting this kind of error is not connected to generating class files but to the semantic analysis, which indeed is desired in this use case - which only means: it's not as easy as just stopping before class file generation. Continuing compilation on broken input is a main contributor to complexity of this already very complex component. That's why avoiding unnecessarily broken input sounds like a much nicer option. and (2) PDE should ... support a way to specify compile dependencies different than runtime dependencies Well, if that's what the OSGi spec says, it shouldn't be hard to convince PDE ... Stephan ___ equinox-dev mailing list equinox-dev@eclipse.org 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 listequinox-dev@eclipse.orgTo change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] dependency on org.osgi.annotation?
On 8 May 2015, at 23:52, Stephan Herrmann stephan.herrm...@berlin.de wrote: I'm not responding to any of that religious anti-PDE flame war which is totally inappropriate in this discussion. I find *that* comment totally inappropriate. BJ has given reasons why he thinks PDE gets certain things wrong. You may not agree with those reasons but it doesn’t work to just claim they are “religious” or inflammatory. On 05/08/2015 10:21 AM, BJ Hargrave wrote: Well I suggest that (1) JDT not have a fatal error here since the goal is not to generate a class file Sounds like the obvious way to go, sure. Just note that reporting this kind of error is not connected to generating class files but to the semantic analysis, which indeed is desired in this use case - which only means: it's not as easy as just stopping before class file generation. Continuing compilation on broken input is a main contributor to complexity of this already very complex component. That's why avoiding unnecessarily broken input sounds like a much nicer option. and (2) PDE should ... support a way to specify compile dependencies different than runtime dependencies Well, if that's what the OSGi spec says, it shouldn't be hard to convince PDE … As we all know, the OSGi spec is nearly silent on how to build stuff. But should we give up on a good idea just because it’s not in the spec? After all, the benefits of building against an API are so obvious (you can’t accidentally depend on implementation-specific code) that it seems we could convince the owners of PDE, whoever they are, on the merits of the idea alone. Neil Stephan ___ equinox-dev mailing list equinox-dev@eclipse.org 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 equinox-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] dependency on org.osgi.annotation?
PDE can have compile time dependencies in its build.properties but naturally build.properties is not part of the final jar Tom Von meinem iPhone gesendet Am 09.05.2015 um 00:52 schrieb Stephan Herrmann stephan.herrm...@berlin.de: I'm not responding to any of that religious anti-PDE flame war which is totally inappropriate in this discussion. On 05/08/2015 10:21 AM, BJ Hargrave wrote: Well I suggest that (1) JDT not have a fatal error here since the goal is not to generate a class file Sounds like the obvious way to go, sure. Just note that reporting this kind of error is not connected to generating class files but to the semantic analysis, which indeed is desired in this use case - which only means: it's not as easy as just stopping before class file generation. Continuing compilation on broken input is a main contributor to complexity of this already very complex component. That's why avoiding unnecessarily broken input sounds like a much nicer option. and (2) PDE should ... support a way to specify compile dependencies different than runtime dependencies Well, if that's what the OSGi spec says, it shouldn't be hard to convince PDE ... Stephan ___ equinox-dev mailing list equinox-dev@eclipse.org 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 equinox-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] dependency on org.osgi.annotation?
There are Eclipse-specific classes in o.e.osgi such as NLS and Debug which makes it hard to do what you suggest, especially since these are provided in a supplements bundle which cannot co exist in an eclipse runtime. Alex Sent from my iPhat 6 On 8 May 2015, at 09:21, BJ Hargrave hargr...@us.ibm.com wrote: From: Stephan Herrmann stephan.herrm...@berlin.de On 05/07/2015 05:21 PM, BJ Hargrave wrote: User has an arbitrary plugin project which obviously depends ono.e.osgi. Well I would say that no one should depend upon org.eclipse.osgi. It is an implementation of the OSGi core spec. If you are writing bundles, then you are dependent on the OSGi API and should put osgi.core and possibly osgi.annotation on your compile path. These jars are available from OSGi Alliance website, Maven Central, JCenter, ... and include their source. Are you saying no-one should use type org.osgi.framework.Bundle, forexample??? Of course not. I am saying you need to compile against API jars (e.g. osgi.core, osgi.annotation) and not against implementation jar (e.g. org.eclipse.osgi). I do this all the time (with bnd/bndtools and not PDE) and don't have the issues you raise here. You read depends and think of a dependency declared by OSGi means, but that's not what I was saying. I'm speaking of the situation of all plug-in developers using Eclipse PDE + JDT (independent of whether you like PDE or not). Well PDE is the source of the problem since it uses the manifest as both a build input and a build output. Perhaps JDT is a bit too sensitive for what it not a real compilation but instead just providing hover information. You're interpretation of compile is narrower, than what I'm talking about. Let me explain: Eclipse has a single component, which is responsible for many tasks, from creating detailed information for various views and hovers, over providing the precise semantic information for refactoring, up-to producing executable class files. We traditionally call this component the compiler. The compiler *must* report any failed attempt to resolve a type. Well the failed attempt to resolve a type is only an issue if the purpose is to create a class file. But if it is to provide hover information, then the missing types are not fatal. It is just reduced information available to the hover information. You seem to be saying, Eclipse shouldn't use the compiler in this way, but that discussion is moot. 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). It is necessary to compile the source. But what you are describing is not really compiling the source but using the source to provide some hover information. So missing things should not blow the whole thing up since it is not a real compilation. You're missing the analogy to @NonNull. There is one more perspective between *building* o.e.osgi and *runtime*: Client compilation. Well my point is the clients should not compile against an implementation: org.eclipse.osgi. They should compile against the API. But as mentioned: this is a different discussion than how to reconcile the incomplete artifact o.e.osgi with JDT. I guess we disagree that org.eclipse.osgi is incomplete. As an implementation, it is fully complete. It should not be used as a compile time dependency. I was hoping that this list could be the place for discussing, how to improve the experience when developing Equinox bundles within the Eclipse IDE with PDE and JDT. Well I suggest that (1) JDT not have a fatal error here since the goal is not to generate a class file and (2) PDE should (a) not use manifest as a build input (but I realize that will not happen since PDE is what it is and why I don't use it) and (b) support a way to specify compile dependencies different than runtime dependencies so you can compile against OSGi API and not OSGi implementation. -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance hargr...@us.ibm.com office: +1 386 848 1781 mobile: +1 386 848 3788 ___ equinox-dev mailing list equinox-dev@eclipse.org 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 equinox-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] dependency on org.osgi.annotation?
From: Stephan Herrmann stephan.herrm...@berlin.de On 05/07/2015 05:21 PM, BJ Hargrave wrote: User has an arbitrary plugin project which obviously depends ono.e.osgi. Well I would say that no one should depend upon org.eclipse.osgi. It is an implementation of the OSGi core spec. If you are writing bundles, then you are dependent on the OSGi API and should put osgi.core and possibly osgi.annotation on your compile path. These jars are available from OSGi Alliance website, Maven Central, JCenter, ... and include their source. Are you saying no-one should use type org.osgi.framework.Bundle, forexample??? Of course not. I am saying you need to compile against API jars (e.g. osgi.core, osgi.annotation) and not against implementation jar (e.g. org.eclipse.osgi). I do this all the time (with bnd/bndtools and not PDE) and don't have the issues you raise here. You read depends and think of a dependency declared by OSGi means, but that's not what I was saying. I'm speaking of the situation of all plug-in developers using Eclipse PDE + JDT (independent of whether you like PDE or not). Well PDE is the source of the problem since it uses the manifest as both a build input and a build output. Perhaps JDT is a bit too sensitive for what it not a real compilation but instead just providing hover information. You're interpretation of compile is narrower, than what I'm talking about. Let me explain: Eclipse has a single component, which is responsible for many tasks, from creating detailed information for various views and hovers, over providing the precise semantic information for refactoring, up-to producing executable class files. We traditionally call this component the compiler. The compiler *must* report any failed attempt to resolve a type. Well the failed attempt to resolve a type is only an issue if the purpose is to create a class file. But if it is to provide hover information, then the missing types are not fatal. It is just reduced information available to the hover information. You seem to be saying, Eclipse shouldn't use the compiler in this way, but that discussion is moot. 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). It is necessary to compile the source. But what you are describing is not really compiling the source but using the source to provide some hover information. So missing things should not blow the whole thing up since it is not a real compilation. You're missing the analogy to @NonNull. There is one more perspective between *building* o.e.osgi and *runtime*: Client compilation. Well my point is the clients should not compile against an implementation: org.eclipse.osgi. They should compile against the API. But as mentioned: this is a different discussion than how to reconcile the incomplete artifact o.e.osgi with JDT. I guess we disagree that org.eclipse.osgi is incomplete. As an implementation, it is fully complete. It should not be used as a compile time dependency. I was hoping that this list could be the place for discussing, how to improve the experience when developing Equinox bundles within the Eclipse IDE with PDE and JDT. Well I suggest that (1) JDT not have a fatal error here since the goal is not to generate a class file and (2) PDE should (a) not use manifest as a build input (but I realize that will not happen since PDE is what it is and why I don't use it) and (b) support a way to specify compile dependencies different than runtime dependencies so you can compile against OSGi API and not OSGi implementation. -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance hargr...@us.ibm.com office: +1 386 848 1781 mobile: +1 386 848 3788 ___ equinox-dev mailing list equinox-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] dependency on org.osgi.annotation?
From: Markus Keller markus_kel...@ch.ibm.com I think we had the same discussion about a year ago: Bug 436469: Declare compile-time (build-time) dependencies in manifest Bug 434243: Import org.eclipse.osgi[.services] as source = compile errors for missing @ConsumerType The problem is still the same: Stephan and I think that builds a) should not be monolithic, and b) should not require external dependency information Well, first the build which makes org.eclipse.osgi is OK since it does build. The issue is with someone else's build using org.eclipse.osgi as a build dependency. The build-time (aka compile-time) dependencies do not have to be the same as the runtime dependencies. That is, if you are making a bundle and using OSGi APIs, then you should compile against the OSGi API (e.g. osgi.core, osgi.annotations) rather than against an OSGi implementation (e.g. org.eclipse.osgi). The issue here is that the build wants to build against the implementation (org.eclipse.osgi) and this causes issues for JDT trying to display information about a CLASS retention annotation which is available when building org.eclipse.osgi but not when (improperly) using org.eclipse.osgi as a compile-time dependency. It should be possible to build bundles that depend on other bundles by just pointing the build process at the bundle's sources and at its pre-built dependencies. Again, there is a distinction between compiling against API or against implementation. A bundle should compile against the API and not against the implementation. But this is currently not possible because build-time dependencies are missing in the bundle metadata. From http://www.osgi.org/Technology/WhyOSGi : The OSGi programming model realizes the promise of component-based systems. The final step to actually realize this promise would be to allow for component-based builds. Building against the same bundle you run against is not necessarily the right thing. You should compile against the lowest version of the API you need so you can run against any implementation of a compatible version of the API. That is a component based build. PDE is the source of problem here in that it treats the manifest as both an input to the build and an output of the build. This makes a proper build hard since you cannot easily specify different jars to compile against (API) than to run against (implementation). Bug 436469 suggests adding more information to the manifest to deal with this problem. bnd/bndtools is a better component build tool for Eclipse since it does not use the manifest as a build input which allows for different compile-time than runtime. -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance hargr...@us.ibm.com office: +1 386 848 1781 mobile: +1 386 848 3788 ___ equinox-dev mailing list equinox-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] dependency on org.osgi.annotation?
I'm not responding to any of that religious anti-PDE flame war which is totally inappropriate in this discussion. On 05/08/2015 10:21 AM, BJ Hargrave wrote: Well I suggest that (1) JDT not have a fatal error here since the goal is not to generate a class file Sounds like the obvious way to go, sure. Just note that reporting this kind of error is not connected to generating class files but to the semantic analysis, which indeed is desired in this use case - which only means: it's not as easy as just stopping before class file generation. Continuing compilation on broken input is a main contributor to complexity of this already very complex component. That's why avoiding unnecessarily broken input sounds like a much nicer option. and (2) PDE should ... support a way to specify compile dependencies different than runtime dependencies Well, if that's what the OSGi spec says, it shouldn't be hard to convince PDE ... Stephan ___ equinox-dev mailing list equinox-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] dependency on org.osgi.annotation?
I think we had the same discussion about a year ago: Bug 436469: Declare compile-time (build-time) dependencies in manifest Bug 434243: Import org.eclipse.osgi[.services] as source = compile errors for missing @ConsumerType The problem is still the same: Stephan and I think that builds a) should not be monolithic, and b) should not require external dependency information It should be possible to build bundles that depend on other bundles by just pointing the build process at the bundle's sources and at its pre-built dependencies. But this is currently not possible because build-time dependencies are missing in the bundle metadata. From http://www.osgi.org/Technology/WhyOSGi : The OSGi programming model realizes the promise of component-based systems. The final step to actually realize this promise would be to allow for component-based builds. Markus From: Stephan Herrmann stephan.herrm...@berlin.de To: equinox-dev@eclipse.org Date: 2015-05-07 18:17 Subject:Re: [equinox-dev] dependency on org.osgi.annotation? Sent by:equinox-dev-boun...@eclipse.org This is not helping. On 05/07/2015 05:21 PM, BJ Hargrave wrote: User has an arbitrary plugin project which obviously depends on o.e.osgi. Well I would say that no one should depend upon org.eclipse.osgi. It is an implementation of the OSGi core spec. If you are writing bundles, then you are dependent on the OSGi API and should put osgi.core and possibly osgi.annotation on your compile path. These jars are available from OSGi Alliance website, Maven Central, JCenter, ... and include their source. Are you saying no-one should use type org.osgi.framework.Bundle, for example??? You read depends and think of a dependency declared by OSGi means, but that's not what I was saying. I'm speaking of the situation of all plug-in developers using Eclipse PDE + JDT (independent of whether you like PDE or not). Perhaps JDT is a bit too sensitive for what it not a real compilation but instead just providing hover information. You're interpretation of compile is narrower, than what I'm talking about. Let me explain: Eclipse has a single component, which is responsible for many tasks, from creating detailed information for various views and hovers, over providing the precise semantic information for refactoring, up-to producing executable class files. We traditionally call this component the compiler. The compiler *must* report any failed attempt to resolve a type. You seem to be saying, Eclipse shouldn't use the compiler in this way, but that discussion is moot. 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). It is necessary to compile the source. But what you are describing is not really compiling the source but using the source to provide some hover information. So missing things should not blow the whole thing up since it is not a real compilation. You're missing the analogy to @NonNull. There is one more perspective between *building* o.e.osgi and *runtime*: Client compilation. But as mentioned: this is a different discussion than how to reconcile the incomplete artifact o.e.osgi with JDT. I was hoping that this list could be the place for discussing, how to improve the experience when developing Equinox bundles within the Eclipse IDE with PDE and JDT. Anyone? Stephan ___ equinox-dev mailing list equinox-dev@eclipse.org 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 equinox-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] dependency on org.osgi.annotation?
From: Stephan Herrmann stephan.herrm...@berlin.de 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 hargr...@us.ibm.com office: +1 386 848 1781 mobile: +1 386 848 3788 ___ equinox-dev mailing list equinox-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/equinox-dev
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.herrm...@berlin.de 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
Re: [equinox-dev] dependency on org.osgi.annotation?
This is not helping. On 05/07/2015 05:21 PM, BJ Hargrave wrote: User has an arbitrary plugin project which obviously depends on o.e.osgi. Well I would say that no one should depend upon org.eclipse.osgi. It is an implementation of the OSGi core spec. If you are writing bundles, then you are dependent on the OSGi API and should put osgi.core and possibly osgi.annotation on your compile path. These jars are available from OSGi Alliance website, Maven Central, JCenter, ... and include their source. Are you saying no-one should use type org.osgi.framework.Bundle, for example??? You read depends and think of a dependency declared by OSGi means, but that's not what I was saying. I'm speaking of the situation of all plug-in developers using Eclipse PDE + JDT (independent of whether you like PDE or not). Perhaps JDT is a bit too sensitive for what it not a real compilation but instead just providing hover information. You're interpretation of compile is narrower, than what I'm talking about. Let me explain: Eclipse has a single component, which is responsible for many tasks, from creating detailed information for various views and hovers, over providing the precise semantic information for refactoring, up-to producing executable class files. We traditionally call this component the compiler. The compiler *must* report any failed attempt to resolve a type. You seem to be saying, Eclipse shouldn't use the compiler in this way, but that discussion is moot. 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). It is necessary to compile the source. But what you are describing is not really compiling the source but using the source to provide some hover information. So missing things should not blow the whole thing up since it is not a real compilation. You're missing the analogy to @NonNull. There is one more perspective between *building* o.e.osgi and *runtime*: Client compilation. But as mentioned: this is a different discussion than how to reconcile the incomplete artifact o.e.osgi with JDT. I was hoping that this list could be the place for discussing, how to improve the experience when developing Equinox bundles within the Eclipse IDE with PDE and JDT. Anyone? Stephan ___ equinox-dev mailing list equinox-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] dependency on org.osgi.annotation?
From: Stephan Herrmann stephan.herrm...@berlin.de I was asking about the following scenario: User has an arbitrary plugin project which obviously depends on o.e.osgi. Well I would say that no one should depend upon org.eclipse.osgi. It is an implementation of the OSGi core spec. If you are writing bundles, then you are dependent on the OSGi API and should put osgi.core and possibly osgi.annotation on your compile path. These jars are available from OSGi Alliance website, Maven Central, JCenter, ... and include their source. 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. Perhaps JDT is a bit too sensitive for what it not a real compilation but instead just providing hover information. 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). It is necessary to compile the source. But what you are describing is not really compiling the source but using the source to provide some hover information. So missing things should not blow the whole thing up since it is not a real compilation. 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. It is wrong to declare a dependency from org.eclipse.osgi to the osgi.annotations since such a dependency is a runtime dependency and there is in fact no runtime dependency on these annotations. Just a compile-time dependency. And in the situation you describe, the source code does not really need to be compiled. 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? How about don't fail when you can't find something just to make hover information? :-) Currently, JDT concludes that the sourceattachment of o.e.osgi is broken. -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance hargr...@us.ibm.com office: +1 386 848 1781 mobile: +1 386 848 3788 ___ equinox-dev mailing list equinox-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] dependency on org.osgi.annotation?
Hi, 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. 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... Am I misreading something? Any suggestions how the compiler can cope with this fatal error on a published artifact? Who is supposed to use the information about this annotation? How does that instance get access to the annotation definition? FYI, the problem occurs when JDT/UI functionality requests the resolved types of methods in the given interface. thanks, Stephan ___ equinox-dev mailing list equinox-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/equinox-dev
