> 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
