| This is definitely something to watch. As with Tom, in the case of Scala modules, I am not too fussed. To me it is an implementation of an OSGi framework (or something akin) that allows for the running of bundles written in Scala. This makes makes sense to me. I differ from Tom in that if a mess of other people come and want to do different languages I still think that they should be part of Equinox. I'm not strongly fixed on this but from a consumer's point of view it is easier to go to Equinox to get the base stuff you need to run OSGi than to go there to get the framework, and somewhere else to get language adapters.
Of course, on the producer side there likely is an impact. Perhaps we should seek to eliminate, redistribute or otherwise deal with that effect?
As for the incubator, that is likely a good idea but not particularly related to the Scala stuff as it is not really going to be incubating for long.
WRT the clutter, the clutter does not go away by making more sub-divisions. For the most part we should have fewer categories of stuff when presenting stuff to users. They get lost in all the detail and never find stuff. We need web pages etc that say "Wanna run OSGi in a variety of languages?", "Wanna run OSGi on a server?" and we would likely need the dreaded "Misc" for stuff that just does not fit.
So, I am not a fan of rt.lanugages (or some such) though would NOT vote -1.
Jeff
On 2010-01-19, at 1:16 PM, Thomas Watson wrote: I share some of the concerns John has. I want to avoid Equinox being the default project where we place all RT projects that don't fit into other projects in RT and may not have the scope or desire to be directly under the RT project.
For the scala modules proposal in particular I gather that the proposal wants to be under the Equinox project (not the Equinox incubator) and will become a graduated project under Equinox by the time Helios releases. I don't have a big issue with the Scala Modules proposal for being included in Equinox but, as a project lead I think Equinox has begun to look very cluttered and confusing to figure out what all the different sub-projects are and how they relate to each other.
I do think we should consider having an RT incubator but that really only solves the issue of cluttering up the Equinox incubator. The incubating projects in RT will still need a place to graduate to. Personally I would like to come to some agreement that makes it clear (easier?) for projects to exist directly under RT if it makes sense. Perhaps that doesn't make sense for Scala Modules but what happens when a similar proposal is made for jRuby, Jython (Python), _javascript_ etc. I really don't want to manage all that under Equinox. Should there be an rt.languages project under RT? Would it make sense to have Scala Modules as a sub-project of rt.languages? Perhaps an rt.languages project would solicit more participation by experts of other languages in the modular programming model we are promoting at RT. Is there some other solution we can think of?
Tom
<graycol.gif>John Arthorne ---01/19/2010 12:45:18 PM---I was about to post this feedback on the Scala Modules proposal, but decided it's more of a general RT issue so wanted to know
<ecblank.gif>
From: | <ecblank.gif>
John Arthorne <John_Arthorne@xxxxxxxxxx> |
<ecblank.gif>
To: | <ecblank.gif>
rt-pmc@xxxxxxxxxxx |
<ecblank.gif>
Date: | <ecblank.gif>
01/19/2010 12:45 PM |
<ecblank.gif>
Subject: | <ecblank.gif>
[rt-pmc] What goes in Equinox vs. RT? |
I was about to post this feedback on the Scala Modules proposal, but decided it's more of a general RT issue so wanted to know what you all think about it. When I looked at the Scala Modules proposal, I was wondering why it should appear as a sub-project of Equinox rather than directly under RT. More generally, what criteria should be used for new RT project proposals to decide if they become Equinox sub-projects versus RT sub-projects. The Equinox mission statement says it is for OSGi spec implementations, infrastructure for running and managing OSGi systems, and key framework services. I'm not sure where Scala Modules, or even Equinox Aspects falls into this. On the other hand, other RT projects such as ECF and the proposed Gemini project *do* provide implementations of OSGi specs, but are *not* part of Equinox (I'm not suggesting they should be - just pointing out the inconsistency).
My impression is that things get put under Equinox because they feel too small to be separate projects on their own, rather than for any specific technical reason. In this sense Equinox, and the Equinox incubator in particular, are being used a general space for any runtime-related technologies that don't naturally fit anywhere else. Maybe this is all fine, but all the incremental content added to Equinox does create a bit of extra overhead for various people who take care of Equinox project management, web content, build, ip logs, bug triage, release engineering, etc. Each new sub-project or component that comes along doesn't create a lot of extra work by itself, but it adds up over time as more and more unrelated pieces are being added to Equinox.
So, I guess my general question is how you decide what becomes part of Equinox vs. under the top level RT, and are there some alternative approaches we should consider? For example should RT have its own top-level incubator like the WTP, Modeling, and DTP top-level projects have? Or, maybe we shouldn't be worried about having lots of little projects under RT, since under the eclipse development process all projects are equivalent regardless of what depth they are in the project tree. Thoughts anyone?
John _______________________________________________
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
|
