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
