Community
Participate
Working Groups
I want to discuss the inclusion of the marketplace client into the classic download. The classic download is the unpolluted download. I can see that inclusion of non-platform code must be avoided but we must answer the following question: "is the classic download something that will be used "as is" or will it be used as a base for customization." If the answer to the question is "as is" then fine, but if it is the latter, i.e used for customization then inclusion of the client is something to reconsider. The "drag to install" experience will not work for classic which is confusing.
Moving to the Platform team because it's their decision what they are providing in their Classic/SDK download. Some things to consider... * The Platform team is always the first team that delivers at +0 day to the build. Therefore they avoid (cyclic) dependencies to downstream projects that deliver their bits later (+1, +2, ...) * I think it's good to have a very small/clean package available from the download page. And if really required the Marketplace client can always be installed from their p2 repository. * In bug 317881 I proposed a really really small Platform+Marketplace Client package (note: not SDK!). Maybe that's close to what you want. If your answer is yes, then it's worth commenting on this bug.
I for one like the idea of a "clean" classic package, and do not use the marketplace which furthermore is something that is only needed at setup time, when building the environment ... and never again afterwards (at least for me as I mainly build "dev" environment). just my 2 cents ;)
(In reply to comment #1) > Moving to the Platform team because it's their decision what they are providing Sure, but I think feedback from projects is valuable to them as well. > > * The Platform team is always the first team that delivers at +0 day to the > build. Therefore they avoid (cyclic) dependencies to downstream projects that > deliver their bits later (+1, +2, ...) Agreed, but this is something that would concern packaging and not per se platform. There will always be a synchronized publish on eclipse.org/download for all the packages and marketplace is provided in all but one.
(In reply to comment #2) > I for one like the idea of a "clean" classic package, and do not use the > marketplace which furthermore is something that is only needed at setup time, > when building the environment ... and never again afterwards (at least for me > as I mainly build "dev" environment). So you do use it ;) I agree with you that the classic package is excellent even without MP, but it is a time saver when you need to install stuff that is not provided in one of the main repos (subclipse, findbugs, maven ..) In fact, 8 of the 10 top downloads in marketplace are outside of Eclipse[1]. [1] http://marketplace.eclipse.org/favorites/top
(In reply to comment #4) > So you do use it ;) No, I was just transposing my use of p2 to what I would do with the MP :). > I agree with you that the classic package is excellent even without MP, but it > is a time saver when you need to install stuff that is not provided in one of > the main repos (subclipse, findbugs, maven ..) > > In fact, 8 of the 10 top downloads in marketplace are outside of Eclipse[1]. > > [1] http://marketplace.eclipse.org/favorites/top To tell the truth, most of the things I install in my environments _are_ out of Eclipse (or in ... but not by default as the annoying-to-find orbit update site). But I can find most, if not all, of their update-sites URIs through google faster than it would take on the marketplace, _if_ they are all on the marketplace ;). Then again, that is only my opinion of the way I use the classic package. I cannot speak for others ^^.
I'm moving this to the PMC bucket for further discussion and final decision. I don't think this belongs into the SDK, but like the idea expressed in comment 1.
I concur with Dani on both points.
Wim, get over it, use a package! ;) But seriously, I like the idea of comment 1.
(In reply to comment #8) > Wim, get over it, use a package! ;) But seriously, I like the idea of comment > 1. :). Sure I would like that. But this is my profile: I am an RCP developer (needs SDK) that has no need for J2EE, BIRT or RAP. What package is there for poor guys like me?
That's more related to the Marketplace, but somehow connected to Eclipse projects, especially the projects participating in the Simultaneous Release... What about making *all* Eclipse projects available from the Eclipse Marketplace? Or at least the Simultaneous Release projects? Maybe a sub-market of its own to keep things separate, but that way we would overcome the unnecessary separation between Eclipse projects ('Help' > 'Install new software...') and 3rd party extensions ('Help' > 'Eclipse Marketplace...'). Just another idea, maybe worth a bug of its own.
I agree with Dani. The whole point of Eclipse Classic is that it's the SDK used for self-hosting Eclipse development. It caters to the Platform team (the "producers") more than the consumers, and it is a building block. Changing its contents has potential for causing more disruption (for builds, due to dependencies as well as for adopters) than there would be value in adding stuff. That being said, I like the idea of making it easier to bootstrap creating a custom Eclipse based IDE that is slightly different than any of the pre-bundled packages. For instance, adding/changing CM integrations should be a lot easier (eg get rid of CVS, but add Subclipse and egit or maybe Perforce). We discussed some of that on the PMC on Oct 5, 2011 : http://wiki.eclipse.org/Eclipse/PMC/Minutes_2011 Regarding that workflow, I agree with Markus that finding the stuff that I need is not easy in MPC. Anyways I think that such improvements should be discussed in the context of the MPC project or Packaging project (Markus' bug 317881 is a good start) since this would primarily cater to the consumers, and not the producers. Maybe there's even a case for removing Eclipse Classic from the package download page, and replacing it by a package more suited for consumers.
(In reply to comment #10) > What about making *all* Eclipse projects available from the Eclipse > Marketplace? Or at least the Simultaneous Release projects? Maybe a sub-market > of its own to keep things separate, but that way we would overcome the > unnecessary separation between Eclipse projects ('Help' > 'Install new > software...') and 3rd party extensions ('Help' > 'Eclipse Marketplace...'). > Just another idea, maybe worth a bug of its own. Yes. This is a great idea. One option that crossed my mind is to provide a flag in the build.properties file in a feature: empc-target: true with some additional marketplace control file perhaps.
I like both ideas: 1) Help "producers" add content to the "classic" Eclipse (like JDT / CDT / GEF / EMF) and so create other custom packages. 2) Add MPC to "classic" or whatever it would be later. I found it really distracting to NOT have MPC in classic, which was and is for years my default distribution.
*** Bug 391422 has been marked as a duplicate of this bug. ***
People are filing bugs to change the behavior of other packages [1]. Maybe we should change this bug. Instead of asking for an upgrade of the Eclipse Classic download. What RCP developers really want is a solid Eclipse for RCP developers build. [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=383802
Filed: https://bugs.eclipse.org/bugs/show_bug.cgi?id=400676
I advocate fixing this through creation of a new "Classic" package that has MPC: https://bugs.eclipse.org/bugs/show_bug.cgi?id=397896 The discussion about creating a new (non-RAP) RCP package is a different one mostly centered around bug 400676 and bug 383802 ; those two are not related to Eclipse Platform PMC. I am, however, interested in making the "bootstrapping" of an Eclipse install more versatile. Wouldn't it be cool if an end user could create his package himself simply by pointing to an URL with a pakcage description (could be via marketplace client) and then exporting that install as a ZIP archive. But that's a separate discussion which I don't want to start before bug 397896 is implemented and thus this one is also fixed..
(In reply to comment #17) Like Yoxos?
(In reply to comment #18) > Like Yoxos? I know Yoxos by name but haven't ever used it personally ... so it might help if you could explain what behavior / user experience you mean by that.
(In reply to comment #19) > (In reply to comment #18) > > Like Yoxos? > > I know Yoxos by name but haven't ever used it personally ... so it might > help if you could explain what behavior / user experience you mean by that. Yoxos is a repository manager / EPP Package creator all built with p2. That is, you add a bunch of components (jdt, pde, git, whatever), and Yoxos will generate a 'profile' for you. You can download the profile as a runnable Eclipse install, or connect to that profile as p2 repository (to share configurations, build targets, create build-time dependencies, etc...). All the dependencies will be computed, so the repository (and the install) will include only what you added (plus their requirements). Martin, I'd be happy to give you a demo at EclipseCon, or try it at https://yoxos.eclipsesource.com/. If you have any questions, feel free to ping me.
This has been implemented with the "new classic" package in Kepler M6, as per https://bugs.eclipse.org/bugs/show_bug.cgi?id=397896 . The package is available from http://www.eclipse.org/downloads/packages/eclipse-classic-43-m6/keplerm6 . Please file any new issues with the classic packaging / contents against the EPP "classic-package" component.
Excellent! Thank you.
