cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian LeRoux...@brian.io>
Subject Re: Mapping plugin ID -> URL
Date Tue, 01 Oct 2013 23:45:52 GMT
So wait, the use case is proj level deps not plugin level?
On Oct 1, 2013 10:50 PM, "Andrew Grieve" <agrieve@chromium.org> wrote:

> There is a need to have plugman look in places other than the registry when
> fetching plugins by ID. This is particularly the case because <dependency>
> plugins now have IDs only instead of specifying a URL.
>
> Downstream distributions need this (e.g. IBM packages plugins with their
> distro). But this would be nice for mobile-spec as well (dependency plugin
> could just list IDs instead of plugin paths).
>
> Idea #1:
> Add a map to a project's .cordova/config.json with explicit ID -> URL
> mappings. E.g.:
> "plugin_map": {
>   "org.apache.cordova.file": "file:///some/path",
>   "org.apache.cordova.file-transfer": "http://git.com/url#hash"
> }
>
> Idea #2
> Add the idea of "plugin search path"
> e.g.:
> .cordova/config.json
>    "plugin_search_path": ["file:///my/local/plugins", "
> http://my/custom/couch/db", "<inherits>"]
>
> Entries here can be:
>   1. local directory where each subdirectory contains a plugin
>   2. http:// to a couchdb of a custom registry
>   3. <inherits>, which means prepend this list instead of replacing the
> setting.
>
>
> Idea #3
> Allow the user to copy / symlink the plugin sources into a projects
> plugins/ directory. The directory names in here would need to be the plugin
> IDs. When a request to install a plugin is made, plugman will first check
> if it already exists within plugins/, and if so, uses that source. It would
> also need to know not to delete the directory on plugin rm.
>
>
>
> #1 is nice because it's simple, but may not be super convenient (since you
> need to explicitly add each plugin). It's also the only suggestion that
> allows you to map an ID to a custom git URL
> #2 will work well for plugin collections, but may be annoying if you just
> want to override a single plugin location.
> #3 is arguably the most flexible since it leaves the fetching completely up
> to the user. It may encourage people to muck with their plugins/ to the
> point of breaking their project though. (e.g. they may delete plugins that
> are installed)
>
>
> I think I'd lean towards allowing both #1 and #2.
>

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