Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 313581 - splitting code and configuration of the Marketplace Client
Summary: splitting code and configuration of the Marketplace Client
Status: RESOLVED FIXED
Alias: None
Product: MPC
Classification: Technology
Component: Install (show other bugs)
Version: unspecified   Edit
Hardware: PC All
: P3 normal (vote)
Target Milestone: 1.1   Edit
Assignee: Benjamin Muskalla CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on: 328605
Blocks:
  Show dependency tree
 
Reported: 2010-05-19 13:07 EDT by Markus Knauer CLA
Modified: 2011-04-19 20:25 EDT (History)
3 users (show)

See Also:


Attachments
patch (1.29 KB, patch)
2011-04-13 05:55 EDT, Benjamin Muskalla CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Markus Knauer CLA 2010-05-19 13:07:14 EDT
The configuration of the Marketplace Client is done via extension points and the configuration of the default/exemplary Marketplace is being kept in the same plug-in as the code. This makes it difficult for adopters to reuse the plug-in in a different context, e.g. in an environment where the adopter provides its own Marketplace and doesn't want to include the exemplary Marketplace.

In particular I am asking to move the org.eclipse.epp.mpc.ui.catalog extension from org.eclipse.epp.mpc.ui in a plug-in of its own.

Apart from that I would move the extension org.eclipse.mylyn.tasks.bugs.support too, but I am not sure if this is possible or not. IMO a tight coupling between the MPC and the Mylyn bugs support is not what users or adopters expect. I would prefer kind of an "optional" dependency, but again - I don't know the architecture behind.
Comment 1 Benjamin Muskalla CLA 2011-03-08 12:02:31 EST
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.
Comment 2 Ian Skerrett CLA 2011-03-08 12:52:32 EST
(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?
Comment 3 Benjamin Muskalla CLA 2011-03-08 12:56:47 EST
> 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?
Comment 4 Ian Skerrett CLA 2011-03-08 13:00:16 EST
(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?
Comment 5 Markus Knauer CLA 2011-03-10 05:25:33 EST
(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.
Comment 6 Benjamin Muskalla CLA 2011-03-10 14:58:46 EST
> 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.
Comment 7 Benjamin Muskalla CLA 2011-03-12 16:34:48 EST
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
Comment 8 Benjamin Muskalla CLA 2011-03-15 14:47:31 EDT
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.
Comment 9 Markus Knauer CLA 2011-03-15 15:57:53 EDT
(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...
Comment 10 Benjamin Muskalla CLA 2011-03-15 16:01:49 EDT
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).
Comment 11 Markus Knauer CLA 2011-03-15 16:10:39 EDT
Okay, good to hear that it is already listed there. Thanks Benny!
Comment 12 Benjamin Muskalla CLA 2011-04-13 05:55:00 EDT
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).
Comment 13 Benjamin Muskalla CLA 2011-04-19 20:25:53 EDT
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.