I think we had the same discussion about
a year ago:
436469: Declare compile-time (build-time) dependencies
434243: Import org.eclipse.osgi[.services] as
source => compile errors for missing @ConsumerType
The problem is still the same: Stephan
and I think that builds
a) should not be monolithic, and
b) should not require external dependency
It should be possible to build bundles
that depend on other bundles by just pointing the build process at the
bundle's sources and at its pre-built dependencies.
But this is currently not possible because
build-time dependencies are missing in the bundle metadata.
"The OSGi programming model realizes
the promise of component-based systems."
The final step to actually realize this
promise would be to allow for component-based builds.
Stephan Herrmann <stephan.herrmann@xxxxxxxxx>
dependency on org.osgi.annotation?
This is not helping.
On 05/07/2015 05:21 PM, BJ Hargrave wrote:
> > User has an arbitrary plugin project which obviously depends
> 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, for example???
You read "depends" and think of a dependency declared by OSGi
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).
> 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
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.
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
> > "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*:
But as mentioned: this is a different discussion than how to reconcile
the incomplete artifact o.e.osgi with JDT.
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.