<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hello Paul, Lincoln,<br>
<br>
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?<br>
<br>
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 :-)<br>
<br>
* 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 <br>
- after some frustrating experiments and reading of the
documentation (dating 2006?!?) ~20 times I debugged and fixed the
problem<br>
- 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>"<br>
<br>
* 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<br>
- after ~15 years of programming thats now the 15th
version of project structure - not again please?!<br>
<br>
* the current state of jars in maven repositories out there
makes integration into OSGi a nightmare!!<br>
- wrong manifests<br>
- manifests full of hundreds of Attributes - totally
useless<br>
- manifests importing dependencies without declaring them
"optional" - please investigate each and every dependency yourself
and rewite them<br>
- manifests declaring dependencies with version
restriction which is not provided by the targeted bundle<br>
- what a mess :-/<br>
- IMHO in essence the current state makes the
OSGi-landscape an island<br>
<br>
* 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<br>
<br>
* 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<br>
<br>
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.<br>
<br>
So I also want to stress the necessity of a "Manifest" for the
"Forge goes OSGi" project - if there is one:<br>
- try hard to stick to maven as build environment. Reasons:
user base, documentation, stability, versatility<br>
- CDI is IMHO the new common understanding, stick to it
please. No OSGi on the surface.<br>
- define precisely the core / plugin bundle interaction<br>
- e.g. from the view point of the "user" we could <br>
- 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<br>
- present a dialog: "which version of core do you want
to start" to enable use of new and old plugins<br>
- tell her that she has lots of plugins, but due to
the version of core none of them are usable<br>
- 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,..<br>
<br>
Sorry if that was not very productive, after 3 weeks of struggling
just had to write that down :-)<br>
Are you experts smiling? At least I hope you do!<br>
<br>
Thanks for your time, commitment and the incredible Forge!<br>
<br>
Forge on,<br>
Thomas<br>
<br>
<br>
<br>
<br>
Am 15.10.2012 23:55, schrieb Paul Bakker:<br>
</div>
<blockquote
cite="mid:9DB8495B-4484-43C5-A591-67332A32DB3E@gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div>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: <a moz-do-not-send="true"
href="http://felix.apache.org/site/apache-felix-dependency-manager-getting-started.html">http://felix.apache.org/site/apache-felix-dependency-manager-getting-started.html</a>.</div>
<div>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. </div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Paul</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<br>
<div>
<div>On Oct 15, 2012, at 23:47 , "Lincoln Baxter, III" <<a
moz-do-not-send="true" href="mailto:lincolnbaxter@gmail.com">lincolnbaxter@gmail.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">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?<br>
<br>
Sorry for all the tough questions :) Thanks for your time!!!<br>
<br>
~Lincoln<br>
<br>
<div class="gmail_quote">On Mon, Oct 15, 2012 at 5:40 PM, Paul
Bakker <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:paul.bakker.nl@gmail.com" target="_blank">paul.bakker.nl@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">It provides several
things:
<div>-Publish OSGi services using CDI annotations</div>
<div>-Inject OSGi services in CDI beans using @Inject</div>
<div>-Inject OSGi APIs such as the bundlecontext using
@Inject</div>
<br>
</div>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
<br>
</body>
</html>