Community
Participate
Working Groups
The mpc currently sends information on operating system, windowing system and java version as url parameters to the marketplace provider. Please add a parameter for the major eclipse version (eclipse platform), e.g. version=3.5 Many solutions have strong dependencies on eclipse versions, so the marketplace provider can do a better job in only providing solutions which can be installed in the eclipse installation calling the service. With Eclipse 4.0 on the horizon this is even more important. The user experience of the MPC client is strongly affected by the ability of the mpc to display solutions that can be installed into the Eclipse installation, so I mark this bug as critical. The Eclipse Marketplace has information about the supported eclipse versions which can be used for the server side of the marketplace.
Moving to MPC
I'm not sure if this will provide any value, given recent capabilities added to p2. For example, I can have 3.5 installed and update most of it to 3.6M7, and the about dialog still lists the major version as 3.5.
You are right with respect to milestone builds. But developers using milestone builds can not really expect that everything works out of the box. For developers sticking with releases the major version of the platform is meaningful. Our experience with this approach is quite positive.
Sounds reasonable to me. What does it mean to provide the major eclipse version? We could provide the symbolic name and version of the org.eclipse.core.runtime.IProduct bundle, as provided by org.eclipse.core.runtime.Platform. Do you have any suggestions?
One possibility is the one you outlined, the other is using the version number of the org.eclipse.core.runtime bundle. The mpc client depends on this bundle anyway, and this bundle is in every Eclipse installation. The IProduct may have a version that has little to do with the Eclipse runtime. Independent of which version number you use I would only send the major version dot minor version, because that matches the data available in the marketplace and is not too fine grained.
Fixed. (In reply to comment #5) > One possibility is the one you outlined, the other is using the version number > of the org.eclipse.core.runtime bundle. The mpc client depends on this bundle > anyway, and this bundle is in every Eclipse installation. The IProduct may have > a version that has little to do with the Eclipse runtime. We're now passing the following metadata: * client=org.eclipse.epp.mpc.core * os=macosx - as provided by Platform.getOS() * ws=cocoa - as provided by Platform.getWS() * java.version=1.6.0_17 - as provided by System.getProperty("java.version") * product=org.eclipse.platform.ide - as provided by Platform.getProduct().getId() * product.version=3.6.0.v201004061034 - as provided by Platform.getProduct().getDefiningBundle().getVersion() * runtime.version=3.6.0.v20091204 - as provided by Platform.getBundle("org.eclipse.core.runtime").getVersion() > Independent of which version number you use I would only send the major version > dot minor version, because that matches the data available in the marketplace > and is not too fine grained. MPC sends the whole version number. That way the server policy can decide what to do with it.
Created attachment 169177 [details] mylyn/context/zip
Changing Target Milestone. I don't believe that there are enough cycles left before Helios to shoehorn this into Marketplace REST calls.
This is fixed: it's already part of Helios RC3 (installation metadata is passed per comment #6) Please track related filtering on bug 313449
