Just my personal opinion, but given that the Marketplace Client is quite popular and is included in almost all of the packages, I would recommend that Eclipse projects take the time to make their project distributions available via that channel.
From: [email protected] [mailto:[email protected]] On Behalf Of Konstantin Komissarchik Sent: May-29-12 12:39 PM To: 'Cross project issues' Subject: Re: [cross-project-issues-dev] Target audience of Juno repo Trying 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. On the other hand, we already have a venue for presenting users with an easier to use course-granularity installation option. Eclipse Marketplace. - Konstantin From: [email protected] [mailto:[email protected]] On Behalf Of Miles Parker Sent: Tuesday, May 29, 2012 9:25 AM To: Cross project issues Subject: Re: [cross-project-issues-dev] Target audience of Juno repo +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 nested categories) wdyt? Pascal _______________________________________________ cross-project-issues-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ______________________________ Miles T. Parker Senior Solutions Architect Tasktop http://tasktop.com Committer, Eclipse Mylyn and Virgo Project Lead, Model Focussing Tools and AMP http://milesparker.blogspot.com skype: milestravisparker
_______________________________________________ cross-project-issues-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
