I think there will be a common repo, where the Cordova core plugins and some others live. See the spec for the remotes.js file; I think it should search for plugins with the given name in each of those universes. Specifying a url in the <dependency> would then only be necessary for other universes.
Braden On Wed, Apr 17, 2013 at 1:56 PM, Filip Maj <f...@adobe.com> wrote: > But then we'd need to be able to discover the different universes.. Unless > we all agree on a "default", don't think this is optional.. > > On 4/17/13 10:53 AM, "Jeffrey Heifetz" <jheif...@blackberry.com> wrote: > > >Coming back to Braden's suggestion of specifying a url and id for plugin > >dependency, I think this is the correct route, and would go further to > >suggest the url is optional. I do not believe we should inherently tie > >plugin dependency to the exact source. Thats why we have a discovery > >system and multiple places to get a plugin from. > > > >On 13-04-17 1:37 PM, "Filip Maj" <f...@adobe.com> wrote: > > > >>Braden and I had a little chat on IRC about install/uninstall and calling > >>prepare. We've agreed that having prepare as a separate command is useful > >>(you tweak some plugin JS files, add more JS files, and want that > >>reflected in your app), but also calling prepare automatically after an > >>install and uninstall makes sense too (otherwise people using plugman > >>will > >>have to call prepare manually after calling install or uninstall). > >> > >>FTR, --prepare composes the cordova_plugins.json object that is read by > >>cordova.js and handles injecting plugin JS into the app. It will also be > >>responsible for handling permissions that plugins require and setting up > >>platform manifests appropriately based on all installed plugins. > >> > >>On 4/17/13 10:25 AM, "Brian LeRoux" <b...@brian.io> wrote: > >> > >>>Braden: you thinking that the config is canonical and then prepare > >>>quietly > >>>does the right thing based on that? > >>> > >>>(Agree less steps is exactly what we're going for here.) > >>> > >>> > >>>On Wed, Apr 17, 2013 at 10:16 AM, Braden Shepherdson > >>><bra...@chromium.org>wrote: > >>> > >>>> Re: --install calling --prepare: no. It could, though, I suppose. > >>>> > >>>> Why not have --prepare handle the plugins rather than install/remove. > >>>>We're > >>>> trying to make less, not more, happen at install time. Someday I hope > >>>> --install ceases to exist. > >>>> > >>>> > >>>> On Wed, Apr 17, 2013 at 12:59 PM, Filip Maj <f...@adobe.com> wrote: > >>>> > >>>> > Max, yeah, at the top of the plugman readme (in both future and > >>>>master I > >>>> > believe), the usage docs don't specify --install or --uninstall as > >>>>an > >>>> > available command, but those commands are referenced right after the > >>>> usage > >>>> > section. I'd be in favor of using --fetch for the RETRIEVAL of > >>>>plugins, > >>>> > --remove for the removal of plugins from the local plugins cache, > >>>>and > >>>> > --install and --uninstall for the relevant actions. > >>>> > > >>>> > Max, re (2): correct. > >>>> > > >>>> > To Braden's points: > >>>> > > >>>> > - I'm fine with url + name attributes for <dependency> elements. > >>>>Will > >>>> > update the spec/README shortly. > >>>> > - Re <clobbers> I will add a note about that to the spec as well. > >>>> > - Re parsing package Ids, fair enough. > >>>> > - About "namespacing" iOS source files, this sounds like a good > >>>>idea. > >>>> > This is something that plugman can handle as well, yes? That is, > >>>> > management of the plist and pointing to the right location. > >>>> > - Re config munging and permissions. I vote in favor of removing > >>>>all > >>>> > permissions and re-adding all of them with every change in plugins > >>>>(add > >>>> or > >>>> > remove), with a de-duping pass. Brute force approach but it'll work > >>>>and > >>>> is > >>>> > simple. However spec wise we need a separate element for this ya? > >>>> > <permission> or something? Then based on what <platform> tag houses > >>>>a > >>>> > <permissions> tag we can deduce where and how to set up the > >>>>appropriate > >>>> > native permissions. > >>>> > - Re the different <*-file> elements. I believe behavior in how > >>>>header > >>>> > and source files are handled on iOS are identical, so consolidating > >>>>those > >>>> > is an easy simplification. I will update the spec with that. I'll > >>>>leave > >>>> > resource-file in there for now. > >>>> > > >>>> > One more question that came up: does a plugman --install call > >>>>implicitly > >>>> > call plugman --prepare ? > >>>> > > >>>> > On 4/17/13 9:31 AM, "Max Woghiren" <m...@chromium.org> wrote: > >>>> > > >>>> > >(1) On line 25 of the cordova-plugman readme, is the command > >>>>missing > >>>> (ie. > >>>> > >--add or --install or whatever)? > >>>> > > > >>>> > >(2) Though two versions of a plugin are not allowed, I just want to > >>>>make > >>>> > >sure: there will be some kind of detection that it's okay if the > >>>> > >*same*version of a plugin has already been installed by a previous > >>>> > >dependency, > >>>> > >right? (For example, plugins A and B both depend on C v1.0, so > >>>>plugman > >>>> > >will determine that this is okay, whereas if A depends on C v1.0 > >>>>and > >>>>B > >>>> > >depends on C v1.1, there'll be an error). > >>>> > > > >>>> > > > >>>> > >On Wed, Apr 17, 2013 at 3:08 AM, Filip Maj <f...@adobe.com> wrote: > >>>> > > > >>>> > >> Hey all, > >>>> > >> > >>>> > >> I've done a review of the spec and updated it. Check it out at > >>>>the > >>>> > >>README > >>>> > >> in the plugman repo's future branch [1]. I've added the last bit > >>>>to > >>>> it: > >>>> > >> <dependencies> and <dependency> elements. Here is an example: > >>>> > >> > >>>> > >> <dependencies> > >>>> > >> <dependency > >>>> > >> url="http://plugins.cordova.io/com.facebook.plugin/plugin.xml"; > /> > >>>> > >> <dependency > >>>> > >> url="http://plugins.phonegap.com/com.adobe.omniture/plugin.xml"; > >>>> > >> version="1.0.0" /> > >>>> > >> </dependencies> > >>>> > >> > >>>> > >> > >>>> > >> Dependencies are specified by providing a url and optionally some > >>>>way > >>>> of > >>>> > >> describing what version of the plugin you want. The only > >>>>constraint > >>>> > >> imposed on plugin dependencies right now is only a single version > >>>>of a > >>>> > >> plugin can be installed in an app at the same time. I think this > >>>>is > >>>> good > >>>> > >> enough, but wanted to let everyone know and give people time to > >>>> comment. > >>>> > >> > >>>> > >> Also did a bunch of updates/tweaks to the plugin.xml spec, made > >>>> explicit > >>>> > >> some failures (if there are file conflicts, error noisily, that > >>>>kind > >>>> of > >>>> > >> stuff). I have a PluginTooling [2] wiki article up where I am > >>>>doing my > >>>> > >> best to summarize these various reqs/use cases floating around > >>>>the > >>>> list, > >>>> > >> IRC, hangout discussions regarding plugin tooling development. If > >>>>you > >>>> > >>have > >>>> > >> anything to add there please do so! > >>>> > >> > >>>> > >> Next, I have a few questions came up when I was going through the > >>>> spec: > >>>> > >> > >>>> > >> - does <clobbers> and <merges> (specified in the JS symbol > >>>>mapping > >>>> > >> section of the plugin spec) create the objects on window if they > >>>>do > >>>> not > >>>> > >> exist? I suppose this is more of a cordova.js question than a > >>>>spec > >>>> > >> question, but that behavior should be explicit in the spec. > >>>> > >> - native code <source-file> elements have a `target` attribute > >>>>where > >>>> > >>you > >>>> > >> specify where within the native project the native code should be > >>>> copied > >>>> > >> into. Is this necessary? For Java files, we could look at the > >>>>package > >>>> > >> declaration at the top to determine where to put it. If I'm not > >>>> > >>mistaken, > >>>> > >> on iOS it doesn't matter where within the directory structure of > >>>>a > >>>> > >> cordova-ios project you put native code in. What is the situation > >>>>for > >>>> > >>the > >>>> > >> Windows (Phone) platforms, and for cordova-osx? > >>>> > >> - the spec currently only accounts for appending XML to specific > >>>> parts > >>>> > >>of > >>>> > >> XML-based configuration documents. Does anyone foresee an > >>>>instance > >>>> where > >>>> > >> some manner of native or cordova-specific config munging OTHER > >>>>than > >>>> > >> appending would be necessary? Removal/modification of existing > >>>> elements? > >>>> > >> - iOS specific: Do we need separate elements for <source-file>, > >>>> > >> <resource-file> and <header-file>? Can we consolidate into one? > >>>>The > >>>> > >> current draft of the spec mentions that this may be an > >>>>implementation > >>>> > >> detail. > >>>> > >> > >>>> > >> Finally, I have two questions/concerns about the command line > >>>> interface > >>>> > >> for plugman. > >>>> > >> > >>>> > >> 1. The --fetch operation seems to need a redundant --plugin flag, > >>>>e.g. > >>>> > >> plugman --fetch --plugin <url>. Shouldn't we just axe --plugin in > >>>>this > >>>> > >> case? > >>>> > >> 2. The API readme mentions --install and --uninstall flags but > >>>>the > >>>> docs > >>>> > >> only show --fetch and --remove. Can we clarify this? > >>>> > >> > >>>> > >> Thanks for everyone's input. I feel we're getting closer to > >>>>shipping > >>>> > >>this > >>>> > >> thing! > >>>> > >> > >>>> > >> [1] > >>>> > >> > >>>> > >> > >>>> > >>>> > https://git-wip-us.apache.org/repos/asf?p=cordova-plugman.git;a=shortlo > >>>>g > >>>> > ; > >>>> > >>h= > >>>> > >> refs/heads/future > >>>> > >> [2] http://wiki.apache.org/cordova/PluginTooling > >>>> > >> > >>>> > >> > >>>> > > >>>> > > >>>> > >> > > > > > >--------------------------------------------------------------------- > >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. > >
