| Re: [e4-dev] Dependency Preference and Versioning |
Versioning packages is good from an Import-Package consumption point
of view. You are correct in stating that it is senseless to use
Import-Package for eclipse API packages which are not versioned.
We attempt to version packages in the Equinox project but I think
we are the exception to the rule in Eclipse. We need really need
tooling to help us manage our package versions.
See https://bugs.eclipse.org/bugs/show_bug.cgi?id=215073
Without tools I do not see how mere mortals are going to get
it correct. We barely get by with versioning at the bundle level.
Dare I mention ICU4J version hell or the other package versioning
issues we are dealing with in orbit?
Tom.
> Tom Schindl wrote:
>
> Hi,
>
> I don't know whether we have thought about this already but the
> discussion and the conclusion that Require-Bundle is bad make it
> necessary that we provide people a possibility to use import-package in
> the 3.x appropriately by versioning our packages!
>
> One can currently use import package against 3.x bundles but can't
> define a version so it renders it quite senseless. I think most of the
> runtime-project already version their packages but e.g. at platform-ui
> bundles we don't which is bad. I'd for example like to use import
> package to use the databinding libs but I need to stay with
> Require-Bundle because I can't define a version.
>
>
> Tom
>
> Jeff McAffer schrieb:
> > People who use Require-Bundle are doing so at risk of having to change
> > their manifests later if packages move. We had all manner of "facading"
> > going on in the 3.0 timeframe because Require-Bundle is all you had
> > before then. That was 5 years ago. Would be great if we got with the
> > program and started supporting/using Import-Package more.
> >
> > As for the Java centricness of all this... OSGi is a Java technology.
> > At least currently. As Tom Watson alluded to in another post, there is
> > a mechanism in Equinox for expressing generic capabilities and
> > requirements. this can be used to talk about non-Java things in a
> > pretty comprehensive way. That is not currently supported by p2 but its
> > just the translation that is missing. p2 is completely based on generic
> > capabilities.
> >
> > As for require-bundle and extension points, NO. This is one of the
> > "great myths" of Eclipse. for the most part OSGi only knows/cares about
> > classloading. The bundle contributing an extension that identifies a
> > class is asked to load that class using normal classloading mechanisms.
> >
> > Jeff
> >
> >
> > Boris Bokowski wrote:
> >>
> >> Tom Schindl wrote on 01/14/2009 12:31:32 PM:
> >>
> >> > ....
> >> > > Yes, whenever you move packages between bundles, the original
> >> bundle has
> >> > > to Require-Bundle the new one and re-export it.
> >> > >
> >> >
> >> > But this is not needed if I use Import-Package because then OSGi handles
> >> > this for me or am I completely mistaken?
> >>
> >> You are right, clients who use Import-Package are not affected. But
> >> since there is no way of stopping clients from using Require-Bundle to
> >> depend on your bundle, you will have to do the re-export.
> >>
> >> All of this still feels too Java-centric to me...
> >>
> >> Boris
> >>
> >> ------------------------------------------------------------------------
> >>
> >> _______________________________________________
> >> e4-dev mailing list
> >> e4-dev@xxxxxxxxxxx
> >> https://dev.eclipse.org/mailman/listinfo/e4-dev
> >>
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > e4-dev mailing list
> > e4-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/e4-dev
>
>
> --
> B e s t S o l u t i o n . a t EDV Systemhaus GmbH
> ------------------------------------------------------------------------
> tom schindl leiter softwareentwicklung/CSO
> ------------------------------------------------------------------------
> eduard-bodem-gasse 8/3 A-6020 innsbruck phone ++43 512 935834
> _______________________________________________
> e4-dev mailing list
> e4-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/e4-dev