Thanks for trying :-) Comments in line...
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>"
Use BndTools instead. There is a wizard "Wrap JAR as OSGi bundle"
* 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?!
Don't try playing with bndtools projects without bndtools. That's like playing with Maven projects without Maven ;-)
BndTools projects are structured as standard Eclipse projects, only the dependency management is done by BndTools (and that's why you should not try to work around that).
* 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
Depending on what you are trying to use this can be the case unfortunately. It's getting better though, more and more libraries come with correct manifests. It's mostly a problem with frameworks (as opposed to libraries). The up-side is that plugin developers will hardly ever introduce frameworks in their plugins, because Forge already offers an easy programming model.
* 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
Isolated classloading is a complicated topic in any modular approach, as an application developer you hardly ever have to deal with that level however.
* 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.
The currently programming model is easy because (mostly Lincoln) did all kind of CDI magic to create this programming model. Out of the box it's really not that easy when looking at just the low-level building blocks. It's the same when we build on OSGI, we have to provide the easy programming model. I strongly believe that it will be as easy as it is now.
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
You are right about the user base, but for the rest it's really very similar.
- 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:
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
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@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