[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [technology-pmc] Nexus Project or perhaps hosting micro-projects directly under Tools Project...
|
I just finished updating the wiki. My understanding is that the wiki has all the content necessary for a project proposal (please point out if you see something missing). As soon as I get the go ahead from the PMC, I will re-format it into form required by EMO and send it on its way. Note that I added a statement to the wiki about how Nexus would exit the Technology project upon maturity, since that was one of the concerns expressed in this thread.
http://wiki.eclipse.org/Nexus_Project
Thanks,
- Konstantin
-----Original Message-----
From: Wayne Beaton [mailto:wayne@xxxxxxxxxxx]
Sent: Monday, September 29, 2008 8:52 PM
To: konstantin.komissarchik@xxxxxxxxxx; Technology PMC
Subject: Re: [technology-pmc] Nexus Project or perhaps hosting micro-projects directly under Tools Project...
I say go ahead and put the project proposal together. We should get input from the Architecture Council as well. Update the wiki page and I'll request their input.
Wayne
Konstantin Komissarchik wrote:
> Haven't seen anything new on this thread for a few weeks now. How should we proceed?
>
> - Konstantin
>
>
> -----Original Message-----
> From: Konstantin Komissarchik
> [mailto:konstantin.komissarchik@xxxxxxxxxx]
> Sent: Thursday, September 18, 2008 9:44 AM
> To: Wayne Beaton; Technology PMC
> Subject: RE: [technology-pmc] Nexus Project or perhaps hosting micro-projects directly under Tools Project...
>
>
>> This sounds a lot like the SOC project. If we go through with this
>> project, I'd consider shutting down SOC to use Nexus instead.
>>
>
> I can see expanding scope of Nexus to cover SOC, but I am more intending Nexus for projects that are likely to make it, rather than something that a student experiments with for a few months and then forgets.
>
>
>> Having said that, I'm not sure what you're hoping to achieve. Are
>> there specific pains you're hoping to address with this? (can you
>> list
>> them?)
>>
>
> Certainly. The main issue is that there is perception (some of it is real, some of it isn't) that creating a project is a lot of administrative overhead. For a large project, the overhead in relation to project size is manageable. Since there are a lot of people involved you can spread the pain of the paperwork and infrastructure setup (build work, website, etc.). For something very small, the overhead starts to look like an impenetrable barrier.
>
> The problem becomes a lot worse when we are talking about code in an existing Eclipse project that has potential for broader appeal if it just wasn't locked away in that project. The idea for Nexus was initially born when I was trying to find ways to break down the silo effect that exists between projects. The very thing that makes Eclipse Foundation so vibrant also makes Eclipse harder for end users to use than a monolithic IDE created by one entity (such as NetBeans or DevStudio). When looking at most EPP packages, it is very sad to see the seams between projects so visible in a finished product. One just has to look at preferences to see half a dozen ways of doing the same thing. A prime example of this is target platform management. JDT, PDE, WTP, CDT, and others all have this need and they all solve it differently.
>
> Past solutions for code sharing revolved around "push to platform" strategy, but as the platform got more and more bloated with code that was not used in the platform, the platform team wasn't very keen on supporting that model further. That's the right strategy for Platform since it's important to keep the core small, but without another solution for code sharing, the silo effect deepened further. While the option of creating projects was always there, the overhead of trying to get a project going is too high. When the cost of setting up a structure that enables code sharing starts approaching the cost for someone to re-write a feature from scratch, we have a problem.
>
> Initially, that was the only problem that I was trying to address with Nexus. The initial proposal sketches would limit admission to existing code from another project or proposed collaboration efforts between two or more existing projects. There was even a provision for requiring a sponsoring project for each Nexus component. Then I came across a bug where a rather heated discussion was taking place. What was going on is that someone got frustrated with inability to view images contained in Eclipse workspaces and wrote a very simple viewer. He first tried to contribute it to platform and was turned away. The platform team said "you know, viewing images is necessary when developing web apps, go talk to WTP instead." Since that would only exacerbate the situation where WTP is serving as a holding pen for technology with broader applicability but no place to go, we at WTP weren't particularly keen on that solution. Neither was the contributor whose use case and desire to create such a viewer had nothing to do with web development. So here we had an individual with an arguably very necessary code contribution as well as willingness to maintain said contribution who had no place to go with it. We are talking of a feature with a maximum of few thousand lines of code here, so going the route of a separate project was not viewed as realistic. Just the build system alone would require more code than the feature itself.
>
> So I started re-working the Nexus idea to try to solve both of these problems. The basic premise is that if we could just pool resources to create something close to a turn-key solution for project creation, then it would facilitate better collaboration among projects and give home to small stand-alone features that can't find home somewhere else at Eclipse (and end up on SourceForge instead). Once the hard work of setting up shared infrastructure is completed, an important part of making this successful is evangelizing that there is a home for small scale projects where the effort of getting setup is not disproportionate with the scale of the project.
>
>
>> One thing that I'm wrestling with with regard to the Examples and SOC
>> projects is the relatively short-term nature that's expected of
>> Technology projects. It sounds like Nexus is yet another project that
>> would be in perpetual incubation with a
>> difficult-to-describe-let-alone-capture project plan.
>>
>
> So I initially approached Tools PMC with this proposal, but Bjorn urged me to go to the Technology PMC instead. I expect that Nexus would get out of incubation fairly quickly since it's just a container / facilitator, while the projects it contains will be at various stages of maturity. Honestly, projects like Orbit, EPP, SOC, Examples, Babel and Nexus don't fit well into either Tools or Technology. They would work better as siblings at top level, except that creating top level projects from scratch is not an option so we have to contend with finding the most appropriate existing top-level project to attach to even if the fit is not perfect. Maybe if Nexus takes off in a big way, the path for it out of Technology Project would be to become a top-level project itself...
>
> I hope this answered at least some of your questions. If you think it would be helpful, I can join one of your meetings or we could do a separate phone call.
>
> Oracle
> Konstantin Komissarchik | Consulting Member of Technical Staff
> Phone: +1 425 201 1795 | Mobile: +1 206 898 0611 Oracle Eclipse
> Tooling
> 411 108th Ave NE, Suite 2100 | Bellevue, WA 98004
>
>
> -----Original Message-----
> From: Wayne Beaton [mailto:wayne@xxxxxxxxxxx]
> Sent: Thursday, September 18, 2008 5:26 AM
> To: konstantin.komissarchik@xxxxxxxxxx; Technology PMC
> Subject: Re: [technology-pmc] Nexus Project or perhaps hosting micro-projects directly under Tools Project...
>
> Hi Konstantin
>
> This sounds a lot like the SOC project. If we go through with this
> project, I'd consider shutting down SOC to use Nexus instead.
>
> Having said that, I'm not sure what you're hoping to achieve. Are
> there specific pains you're hoping to address with this? (can you list
> them?)
>
> Is there some deluge of new projects that we're turning away?
>
> One thing that I'm wrestling with with regard to the Examples and SOC
> projects is the relatively short-term nature that's expected of
> Technology projects. It sounds like Nexus is yet another project that
> would be in perpetual incubation with a
> difficult-to-describe-let-alone-capture project plan.
>
> Wayne
>
> Konstantin Komissarchik wrote:
>
>> Technology PMC,
>>
>>
>>
>> I am in the process of resuming work on Nexus Project proposal and I
>> would like to seek your input.
>>
>>
>>
>> The problem I am trying to solve is how to make Eclipse Foundation
>> friendlier to very small projects. These "micro-projects" have two
>> defining attributes: (1) their scope is rather small (most will
>> likely only support a few committers and in a lot of cases as few as
>> one) and (2) their scope is general enough to not make a good fit in
>> an existing project. These projects can be broken up into two broad
>> types: (1) frameworks that can be used by other Eclipse projects or
>> the broader ecosystem and (2) end-user functionality (recent examples: image viewer and export editor contents as HTML).
>>
>>
>>
>> The idea is to create a new project (Nexus) under the Technology
>> Project to serve as an organizational point for managing these
>> micro-projects. The Nexus project lead and committers would be responsible for:
>>
>>
>>
>> 1. Maintaining project website with information about how to go about
>> creating a micro-project.
>>
>> 2. Promoting the idea that it's now easier to create small projects
>> (both internally and externally).
>>
>> 3. Serving as first-review filter for incoming project proposals. One
>> important function would be identifying proposals whose scope
>> intersects too much with an existing project.
>>
>> 4. Possibly managing org.eclipse.nexus.* namespace under which all
>> Nexus sub-projects would belong (or we could let micro-projects use
>> top-level namespace if everyone was comfortable with that).
>>
>> 5. Monitoring health of existing micro-projects and providing regular
>> updates to Technology PMC.
>>
>> 6. Any necessary infrastructure (mostly build and distribution). The
>> goal is to free sub-projects from having to handle this on their own.
>> It's likely that most of the needs will be addressed by the new build
>> service currently being developed at Foundation's level, in which
>> case this is a catch-all for any remaining infrastructure work.
>>
>>
>>
>> Some have suggested that we don't really need a separate project for
>> this function and that we could ask Technology PMC to accept and
>> manage such projects directly. I tend to think that this will not
>> scale effectively if we are successful in attracting large number of
>> micro-projects, but I'd like to know where Technology PMC members stand on this.
>>
>>
>>
>> Thoughts? Comments?
>>
>>
>>
>> PS: There is an out-of-date wiki page
>> (http://wiki.eclipse.org/Nexus_Project)
>> that I've used in the past to work on this project proposal. It
>> doesn't reflect two important changes at the Foundation since the
>> wiki was lasted updated: (1) it is now possible to create arbitrary
>> levels of project nesting, so micro-projects can be actual projects
>> rather than components, and (2) there is an effort under way to
>> provide a ready-to-use build system directly from the Foundation.
>>
>>
>>
>> - Konstantin
>>
>>
>>
>>
>>
>> Oracle <http://www.oracle.com>
>> Konstantin Komissarchik | Consulting Member of Technical Staff
>> Phone: +1 425 201 1795 | Mobile: +1 206 898 0611 Oracle Eclipse
>> Tooling
>> 411 108th Ave NE, Suite 2100 | Bellevue, WA 98004
>>
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> ---
>>
>> _______________________________________________
>> technology-pmc mailing list
>> technology-pmc@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/technology-pmc
>>
>>
>
>
>
