| Re: [rt-pmc] Re: Virgo |
|
I just wanted to echo some of the comments that Glyn made in his reply
(sorry I can't easily cut-and-paste it here as I'm a late subscriber to
the pmc-list). It seems to me that Jetty is a big winner from the move of the Gemini and Virgo projects to Eclipse.org. In the absence of the proposed donations, Jetty would be shut out of both the reference implementation for web container integration in OSGi, and also of the leading enterprise application platform for OSGi-based enterprise application development. We have been quite clear in the proposals and on the Gemini forums that we are very open to integration with Jetty in both of these projects. The first step should be to integrate Jetty as an option for the Gemini Web Container project as this is the primary vehicle under which Virgo consumes its servlet container. The expectation here is that this is a very small amount of work. The integration will live in the Gemini Web Container project, and two downloads will be made available from the Gemini project page - one with Tomcat and one with Jetty. Within the Virgo project, it is easy to change the initial list of bundles to be loaded to provide web support simply by editing the bundle list in the web subsystem "plan" file. Therefore it is easy to make Virgo pickup a Jetty based web container bundle rather than a Tomcat-based one. There *are* some additional dependencies on Tomcat outside of the Gemini dependency, and we will need to isolate these and work with you to find out Jetty equivalents. That integration code can then also live in the Virgo project. Virgo will continue to make a Tomcat-based distribution available (as the primary distribution) for the foreseeable future. We have a two-year history of users working on Tomcat, and who are familiar with its configuration, production characteristics etc.. Even today I had a conversation with a user who was anxious that Tomcat support remained. A Jetty-based distribution can also become an option to download from the project page as soon as the integration work is completed. As I hope Glyn made clear, no-one is suggesting that code to support Virgo should exist in the Jetty project. The Jetty integration code should live in the Gemini and Virgo projects. Regards, Adrian. Greg Wilkins wrote: Jeff, If it Virgo/Gemini were going to continue to use felix and expected the equinox team to make the effort to maintain integrations, then I don't think this issue would be punted to a beer and hacking session at the next eclipsecon. So it feels like there is a bit of a double standard being applied here. RT is more than equinox now and other projects should be given similar consideration. We are more than happy to contribute to the effort to integrate jetty with gemini/virgo and even make changes to jetty if need be. But I do not see why we should be expected to lead that effort any more than the equinox team is expected to lead the work to port dm from felix. Also from a design perspective, making the jetty project depend in virgo/gemini in order to have this integration would create a cyclic dependencies between the projects if ever virgo/gemini were to use jetty. >From a paperwork perspective, if the Jetty project depends on virgo/gemini then we will have a much larger set of CQ's which will include Tomcat. This will be very confusing for anybody tracing jetty's dependencies! I know spring is a dependency injection framework, but I didn't expect it to inject dependencies into the jetty project !-) The natural home for an integration module is within the virgo/gemini projects, so I don't think it is unreasonable to ask them to commit to the integration as part of their proposal, just as they have committed to integrate with equinox. I know at least some of the early DM work was done with Jetty, so I'm sure the DM team could more easily do the integration (with our help). With regards to IP. We did not choose to split jetty into two distributions. We would like to have a complete application server available for distribution from eclipse (rather than just the HTTP server part). But the advice that we were given, and accepted, was that the dependencies on our main distribution were such that they would not easily be CQ'd. We asked for, but did not receive, special consideration for our existing user base. So if the eclipse approach is going to be "tempered" for virgo/gemini, then we would like to received the same special consideration. However, I actually think that neither project should receive such consideration and the IP rules should be equally applied to both. Weak IP rules are about as good as no IP rules. If virgo/gemini are able to CQ tomcat (aand enough of it's transitive dependencies to make it a useful application server), then great! We probably would be able to use some of those components to improve the jetty distribution. cheers Jeff McAffer wrote:As a RT PMC colead I would like to see as much of the RT technology used in as many places as possible. I strongly believe that Eclipse technologies should be consumed by Eclipse projects wherever possible. I have (and will continue to) pushed hard to have various projects use Eclipse bits. This is good for everyone IMHO. That approach needs to be tempered with the reality that pre-existing projects such as Virgo and Jetty have many existing consumers and those consumers often know only some sort of non-eclipse style distribution (whatever that means in the particular case). It is critical that these consumer requirements not be ignored. Jetty has, for various reasons, chosen to continue its "legacy" deliverables at Codehaus in the near term. Seems like Virgo/Gemini are looking to put those deliverables at Eclipse if possible. There may well be similar IP challenges and a backup position may be needed. That process will unfold as the project evolves. Other projects such as Swordfish have chosen to use technology from Apache and elsewhere in lieu of Eclipse projects and seem to have no intention of changing. While this is disappointing, the community has trust the project teams to know what they are doing and to be open to others helping with the adoption of Eclipse technology. Projects that are not open to such help would need to explain in great detail why. In the case of Gemini and Virgo, the proposing teams have made several positive openness statements. While they have working solutions using Apache etc technology, it is my personal hope is that over time the projects will produce releases that include the maximum possible EclipseRT technology. This includes the use and distribution of Jetty. How they get their and who does the work is going to be something of a community decision. I suggest that the relevant parties get together at EclipseCon for a couple hours and a couple beer and just hack. For all we know it just works and there is really no technical issue. Then it becomes one of satisfying community demand--give the community the choice and see what happens. Jeff Jeff McAffer | CTO | EclipseSource | +1 613 851 4644 jeff@xxxxxxxxxxxxxxxxx | http://eclipsesource.com On 2010-01-13, at 6:16 PM, Jesse McConnell wrote:Sure, I have no issues keeping discussion on the public lists. I am just curious as to the rational behind having the default web container for another project coming in under the Eclipse Runtime being something other then another Runtime project that (afaik) does everything needed. Perhaps its my inexperience at eclipse and with the process that eclipse advocates but: * Is it not the goal of the Runtime project to encourage the projects being accepted into it to leverage each other where appropriate, and where appropriate be each others default components? indeed one of our goals with jetty is the be the default implementation for equinox (which we were before) but also to further enhance that relationship...we have made a lot of strides on that recently with hugues's jetty-osgi efforts and will be shortly able to publish a more comprehensive update site aside from my previous manually created one. * On the offer to have jetty committers be the responsible party for providing the integration portion of virgo...correct me if I am wrong here but wouldn't that be a part of Virgo itself and fall under the 'playing nice with the neighbors' clause for the Eclipse Runtime project? I am fine with answering questions and helping out where I can but am lukewarm on taking on new development tasks. Just so its absolutely clear I am not going on some <rawr>Jetty needs to be the default container!</rawr> rant here, but I thought it was the goal that runtime projects are 'encouraged' to use each others as defaults...our 'default' test platform for osgi related things is now equinox whereas before (at least I) tested osgi bundles out on felix. As to the requirements to support existing users, I can offer up us as an example, we have maintained an external distribution because we have historical users that expect a certain set of functionality as well, but we maintain that at The Codehaus since much of it would not come through the intensive Eclipse IP validation process, third party integrations etc, but then we also have our eclipse jetty distribution which bundles only approved, IP clean dependencies in the download bundles. anyway..I am looking forward to seeing how this stuff comes together, it sounds like it could be a fun project and a useful addition to the eclipse runtime family cheers! jesse -- jesse mcconnell jesse.mcconnell@xxxxxxxxx On Wed, Jan 13, 2010 at 11:54, Mike Milinkovich <mike.milinkovich@xxxxxxxxxxx> wrote: --
CTO SpringSource, a division of VMware http://www.springsource.com acolyer@xxxxxxxxxx |