Community
Participate
Working Groups
Hi, we currently use the "Eclipse Download Stats" page [1] to keep track of the number of Code Recommenders installs and it works very well for this: just search for a partial file name of "/stats/recommenders" set as p2.statsURI and you are done. Perfect. :-) Alas, there's one further use case we have for the "Eclipse Download Stats" page: track the number of downloads below "/recommenders/models". Background: Code Recommenders obtains its recommendation models from (one of several) Maven repositories, e.g. [2]. Unfortunately, this downloads (performed by the Code Recommenders plugin through Aether) are not listed on [1]. Apparently, the following applies: "Direct downloads from mirrors and files linked directly to download.eclipse.org are not included here." [1] Is there a way to easily count these downloads as well? (AFAIK, none of the downloads goes through a mirror, unless download.eclipse.org uses something like round-robin DNS.) Would deploying our models to repo.eclipse.org be a workaround? (Possible issue: They have all SNAPSHOT versions but mustn't be garbage collected after one month) Any further suggestions? Best wishes, Andreas [1] <https://dev.eclipse.org/committers/committertools/stats.php> [2] <http://download.eclipse.org/recommenders/models/luna-m3>
I don't know what the solution is for maven artifacts. We can certainly pull logs from repo.eclipse.org but if repo.eclipse.org cannot leverage some form of mirror network for mass downloads, we're doomed bandwidth-wise (this is why we don't include direct downloads from download.eclipse.org -- we want to encourage our projects to use mirrors as much as possible). Perhaps Thanh can chime in with some bandwidth usage and download metrics he's seeing from repo.eclipse.org, and perhaps shed some light on how repo.eclipse.org would scale if every project was to begin using it.
I can totally understand your desire to discourage un-mirrored access to download.eclipse.org. In fact, Aether has mirroring build in, but as far as I can tell there is a mismatch between the way it performs mirror selection and the way download.php works (which picks a mirror anew for each file). Aether typically transforms a bunch of files, some of which are metadata files describing the others. It is thus important that they are consistent, which means that if a mirror has a metadata file it better had also the files it describes and vice versa. In practice, this probably means that it shouldn't switch mirrors between requests and that it should only access fully-synced mirrors (our model repositories don't change very frequently, so they should eventually become fully synced). Thus, if mirroring is desired, relying on download.eclipse.org's mirrors may not work for us. But if anyone were mirroring repo.eclipse.org (Red Hat perhaps?) that would be a point in favor of moving our recommendation models from download to repo.eclipse.org.
Moving to CommitterTools
We won't address this specific case. We do have a need for better download stats, but those are submitted in separate bugs.
