The RI shipped by the OSGi Alliance is configured to be a strict OSGi Framework. To launch the official RI from OSGi you must follow the instructions provided by the OSGi Alliance. That will give you a strict OSGi Framework. Changing Equinox to default to a strict OSGi Framework and then force Eclipse to configure it for its needs will cause issues for all Eclipse clients and applications. All of the Eclipse clients/applications will have to be reconfigured when they are upgraded to the latest Equinox that is now strict. That is something I'm sure the Eclipse community would not enjoy.
Tom BJ Hargrave/Austin/[EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 03/20/2007 09:59 PM Please respond to OSGi Developer Mail List <[email protected]> To cc OSGi Developer Mail List <[email protected]> Subject Re: [osgi-dev] Interoperability problems... Lets move this discussion to the equinox-dev list. I can see the point that by default Equinox is strict and Eclipse sets the proper Equinox options to enable the more relaxed mode it requires. BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] office: +1 386 848 1781 mobile: +1 386 848 3788 "Niclas Hedhman" <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 03/20/2007 10:28 PM Please respond to OSGi Developer Mail List <[email protected]> To "OSGi Developer Mail List" <[email protected]> cc Subject Re: [osgi-dev] Interoperability problems... On 3/20/07, Thomas Watson <[EMAIL PROTECTED]> wrote: Thanks for the history lesson... Unfortunately this change to boot delegation has serious backwards compatibility issues for stack products running on top of Eclipse. Remember the Equinox team has no control over what products do and the Equinox team cannot easily force them to change. In many cases the Eclipse teams are completely unaware of who is using the platform. The Equinox team tried very hard to be a "strict" OSGi R4 framework out of the box in the Eclipse 3.1 release, but ran into many issues where bundles did not work because they assumed the Framework would always delegate to boot first (after all that is what the R3 spec says right?). But hold on a second here... The main reason that Equinox is not (IMO) compliant with the specs out of the box, is that the Equinox usage in Eclipse require various settings to work. Isn't that backwards? Shouldn't The Reference Implementation be "strict" and that either the Eclipse team or Equinox folks acting on behalf of the Eclipse team, tailor Equinox to their need? What I am trying to say; I have no problems that Equinox is 'different' or has 'special defaults' to accommodate Eclipse. I do have a problem that it is also called the Reference Implementation, because that gives signals (implies) to my customers(!) (and potentially vendors in the future) that if a bundles run on Equinox, the bundle is not faulty, even though it is. For the Eclipse 3.3 release we are once again trying to disable bootdelegation=* (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=162231 ). This attempt is adding a last resort boot delegation, but this change still is causing us a significant amount of issues (most of which we are working through). If we change Equinox to be "strict" WRT boot delegation then a true riot will occur among the community expecting each version of Eclipse to be backwards compatible with the last (the Equinox team experienced this in Eclipse 3.1 when it was tried). Yeah, see above. I understand your situation, and I have no problem with that. Note that I didn't bring this discussion to equinox-dev, since I don't think this is a Equinox "problem", but a "problem" with Equinox being the Reference Implementation. I see two possible actions; 1. Equinox is not the Reference Implementation (big work item) 2. Equinox comes in two flavours, the RI and the delivery for Eclipse. Cheers -- Niclas Hedhman, Software Developer I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug _______________________________________________ OSGi Developer Mail List [email protected] http://www2.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List [email protected] http://www2.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________ OSGi Developer Mail List [email protected] http://www2.osgi.org/mailman/listinfo/osgi-dev
