cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gorkem Ercan <>
Subject Re: Consolidating the Distribution of Platforms & Plugins
Date Fri, 14 Mar 2014 02:14:22 GMT
Great idea..  I especially don't like the git archive download. It does not
really allow us to track some sort of statistics reliably. I think its
replacement should allow collection of download statistics. The plugins
stats from plugman seems OK. I am not sure if npm would allow such stats.

Not that important to this discussion but I think plugman has a cache in


On Thu, Mar 13, 2014 at 11:25 AM, Andrew Grieve <>wrote:

> Right now, CLI downloads & caches platforms & plugins using two different
> mechanisms, with totally independent code paths.
> plugman uses the request library, with proxy settings in .plugman/config.
> It downloads the tars directly from It does not cache
> them.
> CLI uses the request library as well, with proxy settings from .npmrc. It
> downloads tars directly from our git server's archive endpoint. It caches
> them in ~/.cordova.
> I'd like to propose that we unify them. Specifically:
> 1. Store platforms on
>   - This would allow CLI to easily see what versions of platforms are
> available, and be able to choose between them.
>   - This (I'm sure), INFRA would be much happier about than our current
> fetch-from-git approach
> 2. Unify CLI & Plugman's downloading logic
>   - Use the same code-path for both.
>   - Have them use the same caching logic.
> 3. Use npm's cache logic instead of our own:
>   - Just type npm help cache to see what it does
>   - Would allow for: "cordova cache clean"
> I would *not* want to lose our support for --searchpath, as I think it's
> really handy. I don't see a problem with this though.
> This would also enable CLI to answer queries like "what platform versions
> are available", and make it trivial to do "install cordova-android@3.0.0"
> This isn't something I have time to work on in the near future, but wanted
> to see if everyone would be onboard with the change. I'll end up just
> filing bugs for the changes if it sounds good... but if anyone else wants
> to work on it... :)

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message