Hi Max,
About your "server" question in the last sentence. If you refer to my post, I was trying to make an analogy:
server <-> applications == Forge core <-> Forge plugins
Please, let us not go to p2, tycho and Equinox? :-)
I think that the most unobtrusive OSGi for Forge would be the bnd stuff described by Paul. However, I am not sure how does bnd restrict the number of exported packages by a plugin. If it exports everything, then why do we use OSGi at all?
Cheers,
Ivan
On Wed, Sep 26, 2012 at 3:46 PM, Max Rydahl Andersen
<max.andersen@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 :)
would need someone to maintain work on it and make sure it does not conflict with using tycho/p2 for osgi development which is the osgi tools used in eclipse land.
note, Forge moving to osgi doesn't make it easier to use from JBoss Tools, it probably makes it harder - unless the choice is osgi equinox and something compatible with
Eclipse plugins/osgi....
btw. anyone able to outline me why forge 2 is needed and why the word "server" is now used for Forge ?
/max