On 19/10/2015 9:38 AM, John Arthorne
wrote:
These recent comments are along the lines of "let's
split Eclipse projects into even smaller separately installable
pieces", which I think goes in the wrong direction. This might let
an expert craft a finely tuned install of exactly the pieces they
need, but makes the problem of plugin discovery, configuration,
and management more painful. I think this hurts the novice or
casual user, and even highly advanced users like Michael Scharf
find this cumbersome. I would rather there be fewer choices a user
has to make, even if it means bundling in things they might not
need.
I agree that cutting things up into even smaller units that users
are expected to install is not helpful. However, I think that the
problem is subtly different than how you have stated it.
I would characterize the problem as we "ship our organization",
rather than focusing on solutions from the users perspective. As a
simple example XML editing is a feature that almost all developers
will need at some point. But instead of having our best XML editor
in our base Java package we expect users to figure out that it's in
WTP. And, I am assuming, they need to install all of WTP if they
want the better XML editing features.
Our users do not care about how we are organized. Top-level projects
are something that only a very few Eclipse cognoscenti care about.
Delivering the right combination of features --- regardless of their
project homes --- is what our users want.
|