Re: [rt-pmc] Re: Virgo

[Jeff McAffer <jeff@xxxxxxxxxxxxxxxxx>]

On 2010-01-13, at 11:36 PM, Greg Wilkins wrote:

> 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.

I was not intending to make light of this by "punting". Rather my expectation and understanding was that the integration effort would require a joint effort with understanding on both sides and that by the time any of this code is available in a repo etc it will be EclipseCon. It may turn out that the integration is very straightforward and an excellent way to find out is to huddle at EclipseCon when the relevant parties are physically co-located.

> 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.

From my point of view, to be "eclipse", a project output must be able to be run on Equinox. This is a consumer level statement. It allows the different pieces to be used together and thus enables consumers to compose systems that function. This is not related to who produced what. There can only be one framework in a system. For example, if Jetty@Eclipse did not work on/with Equinox, the IDE would be forced to drop it for something else regardless of the fact that Jetty comes from Eclipse. Looking the other direction, it's even better if Eclipse bits run on other frameworks as that allows more people to consume Eclipse tech but that is a bonus.

There is a difference IMO between that situation (the choice of framework) and the choice of components on top. In many cases different teams can select different infrastructure pieces for their implementations and happily co-exist. Indeed this is part of the power of OSGi. I completely agree that teams should be encouraged to consume other Eclipse bits and should really have good reasons why they are not but I stop short of forcing that as a requirement.

I don't think this is a double standard because in my mind the two things are different.

In any event, that is a bit off topic and I don't think we are at or even near that point. Everyone is saying they are willing to make it happen, so lets do it!

> 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

It seems like the Gemini/Virgo folks are willing to pitch in and the Jetty folks have said similar things so what really is left is to tweak the projects to recognize that "co-committment" and make available, in a first class way, a Jetty-based releases.  Does that make sense?

This integration need not happen immediately as I'm sure that there will be a ton of work just getting the initial contribution in but it would be ideal to set a timeline.  As with the move of all Jetty to Eclipse however, that timeline may be influenced (positively or negatively) by IP issues.

> 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.

I agree entirely and will not be approving any CQs that compromise the IP stature of Eclipse. I don't think that Gemini/Virgo have been asking for or receiving any special consideration. Fact is, the contributions have not been made yet so the potential problems are not yet known.  It may well turn out that they have very similar issues to what was seen in Jetty and they may yet end up taking a similar approach.

> 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.

Yup, that would be a win.

Just a quick closing not.  This kind of discussion is exactly why we have a proposal phase. It lets folks surface issues, volunteer additional contributions, voice support, ...  Its good to see the process working.

Jeff