Hello Paul, Lincoln,

since the discussion started about moving to OSGi I have been reading, investigating and experimenting a bit and want to share my experiences as a novice - are you smiling already?

I started with the current working Forge set of jars and tried to throw it at Felix - hindlooking somewhat naive I admit. Then the adventure started :-)

    * the BndTools 2.0.0 alpha command line "wrap" generated the new Manifest internally, but didn't write it into the jar in the end
        - after some frustrating experiments and reading of the documentation (dating 2006?!?) ~20 times I debugged and fixed the problem
        - comment by Peter Kriens: command line "wrap" is "for quick use, for serious use, always make a bnd file that controls the process" - which practically means: best write the Manifest yourself, honestly I can't see so much difference between calling "jar ufm <jar> <manifest.part>" and "bnd <bndfile> -o <jar> <jar>"

    * the structure of Bnd-projects is totally different to maven projects - I tried to setup the bnd source whithout Bnd-Tools, this is _no_ fun
        - after ~15 years of programming thats now the 15th version of project structure - not again please?!

    * the current state of jars in maven repositories out there makes integration into OSGi a nightmare!!
        - wrong manifests
        - manifests full of hundreds of Attributes - totally useless
        - manifests importing dependencies without declaring them "optional" - please investigate each and every dependency yourself and rewite them
        - manifests declaring dependencies with version restriction which is not provided by the targeted bundle
            - what a mess :-/
        - IMHO in essence the current state makes the OSGi-landscape an island

    * after reading the IMHO excellent book "OSGi in Action" @Manning I understand, that the resulting class loading inside the framework is far from easy to understand, if you go only one level deeper into the real mechanics - it's still no magic going on there

    * it's all about control - yes, sure, I understand that - but in the end we have to hide the complexity completely! After so many years of struggle I do not expect all Java programmers to gladly jump on the OSGi bandwaggon just because of the advent of Forge 2.0

I am completely convinced, that OSGi is the best currently available instantiation of a framework we want in a tool like Forge, but the current situation makes the move substantial and painful - compared to the current easy going programming model.

So I also want to stress the necessity of a "Manifest" for the "Forge goes OSGi" project - if there is one:
    - try hard to stick to maven as build environment. Reasons: user base, documentation, stability, versatility
    - CDI is IMHO the new common understanding, stick to it please. No OSGi on the surface.
    - define precisely the core / plugin bundle interaction
        - e.g. from the view point of the "user" we could
            - present a version of core internally for each major version of dependent plugins to enable her to use old and new plugins side-by-side
            - present a dialog: "which version of core do you want to start" to enable use of new and old plugins
            - tell her that she has lots of plugins, but due to the version of core none of them are usable
        - due to the nature of OSGi I am convinced, that a great deal of thought should be invested in the _vision_ we have of Forge before starting the hacking sessions - especially regarding the current state of it: versatile, flexible, open, based on sound tooling,..

Sorry if that was not very productive, after 3 weeks of struggling just had to write that down :-)
Are you experts smiling? At least I hope you do!

Thanks for your time, commitment and the incredible Forge!

Forge on,
Thomas




Am 15.10.2012 23:55, schrieb Paul Bakker: