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 > 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.
--
|
