directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John E. Conlon" <jcon...@verticon.com>
Subject Re: [OSGi] Implementing OSGi for 1.5
Date Sat, 10 Feb 2007 22:37:39 GMT
David Jencks wrote:
> IMO if including the osgi metadata in the jars won't break anything 
> else we should put it in right away.  
That is the idea. Just an accommodation to OSGi metadata right now.
> It doesn't need to work completely or even partially.  I think that 
> one of the benefits of the osgi effort even for non-osgi uses is that 
> it encourages cleaner division of responsibility between jars and 
> again IMO anything that makes problems in this area visible even if 
> they don't get fixed immediately is a good thing.
Right.  And more importantly the meta data generated by the plugin will 
increase our visibility down to the package level as well.  This by 
itself is a side benefit which can then be used to decrease decoupling 
down to packages.  The metadata can then be tuned to specify which 
packages are exported for public consumption and which are private.  
When loaded in  an OSGi runtime this decoupling to the package level is 
enforced by the metadata driven OSGi classloader matrix.  This is what 
give OSGi applications the uptime longevity - they can be updated on the 
fly.
>
> I would not support forcing anyone to change their coding style for 
> public/private method access, use of getter/setters etc in order to 
> use OSGI.  
The same jars and packages still work as usual.  Coding styles are all 
the same.

I expect as people see the advantages of a cleaner division of 
responsibility that OSGi brings not only at the module (jar) level but 
at the package level as well we can expect to see movement from just an 
OSGi accommodation to a full commitment. 

But they have to see the initial benefits first.
> I do think that generating classloading metadata is a good thing.
thanks for your comments,
John

Mime
View raw message