Bugzilla – Full Text Bug Listing
| Summary: | Include Yoxos marketplace in marketplace listing | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Technology] MPC | Reporter: | Jochen Krause <jkrause> | ||||
| Component: | Install | Assignee: | Project Inbox <mpc.install-inbox> | ||||
| Status: | CLOSED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | ian.skerrett, mknauer, nathan | ||||
| Version: | unspecified | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Mac OS X - Carbon (unsup.) | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Jochen Krause
Moving to MPC project The Eclipse Foundation would like the ability to bundle external catalogs from Strategic Members. It is not clear to me if this should be managed/handled in the MPC project or the EPP project. My inclination is that since this is packages, it should be handled by the EPP project. Markus do you have an opinion? Ideally we would include the Yoxos catalog for RC1. Jochen, for this to happen we really need that patch today. We also need Yoxos people to help with the package testing. (In reply to comment #2) > Markus do you have an opinion? Technically we have several options and I can add the catalog definition to the branding plug-ins of the EPP packages. But I think it is important to keep the definition of all MPC catalogs in *one* place/project, either in the MPC project itself, or in the EPP packages. What I would like to avoid is to keep the definition of the Eclipse Marketplace in MPC and to maintain other catalogs (e.g. the Yoxos catalog) in the EPP packages. IMO we should decide between (a) removing the catalog definition from the MPC plug-ins and adding all definitions to the EPP branding plug-ins OR (b) adding all catalog definitions to the MPC plug-ins (In reply to comment #3) > (In reply to comment #2) > > Markus do you have an opinion? > > Technically we have several options and I can add the catalog definition to the > branding plug-ins of the EPP packages. > > But I think it is important to keep the definition of all MPC catalogs in *one* > place/project, either in the MPC project itself, or in the EPP packages. What I > would like to avoid is to keep the definition of the Eclipse Marketplace in MPC > and to maintain other catalogs (e.g. the Yoxos catalog) in the EPP packages. Why do you think it is important we keep all the catalogs in one place? MPC needs at least one catalog to work and the Eclipse Marketplace will always be the default catalog. Basically the exemplary tool (catalog) for MPC. Therefore, I can definitely see the MPC team wanting/requiring that they ship with that catalog. The additional catalogs are a bit of a gray area for me but it feels like their addition is a packaging function. However, I don't have a strong feeling. I am curious why you think it is important they are all in one location? If someone would like to run the marketplace client internally he probably does not want the Eclipse listing. He would then have to "hack" the marketplace client plugin. I see this use case for some of our clients. I think it would be best to separate the marketplace configuration from the actual functionality. It does not really matter where the configurations are added, but the packaging project seems like a good fit. (In reply to comment #5) > If someone would like to run the marketplace client internally he probably does > not want the Eclipse listing. He would then have to "hack" the marketplace > client plugin. I see this use case for some of our clients. > > I think it would be best to separate the marketplace configuration from the > actual functionality. It does not really matter where the configurations are > added, but the packaging project seems like a good fit. If MPC doesn't have a configuration then it won't work or at a minimum very useful. I believe MPC needs to actually work if downloaded independently. I can imagine a use case of someone wanting to remove the Eclipse Marketplace configuration and that should be as easy as adding a new one? I would still suggest to unbundle the configuration from the code. Just create another bundle for the Eclipse marketplace configuration. Then it becomes a bundling decision whether you want to have the Eclipse marketplace in your MPC or not. If you keep the config in the MPC plugin adopters will have to remove it from the plugin.xml file. This would e.g. invalidate the cryptographic signature. Created attachment 168834 [details]
logo for marketplace listing
This is the extension to add the catalog listing. Depending on where the configuration is stored (epp or mpc) we can create a full patch.
<extension
point="org.eclipse.epp.mpc.ui.catalog">
<catalog
description="The fast and reliable source for Eclipse plugins and solutions. Experience the difference."
icon="icons/yoxos32.png"
label="Yoxos Marketplace - by EclipseSource"
url="http://market.eclipsesource.com/yoxos">
</catalog>
</extension>
Markus, I didn't hear back from you regarding why the configurations should all be in one place? We are running out of time for RC1. How about for RC1 we include Yoxos in the RCP package. This will allow us to test out have multiple marketplaces and also decide what is the best way to manage it. First: I agree, most important is that we integrate it into one or all RC1 packages. I am working on it and started an EPP build with the new MPC catalog added to the RCP package. (There was a dependency problem in the Buckminster-based EPP repository build that prevented the addition of the MPC configuration to *any* of the EPP package branding bundles. It took longer than I thought to find the error, but now it seems to be fixed and a new build is running.) Back to the discussion and to the questions: One reason has been given by Jochen: From a consumer's point of view it is not ideal to integrate the standard configuration (Eclipse Marketplace) into one of the main bundles (here: the org.eclipse.epp.mpc.ui bundle). I think this needs to be refactored into an additional plug-in in RC2. The second reason needs a longer explanation: On Monday (see comment #2) I thought that the definition of additional catalogs means maintaining them in *each* package independently. And that would be a nightmare for someone (me?) who tries to keep the packages in sync. Given this and the above reason, I thought that we need to change things anyway and in order to minimize the effort we should try doing this in one single place for *all* catalogs. To summarize what we have learned: * It is advisable to move the Eclipse Marketplace definition into its own bundle even if this Marketplace is the exemplary and default marketplace and even if the MPC without at least one marketplace is useless. * We need a technology in the EPP packages to define configurations, dependencies, etc. that are common to all packages. I did this now and will test it with the RCP package before applying this change to the other packages. (In reply to comment #11) > To summarize what we have learned: > > * It is advisable to move the Eclipse Marketplace definition into its own > bundle even if this Marketplace is the exemplary and default marketplace and > even if the MPC without at least one marketplace is useless. Agreed. Will you open another bug to track? I don't think this is something we will do for Helios but it can be a future release. > > * We need a technology in the EPP packages to define configurations, > dependencies, etc. that are common to all packages. I did this now and will > test it with the RCP package before applying this change to the other packages. Cool, thanks! The additional catalog is listed in the EPP RCP package starting with build 20100519-1205: http://build.eclipse.org/technology/epp/epp_build/36/download/20100519-1205/ The extension is defined in a new plug-in org.eclipse.epp.package.common that is build by the EPP repository build. It can be found in the EPP CVS location in org.eclipse.epp/packages/... The plan is to contribute this plug-in to all remaining packages after Helios RC1 with the org.eclipse.epp.package.common.feature that will act as a central place for configurations that need to go in all packages (see bug 313575). As requested, I covered the split between the configuration and the code in bug 313581. Available in the Helios RC1 RCP/RAP package download. This is the direct link to the package: http://www.eclipse.org/downloads/packages/eclipse-rcp-and-rap-developers/heliosrc1 Jochen and Markus, It seems the Yoxos MP has been integrated. However, when I browse more solutions, the embedded browser says 'Coming Soon'. When is it going to be available? I think this needs to be fixed before we go live? (In reply to comment #15) > It seems the Yoxos MP has been integrated. However, when I browse more > solutions, the embedded browser says 'Coming Soon'. When is it going to be > available? I think this needs to be fixed before we go live? Yes, the link to the Yoxos MP has been integrated in the packages, but the final content will be made available with the launch of our MP together with Helios on June 23. That's why it still shows up with the 'Coming soon' page. If you are interested, I could send you the URL of our development system where you could see the 'final' Yoxos MP in a private mail. The Installed Tab on the Yoxos MP seems to list things that I have already installed, ex it lists Eclipse CVS Client, Eclipse JDT, Eclipse Platform in my installed list. However, it I try to select Install it says there is nothing to install. btw, I am using the updated patch from #316362 and RC4 of the Java IDE package. The behaviour that you describe is a side effect of the patch for #316362. Only solutions that have directly been installed by the marketplace can be updated / uninstalled. It seems that for features that are installed and have been visited on the marketplace the install button is shown. This has nothing to do with the Yoxos marketplace, the behaviour is the same for the Eclipse Marketplace. (In reply to comment #18) > The behaviour that you describe is a side effect of the patch for #316362. Only > solutions that have directly been installed by the marketplace can be updated / > uninstalled. It seems that for features that are installed and have been > visited on the marketplace the install button is shown. > > This has nothing to do with the Yoxos marketplace, the behaviour is the same > for the Eclipse Marketplace. Can you show how I can recreate this in the Eclipse MP? I don't see it there. A bit more details, the Yoxos Installed list shows the FreeMarker IDE. I know I have never vistied this features, since I have never heard of it. It is also not listed on the Eclipse MP. The freemarker ide may have been installed as a dependency of another install. Did you install anything from JBoss? (In reply to comment #20) > The freemarker ide may have been installed as a dependency of another install. > Did you install anything from JBoss? Yes I did install something else from JBoss but Freemarker was not installed. I can figured out how to recreate this in the Eclipse MP, so I will open another bug. FYI, bug 316362 has introduced the problem in comment #17. I've opened bug 316631 to track this problem. Note that these were listed as installed prior to the fix for bug 316362, however before they had an 'Update' button which could lead the user into updating an installed solution from an unknown/untrusted repository. |