Denis,
I
tried this on BIRT 2.6 repository. I used the URL: http://download.eclipse.org/stats/org.eclipse.birt.bundle
in artifacts.jar
After
installing BIRT from this repository, I checked Download Stats
in committer tool and found there is counts for the bundle?
Does
the download stats updated immediately according the
http request?
Another
question, when Helios is released, most users will
choose Helios repo to install features and can we track that? Will
someone add
the track properties to the metadata of Helios repo?
Thanks,
Xiaoying
You could
actually have it
easy both ways.
http://download.eclipse.org/stats/helios/somejar-versionid
http://download.eclipse.org/stats/webtools/somejar-versionid
When using the Download Stats UI, searching for "somejar-versionid"
will return both URLs, and can be grouped into a single result.
Obviously, searching for /stats/webtools/somejar-versionid will return
only
those results in the webtools directory.
BTW: no need to pollute the URL with "/releases" unless you're keen
on maintaining consistency with the location of the file on
download.eclipse.org. /helios/somejar should work, and will still
allow
you to separate the two service releases, /helios/sr1/somejar and
/helios/sr2/somejar.
Denis
On 05/19/2010 11:12 PM, John Arthorne wrote:
Adding
an
indicator of the repository source should be fine. It means a little
bit of
extra work to collate the statistics to find out the total download
count, but
if you really want to know what repository downloads are coming from, I
don't
see why not.
doh. Of course. Thanks for the clarification on 'feature'.
One more question/recommendation ...
I think we should, by convention, add the "repo uri" to the repo
specific part?
http://download.eclipse.org/stats</repo/uri>
so for example ... we'd have
http://download.eclipse.org/stats/releases/helios
for the common repo ... but could use
http://download.eclipse.org/stats/webtools/repository
for webtools specific artifact repositories.
It would be the same amount of data coming back to eclipse.org, but
would help
tell which
repositories were in use ... in those cases where things are available
in
multiple repos.
Make sense? Any reason not to?
Thanks again.
David Williams wrote on 05/19/2010 03:11:49 PM:
> The more technical question, the directions say, "You can
pick one
> plugin in your feature for example "
> Does it have to be a plugin? Could it not be the
"...feature.group"?
> Was there a reason the instructions say "plugin"? For
example, is
> there a trick to include a "tracking plugin" in a feature?
The "..feature.group" is in the metadata but is not an artifact
(something that is downloaded during install). There is an artifact
containing
the feature.xml file that could be used though. Feature artifacts
something like this:
<artifact classifier='org.eclipse.update.feature'
id='org.eclipse.sdk' version='...'
The stats mechanism works the same on any artifact. So, you could
use the
artifact for either a feature or plugin with the same effect.