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?

> But it's probably not a great idea for end users, at least not yet.

 

Plenty of time to work out the major kinks in time for Luna if we get started soon.

 

> And it certainly isn't a good idea for the Eclipse infrastructure and would chew through way too much bandwidth.

 

I wonder if this a valid assumption. On one hand, a single package will be unquestionably bigger. On the other hand, we would be cutting down on times that people have to re-download packages since they’ve downloaded the wrong one. Not an uncommon occurrence judging by forum posts. Not to mention that there will be less traffic on the aggregate repository since many users will already have everything that’s available there. Also, building and hosting a single package is also cheaper than doing that for twelve packages.

 

> Maybe we can use or adapt the Ecilpse Marketplace to make it easier to load up components.

 

All sorts of technological solutions are possible, but then someone would have to invest into that and usability improvements are not guaranteed. Building a single package instead of twelve doesn’t require new technology to be developed and instantly puts most available tools from eclipse.org in user’s hands.

 

I would be willing wager that if we were to run an experiment where we kept the existing twelve packages and added an everything package, the download numbers on existing packages would plummet into nothing. Right now, the user perception that I see in the forums is that Eclipse is a “some assembly required” IDE, while NetBeans or IntelliJ give them everything they need to be productive. I would love to put an end to that sentiment.

 

- Konstantin

 

 

From: cross-project-issues-dev-bounces@xxxxxxxxxxx [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of Doug Schaefer
Sent: Monday, July 29, 2013 5:16 PM
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.

 

Doug.

 

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.

 

Thoughts?

 

- Konstantin


Back to the top