On Wed, Apr 17, 2013 at 5:44 PM, Michal Mocny <mmo...@chromium.org> wrote:
> Is it possible to re-do the platform modifications on every `cordova > prepare` by running through each plugin.xml? That way, on uninstall you > needn't do anything, just remove the plugin and run prepare again. This > would also make it possible to make changes to a plugin's native code > without reinstalling it. > Stated another way, if we move more of --install into --prepare, we wont need as much in --uninstall, right? Is that possible? > > RE: plugin universe lookup by name: If there were conflicts we could > prompt, or even just error out and have the user file an issue/remove > 3rdparty universe. I don't think this should be common, given that I > really doubt a user would have large N *global* universes to look into.. > for something like phonegap build, each app would be explicit about its > dependancies, likely. > > RE: deps using same relative URL: I was thinking this would be a first > effort with fallback to normal lookup in universes, so we can still handle > the case you mentioned. Either way, we need *some* way to reference plugin > dependancies to local files, otherwise, how do we add them? If plugins > pulled deps from universe exclusively, you'de have to add in > reverse dependency graph order and hope there are no circular references. > > -Michal > > > On Wed, Apr 17, 2013 at 5:31 PM, Filip Maj <f...@adobe.com> wrote: > >> K I will hold off on <permission> until we come to a consensus. You're >> right in that we could put it in as a child to <config-file>.. Duplication >> can be easily prevented (check if permission exists already before adding >> it). >> >> Removing config-file stuff during a plugin uninstall is trickier.. If two >> plugins depend on the same permission (or library, or whatever config-file >> modification), but you only uninstall one of them, we have to make sure >> that it is still there. The naïve first-pass solution to --uninstall >> testPlugin: >> >> 1. Uninstall all the things >> 2. Re-install all the things not named testPlugin >> >> Net result being: testPlugin is uninstalled. >> >> On 4/17/13 2:12 PM, "Anis KADRI" <anis.ka...@gmail.com> wrote: >> >> >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=shortlo >> >>>>g >> >> ; >> >> >>h= >> >> >> refs/heads/future >> >> >> [2] http://wiki.apache.org/cordova/PluginTooling >> >> >> >> >> >> >> >> >> >> >> >> >
