| 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.
 
 
 |