[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[smila-dev] AW: [Aperture-devel] Aperture bundlization for SMILA
|
Hi all,
> -----Ursprüngliche Nachricht-----
> Von: Antoni Mylka [mailto:antoni.mylka@xxxxxxxxx]
> Gesendet: Sonntag, 14. Dezember 2008 19:10
> An: Aperture Devel
> Betreff: [Aperture-devel] Aperture bundlization for SMILA
>
> I've committed a preliminary version of the new build setup to a
> smila-prep-branch. Just type ant osgirelease, and you should get three
> bundles core, impl and safe. Core is the same as it was, safe means
> all implementation stuff that works with "safe" libraries submitted by
> Daniel. Impl is the rest. Safe does not contain any embedded jars -
> depends on external bundles via Import-Package, impl contains embedded
> jars.
>
> It works more-or-less. If you spot problems - send an email to
> aperture-dev.
>
> Javamail from orbit is based on implementations from the geronimo
> project, which don't work. We get about 50 test failures. Didn't
> investigate further.
I have created two new bundles javax.activation 1.1.1 and javax.mail 1.4.1 from the glassfish release and updated the zip file at http://demo1.brox.de/aperture-plugins.zip. These are the newest releases and are licensed under CDDL. There are also older versions available, but I'm not sure under which license these are released.
Could you please check if these bundles work for aperture ?
> The requirement from the eclipse foundation
> - all dependencies available as separate jars with separate osgi
> headers
> - all dependencies have undergone the CQ process and are available in
> orbit
> ... is draconian from our point of view.
There are some misunderstandings:
- it is not required by the eclipse foundation to provide every jar as a separate bundle. As SMILA is based on OSGi we decided to use this approach as a best practice. It emphasizes modularization and allows for selective updates of bundles. We tried to integrate apache Tuscany into SMILA, which at that time had one large 3rd party bundles with all dependencies in it, and failed. Lots of classloading problems occurred. They just started to provide smaller bundles ...
- it is also not required to contribute all bundles to Orbit. In fact, we only want to contribute bundles to Orbit that are of general interest to the community (e.g. apache commons* bundles). We recently had requests for Javax XML Bind, JAXBand Joost STX processor.
Bye,
Daniel