[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] dependency on org.osgi.annotation?

> From: Stephan Herrmann <stephan.herrmann@xxxxxxxxx>

> 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

office: +1 386 848 1781
mobile: +1 386 848 3788