In my mind that is certainly an objective, Brian. 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=shortlog >> > ; >> > >>h= >> > >> refs/heads/future >> > >> [2] http://wiki.apache.org/cordova/PluginTooling >> > >> >> > >> >> > >> > >>
