David Jencks wrote:
On Oct 27, 2008, at 1:15 PM, Chris Custine wrote:
Hi Guys,
As an interim step to eventually deploying inside an OSGi container,
I have started working out packaging the jar files as OSGi bundles
just to see how much work it will be. The idea is that in the short
term nothing should affect ongoing development because the bundle
packaging is just some modifications to the module pom.xml files
which add the OSGi headers to the MANIFEST.MF files at build time.
In doing this I have realized that there are quite a few cases of
split packages where two (sometimes three or more) projects have
classes in the same package. This is important for the OSGi
packaging because package names are the primary descriptor for
importing and exporting code from bundles and if more than one bundle
exports from the same package there is quite a bit more work to
maintaining the packaging configuration (in this case, a plugin
config in the pom.xml). One big example is the
org.apache.directory.server.core.partition.* packages which are
contained in multiple partition implementations as well as
apacheds-core.
So my first question is if this is something that we want to discuss
and start taking care of now? There are several solutions obviously,
and it is quite possible that we can work around this with hand
crafted packaging descriptors for the OSGi bundles. This is a bit of
work however and long term maintenance of the packaging will be much
higher. Other options include re-organizing packages to have more
unique structure (my personal preference), or we could also combine
some of the scattered code into consolidated jar files.
Any input or alternative ideas?
IMO fixing this so that all classes from a package are in the same jar
is the way to go, and sooner is better. I think that looking
carefully at what is misplaced will be needed to determine if changing
the package name or moving the class is a better solution.
Here are the projects which are sharing the same package :
apacheds/core & apacheds/xdbm-base
are sharing
org/apache/directory/server/core/partition/impl/btree
apacheds/core & apacheds/jdbm-store
are sharing
org/apache/directory/server/core/partition/impl/btree/jdbm
apacheds/core-shared, apacheds/schema-bootstrap & apacheds/schema-extras
are sharing
org/apache/directory/server/schema/bootstrap
There is not so much we can do with the last example, as this code is
pretty generic, and _must_ be in the same package, even if not in the
same project. However, they are closely related. For the two previous
cases, core, xdbm-base and jdbm-store are also closely related.
I don't know how possibly I can help with this issue, except that I
think they should be delivered as a single OSGi assembly, as it does not
make sense to load core without loading at the same time jdbm-store and
xdbm-base.
My guess (but I know nothing about OSGi), is that Guillaume is close to
the best possible solution : consider the project not as an assembly of
50 small elements, but as 4 or 5 projects (apacheds, shared,
protocol-XXX, etc)
I don't know if it helps ...
PS : I extracted those info with grep, sed, and OpenOffice spreadsheet.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
