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:
First of all I don't think it should be a requirement, you can
get a
very similar programming model doing pure OSGi. The alternative I use
most is Felix DM:
http://felix.apache.org/site/apache-felix-dependency-manager-getting-star....
You can either use a Java API or annotations (probably we should use
annotations). It can do pretty much everything CDI can, but based on
OSGi services.
I'm obviously not against CDI at all, I'm a big fan of it, just think
we should be careful using a framework that will most probably change
significantly in the next few months. But before making that choice,
maybe we should include Mathieu and David in this discussion.
Paul
On Oct 15, 2012, at 23:47 , "Lincoln Baxter, III"
<lincolnbaxter(a)gmail.com <mailto:lincolnbaxter@gmail.com>> wrote:
> Since CDI annotations is a requirement, isn't this something we will
> need? What do you recommend as an alternative? What is it missing
> that would be a blocker?
>
> Sorry for all the tough questions :) Thanks for your time!!!
>
> ~Lincoln
>
> On Mon, Oct 15, 2012 at 5:40 PM, Paul Bakker
> <paul.bakker.nl(a)gmail.com <mailto:paul.bakker.nl@gmail.com>> wrote:
>
> It provides several things:
> -Publish OSGi services using CDI annotations
> -Inject OSGi services in CDI beans using @Inject
> -Inject OSGi APIs such as the bundlecontext using @Inject
>