Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [libra-dev] [virgo-dev] A home for Bundlor


On Jan 29, 2012, at 2:50 AM, Martin Lippert wrote:

Hey!

Just a few thoughts from my side:

In my dreams, the Virgo IDE server adaptor would be able to deploy:
- PDE projects
- Bundlor projects
- bndtools projects
- WAR/Web projects
- PAR projects
- plans?

To me this doesn't sound like PDE is the common piece that once we have it will enable us to do all the other things as well.

Yes, that seems clear now. I'm afraid that I'm showing my Eclipse app developer biases. What I would like to find is one single abstraction for deployment 


I would prefer to decouple the discussion around the home of the Bundlor project from the deployment features of the Virgo IDE or the Virgo server adaptor (which might become part of Libra one day).

Agreed.

Therefore I could imagine having something like an extension point for those deployment scenarios (a "deployer" extension point maybe), where the server adapter is using the "deployer extensions" to deploy different kind of projects. Then we could implement, step by step, extensions for those different kind of projects. Its just a rough idea, but I would be happy to hear your opinions... :-)

When we decide to let the Bundlor tooling become part of PDE (or an extension to PDE), we would just need to modify the deployer extensions for those two projects (or just eliminate the bundlor specific one). When we decide that Bundlor is not becoming part of PDE, then we just keep those two extensions.

What do you think?

I think it sounds extremely sensible.

On Jan 29, 2012, at 5:16 AM, Naci Dai wrote:

Framework adapters already support this.

Thanks for the great info, Naci!

Martin wrote:
If I understand this correctly in your terms, I would like to implement one server adaptor for Virgo servers, but let other bundles add module types (and their associated behavior) to that adapter.

Yep, that's my question two. Again the idea being to have some sort of common bus that all of the deployment sources and targets can interact through so that we don't have the many-many mapping problem.

thanks everyone for their thoughtful responses,

Miles


Back to the top