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

[BJ Hargrave <hargrave@xxxxxxxxxx>]

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