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.
