Skip to main content

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

Hi, 

The WTP Server framework is quite flexible. As Naci said everything can be represented as deployable module types. And PDE projects can be too. In fact this is already available in Libra as the OSGi Bundle facet. Server adapters just need to support this module type. 

I would not go to the extreme to represent all possible module types as PDE projects. There is no problem for a server adapter to support the regular Java EE module types: WAR, EJB-JAR, EAR, etc. and in addition to support projects with the OSGi Bundle facet (de facto PDE projects). And even to distinguish mixtures like WAR + OSGi Bundle. 

Perhaps, it worth taking a look at the current implementation of the WTP server adapter in the Virgo IDE. AFAIK, it supports  the OSGi-free WAR module type, as well as the variety of Virgo-specific module types like PARs, Plans, etc. May be it just needs to start supporting the Libra's OSGi Bundle facet. 

You can also have a look at the available documentation about the WTP Server framework: http://eclipse.org/webtools/server/server.php 

And yes, all above is quite a separate thing from having Bundlor as extension to PDE. 

Greetings,
Kaloyan

-----Original Message-----
From: libra-dev-bounces@xxxxxxxxxxx [mailto:libra-dev-bounces@xxxxxxxxxxx] On Behalf Of Martin Lippert
Sent: 29 януари 2012 г. 20:22 ч.
To: Libra developers list
Cc: Martin Lippert; Virgo Project
Subject: Re: [libra-dev] [virgo-dev] A home for Bundlor

Hi Naci!

>> 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... :-)
>
> Framework adapters already support this.  It is based on an inherited
> capability from WTP server adapters.  From 10000 ft it look a bit like
> this:

I don't have enough in-depth knowledge of the adapter technology in WTP, 
but I had something in mind which allows you to fully implement the 
server adaptor without the exact knowledge of all the different kind of 
projects and let separate bundles implement some kind of a bridge 
between the Virgo server adapter and a concrete project type.

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.

Do you think that is possible?

Cheers,
-Martin





>
>
> Every runtime type (i.e. equinox, felix, virgo or tomcat) can support
> different types of modules. For example the Equinox adapter supports:
>
>        <runtimeType
>              id="org.eclipse.libra.framework.equinox.runtimeType.30x"
>         ..
>              class="org.eclipse.libra.framework.equinox.EquinoxFramework">
> 		<moduleType
> 		         types="osgi.bundle"
> 		         versions="4.2"/>
> 		....
>
>
> Which is any PDE bundles that has a facet.  Tomcat or JOnAS support
> other things such as WARs, EARs etc., not all of them OSGi.  In WTP
> terminology these are called modules
> (org.eclipse.wst.server.core.IModule). This determines what can be
> targeted to an adapter, also each Module type can have different
> behavior associated with publishing/deployment.   These differences
> are typically handled in IFrameworkInstance extensionsor WTP
> IServerBehaviour in methods such as publishServer or publishModule.
>
> It is quite possible to write an adapter for Virgo that can handle
> each type of module (PDE, Web, Bundlor generated etc) in its own way.
>
>
>
>> 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?
>>
>> Cheers,
>> -Martin
>>
>>
>>
>>
>>
>> On 27.01.12 21:43, Miles Parker wrote:
>>>
>>>
>>> Yeah, that would be a problem, wouldn't it. :) TO be clear, I meant "if
>>> Virgo *IDE* only supported.."  I think what I'm asking is that if Libra
>>> tools are capable of packaging up WAR and web projects as PDE projects
>>> (still not clear on whether that is true) and Virgo IDE could manage those,
>>> then you would have a single PDE deployment scenario.
>>>
>>> The reason that I'm asking all of these questions is that I'm trying to
>>> think through the implications of having many to many relationships between
>>> the development environment and the deployment environment. If you were able
>>> to have a common interchange mechanism it seems that it could simplify a lot
>>> of things, as you would only have to maintain a) something to get all
>>> development artifacts treated as PDE, and b) something to manage the
>>> deployment of those artifacts so they end up on the Virgo server as
>>> expected. I'm not saying this is a *good* idea or one that should even be
>>> seriously considered, but I'm trying to wrap my head around whether it is
>>> even possible.
>>>
>>> Also to be clear, I'm only talking about bundles / plugin projects, i.e.
>>> actual components needed to support clients post-deployment. So AFA plans
>>> go, that would be handled by unique tooling. There is a bug open on that.
>>>
>>>
>>> On Jan 27, 2012, at 12:26 PM, Christian Dupuis wrote:
>>>
>>>>> OK, so it sounds like PDE is the common denominator, which was sort
>>>>> of my expectation / hope. I think the important question to ask at
>>>>> this point is the reverse; if Virgo *only* spoke PDE, what
>>>>> implications would that have for users? Are there scenarios that we
>>>>> couldn't support -- even with the Libra adapters -- given that?
>>>>
>>>>
>>>> You wouldn't be able to deploy WAR projects, plans or web modules.
>>>>
>>>> Christian
>>>>
>>>> --
>>>> Christian Dupuis, Director, R&D
>>>> SpringSource, a division of VMware
>>>> www.springsource.com - cdupuis@xxxxxxxxxx - @cdupuis
>>>>
>>>>>
>>>>>
>>>>> cheers,
>>>>>
>>>>>
>>>>> Miles
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> 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 like https://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.
>>>>>
>>>>>
>>>>>
>>>>> -Miles
>>>>>
>>>>> _______________________________________________
>>>>> virgo-dev mailing list
>>>>> virgo-dev@xxxxxxxxxxx
>>>>> https://dev.eclipse.org/mailman/listinfo/virgo-dev
>>>>>
>>>> _______________________________________________
>>>> virgo-dev mailing list
>>>> virgo-dev@xxxxxxxxxxx
>>>> https://dev.eclipse.org/mailman/listinfo/virgo-dev
>>>
>>>
>>> _______________________________________________
>>> virgo-dev mailing list
>>> virgo-dev@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/virgo-dev
>>
>> _______________________________________________
>> libra-dev mailing list
>> libra-dev@xxxxxxxxxxx
>> http://dev.eclipse.org/mailman/listinfo/libra-dev
>
>
>
_______________________________________________
libra-dev mailing list
libra-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/libra-dev

Back to the top