Agree the use-case is valid. Here's a variation on (1) that I think is marginally nicer:
url="." to be made optional, but default value is "." subdir="" works only with git repos and is always relative to the root of the repo. path="" works with git repos or local paths and is relative to the plugin.xml of the current plugin. You can't have "url" or "subdir" if you have "path". Support was just added for specifying commit and path within url. So, we could actually just deprecate "subdir". and have "url" or "path" E.g.: url="some/path.git" would specify a git URL relative to the current plugin's git url. E.g.: url="#branch2" would specify a branch on the current URL (cordova-labs style) E.g.: url="#branch2:plugins/A" would specify a branch on the current URL plus a subdir within it. E.g.: url="#:plugins/A" would be invalid. (Use path if you just want to set the path) E.g.: path="../B" is always a relative fs path. If the current plugin is from git, then be careful not to go above the git root. On Tue, Sep 3, 2013 at 10:27 PM, Michal Mocny <mmo...@chromium.org> wrote: > Mulling this over a bit, I think I would like a solution for specifying > dependancies that would work regardless of where/how the plugins are > hosted, git or local. If you had: > > BB_PLUGINS/ > - plug1/ > - plug2/ > ... > > (and plug1 depends on plug2), then: > > cordova plugin add LOCAL/PATH/TO/BB_PLUGINS/plug1 ..and.. cordova > plugin add GIT_REPO:BB_PLUGINS/plug1 > > ..should both work without changing all of the dependency tags in plug1. > Actually, the plugin author should not have an explicit say in how a user > manages these directories (except in the directory structure). Note that > this situation applies whenever a user clones your plugin repo to locally, > or for the reverse direction, when ever they add your plugins into their > teams' git repo. > > > Right now, thats not possible, because when installing from local path with > url="." there is no way to know which of the plugins parent directories to > consider as the "root". We could resolve this using several ways, among > them: > > (1) Jeffreys proposal: dropping the url="." means "path relative to this > plugin" (note however, that I propose it also works when installing from a > git repo). Deprecate/warn against using url=".". > > (2) Support a new special file to "mark" the plugin root dir so we can walk > the directory tree to find the valid target for url="." (ie, replace the > requirement for a .git with a requirement for a .cordova_repo, which BB and > others could place within their plugin bundle). > > > I like (1). > > -Michal > > > On Tue, Sep 3, 2013 at 9:54 PM, Michal Mocny <mmo...@chromium.org> wrote: > > > Sounds reasonable to me. > > > > Conceptually, I'm not sure why the syntax for (2) shouldn't do what you > > request when the url for the original plugin was a local path? Maybe > just > > a bug? > > > > -Michal > > > > > > On Tue, Sep 3, 2013 at 9:38 PM, Jeffrey Heifetz <jheif...@blackberry.com > >wrote: > > > >> We were working on a redistribution of Cordova that included some > plugins > >> and ran into a use-case not covered by the current plugin spec.[1] > >> > >> Currently there are two ways to specify a dependency > >> 1. Using a combination of url, commit and subdir which plugman will use > >> to clone down a repo and install > >> 2. Set the url to ".", skip the commit and specify a subdir relative to > >> the root of the repo. Plugman then runs git-rev parse to find the root > and > >> install from there. > >> > >> I would like to propose a third way which would be relative to the > >> current install and not use git at all > >> 3. Skip the url, skip the commit and specify a subdir relative to the > >> current plugin.xml. > >> > >> This would allow us to distribute a version of cordova with plugins to > >> anyone without an unnecessary requirement on git (considering the > plugins > >> are fully installed) > >> > >> > >> > >> 1. http://cordova.apache.org/docs/en/3.0.0/plugin_ref_spec.md.html > >> > >> --------------------------------------------------------------------- > >> This transmission (including any attachments) may contain confidential > >> information, privileged material (including material protected by the > >> solicitor-client or other applicable privileges), or constitute > non-public > >> information. Any use of this information by anyone other than the > intended > >> recipient is prohibited. If you have received this transmission in > error, > >> please immediately reply to the sender and delete this information from > >> your system. Use, dissemination, distribution, or reproduction of this > >> transmission by unintended recipients is not authorized and may be > unlawful. > >> > > > > >
