[
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...
|
You just have to fully qualify it. Searching for "eclipse nexus project" shows the wiki as the first result. That's pretty good considering it's the only web reference to this to date.
- Konstantin
-----Original Message-----
From: technology-pmc-bounces@xxxxxxxxxxx [mailto:technology-pmc-bounces@xxxxxxxxxxx] On Behalf Of Eugene Kuleshov
Sent: Tuesday, September 30, 2008 9:44 AM
To: Technology PMC
Subject: Re: [technology-pmc] Nexus Project or perhaps hosting micro-projects directly under Tools Project...
Query on Google for "nexus project" returns 430,000 results, so it won't be pleasant to search for it. Maybe it would be a good idea to reconsider the project name.
regards,
Eugene
Wayne Beaton wrote:
> 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
>>>
>>>
>>
>>
>>
>
> _______________________________________________
> technology-pmc mailing list
> technology-pmc@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/technology-pmc
_______________________________________________
technology-pmc mailing list
technology-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/technology-pmc
