Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Are too many packages actually hurting Eclipse?

There was a “build your own Eclipse” initiative a few years back that was a similar concept, except the assembly would happen before the download. That didn’t go anywhere. I don’t recall seeing an explanation of why it was abandoned, but I imagine lack of resources played a part. Most parties contributing to Eclipse would rather develop features than work on improving packaging and distribution. Even for existing solutions, such as Eclipse Marketplace Client, enhancements and fixes are hard to come by. For instance, we still can’t filter solutions by compatible Eclipse releases. Not a criticism, mind you, but an acknowledgment that it is easy to get lost dreaming of solutions that ultimately have little chance of being developed.


- Konstantin



From: cross-project-issues-dev-bounces@xxxxxxxxxxx [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of Andrew Ross
Sent: Monday, July 29, 2013 6:11 PM
To: cross-project-issues-dev@xxxxxxxxxxx
Subject: Re: [cross-project-issues-dev] Are too many packages actually hurting Eclipse?



Looking at your Linux distro of choice or Android as examples... this model works very well and is still nicely flexible.

On 29/07/13 20:36, Doug Schaefer wrote:

+1 for that. I've seen (and made for that matter) commercial products do that. Download a minimal p2 install with an Eclipse application that drives the rest of the install. We could ask for a list of languages or platforms they want to develop for and then install the necessary components.


From: Mike Milinkovich <mike.milinkovich@xxxxxxxxxxx>
Reply-To: Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
Date: Monday, 29 July, 2013 8:30 PM
To: "cross-project-issues-dev@xxxxxxxxxxx" <cross-project-issues-dev@xxxxxxxxxxx>, Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
Subject: Re: [cross-project-issues-dev] Are too many packages actually hurting Eclipse?



Another potential solution that should be on the list for consideration is a reasonably smart installer. 


Mike Milinkovich

From: Doug Schaefer

Sent: Monday, July 29, 2013 8:16 PM

To: Cross project issues

Reply To: Cross project issues

Subject: Re: [cross-project-issues-dev] Are too many packages actually
hurting Eclipse?


That's great question I was asking myself looking at the Download page the other day. I don't think I have a great answer though.


I like the idea of the big uber package for the reason you list as #3. I'd like to fix our tools plug-ins to play nicer together. Having this package would give us a test bed to work towards.


But it's probably not a great idea for end users, at least not yet. And it certainly isn't a good idea for the Eclipse infrastructure and would chew through way too much bandwidth.


Maybe we can use or adapt the Ecilpse Marketplace to make it easier to load up components. The p2 UI is pretty tough on new users. Marketplace client is a much better experience but it's still hard to discover things. But we could provide our own catalog to accomplish this goal.




From: Konstantin Komissarchik <konstantin.komissarchik@xxxxxxxxxx>
Reply-To: Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
Date: Monday, 29 July, 2013 6:35 PM
To: 'Cross project issues' <cross-project-issues-dev@xxxxxxxxxxx>
Subject: [cross-project-issues-dev] Are too many packages actually hurting Eclipse?


There are twelve packages currently listed on the downloads page, not counting the promoted ones. Are so many packages actually a benefit to users? We try to define packages based on developer profiles, but real developers rarely fit a profile. One of the most common complaints that I have seen on forums are related to difficulties in getting an Eclipse installation that has all the pieces that the developer requires. The ironic thing is that we go through a lot of trouble to define a common repository with components that are known to work with each other, but then fragment the result into a dozen different packages.


Would user experience be better if there was only one Eclipse package on the main download site that had pretty much everything that’s in the aggregated repository?


Some of the reasons for not doing that…


1. The package would be too large. With modern download speeds, I suspect most users would rather wait a few minutes longer for Eclipse to download than spend time later trying to figure out how to install the missing pieces. The disk space difference is also inconsequential these days.


2. The users prefer to not include pieces in their installation that they don’t use. I can see that being the case for some advanced Eclipse users, but I don’t believe this holds true across the user base. I suspect that most users would rather spend time on their development project than tuning their Eclipse installation.


3. Too many plugins in one installation leads to poor user experience. If there are problems like that, we should be identifying and fixing them.




- Konstantin


Back to the top