+1
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 <[email protected]
<mailto:[email protected]>>
Reply-To: Cross project issues <[email protected]
<mailto:[email protected]>>
Date: Monday, 29 July, 2013 8:30 PM
To: "[email protected]
<mailto:[email protected]>"
<[email protected]
<mailto:[email protected]>>, Cross project issues
<[email protected]
<mailto:[email protected]>>
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
[email protected] <mailto:[email protected]>
+1.613.220.3223
*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.
Doug.
From: Konstantin Komissarchik <[email protected]
<mailto:[email protected]>>
Reply-To: Cross project issues <[email protected]
<mailto:[email protected]>>
Date: Monday, 29 July, 2013 6:35 PM
To: 'Cross project issues' <[email protected]
<mailto:[email protected]>>
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
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
