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

I think we had the same discussion about a year ago:

Bug 436469: Declare compile-time (build-time) dependencies in manifest
Bug 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 information

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.
From http://www.osgi.org/Technology/WhyOSGi :
"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.

Markus



From:        Stephan Herrmann <stephan.herrmann@xxxxxxxxx>
To:        equinox-dev@xxxxxxxxxxx
Date:        2015-05-07 18:17
Subject:        Re: [equinox-dev] dependency on org.osgi.annotation?
Sent by:        equinox-dev-bounces@xxxxxxxxxxx




This is not helping.

On 05/07/2015 05:21 PM, BJ Hargrave wrote:
>  > User has an arbitrary plugin project which obviously depends on o.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, for example???
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).


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

Anyone?

Stephan
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev