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 <[email protected]> wrote: > > > From: Stephan Herrmann <[email protected]> > > > 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 > [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
