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