Bug 200097

Comment 1 John Willson 2007-08-20 08:58:30 EDT

[Frees the plugin maker] I'd like to have the modern container features like ioc in equinox for Eclipse 4. One example I can think of is injecting configurations into plugin, configuration by annotation. For extension points, maybe we can borrow some things in Tapestry 5 (http://tapestry.apache.org/tapestry5/tapestry-ioc/).

Comment 2 Wendell Beckwith 2007-08-21 17:56:22 EDT

Fundamentally Eclipse is doing great but 2 big areas I think the community would love to see get attention in the next major version is the concept of workspaces and the resources in them.  The WorkspaceRoot should be able to contain other workspaces and not just projects.  As an example to hopefully make this clearer, if a user is working on 2 streams of development for Product Foo and another Product Bar then the Eclipse workspace model with look like:

WorkspaceRoot/
  Product Foo [trunk]       <- is a workspace
    Project A
    Project B
    Project C
  Product Foo [3.x branch]  <- is a workspace
    Project A
    Project B
    Project C
  Product Bar [trunk]       <- is a workspace
    Project A
    Project B
    Project C

Currently dealing with multiple projects with the same name (a project from the trunk and a branch) is cumbersome because multiple workspaces are needed.  In this case multiple workspaces are still needed but are contained, from a model standpoint not necessarily physically, within a single root.  And finally nested projects, the next major version simply needs to support them.

Comment 3 Martin Oberhuber 2007-09-18 06:42:16 EDT

I think that macro recording and playback (bug 8519) should be part of the 4.0 plan. This is one of the most voted-for bugs, and one of the few features where Eclipse falls short of commercial closed-source solutions.

The reason why this can not be addressed in Eclipse 3 is that in an open ecosystem of plugins contributed by multiple different sources, macro recording and playback can only be provided consistently when all plugins "play by the rules", i.e. adhere to a common API needed for scripting.

In other words, they need to offer their functionality not only by menu actions, views and key commands but also by scriptable commands; and, when macro recording is turned on, they need to pass the actions they perform into the macro recorder.

I'd think that for Eclipse 4, the Platform should come up with the APIs and Rules that plugins need to implement if they want to be part of macro recording and playback. Given that it would not be user friendly if a macro recorder would supporrt "most" but not all actions performed by the user, plugins should be strongly encouraged to follow those rules.

Comment 4 Mike Wilson 2007-09-18 09:31:50 EDT

Definitely good inputs. Thanks, all.  I like the notion of capturing high-level descriptions of possible directions in this bug, as long as we don't get bogged down in discussion of individual ideas. That's best done in separate bugs.

Comment 5 Carsten Pfeiffer 2007-11-13 10:17:41 EST

I'd really like to see the API to be Java 5'ified (i.e. make use of genericity). I know that that's going to be a lot of work, especially with regard to compatibility. But arrays and untyped collections are not quite state of the art anymore.

Comment 6 Chris Aniszczyk 2007-11-13 10:34:51 EST

