[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
hargrave@xxxxxxxxxx

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