[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[equinox-dev] Re: [osgi-dev] Interoperability problems...


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/IBM@IBMUS
Sent by: osgi-dev-bounces@xxxxxxxxxxxxx

03/20/2007 09:59 PM

Please respond to
OSGi Developer Mail List <osgi-dev@xxxxxxxxxxxxx>

To
cc
OSGi Developer Mail List <osgi-dev@xxxxxxxxxxxxx>
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
hargrave@xxxxxxxxxx

office: +1 386 848 1781
mobile: +1 386 848 3788




"Niclas Hedhman" <niclas@xxxxxxxxxxx>
Sent by: osgi-dev-bounces@xxxxxxxxxxxxx
03/20/2007 10:28 PM
Please respond to
OSGi Developer Mail List <osgi-dev@xxxxxxxxxxxxx>


To
"OSGi Developer Mail List" <osgi-dev@xxxxxxxxxxxxx>
cc

Subject
Re: [osgi-dev] Interoperability problems...








On 3/20/07, Thomas Watson <tjwatson@xxxxxxxxxx> 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
osgi-dev@xxxxxxxxxxxxx
http://www2.osgi.org/mailman/listinfo/osgi-dev

_______________________________________________
OSGi Developer Mail List
osgi-dev@xxxxxxxxxxxxx
http://www2.osgi.org/mailman/listinfo/osgi-dev