Community
Participate
Working Groups
Having the client hard coded with the locations of all the Marketplace Catalogs could prove troublesome if we ever have a problem with a catalog and wish to de-list it permanently or temporarily. We should move this list to the server and fetch it when launching MPC. This would allow not only remove entries but also add them on the fly.
Nathan, we'd need new API to retrieve the list of marketplaces here. Or do we already have API for this somewhere? If not, I'd suggest to use the attributes that we currenlty have in the extension point: url - An URL that points to a web resource that implements the marketplace API. label - A label that identifies the catalog description - A brief description of the catalog which is presented to the user. icon - A branding icon for the catalog. Must be of size 32x32. selfContained - A boolean indicating if the catalog is self-contained. If unspecified, the default value is 'true'. dependenciesRepository - An URL that points to a a software repository that can be used to resolve dependencies for solutions installed from this catalog. One thing I wonder about: Should we implement this in addition to the extension point? If we'd remove the extension point now, this would be an API break. I'd rather deprecate the extension point. In addition, we need to provide a new extension point that allows to plug in the "central repository" that delivers the locations of the marketplaces (only Eclipse.org for now) so others can integrate their own markeplace listings into their products.
(In reply to comment #1) > One thing I wonder about: Should we implement this in addition to the extension > point? If we'd remove the extension point now, this would be an API break. I'd > rather deprecate the extension point. In addition, we need to provide a new > extension point that allows to plug in the "central repository" that delivers > the locations of the marketplaces (only Eclipse.org for now) so others can > integrate their own markeplace listings into their products. I was wondering about that, too. Ian, what was your idea on how third parties can contribute their catalogs? By providing their own REST service (and the MPC client somehow, e.g. extension point, getting this locaion)? Or by providing the catalog information (or URL(s)) to eclipse.org's Marketplace, which is serving all those third party catalogs to the MPCs? Ben, correct me if that's already known or discussed.
(In reply to comment #1) > One thing I wonder about: Should we implement this in addition to the extension > point? We need to keep the extension point. Anyone should be able to add a catalog. All we are saying is that the catalogs that come 'pre-bundled' with MPC need to be discovered through a call to a service hosted at eclipse.org. The Eclipse Foundation will run and manage what is made available. FYI, right now any strategic member is allowed to provide a catalog that gets bundled with MPC.
(In reply to comment #2) > (In reply to comment #1) > > I was wondering about that, too. > Ian, what was your idea on how third parties can contribute their catalogs? By > providing their own REST service (and the MPC client somehow, e.g. extension > point, getting this locaion)? Or by providing the catalog information (or > URL(s)) to eclipse.org's Marketplace, which is serving all those third party > catalogs to the MPCs? Right now the MPC bundles the extension points that include the third party catalogs. We want to move to a model so that the eclipse.org can provide the catalog list dynamically. However, as I mentioned we need to keep the extension point. This will allow others to provide catalogs.
Over to you Nathan. It would great to get this resolved so we can start working on this. This would also involve additional attributes for 336159: user can see catalog branding in MPC wizard https://bugs.eclipse.org/bugs/show_bug.cgi?id=336159
(In reply to comment #5) > Over to you Nathan. It would great to get this resolved so we can start working > on this. > This would also involve additional attributes for 336159: user can see catalog > branding in MPC wizard > https://bugs.eclipse.org/bugs/show_bug.cgi?id=336159 I've begun building the blocks on Marketplace to make this happen. I'll keep this bug updated.
I've published the initial implementation of the catalog API. http://marketplace.eclipse.org/catalogs/api/p Please review and provide feedback.
From my POV, the API looks good. Will get back to you in case there is something blocking the implementation. An open question is: which information to use in case we have a local contribution (plugin.xml) and the same information retrieved from the server. In my eyes, it makes more sense to use the remote information as this is potentially newer than the local one. We will still merge both catalog contributions, this question is only about duplicate information (read: urls are equal). Ian, does this make sense to you?
It makes sense to me that the remote contribution should override the local one in the case where the referenced catalogs are the same (ie: they have the same URL).
(In reply to comment #8) > From my POV, the API looks good. Will get back to you in case there is > something blocking the implementation. > > An open question is: which information to use in case we have a local > contribution (plugin.xml) and the same information retrieved from the server. > In my eyes, it makes more sense to use the remote information as this is > potentially newer than the local one. We will still merge both catalog > contributions, this question is only about duplicate information (read: urls > are equal). Ian, does this make sense to you? Shouldn't we be showing both as two different catalogs? Maybe I am not understanding the scenario?
The scenario is that a catalog (identified by its URL) is specified twice: once by the user's local installation as a plug-in contribution, and second time by the catalog listing service (on the server). It's one catalog, specified multiple times.
(In reply to comment #11) > The scenario is that a catalog (identified by its URL) is specified twice: once > by the user's local installation as a plug-in contribution, and second time by > the catalog listing service (on the server). It's one catalog, specified > multiple times. So if it is the same URL I can imagine the catalog information would be identical? What we are discussing is potential branding differences. Is that correct? First, I am not sure how we would get into such a situation. One scenerio I can imagine is for testing purposes a catalog provider wants to override the server for their own workspace. Are there other scenerios?
Another scenario is that MPC ships with Eclipse Marketplace defined by a plug-in, and then decides to update branding by listing on the server as well.
Ian, another possible scenario: current EPP bundles include the Yoxos marketplace and call it "Yoxos Marketplace" (local). The marketplace server lists the Yoxos marketplace as "EclipseSource marketplace" (remote). In this case, we have the same marketplace with different brandings. That's why I think the "remote" information should override the local information to be able to update the branding of the marketplaces without a new Eclipse release. Nathan, currently I'm missing the "dependenciesRepository" attribute in the marketplace listing. Could you please add that? For now, the eclipse marketplace can point to "http://download.eclipse.org/releases/indigo". Thanks
(In reply to comment #14) > Ian, another possible scenario: current EPP bundles include the Yoxos > marketplace and call it "Yoxos Marketplace" (local). The marketplace server > lists the Yoxos marketplace as "EclipseSource marketplace" (remote). In this > case, we have the same marketplace with different brandings. That's why I think > the "remote" information should override the local information to be able to > update the branding of the marketplaces without a new Eclipse release. > FWIW, I don't see EPP bundling marketplace plugins. The whole idea of having the control from the server was to give us more flexibility to update, add and remove catalogs outside of a package release. btw, I am not against the remote server being the default. I just think we might get a situation where the decision will not be what someone would expect.
Is the server listing providing a dependencies repository? It should (see bug 332073). The extension point allows for that: bc. <catalog description="%catalog.description" icon="icons/marketplace32.png" label="%catalog.label" url="http://marketplace.eclipse.org" dependenciesRepository="http://download.eclipse.org/releases/helios"> </catalog> The @dependenciesRepository@ attribute is used to specify where dependencies are resolved from when installing solutions from the marketplace. Catalogs can (should) specify a composite repository so that they can add multiple repositories when it makes sense (eg: both helios and indigo)
Changes were merged together with the branding feature. See task 336159 for the changes.
I've updated the catalog API call to include the icon as an attribute of the catalog. http://marketplace.eclipse.org/catalogs/api/p I've also added the Marketplace listing and Yoxos catalogs to the server.
These look good Nathan, except that the @dependenciesRepository@ is not appearing.
(In reply to comment #19) > These look good Nathan, except that the @dependenciesRepository@ is not > appearing. Sorry about that, should be appearing now.
Catalogs are now retrieved from the server. Closing this as fixed.
