Bad news,
I've been reading a long thread in cross project concerning
download stats...
Quiting David Williams:
"Any 'download.stats'
properties from your artifact repository should be copied over to
the common
one.
"
So, since our milestones builds (RCs) didn't have said
"download.stats" properties, the downloads done from the indigo
repository [1] will never be registered.
Downloads from our Indigo release repository [2] will be registered,
but I'm afraid that most of potential downloads will probably come
from the main Indigo one... Perhaps, the only advantage will be
having some kind of information to know if somebody is using our
releases repository...
On the other hand, I have more interesting comments:
- Quoting Martin Oberhuber:
"1. It
is better to tie stats to a FEATURE rarther than a bundle.
Because bundles come
in 2 variants (.pack.gz / .jar) so with a bundle you have
duplicate work adding the
stats tracker (and, the app from bug 310132 which
auto-generates stats properties
doesn't
support it).
1a)
Note though that a commercial product which uses a different
feature
structure than Eclipse Open Source (and so just gets your
bundle) won't
be counted when you count feature access. That's likely not
relevant."
When automating, 1 should not be relevant. However 1a) comes with an
interesting question. Are we really interested in knowing if other
components downloads an ocl plugin (for instance Acceleo, or whoever
depends on Eclipse OCL) ?:
- Yes: We should probably track download stats from
org.eclipse.ocl plugin (the core plugin, which will always exist if
somebody wants Eclipse OCL).
- No: Just tracking features should suffice.
[1] http://download.eclipse.org/releases/indigo
[2] http://download.eclipse.org/modeling/mdt/ocl/updates/releases/3.1.0
Best Regards,
Adolfo.
El 15/06/2011 11:16, Adolfo Sánchez-Barbudo Herrera escribió:
Hello All,
El 14/06/2011 16:44, Adolfo Sánchez-Barbudo Herrera escribió:
Likewise, there should be some stats recording from our release
repository. I'll need to check some test results, which will be
tracked by the download stats tools tomorrow. The tool to check
the stats may be accessed through the portal (thanks Laurent for
pointing this tool out):
Here we have the results. The test was installing the OCL End User
SDK in a clean Indigo RC4 Eclipse Classic installation:
Query took 0.065 sec (0.007 connect time)
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.
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
|
