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
