Re: [architecture] Geronimo and OSGi

["Richard S. Hall" <heavy@xxxxxxxxxxxxxx>]

Jean-Bernard Stefani wrote:

> Just a small reaction on one bit of creeping misunderstanding. Sorry 
> to pick on you Pierre-Yves, but there is no 'Fractal vs OSGI' issue at 
> OW in my opinion, only people who do not understand the difference 
> between Fractal and OSGI. Also, lying beneath this sort of remark is 
> the implicit statement that the 'insistence' of Fractal in OW is 
> somehow preventing OW projects to use useful technology: This is just 
> not true since no one to my knowledge has ever been forced to use 
> Fractal. And the JOnAS tema is sovereign in deciding where he wants to 
> go. But let's set the record straight once and for all.
>
> OSGI is primarily a packaging technology. It only allows you to 
> capture a small part of your software' architecture (via export and 
> import clauses), and to deploy it locally.


I agree that the two technologies are not really competitors and this 
has been the position of LSR since the beginning concerning OSGi and 
Fractal. But it is possible that some of this "competition confusion" 
was fostered by certain decisions and approaches taken within our 
community. For example, the insistence that Fractal should be on the 
bottom of everything else, even though OSGi's reliance on class loaders 
clearly puts it pretty close to the bottom (as far as Java is 
concerned)...we have long described OSGi as a "super" class loader.

From my perspective, this belief was particularly evident in the 
"Fractal deployment" effort from a little while back. I would have 
thought that the best direction to go would have been to define a 
standard way to package Fractal components into OSGi bundles, but the 
pursued direction was not so simple and it was my understanding that 
this was because of the belief that Fractal should be on the bottom.

To be clear, I am not saying one approach is right or wrong, but if we 
have failed at many opportunities to define the complementary nature of 
these two technologies.

-> richard