I agree with you on one point… EPP should be installing everything as a top-level feature so that updates work properly.
As to the rest… If installable components were easy to discover and user didn’t mind doing this, we wouldn’t see comments about Eclipse missing basic functionality, like XML support.
When our competition ships a complete product and we ship a box of parts with a “some assembly required” sticker, we don’t position Eclipse in a good light. Rather like in the car world, we have a relatively small community of folks who like to tinker with their IDE, but the majority of people just want to get the job done.
Thanks,
- Konstantin
From: Szymon Ptaszkiewicz
Sent: Wednesday, October 21, 2015 4:45 AM
To: Discussions about the IDE
Subject: Re: [ide-dev] Ctrl-1 driven development
> because Eclipse.org was pushing the "lowest common denominator"
Well, to me that was a tradeoff.
One significant advantage of using the "lowest common denominator" is that whatever you install on top of it, it is installed as the root feature which means "Check for updates" works as one might expect. And in order to install anything you need to go to Help > Install New Software... and then browse the list to find what you need. You achieve 2 goals: user has to browse the list manually so he gets familiar with what he can find there and "Check for updates" works.
In case of EPP packages, we try to be smart and collect features that certain group of people may need, but as shown in this discussion this is not always easy and there are different opinions whether functionality X should be part of package Y. So we achieve 3 goals: packages don't meet users' needs (or at least are controversial), "Check for updates" does not work and we have endless discussions how to provide better packages and possibly release it more frequently to mitigate the lack of "Check for updates".
The tradeoff is that we replaced flexibility of a thin base package (be it Eclipse SDK or a thin EPP package) with predefined suitability of EPP packages which is not always really suitable. In order to explain the difference to a regular user, you need to explain what root features are there and this is an advanced topic even for professionals and experienced Eclipse users. To me, it is better to give a thin base and then let the user choose what he needs to install while at the same time he learns what other cool features are there, rather than give them what we think he may want and either way expect him to find and install additional stuff. Explaining how to install a new feature is a basic discussion and can be done with any user even newcomer, but explaining why some features benefit from "Check for updates" and some not is a lot more difficult.
To summarize, I'm not sure if we are "recovering" in the right direction.
Szymon
"Max Rydahl Andersen" ---2015-10-21 12:35:43---On 20 Oct 2015, at 18:57, Wayne Beaton wrote: > FWIW, I regard the Eclipse SDK as the output of the
From: "Max Rydahl Andersen" <manderse@xxxxxxxxxx>
To: "Discussions about the IDE" <ide-dev@xxxxxxxxxxx>
Date: 2015-10-21 12:35
Subject: Re: [ide-dev] Ctrl-1 driven development
Sent by: ide-dev-bounces@xxxxxxxxxxx
On 20 Oct 2015, at 18:57, Wayne Beaton wrote:
> FWIW, I regard the Eclipse SDK as the output of the Eclipse project,
> not one of our front-line "consumer" downloads.
exactly and it is only recently (last year?) we finally got the download
page to not serve the "basic" package as default.
I think alot of users missed things like code recommenders, maven and
xml for years purely because Eclipse.org was pushing
the "lowest common denominator".
It will take some time to 'recover' from this.
/max
http://about.me/maxandersen
_______________________________________________
ide-dev mailing list
ide-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ide-dev
