OSGi would definitely NOT be overkill for something like Forge. My only concern is
compatability, but if we can break that, it's certainly something to consider
seriously. How would you feel using bndtools for Forge development if we go this way? It
would really speed up development, but on the down side force people to use eclipse (for
core development, plugins doesn't matter).
Paul
Sent from my iPhone
On 26 sep. 2012, at 07:38, George Gastaldi <ggastald(a)redhat.com> wrote:
Hi Paul !
I watched your presentation and I found it very nice. As in Forge 2.0, we are totally
rewriting the core, so full backward compatibility shouldn't be possible in a first
glance.
Lincoln already started something in the 2.0 branch using JBoss Modules and also started
to hack it a little deeper.
As for me, I am also not a big fan of JBM, probably because it may be lacking some
reference docs, which leads to deep diving into the code itself to better understand it.
In terms of being future-proof, OSGi might sound a better path to go. However I am afraid
that we may be wanting to kill a mosquito with a cannon, or in other words, trying to cram
a technology which may hinder the adoption on Forge in future versions.
In case we adopt it, I hope that in the future this bnd plugin could be part of JBoss
Tools and we could call it "Forge Developer Platform" or something :)
Anyway, we should focus on making things simple, but powerful. Maybe we should schedule a
meeting to discuss about it anytime.
Many thanks for all your points of view so far !
Best Regards,
George Gastaldi
Em 26/09/2012, às 00:40, Paul Bakker <paul.bakker.nl(a)gmail.com> escreveu:
> When using OSGi you should not deal with injection or package imports by hand.
Package imports should be calculated by byte code analysis (bnd does this). Injecting
services should be done with a DI framework such as Felix DependencyMAnager (that's
what I use mostly) or declarative service annotations for example. The fact that you can
lookup services by hand using the low level Apis doesn't mean you should... ;-)
>
> For building stuff you could either use the Bnd plugin in maven (by default it only
imports packages that you really use, using byte code analysis). Even better would be
switching to BndTools. This is an eclipse plugin specially for OSGi development. It gives
hot code reloading etc, no more slow maven builds to see your changes! See my talk to see
this in action :-)
>
> I don't like JBM because its not doing enough; e.g. no dynamic services. Besides
that, OSGi exists for a long time and has proofed to work well. There is a lot of
documentation, books etc. JBM is still very much an internal JBoss thing, and almost
nobody knows anything about it. I can understand why AS7 required a custom solution, but
Forge has very different requirements.
>
> Still, not sure it's feasible to start using OSGi for Forge at this point. It
would have a lot of impact...
>
> Paul
>
> Sent from my iPad
>
> On Sep 25, 2012, at 11:43 PM, "Ivan St. Ivanov"
<ivan.st.ivanov(a)gmail.com> wrote:
>
>> Hi,
>>
>> I'd like to share my point of view here as well. Before doing that, let me
state some things:
>>
>> * I don't like OSGi, but I will try to be as objective as possible
>> * I have some (though little) experience with OSGi and with some of its
Eclipse's extensions (tycho, p2, equinox)
>>
>> In my opinion, if you are an application developer (or in our case, plugin
developer), you should take care about OSGi as little as possible. You just need to
[@]Inject your dependencies to the core and forget. No nasty import packages declarations
in manifest files, not even nastier [declarative] services declaration via OSGI-INF.XML or
even worse - looking them up from the service tracker (I think the JNDI was forgotten in
Java EE 5?). Yes, I also heard that there were some efforts that DI for Java, or even CDI
annotations were brought to OSGi. But are you sure that it will work right now?
>>
>> That was about plugin development. As for the server (or in our case Forge core)
development, I am sure we definitely need some kind of a modular runtime. Its basic idea
is to take the burden of classloading and version management from us. It doesn't
matter whether it is OSGi, JBoss Modules or whatever you say. Just take this burden out of
Forge. So we have to now decide which solution better suites us.
>>
>> If we decide to choose OSGi, then let's speculate on how we build and
assemble Forge. We are apparently using Maven for that. But Maven understands its own
dependencies, not those in OSGi's manifests. So we have three options here:
>>
>> 1) Duplicate the dependencies declarations in pom.xml and in manifest files.
Stupid I would say...
>> 2) Use Maven's bnd plugin to create our manifest files based on the
dependencies declared in the pom.xml. I'm not sure though whether this plugin would
allow us to import and export only the packages that we want to. By default it imports
everything and (which is worse) exports everything
>> 3) Use Maven's tycho plugin. It teaches Maven how to use your manifest files,
so you don't need to declare dependencies in pom.xml in parallel to importing
packages. However with tycho you enter the Eclipse world of OSGi. Which means that we have
to create a special target platform maven project. And should rewrite our dist project
from scratch. And we'll have to find special repositories for all our dependencies
(standard Nexus repositories don't work to my knowledge, they have to support the p2
protocol). And will have to pray to God every time we run a build that our dependencies
are found. Because guessing the reason for a failure to find a dependency is sometimes
harder than guessing the numbers of the lottery. My opinion: the worst option!
>>
>> So, after this long post, my final question is: what is that you don't like
in JBoss modules so that you want to replace it with OSGi? Because I also think that
having them both working together is not necessary and is a bit overkill.
>>
>> Cheers,
>> Ivan
>>
>> On Tue, Sep 25, 2012 at 1:05 PM, Paul Bakker <paul.bakker.nl(a)gmail.com>
wrote:
>>> Let's make sure I understand your question. The scenario would be as
follows:
>>> -Forge core services have some state shared with plugins
>>> -There are plugins using this service
>>> -A core service gets unregistered (software update for example)
>>> -What happens with the plugin?
>>>
>>> I would say, the plugin should get unregistered as well, and register again
as soon as the core service comes back. This might sound tricky (it is if you do service
registration by hand), but is trivial when using something like Felix Dependency Manager.
>>> If the shared data is in-memory it will be lost when the service
re-registers, but you could serialize it to the bundle cache and deserialize when the
service comes back.
>>> The important concept is that you don't HAVE to deal with services not
being available, the most used scenario is to just deregister all dependent services as
well, which will degrade application functionality (at least temporally), but that is no
problem for things like updates.
>>>
>>> As another concrete example, in the app I'm working on we have a lot of
JAX-RS services. Those services often use other services to get to data (e.g. mongo
services). Both the JAX-RS services and mongo DOAs are OSGi services. When a Mongo DAO
bundle gets updated it's service get unregistered. At that moment, the JAX-RS service
will be automatically unregistered as well (making the resource unavailable). When the
update is complete, the Mongo service is registered again, and the JAX-RS resource will be
registered again as well.
>>>
>>> Paul
>>>
>>>
>>> On Sep 25, 2012, at 10:21 , Max Rydahl Andersen
<max.andersen(a)redhat.com> wrote:
>>>
>>> >
>>> > On 25 Sep 2012, at 09:39, Paul Bakker <paul.bakker.nl(a)gmail.com>
wrote:
>>> >
>>> >> Semantic versioning is a lot easier when using OSGi I think, so in
that aspect it will help with the versioning problem.
>>> >> I don't agree on the services part; I'm working on large
OSGi applications right now and that's ALL services (hundreds of them), and that works
fine (as well a "normal" DI solution would).
>>> >
>>> > yeah, i'm not saying its not useful for some systems.
>>> >
>>> > I haven't seen a good example of a plugin system that allows
extensions to access its datastructures and still be replacable dynamically ....you got
examples of that ?
>>> >
>>> >> Eclipse is the best known example, but also the worst example of
using OSGi. There is a lot of things in Eclipse that are considered anti-patterns in the
rest of the OSGi world. Often with good (sometimes historic) reasons, but don't look
at it as the ideal OSGi application ;-)
>>> >
>>> > neither do I - but its at least one data point in how even if you use
osgi it doesn't really help you if your app has type data sharing needs.
>>> >
>>> >> Good point about JSR-330. On top of that; there is a new OSGi spec
in development (spec lead is a JBoss guy I believe) that makes CDI available in OSGi.
There is already a prototype in Weld.
>>> >
>>> > yes, and just for kicks, here is a footnote about JSR-330 in eclipse4.
>>> >
>>> > This was around the time google guice/Seam was popular and the JSR-299 /
330 "battle" was on. When I asked why they chose JSR-330 over JSR-299 (since IMO
JSR-330 is not sufficient for what you need inside an UI app) there answer back then
(2years?) was that Google and Spring supported JSR-330 and JSR-299 wasn't possible to
use because it has no official backing and was tied to JEE.
>>> >
>>> > Then the conversation moved to how they were hitting the limits of
JSR-330 not having an event model, not having a way to define boundaries of the injection
and so forth.
>>> >
>>> > It was then fun to point out JSR-299 actually had more backing than
JSR-330 and that JSR-299 actually had an even model and that at least Weld could be looked
at to see if it could help to their "injection boundaries".....but yeah, the
tied to JEE was at that time not easy to hide even though Weld could load on JavaSE.
>>> >
>>> > In the end they ended up doing their own "mutated" version of
JSR-330 + the "missing features"
>>> >
>>> > I hope to see CDI available on eclipse equionox one day - would be fun
to see it compare.
>>> > /max
>>> >
>>> > Paul
>>> >>
>>> >>
>>> >> On Sep 25, 2012, at 9:31 , Max Rydahl Andersen
<max.andersen(a)redhat.com> wrote:
>>> >>
>>> >>> btw. Eclipse Osgi and the Eclipse 4 platform uses JSR-330 style
injection for their stuff. worth taking a look at if you are going this way.
>>> >>>
>>> >>> does osgi solves tooling multiple version problems ? nope -
osgi's notions aren't really helpful in having a tool that can work reliable
against multiple runtimes.
>>> >>> since osgi is used in eclipse tooling it allows
install/uninstalls ? N
_______________________________________________
forge-dev mailing list
forge-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev