Re: [rt-pmc] Re: Virgo

[Jesse McConnell <jesse.mcconnell@xxxxxxxxx>]

Great, the 'where the integration would live' question is I think
clearly answered now...

and please don't get me wrong I have never advocated, nor would I,
that Virgo would just drop tomcat support or anything like that, that
would be absurd..

Outside of the 'where integration lives' question, the only other
thing I have been trying to get clearly explained to me is what the
overall Runtime project's goal is here.  Maybe I assume too much that
there is an overarching goal and mission of the Runtime to produce an
interrelated stack...I hear best of breed components a lot but maybe
there isn't a larger goal or force at work, dunno.  I am not
particularly interested in "positive openness statements" as Jeff
describes them as I haven't been thinking of it as a tomcat vs jetty
sort of deal at all.  I have been looking at it from what I hope would
be as a member of the Runtime community and how the Runtime project
presents itself.  There has been a lot of lip service paid as of late
towards trying to create a single unified message for Eclipse
Runtime...and with that in mind it seems to me that it would behoove
new projects coming into Runtime to at least state an intent that it
was the goal to distribute with the other projects where applicable,
time and resource providing, yadda yadda.  Jetty came to the Runtime
project and we would like to see it succeed beyond measure, that
benefits everyone :)

Now maybe I misread the Virgo proposal a bit, under the Jetty bit it
references another Runtime project called the Eclipse Gemini Web
Container which just cropped up around the holidays...so maybe that is
the thing that needs to be looked at message wise, could be that is
where the beer and pretzels need to be scattered.

Regardless of where the message is dropping here (is it only to me?),
it doesn't look particularly good to have the Runtime project
apparently going different directions and still trying to hammer out a
single unified message like it has been.  Its hard to advocate 'come
use our stuff!' when its own projects don't use each other (by
default).

cheers!
jesse

--
jesse mcconnell
jesse.mcconnell@xxxxxxxxx



On Thu, Jan 14, 2010 at 09:05, Adrian Colyer <acolyer@xxxxxxxxxx> wrote:
> 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:
>
>
> Please keep these conversations visible and transparent. The PMC list or the
> Virgo forum would both be fine.
>
>
>
> I am happy to continue the discussion, preferably on the Virgo forum, or
> via email or skype (glyn.normington) if you would prefer an informal chat.
>
>
> _______________________________________________
> rt-pmc mailing list
> rt-pmc@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/rt-pmc
>
>
>
> _______________________________________________
> rt-pmc mailing list
> rt-pmc@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/rt-pmc
>
>
> _______________________________________________
> rt-pmc mailing list
> rt-pmc@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/rt-pmc
>
>
>
>
> --
> Adrian Colyer
> CTO SpringSource, a division of VMware
> http://www.springsource.com
> acolyer@xxxxxxxxxx
>
>
> _______________________________________________
> rt-pmc mailing list
> rt-pmc@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/rt-pmc
>
>