Bugzilla – Full Text Bug Listing
| Summary: | splitting code and configuration of the Marketplace Client | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Technology] MPC | Reporter: | Markus Knauer <mknauer> | ||||
| Component: | Install | Assignee: | Benjamin Muskalla <b.muskalla> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | greensopinion, ian.skerrett, tom.seidel | ||||
| Version: | unspecified | ||||||
| Target Milestone: | 1.1 | ||||||
| Hardware: | PC | ||||||
| OS: | All | ||||||
| Whiteboard: | |||||||
| Bug Depends on: | 328605 | ||||||
| Bug Blocks: | |||||||
| Attachments: |
|
||||||
|
Description
Markus Knauer
Markus, I see two separate requests here. > move the extension for the Eclipse marketplace bundle itself into the EPP bundles I think this makes sense to have not that tight couling between the MPC and which marketplaces are listed. Ian, what do you think? From our users POV, nothing would change. But this change would allow integrators of the MPC to use their own marketplaces instead of having the Eclipse marketplace hardcoded. This is the same approach we currenlty do for other marketplaces (eg. yoxos) which live in org.eclipse.epp.package.common > Remove the mylyn dependency The idea is great, I just don't see any action required for now. MPC does't have an hard dependency on Mylyn (eg. it doesn't pull in Mylyn) but contributes to an mylyn extension point. This means that if mylyn is not available, no harm is done. If mylyn is available, the bug support is used. (In reply to comment #1) > Markus, I see two separate requests here. > > > move the extension for the Eclipse marketplace bundle itself into the EPP bundles > I think this makes sense to have not that tight couling between the MPC and > which marketplaces are listed. Ian, what do you think? From our users POV, > nothing would change. But this change would allow integrators of the MPC to use > their own marketplaces instead of having the Eclipse marketplace hardcoded. > This is the same approach we currenlty do for other marketplaces (eg. yoxos) > which live in org.eclipse.epp.package.common > I agree it should not be hard code. However, now that we get the catalogs from a server does this remove the problem? I guess we should make sure the actual server location is not hard coded too? > I agree it should not be hard code. However, now that we get the catalogs from
> a server does this remove the problem? I guess we should make sure the actual
> server location is not hard coded too?
My suggestion would be:
* remove marketplace definitions from EPP bundles
* let marketplace definitions come from the server
* server location *can* be contributed, default is eclipse.org
This way, Eclipse.org has the control over the marketplaces of the EPP packages and integrators can provide their own marketplace listing. Does this make sense to you Ian?
(In reply to comment #3) > > I agree it should not be hard code. However, now that we get the catalogs from > > a server does this remove the problem? I guess we should make sure the actual > > server location is not hard coded too? > > My suggestion would be: > * remove marketplace definitions from EPP bundles > * let marketplace definitions come from the server > * server location *can* be contributed, default is eclipse.org > > This way, Eclipse.org has the control over the marketplaces of the EPP packages > and integrators can provide their own marketplace listing. Does this make sense > to you Ian? Sounds good. Markus do you agree? (In reply to comment #4) > Sounds good. Markus do you agree? Sure, sounds good to me, too! (In reply to comment #1) > > Remove the mylyn dependency > The idea is great, I just don't see any action required for now. MPC does't > have an hard dependency on Mylyn Did something change in the meantime or what did I see back then? I am not sure what I observed last year. Anyway, if there is no (hard) dependency I take that back. > Did something change in the meantime or what did I see back then? I am not sure
> what I observed last year. Anyway, if there is no (hard) dependency I take that
> back.
From the git history, nothing changed. And I just checked it again, no Mylyn dependencies in MPC.
Ok, to summarize: * resolve 328605: MPC should retrieve list of catalogs from the server https://bugs.eclipse.org/bugs/show_bug.cgi?id=328605 * remove Eclipse Marketplace extension from o.e.e.mpc.ui bundle * remove Yoxos extension from EPP commons bundle Ian, giving the time constraints we have, I'd postpone this change to do after M6 so we can test it properly. From a user POV, nothing changes, this is only about code cleanup. The marketplace branding etc overrides the local extensions anyway. So nothing critical for M6. (In reply to comment #7) > * remove Yoxos extension from EPP commons bundle This is (was) done. Do you have any pointers what I have to do next in order to re-include Yoxos? I am sure there is a bug or a web page that describes the required steps... Markus, the intention of this task is to move the marketplace information from the client (plugin.xml) to the server. Yoxos is already listed as marketplace in the foundation database with the same information that was in the plugin.xml (see http://marketplace.eclipse.org/catalogs/api/p). I'm sure Ian can shed some light on this how to maintain the information on the server in the future (communication between Strategic members and the Foundation). Okay, good to hear that it is already listed there. Thanks Benny! Created attachment 193141 [details]
patch
This patch removes the marketplace contribution from the MPC bundle as the catalogs are retrieved from the server anyway. Will commit once voting is done.
Markus, do you have a bug over at EPP to do the same there? Essentially it's about deleting the o.e.epp.commons bundle (or just remove icon and plugin.xml).
Patch pushed to master. MPC itself doesn't contribute anymore any catalogs and completely relies on the server-side configuration of marketplaces. Markus, I created bug 343327 for the EPP part. From an MPC POV, we're done here. |