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 cases.
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 end users.
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