[forge-dev] Fwd: In Relation To... Not one, two Weld releases - 1.1.10.Final and 1.2.0.Beta1 !!
fruehbeck at aon.at
Tue Oct 16 03:14:50 EDT 2012
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
* 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
- 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
- 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
* 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
- 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!
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:
> 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.
> On Oct 15, 2012, at 23:47 , "Lincoln Baxter, III"
> <lincolnbaxter at gmail.com <mailto:lincolnbaxter at 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!!!
>> On Mon, Oct 15, 2012 at 5:40 PM, Paul Bakker
>> <paul.bakker.nl at gmail.com <mailto:paul.bakker.nl at 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the forge-dev