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.herrm...@berlin.de> To: equinox-dev@eclipse.org Date: 2015-05-07 18:17 Subject: Re: [equinox-dev] dependency on org.osgi.annotation? Sent by: equinox-dev-boun...@eclipse.org 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@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________ equinox-dev mailing list equinox-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/equinox-dev
