[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
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
