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
