I was thinking exactly along the same lines as Braden. Whatever universe the cordova core plugins live in will likely be default, with the wild west following it. SO long as plugman is explicit about where it is fetching from, a dev shouldn't have to find the URL and hope it never changes.
On 13-04-17 2:01 PM, "Braden Shepherdson" <bra...@chromium.org> wrote: >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. >> >> --------------------------------------------------------------------- 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.
