i remember this post:
I've rarely in my life met a more overengineered, overcomplex spec than
OSGi. Compatibility with OSGi should be an anti-requirement in any sane
world.
Unfortunately we live in this world :-(
Gavin King
[
http://in.relation.to/22155.lace]
Fiorenzo
PS i never used osgi in my jee apps, and i hate my eclipse when i need
to restart it after a plugin installation...
2012/9/25 <ggastald(a)redhat.com>
Hello,
I've been done some thinking and researching for Forge 2.0 based on the
last forge meeting we had and the current code in the 2.0 branch, and it
seems that the architecture we're looking for is very close to OSGi
architecture itself (regarding to plugability and modularity).
I'm also afraid that we'll face the same problems that OSGi tries to
solve. As my current experience with OSGi is next to minimal (and probably
to better understand why and have some arguments if someone asks me about
it), I would like some opinions about the advantages/disadvantages of why
not having the Forge container as an OSGi compliant solution.
Also, don't get me wrong: I am not trying to convince anyone of using OSGi
into the forge core, just want to understand better why this architecture
is not a viable solution so far. I know Lincoln is against using it, but I
just want some arguments in case someone asks me in conferences and stuff :)
Of course, we need to keep using CDI and annotations as well. So if it's
possible to have that and at the same time the modularity (and plugability)
offered by OSGi, it would be awesome.
Looking forward for your answers !
Best Regards,
--
*George Gastaldi* | *Senior Software Engineer*
JBoss Forge Team
Red Hat
_______________________________________________
forge-dev mailing list
forge-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev