Re: [Aperture-devel] [smila-dev] AW: Aperture bundlization for SMILA

[Antoni M. <ant...@gm...>]

A reply to aperture-dev:

2009/1/26 Antoni Mylka <ant...@gm...>:
> 2009/1/26  <Dan...@em...>:
>> Hi all,
>>
>> with the fixes provided by Antoni I managed to get the "bundelized"
>> aperture to run in Smila.

Leo, Christiaan, the discussion about coarse vs. fine grained bundles
has been going in circles for more than two years now. The current
solution, with selectors.xml is a kludge. We create some bundles but
the only way to tell if they work is to deploy them in an app and see
what happens. These are hundreds of manifest entries (Import-Package,
Export-Package, versions, ids etc). All this for three aperture
bundles, rdf2go, sesame, and third-party libs. I announced the first
version of the smila-prep-branch on 14.12.2008 - a month ago and it
started to work only now.

I say that if we have 20 bundles instead of 3 it will be VERY
difficult to produce a working release at all with the current source
layout.

I proposed a compromise on
http://www.dfki.uni-kl.de/~mylka/aperture-smila-test.tar.gz with three
bundles the core, impl and contrib. Impl is clear to use in eclipse,
contrib is not. All the libs are either in the 'inlib' subofolder of
each module or packaged into a target platform. The inlibs go INTO the
generated bundle jars, the target platform goes directly into the
distro. If a component is cleared with ESF, we can just move the
files, without changing anything in ant scripts

If we really want to make a proper division of concerns between
modules, we'd need something similar to the maven setup Aduna did for
Sesame (many small modules AND the ability to build a onejar),
together with the ability to generate OSGI manifests, for each of them
and include them in a PDE workspace, I say generate and not store them
in SVN for manual maintenance. Two years ago the state of OSGI tools
was different. Now the bnd is nice enough, I use it to generate the
sesame bundle and it works.

So there are three ways:
1. Aduna experience + research into maven-osgi problems = 45 bundles.
(don't know if we'll be able to use PDE though, the concept of a
target platform requires all jars to be in a single folder, while
maven wants each jar to be in the repository - don't know if they
sorted it out).
2. My compromise solution -
http://www.dfki.uni-kl.de/~mylka/aperture-smila-test.tar.gz = 4
bundles (core,impl,contrib,example), it will take a day or two to
solve all minor issues, to make all tests pass and to prepare
everything, you can still work on it in eclipse as a single project,
just as you do now, if you don't want osgi, the only thing you need to
endure are 8 or 9 source folders instead of 4. If you want to work on
OSGI, set up another workspace according to instructions and you can
use PDE.
3. Status quo - selectors.xml, manual maintenance, more difficult
testing and lower quality.

-- 
Antoni Myłka
ant...@gm...