On Wed, Apr 17, 2013 at 9:59 AM, 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. >
+1 > - 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. > +1. looks like the issue is assigned to me. > - 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. > I don't think we need a separate element for this. Right now permissions are XML fragments that are added to configuration files and adding/removing works just fine EXCEPT when the XML fragments have variables in them (example PACKAGE_ID, API_KEY etc...). Brett is working on fixing it. > - 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. > As I said on IRC. Header, Source and Resource files are all placed in different sections of the iOS pbxproject so they need to be separated. > > One more question that came up: does a plugman --install call implicitly > call plugman --prepare ? > It looks like it does now but needs to be tested :-) > > 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 > >> > >> > >
