Hi Miles,
I am sorry for the delayed response.
Yes to the first question. I'm not sure it's related to the second bug.
The problem in bug 329198 is that the Virgo server adapter cannot read OSGi projects with PDE structure. It reads OSGi projects with Bundlor structure. Integrating Bundlor with PDE imply merging these two project structure. Then solving bug 329198 should much easier.
In the first case we're asking "would Bundlor be useful to general PDE projects, and if so would that usefulness outweigh potential loss of transparency, maintenance costs and so on". As POC would be like, "support creating of generic PDE projects that make use of the bundlor mechanism". I think that PDE is best qualified to give an answer to that one. Is there anyone from PDE who has thoughts to share on that?
IMHO Bundlor would be a great complementary option for PDE project. If it is introduced as optional functionality for automatic generation of OSGi manifest then it will be up to the developer to decide if she wants to take advantage of it or continue in the good old Manifest-first approach.
In the second we're really asking "given a PDE project, can we make it more easy to build, execute and run with Virgo and other [non-Eclipse SDK] Runtime environments by leveraging PDE tools?" I think the Libra and Virgo teams will have to answer that one. Note by the way that it is perfectly easy at this point to actually deploy PDE built bundles, you just have to do the extra steps of exporting or building the plugins manually and then copying them off to Virgo runtime. So I think this part is largely a matter of some automation. But there are much more complex scenarios, where for example we might want to use the Run Configuration stuff as the primary gateway into launching and testing for self-hosted Virgo and Libra targets, rather or in addition to the current approach of manually creating local server(s) instances for that.
There is a lot done in this direction in Libra already. There are WTP server adapters that run the most popular open source OSGi frameworks like Equinox, Felix and Knopflerfish. These server adapters actually mask PDE target platforms. There are also adopter products that takes advantage of the same pattern using parts of Libra. So, if Virgo starts speaking PDE, it can easily join the Libra club J.
Greetings,
Kaloyan
From: Miles Parker [mailto:miles.parker@xxxxxxxxxxx]
Sent: 20 януари 2012 г. 20:48 ч.
To: Glyn Normington
Cc: Raev, Kaloyan; Martin Lippert; Leo Dos Santos; libra-dev@xxxxxxxxxxx; virgo-dev@xxxxxxxxxxx; pde-dev@xxxxxxxxxxx
Subject: Re: A home for Bundlor
On Jan 20, 2012, at 1:43 AM, Glyn Normington wrote:
On 20 Jan 2012, at 02:10, Miles Parker wrote:
the larger Spring donation which has also spawned Libra etc..
For the record, let's be clear that SAP donated Libra and then factored some of the SpringSource donated Virgo IDE into Libra.
Thanks Glyn, my mistake. I'm still not familiar with all of the history here.
Do you agree that a Proof-of-Concept showing how Bundlor can be integrated with PDE is a good first step? If we see that this is possible (and also how it is possible), will open the door for many improvements likehttps://bugs.eclipse.org/329198 you have mentioned.
Yes to the first question. I'm not sure it's related to the second bug.
In the first case we're asking "would Bundlor be useful to general PDE projects, and if so would that usefulness outweigh potential loss of transparency, maintenance costs and so on". As POC would be like, "support creating of generic PDE projects that make use of the bundlor mechanism". I think that PDE is best qualified to give an answer to that one. Is there anyone from PDE who has thoughts to share on that?
In the second we're really asking "given a PDE project, can we make it more easy to build, execute and run with Virgo and other [non-Eclipse SDK] Runtime environments by leveraging PDE tools?" I think the Libra and Virgo teams will have to answer that one. Note by the way that it is perfectly easy at this point to actually deploy PDE built bundles, you just have to do the extra steps of exporting or building the plugins manually and then copying them off to Virgo runtime. So I think this part is largely a matter of some automation. But there are much more complex scenarios, where for example we might want to use the Run Configuration stuff as the primary gateway into launching and testing for self-hosted Virgo and Libra targets, rather or in addition to the current approach of manually creating local server(s) instances for that.