(In reply to comment #5)
> I'd really like to see the API to be Java 5'ified

One thing you have to becareful about is that there are these things called mobile devices and they don't support J2SE-1.5 yet. As a platform, Eclipse needs to care :)

Comment 7 Carsten Pfeiffer 2007-11-13 11:04:32 EST

(In reply to comment #6)
> One thing you have to becareful about is that there are these things called
> mobile devices and they don't support J2SE-1.5 yet. As a platform, Eclipse
> needs to care :)

According to http://www.news.com/8301-13580_3-9800679-39.html?part=rss&subj=news&tag=2547-1_3-0-5
J2ME is about to be replaced with JavaSE and JavaFX. I'd hope that Eclipse 4.0 will target these newer devices, so that all the other consumers of the platform won't be stuck with Java 1.4-style API for another few years. (I suppose that such a change would only be made for a major release.)

Comment 8 Mike Wilson 2007-11-15 14:14:50 EST

First off, I think we need to be clear that rev'ing the major version number is not equivalent to giving us carte blanche for API *breakage*. If there was a clear, strong benefit to be gained from a particular change, then it would worth considering, but I am not going to break (literally) millions of lines of code, simply because our API doesn't use some cool Java5 feature.

Even if we were just talking about non-breaking changes, such as providing parallel API *additions* that took generics, between...
- enforcing consistency across similar API patterns
- managing all the interactions between new and old APIs
- rev'ing all the IWhateverItIs" interfaces to "IWhateverItIs2"s
-  ensuring that we didn't introduce performance problems
- dealing with the increased size
- etc.
... we couldn't justify the cost in development resources without believing, for example, that changing something that is already working, so that you can call it with a different shaped API, is more valuable than adding genuinely new functionality.

Having said that, what you might see is that Java5 APIs start to appear "at the edges" in new and "separable" major pieces of function. We're not actually averse to the new Java capabilities [although, I may never figure out what 'public <U extends T> Matcher<T,R> add(Class<U> aCase,{U=>R} f)' means] we just have a responsibility to the framework to move carefully. As Chris alluded in comment #6, we really do target a range of different class library levels on a per plug-in basis. Take a look at Appendix 1 of the the R3.4 plan (http://www.eclipse.org/eclipse/development/eclipse_project_plan_3_4.html) to see what I mean.

Comment 9 Carsten Pfeiffer 2007-11-16 03:57:32 EST

(In reply to comment #8)
> but I am not going to break (literally) millions of lines of
> code, simply because our API doesn't use some cool Java5 feature.

Of course not.

> [although, I may never figure out what
> 'public <U extends T> Matcher<T,R> add(Class<U> aCase,{U=>R} f)' means] 

I for one can never remember which constants to pass to 
new GridData(int)
new GridData(int,int,boolean,boolean)
new GridData(int,int,boolean,boolean,int,int) or
new GridData(int,int)

The class org.eclipse.swt.SWT with its 3000 lines of constants (including comments) speaks for itself, I think (best one is SWT.NONE vs. SWT.None). 

The use of enums would be very helpful there. Hey, it's almost christmas, can't I make a wish? ;-)

> Take a look at Appendix 1 of the the R3.4 plan
> (http://www.eclipse.org/eclipse/development/eclipse_project_plan_3_4.html) 

Thanks for the pointer.

Comment 10 Boris Bokowski 2007-11-22 17:08:39 EST

Tentatively adding the dependency injection work to the 4.0 plan.  See bug 209873 for experimental work in this direction (for Platform UI and the Workbench).

Comment 11 Gabriele Garuglieri 2007-12-07 05:31:40 EST

Hi all,
just to suggest something different, instead of going around looking for new bells and whistles to embellish eclipse, why don't you have a look to the hundreds of bugs and enhancements requests that sits in a limbo since years?

There are many areas of improvements, project organization, editor management, ant management, project importing etc. etc. where there are bugs with tenths of comments and tenths of CCs, sign that there's big interest in those bugs.

These are exactly the areas of which i hear complains about from developers in my groups. 
I can summarize these complains and the feelings with the following analogy:
often using eclipse one feel like having a wonder hammer that while nailing down something, makes coffee, and plays music to entertain you.
And hear, the next version will even cook a pie and brush floors!
Nice you'd say! 
Well i'd say it too, if it were not for the fact that more often than not for your daily work you don't care about the coffee , the pie or what else. 
How do you feel when you only need to nail down something, but instead the hammer bends the nail instead of pushing it down, or it's head slips over the nail and bangs on your fingers or worst it stops playing music  and screams at you "I'm not willing to push this nail down for you, got it? Just take a screwdriver(??) and do it yourself!!"?
Got the meaning?

I think you'd hear a big hurrah! from the community if you would be willing to solve problems starving in bugzilla backlog and lagging support since years.

Sincerely,  Gabriele

Comment 12 Gabriele Garuglieri 2007-12-14 03:32:27 EST

Pls see bug 40493 (4 years) and bug 81895 (2 years) to have an example of what i mean...

The workspace i'm carrying along since version 3.1 is now corrupted beyond repair and i'll need a lot of work to manually edit, import, restore the .project files of the branches of the projects i have in my old workspace.

A lot of pain, for a work that should have been a snap, due to the lacking of a basic function like supporting the import of multiple branches projects.

And i don't even want to talk about nested projects!

I'd like to hear the opinion of those who are in charge to decide eclipse future. I'm i asking something wrong?
Don't you think that before looking for new functions you should address these basic issues first?

Thanks,  Gabriele

Comment 13 Axel Rauschmayer 2008-01-12 10:23:19 EST

It is still too hard to write programs for the RCP. These problems cannot be solved by only expanding Eclipse's functionality, there has to be consolidation, too. I'd like to see some of the impressive collective brain power behind Eclipse be used to come up with new ideas for handling large code bases.

If Eclipse does not find a way of simplifying and innovating, I'm afraid it might be outmaneuvered by Netbeans in the long run. Netbeans has been quite courageous in refactoring its code base and version 6.0 has provided many new features, in a streamlined, highly integrated fashion.

Below are a few ideas of mine on this topic.

== Improving the internals ==

- Better coding: Some of the coding patterns are ugly; Eclipse deserves better. Examples: Downcasts, factory not documented at product, constants hard to find (SWT is inconvenient and error-inviting, enums would be much better and not necessarily much more inefficient), long method invocation chains to get to a service provider (dependency injection might help here; if you want to see DI done well, look at Guice), too much nomenclature.

- Navigating plugins and the RCP framework: Eclipse does reasonably well when it comes to code, so dealing with the extension XML should be as easy as dealing with code and both should be even more integrated. Can we come up with new ways of making it easy to discover functionality and to find one's way around in the mix of artifacts that is currently supported by Eclipse? Better cross-artifact refactoring would not hurt either.

- Snippets: They are brilliant for looking up stuff, but shouldn't some of that code be encapsulated (e.g., turned into a method)?

- Netbeans has project "Schliemann" [1]. Does Eclipse have something similar?

[1] http://wiki.netbeans.org/wiki/view/Schliemann

== New external features ==

- Finding code: Because one cannot extend classes a posteriori in Java, functionality is often put into separate classes, as static methods (e.g. Collections). How can one find this functionality if one does not know about it?

- Structuring code: One has to be able to mark up scattered concerns and to structure large classes. I've posted some ideas at [2], including making better use of the @category Javadoc tag.

- A simplified formal model for searching source code: One could store all source code associations as RDF and use SPARQL to query it or one could implement one's one Prolog-like query language, much like JQuery [3] has done it.

- Multi-dimensional browsing: Currently displayed hierarchies such as the call hierarchy and the inheritance hierarchy cannot be mixed. Relo [4] is an example of freely mixing these hierarchies. This feature is much easier to implement, if one has a formal model of the source code (see previous entry).

- Source code fragment editing: With polymorphism, one often needs to look at the declaration of a method together with all of its implementations. Eclipse should return search results as a sequence of source code fragements (I think member granularity if fine enough) and display all these fragments next to each other in a single editor.

[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=132326
[3] http://jquery.cs.ubc.ca/
[4] http://relo.csail.mit.edu/

== Minor improvements ==

- Option: only refresh inheritance hierarchy on-demand, manually.
- F4 while on a method should immediately show members in the hierarchy.

Comment 14 Bryan Hunt 2008-01-16 16:19:28 EST

I need more flexibility in the customization of the IDE.  I need to turn off more menus, toolbar icons, wizards, etc.  My domain is hardware development and within that domain, there are many perspectives with vastly different action sets.  For example, in a VHDL perspective, it makes sense to build a VHDL project, but you can't run the result of the build as it's not an application.  In a test prospective there is no concept of build, but there is a concept of run - though using the existing launch configuration mechanism is not practical.  I also need to use CDT in the same application, where build, run, debug, etc makes perfect sense, so using RCP isn't really the best option.  Basically, I need one perspective to look like an RCP app while another looks like a full IDE app.

I'd also like to see some tooling in the area of icon management.  I can never remember which directory which icon is supposed to be in.  It would also be nice if I could see all of the available icons so that I might find one I can reuse instead of re-inventing one.

Comment 15 Antoine Toulmé 2008-03-08 18:50:06 EST

(In reply to comment #2)

Regarding this particular comment can you look at 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=163601 ?

Please vote and help with the patch if you feel like it. I tried actualizing it but it seems I don't have enough knowledge of the Eclipse platform, I couldn't get it started with the latest nightly build.

Comment 16 Chris Hubick 2008-03-09 13:26:41 EDT

I think comments here will spiral out of control without some way for people to nominate bugs for e4 prioritization - is there a keyword we can flag bugs with?  Until then, how about people just post a one line comment like:

Nominate bug 35779, bug 40623.

Those are my nominations, but I agree that e4 planning should start with a list of all bugs marked as RESOLVED LATER, sorted by vote.

Comment 17 Boris Bokowski 2008-03-09 23:28:38 EDT

(In reply to comment #16)
> I think comments here will spiral out of control without some way for people to
> nominate bugs for e4 prioritization

I agree and suggest that we use the wiki instead. I have created a wiki page at [1] and copied suggestions from comments 1 to 10 into that document. Feel free to add to that list (or copy ideas from comments 11 on into there too).

[1] http://wiki.eclipse.org/Eclipse_4.0/Wishlist

Comment 18 Mauro Molinari 2008-04-03 10:23:17 EDT

IMHO, I agree with those asking for Eclispe 4.0 to fix some long-standing bugs and/or to implement some long-awaited enhancement requests here in Bugzilla.

When looking at request enhancements in Bugzilla I almost always read answers like: "it's out of scope", "we don't have the manpower for implementing this", "we expect help from the community", and so on. I'm not going to say that these answers are not legitimate or justified, but I often find myself to wonder what actually IS in scope and/or planned for the future releases of the Eclipse platform then?

Mauro.

Comment 19 Andrey Loskutov 2008-04-07 17:13:05 EDT

(In reply to comment #11)
> Hi all,
> just to suggest something different, instead of going around looking for new
> bells and whistles to embellish eclipse, why don't you have a look to the
> hundreds of bugs and enhancements requests that sits in a limbo since years?

A handy link to the ~30 most voted bugs (at least 30 votes):

https://bugs.eclipse.org/bugs/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&field-1-0-0=votes&votes=30&order=bugs.votes%2Cbugs.bug_id

The list contains many items which should go *directly* to the 4.0 plan.

Comment 20 Luke Maurer 2008-05-07 18:08:45 EDT

The big theme of Eclipse 4.0 needs to be *refactor*, *refactor*, *refactor*.

Seriously, the amount of duplicated functionality around the Eclipse code base is ridiculous. Every time someone wants to support a new file type, they need to reimplement configuration of syntax highlighting. For projects whose Eclipse plugins are low priorities, this is simply more work than they can afford, and so we end up with things like the Drools plugin hard-coding all the colors (which then clash with my background color). Then, we end up with twenty different panels in which to configure syntax highlighting, and it's all Balkanized - compare to Vim (or Emacs, or NetBeans, or ...) where I can say "make keywords yellow" once and it happens for *every* *language*.

Plus, all the code bloat makes Eclipse a *huge* memory hog.

So please, *please*, forget the big, shiny new features. Eclipse has lots and lots of awesome little features as it is. But it remains incredibly buggy for a product so mature. There's a reason there are such popular issues lasting for years and years, and it's that nothing ever gets simplified. The layers of overengineering just keep piling on.

Comment 21 Mike Wilson 2008-06-09 16:01:33 EDT

Marking as FIXED to align with move to Committed items list in the plan. The overall structure of how Eclipse 4.0 will be built (and the initial set of work areas) has been identified. See the wiki starting at "http://wiki.eclipse.org/E4"

Comment 22 Dieter Krachtus 2008-09-19 18:34:30 EDT

I would like to see Eclipse running on Swing. This has many advantages one of them that you can run Eclipse in the browser.

Technical article: http://eos.sourceforge.net/data/Flexibility%20at%20the%20Roots%20of%20Eclipse.pdf

Plugin to run Eclipse 3.2 *without code changes* on Swing: http://eos.sourceforge.net

For instant evaluation try the simple webstart demo which runs a smaller SWT paint app *without code changes* on Swing: http://eos.sourceforge.net/paint/paint.jnlp

Everything is under the EPL which makes it easy to adopt for e4.

Comment 23 Thomas Schindl 2008-09-20 07:48:29 EDT

If you follow the modeling of the workbench, you'll see that the internals are getting structured in a way that you can replace it with whatever technology you want.

Comment 24 Dieter Krachtus 2008-09-20 08:03:03 EDT

(In reply to comment #23)
> If you follow the modeling of the workbench, you'll see that the internals are
> getting structured in a way that you can replace it with whatever technology
> you want.
> 

Are you referring to SWTSwing replacing SWT? 

One can already switch between them already although the structuring you described really helps. Still, it's more a question of the long term development and support taken over ideally by IBM and that it is shipped as part of e4.

Comment 25 Thomas Schindl 2008-09-20 08:10:28 EDT

Do you suggest that SWTSwing is moved to Eclipse?

Comment 26 Dieter Krachtus 2008-09-20 10:30:17 EDT

(In reply to comment #25)
> Do you suggest that SWTSwing is moved to Eclipse?


In my opinion Eclipse is by now more of a platform than anything else. Being a platform and not only an IDE it is high time that it supports Swing. The technology is there and working. As shown by the EOS project wrapping SWTSwing as plug-in/fragment changes to Eclipse internals necessary for integration are basically none (although minor could help simplify the threading in SWTSwing).

Currently requests mainly from smaller companies who are focused on software migration to the Eclipse platform but are facing the problem that the Eclipse platform only supports SWT which does not run on certain systems:

AIX 5.3/HP-UX 11.0 (http://www.jroller.com/dk/resource/aix_hpux.jpg)
OS/2 (http://www.jroller.com/dk/entry/does_os_2_support_eclipse)

Others want to run their existing Eclipse RCP app where SWT (Cocoa) doesn't exist yet:
OSX 64bit (http://www.jroller.com/dk/entry/swt_running_on_os_2)
...

Apart from having a fall-back implementation of SWT for the Eclipse platform which basically allows it to run on every system that supports Java/Swing, other parties want to use it for company branding, achieve true platform-independence or build Applets based on the Eclipse RCP which run inside the browser.

A big majority are simply interested to use the many advantages of the Eclipse platform and build Eclipse RCP based Swing applications with the neat option to switch to SWT at any time without code changes and zero overhead. Since these parties cannot rely that the technology is maintained as part of the Eclipse platform they stick with their own solutions or use the Netbeans RCP.

There are actually many more opportunities and different interests by all kinds of third parties. A move may inspire even more use cases once people start to fathom the new possibilities the Eclipse platform offers with this technology. I can only hope this will create the incentive to make it a part of e4 (ideally backed up by somebody like IBM).

Comment 27 Antoine Toulmé 2008-09-20 10:54:40 EDT

Dieter, my take on this is that you should create a proposal to create a new component for SWT named SWTSwing, try to get people join the project, manifest their interest and so on, and if possible have a code contribution from the current SWTSwing project. If there isn't already a bug for this, you should open one, and work on the proposal there.

I don't think this should specifically be part of e4, I think you should do it now if you want it to happen, and people will join and help along the way. 

Getting committers from IBM should not be a prerequisite to opening a new component.

I hope this helps you.

Comment 28 Dieter Krachtus 2008-09-20 11:43:03 EDT

(In reply to comment #27)
> Dieter, my take on this is that you should create a proposal to create a new
> component for SWT named SWTSwing, try to get people join the project, manifest
> their interest and so on, and if possible have a code contribution from the
> current SWTSwing project. If there isn't already a bug for this, you should
> open one, and work on the proposal there.

I guess Christopher Deckers would rather do such a step. EOS/SWTSwing are only pet projects in our free time which haven't seen much progress in the last month due to lack of time. As far as I am concerned (and I believe it is similar for Chris) I am pretty busy as it is but would be willing to help in any transition if it holds promise for success.
 
> I don't think this should specifically be part of e4, I think you should do it
> now if you want it to happen, and people will join and help along the way. 
> 
> Getting committers from IBM should not be a prerequisite to opening a new
> component.

That is one way to see it. My view on things is that a Swing implementation of SWT is exceptional from all other aspects comprising the Eclipse platform, most likely comparable to something fundamental as OSGi. Since it is so very fundamental in its nature, for interested parties it is rather a question of trust in long term support as part of e4, then any technological reasoning. Bottom line, somebody like IBM has to step in to make it successful in the long run and e4 would be my opinion the perfect 'place and time' to do it. 

I guess 1-2 (exclusive) committers would be enough to remove all remaining bugs and ensure long-term maintenance. A small price to pay considering the possibilities for Eclipse as a platform presenting something really exciting for e4.

Comment 29 Thomas Schindl 2008-09-20 12:35:02 EDT

Though I agree that it would be great to have an offical SWT-Port for Swing I don't think this will happen simply because there are not enough resources available. SWT is currently porting their code for cocoa.

You are right that Eclipse is much more moving towards a platform and not an IDE. When we talk about RCP, do you want to reuse 3rd party code and mix it with your application. If the answer to this is yes then I think E4 and the workbench-model we have in CVS already for our demo-application makes it possible to exchange SWT through "native" Swing (you don't need a port of SWT for Swing). By the way I have proposed a project named "UFacekit" [1] which provides a highlevel API around Widget-Toolkits and we also support Swing there. I name this because the Platform-Team and the Foundation recognize that Eclipse is not an IDE anymore but a platform.

[1]http://wiki.eclipse.org/Incubator/Platform/UFacekit

Comment 30 Alvaro Romero 2008-11-20 05:35:46 EST

Before all the chat, I apologize for my bad English...

I think that Eclipse really needed features for the next release must be:

1) Simplification: I haven't seen anything of Eclipse's internal code, but the gui and its tools are unfriendly with the user - "usability" means something to users -, because they are "obscure" and hard to learn to new users -even to experienced users -. If the outside is ugly, I don't want to look inside :-D.

Next, a pair of examples... Why the updates are in the Help menu ? Is really hard to implement a "configuration" menu entry where to put all the configurations instead of putting them in the "Window" submenu? Many weird things. They may be stupid issues, but important in the long term - like the configuration files "mess" -.

Simplification makes development and collaborations easier and faster, and improves the evolution of the system. Keep the KISS model as an example.

2) Better update and configuration system: every time I must manage the sites configuration for updates, I have the fear of introducing failures into my Eclipse installation. 

What was bad or ugly in the old, plain and friendly sites.xml to manage the update sites in Ganymede? 

Why I can't see more the description of a feature, if I don't know what it does? 

Why I doesn't have a simpler and centralized configuration system - I tried to change the path of 2 libraries and Eclipse hanged up -?

Configuration files are too disperse.

3) A Eclipse/Web tools "failure" : more control on the project deployment and configuration; the lack of configuration options is frustrating, because is very good for small projects but too bad for the big ones... The EAR configuration seems ridicously simple, whith all jars in the root of the file, and it must be a file instead of a directory - JBoss support this two ways for deployment -.. I had to change the deployment file for JBoss to make the custom deployment layout we needeed, but the web projects inside the EAR are compressed... 

Why developers must use the whole EAR file in every update??? I must deploy a monster of 250+ megs every time for a minor module update?

Why I must put all my utility files with the EJBs, for example, instead of other directory? 

Why I must edit the "obscure" and "hidden" files to customize my deployments, instead of using the IDE?

I agree with other users, less bells and more polish :-)... Eclipse looks more "hackish" and bloated in every release, like PHP in the good times ;-).