Let's be clear about the terminology first:

"Eclipse 4.0" simply means "the first release of 'Eclipse' in the 4.x
stream". The problem is that it's *singularly* unclear what the word
'Eclipse' denotes, in this case. Let me show you what I mean...

Given the team that you and I are both on, and your other comments, I might
assume that you really meant the "Eclipse SDK". If that's true, then the
answer is simple: "Eclipse SDK 4.0" is simply the same as it has always
been: "the SDK that you would want, in order to be able to build itself".
(Isn't recusion always described as "simple". <g>)

However, it's important to understand that the things that happen at
Eclipse.org are *much* bigger than that.  It's definitely not just about
IDEs any more. There are runtimes, widget toolkits, RCP and SOA frameworks,
you name it. Even in the IDE space, the Eclipse SDK, is only a small piece
of the many, many IDE-ish things that are built with Eclipse. (Some of
those things are captured by other IDEs like Netbeans or IDEA, but many are
not.) The thing is though, work on all those things proceeds *outside* the
scope of the _Eclipse_Project_ (i.e. the team you and I are on, not
Eclipse.org in general), and as such are not things that we will implement.

So how did we end up with initial set of directions that are being
discussed? We started with the germ of an idea that one way to look at what
the Eclipse Project produces is that we make the "plumbing" that most other
things at Eclipse.org are made from. [That position was easier to defend
before the Equinox team moved to the RT project. ;-) ] Essentially, we
build the "platform". So, the obvious starting point for the work is to
identify the things that the platform needs to do to be a better basis for
the other things that are done at Eclipse.org. Several of us spent a
significant amount of time during the 3.4 release cycle trying to
understand what that list might look like by doing two things:

1) looking inward at our current platform and based on bugs, mailing lists
and newsgroup postings, discussions with others at Eclipse.org, etc.,
trying to see where the pain points were (like the huge learning curve for
new developers, and a Resource layer that was really only useful for Java
plug-in developers)

2) looking outward at the larger software development community to see what
would be expected from a modern platform. That depends, of course, on how
loosely you define a platform, but there were some obvious trends:
    - Applications are *expected* to have a polished, stylish look and feel
now -- we had better be able to build applications that look like that on
our platform
    - The web is *very* important. Even for applications that are not
moving to "pure" web UIs, it is expected that some of the application's
functionality could be provided via the web -- we had better be able to do
that too.

Unfortunately, it also became very clear to us is that a) we simply didn't
have the scope to understand whether we had captured all of the platform
requirements, and b) even for the set we did know about, it was obvious
that we would need more resources than we could provide ourselves to
implement them. That, together with some "gentle chastisement" (tm) from
the community about how closed we had been in the past, made it very clear
that the only way this effort would succeed would be to open up the
development so that others at Eclipse.org, who had *specific* needs for
improvements in the plumbing _for_purposes_appropriate_to_their_work_,
could participate and drive the development in ways that were useful to
them. In the world we live in, that's as close as you can get to the
"purpose" you were asking about in your note.

So, for all things "4.0", I think first about a new platform that will be
"the plumbing for the next generation of things done at Eclipse.org".
*That* is what we have taken to calling "e4", and that's so far been the
focus of most of the discussion in this list. We also build an "Eclipse
SDK" that is the thing that we need to build that platform, and that is
what we would call "Eclipse SDK 4.0".

In reality though, there is a much bigger/harder question which may be the
crux of what you are really trying to figure out (although you may not have
realized it): Who is responsible at Eclipse.org for the "big picture"? The
team that is ensuring that the Eclipse SDK + WTP + TPTP (+ all the other
pieces that are required) really is a credible competitor for NetBeans or
IDEA or whatever else is a threat to some parts (or all) of our community?

That's a good question.

McQ.



|------------>
| From:      |
|------------>
  
>-----------------------------------------------------------------------------------------------------------------------------------------|
  |Oleg Besedin/Ottawa/[EMAIL PROTECTED]                                        
                                                                    |
  
>-----------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To:        |
|------------>
  
>-----------------------------------------------------------------------------------------------------------------------------------------|
  |[email protected]                                         
                                                            |
  
>-----------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date:      |
|------------>
  
>-----------------------------------------------------------------------------------------------------------------------------------------|
  |05/02/08 03:10 PM                                                            
                                                            |
  
>-----------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject:   |
|------------>
  
>-----------------------------------------------------------------------------------------------------------------------------------------|
  |[eclipse-incubator-e4-dev] E4: shouldn't we define the goals first?          
                                                            |
  
>-----------------------------------------------------------------------------------------------------------------------------------------|






In all the discussions that went around E4, I haven't seen a "definition"
of what Eclipse 4.0 is going to be about. Is it going to be a perfect IDE?
Or a portable runtime? Or something a student can learn in 24 hours?

What would be a motivation for an Eclipse 3.x user or a Netbeans or Idea
user to switch to Eclipse 4.0?

I think we'll have a better chance of success with E4 if we define what we
are trying to achieve first, before we go into EMF, API, and JRE
discussions.

        (First) work out a "definition" of what is the purpose of Eclipse
4.0
                + define a target audience by developer type and supported
environment
                + some competitive analysis: current strengths and
weaknesses, projections for the target market 2 years down the road

        (Next) based on the "definition", start branching into the end-user
requirements - both from the today's pain points and from the new areas
we'd like to cover

        (Very next) based on requirements, work out specific technologies
to be used

Was this addressed in a presentation for the Eclipse board that somebody
mentioned?

Thanks,
Oleg _______________________________________________
eclipse-incubator-e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev

<<inline: graycol.gif>>

<<inline: ecblank.gif>>

_______________________________________________
eclipse-incubator-e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev

Reply via email to