[forge-dev] Fwd: In Relation To... Not one, two Weld releases - 1.1.10.Final and 1.2.0.Beta1 !!

[Thomas Frühbeck]

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-started.html.
> 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 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!!!
>>
>> ~Lincoln
>>
>> 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...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20121016/fb50684a/attachment.html