to fragment the repository around user profiles isn’t
going to be easy or clean. Many users and use cases will
not easily fit into neat profiles.
the other hand, we already have a venue for presenting
users with an easier to use course-granularity
installation option… Eclipse Marketplace.
+1, but probably way too late to be asking people to make
these kind of changes now. Something that people should be
thinking hard about for Kepler. There is a major need for
a higher level of granularity on the features. Ideally it
would be one per project but that isn't practical in many
On 2012-05-29, at 8:29 AM, Pascal Rapicault wrote:
Once in a while I go through the
content of the Juno repo to see what's there; and I try to
see if I can make any sense of what is made available.
Unfortunately this year it reached a point where I just
can't. There are way too many entries that are subtle
variations around the same project and whose installation
result in unexpected results or non functional additions
to my install. For example there is 11 entries for
Sapphire, 5 entries for windowBuilder, an infinity of
Mylyn related entries...?
I understand that we are all trying
to promote our project and brand, but I would argue that
the plethora of entries has a reverse effect that let
the user confused as to what to install.
So the main question is "what is the
primary target audience of the Juno repo?"
- an eclipse user - e.g. a JEE programmer
- an eclipse extender - e.g. someone using
eclipse technologies to build an app
At this point, the content of the
repo looks like what we are addressing both audience
which may be a convenience for us but a nuisance for the
IMO, the Juno repo should be "end
user" focused and only include entries whose
installation will result in new functionalities to be
added to the IDE. Also each entry should have
- a descriptive name (which include removing
adjectives such as incubation, extender)
- a minimal number of entries returned when I
search for the name
- be adequately categorized
How do we go about exposing the rest
of the content for extenders?
- Different repo URLs (e.g. download.eclipse.org/releases/juno/developer)
- Addition of a developer focused category (with
cross-project-issues-dev mailing list
Mylyn and Virgo
Lead, Model Focussing Tools and AMP