| [mdt-ocl.dev] Download stats was: Building from git? |
|
Hello All, El 14/06/2011 16:44, Adolfo Sánchez-Barbudo Herrera escribió: Here we have the results. The test was installing the OCL End User SDK in a clean Indigo RC4 Eclipse Classic installation:
The features which are currently tracked are the following: - org.eclipse.ocl - org.eclipse.ocl.all.sdk - org.eclipse.oxl.examples The conclusion is: Installing the OCL End User SDK (org.eclipse.ocl.all.sdk feature) also make the included features be registered (in this case, the org.eclipse.ocl one). So I think that it could be interesting making all the features be tracked instead of simply using the ocl.all.sdk.feature one. The reasons are: - We could track if any other thirdparty P2 repository tried to download a narrow feature from our release repository (i.e OCL Core SDK, OCL Runtime, etc.. ) - We could have an idea if the feature organization is being useful. If OCL End User SDK has the same hints as OCL Core SDK, means that the latter is not being used/useful for our clients). Apart from making all our features be registered I want to do a couple of things more: 1. Now I want to install the OCL Examples in a clean installation. Examples doesn't include other features, but depend on/requires some plugins (also ocl plugins). I would like to know what happens in this case. I suppose that the depending plugins will be simply downloaded from the repository, and no hints for the other features will be registered (I think that this is the same situation for downstream projects such as Acceleo). We could also register hints for plugins (perhaps the narrower one: org.eclipse.ocl), although I read somewhere that it's better to register hints from our features (I'll try to look for more information about this). 2. Add some version information of the feature so that different repositories (even nightly/milestones) have different stats for the same feature. I was thinking about trailing the feature version behind the feature name. However, this would make harder to track the content registered for the repository in the portal web UI. So instead of having: /stats/org.eclipse.ocl.feature-3.1.0.vAAAABBCC-ddee /stats/org.eclipse.ocl.feature-3.1.0.vFFFFFGGHH-iijj ... /stats/org.eclipse.ocl.all.sdk.feature-3.1.0.vAAAABBCC-ddee /stats/org.eclipse.ocl.all.sdk.feature-3.1.0.vFFFFFGGHH-iijj I was think about trailing the version in the beginning: /stats/3.1.0.vAAAABBCC-ddee-org.eclipse.ocl.feature. /stats/3.1.0vAAAABBCC-ddeej-org.eclipse.ocl.all.sdk.feature. ... /stats/3.1.0.vFFFFFGGHH-iijj-org.eclipse.ocl.feature. /stats/3.1.0.vFFFFFGGHH-iijj-org.eclipse.ocl.all.sdk.feature. Another interesting alternative: Including our project name and build information: /stats/mdt-ocl-3.1.0.RAAAABBCCDDEE-org.eclipse.ocl.feature. /stats/mdt-ocl-3.1.0.RAAAABBCCDDEE-org.eclipse.ocl.all.sdk.feature. ... /stats/mdt-ocl-3.1.0.NFFFFFGGHHIIJJ-org.eclipse.ocl.feature. /stats/mdt-ocl-3.1.0.NFFFFFGGHHIIJJ-org.eclipse.ocl.all.sdk.feature. Thoughts ? Best Regards, Adolfo. --
| |||||||||||||||
