On Wed, Feb 25, 2015 at 3:08 PM, Steven Gill <stevengil...@gmail.com> wrote:
> All versions of released core plugins have been published to npm. > https://issues.apache.org/jira/browse/CB-8529 > All our core plugins now have a package.json file. > https://issues.apache.org/jira/browse/CB-8538 > > A few of us from Adobe met with NPM yesterday. Summary: > > - Migration > - Use 'ecosystem:cordova' as a keyword in plugins for discoverability > (instead of 'cordovaplugin'). I updated createpackagejson already with this. > - npm has final say on naming disputes. We can go to them with issues. > > - Discoverability > - npm Ecosystems will be up sometime this year > - stopgap: they can give us list of plugins based on ecosystem:cordova > keyword that we could use as data in our existing plugins site > - you can already find all of our plugins on npm via searching > ecosystem:cordova (https://www.npmjs.com/search?q=ecosystem%3Acordova) > > - Documentation > - They don't have a way to handle uploading anything other than readme > to npm > - we could build our own packager that could publish doc/en/index.md, > but not worth it > - Potential Solution: Copy doc/en/index.md into readme, also add > links to other language documentation in readme that points to github > markdown files > - Internationalization is something they want to solve, just no cycles > for it in the immediate future > > - Dependency, Multiple versions of same plugin issue > - This one was tricky. They don't have a good solution really > - Seems like best case is to use peer dependencies in package.json > files of plugins. Users will get a warning about missing dependency and > will have to explicitly install the missing dependency. Make it a userland > problem. > - Ex: user installs cordova-plugin-file-transfer, they will see a > warning about having to install cordova-plugin-file (maybe a specific > version) > - This would insure plugins are flat and should prevent multiple > versions of the same plugin to be installed. > > - Plugin Post Install Hooks > - It was brought up that having a generic post install hook that could > move native files into cordova projects might be a good solution. I know we > discussed it briefly and decided it would be to hard to get right. After > more thought and discussion, I think we should revisit this as a potential > solution. We wouldn't be dependent on cordova-lib/plugman to install > plugins anymore. As long as plugins still have plugin.xml (which they will > for a little while), we could still support the cordova-lib/plugman > workflow too. Lets discuss this more in its own thread. > Yes, lets start a new thread. Have many questions ;) > > Plugin TODO: > - Rename id to package-name in package.json files and plugin.xml > +1 > - move english documentation into readme, add links for other languages > into readme pointing to github markdown files > +1 > - Add peer dependencies to package.json > +1, especially for as long as we are still fetching via plugman/cordova-cli. Though for the record, the plan for npm 3.0 seems to be to have a flat hierarchy even for dependencies. Was this discussed? > - Major bump plugin versions > +1 > > Tools TODO: > - NPM fetch as fallback > Do we agree to go directly to NPM if we know for sure the plugin name fails the CPR publishing requirements (aka, is not in reverse domain format)? > - Mapper module will only warn to use the new name, won't actually > redirect. We can turn on redirecting when we default to npm or shutdown > cpr. > Fair enough for step 1! > > Today I am working on the tools todos. > > On Mon, Feb 23, 2015 at 7:55 PM, Michal Mocny <mmo...@chromium.org> wrote: > >> Summarizing conclusions so far (not 100% we all agree on this, please do >> speak up): >> >> - PluginId and Npm Package Name should be the same. We cannot force this >> for all plugins, but we can set the tone with core plugins. >> - We will change all plugins to use the cordova-plugin-* name/id. >> - We will bump MAJOR version to signal this change, and so plugins that >> depend on core plugins know to update to reflect the id change. >> - Publish old versions of plugins with the new package name but old plugin >> ids to npm. >> - CPR will be hit first, then fallback to npm, for the first N months. >> - We could go directly to npm first if the name is known to not match >> CPR >> requirements (i.e. cordova-plugin-* is known to not be in CPR by existing >> plugin id requirements) >> - Mapper module can help transition users of old ids to new package names, >> by warning that plugins have moved, and (perhaps?) automatically >> redirecting. >> - If we drop the automatic redirection requirement, we could just update >> CPR plugins with <info> inform users of the change. >> >> I think thats it.. >> >> Steve, mind updating us on how far along you are, and with what you would >> like help? >> >> -Michal >> >> On Mon, Feb 23, 2015 at 10:44 PM, Michal Mocny <mmo...@chromium.org> >> wrote: >> >> > Just thinking out loud.. >> > >> > I guess it wouldn't actually do that unless you are using actual npm cli >> > to install plugins. With the current plan we are still just using >> > cordova/plugman to fetch using the npm lib, and so can probably resolve >> > peerDependencies whenever/however we want (like auto-fetching only once >> the >> > platform is added). >> > >> > If we did move to top-level package.json and installing dependencies via >> > npm, it may be a little annoying to have that message. >> > >> > I guess the reason we are discussing dropping <dependency> anyway was >> for >> > the move to using npm cli directly, and since we are still a ways away >> from >> > that, I guess we can punt this change for now and keep using a tag? >> > >> > -Michal >> > >> > On Mon, Feb 23, 2015 at 9:52 PM, Andrew Grieve <agri...@chromium.org> >> > wrote: >> > >> >> I suppose it's workable, but it seems worse than what we currently >> have. >> >> E.g. I don't care about Android, but npm peerDependencies will complain >> >> until I've installed the android.support.v4 plugin into my >> node_modules. >> >> >> >> On Mon, Feb 23, 2015 at 4:26 PM, Michal Mocny <mmo...@chromium.org> >> >> wrote: >> >> >> >>> I scanned the core plugins, and only contacts uses platform specific >> >>> deps, >> >>> and only for 2 BB plugins. >> >>> >> >>> Also scanned the top 20 non-core plugins from CPR, and: >> >>> >> >>> - com.cranberrygame.phonegap.plugin.ad.admob >> >>> - depends on google-play-services only on android, but that plugin >> only >> >>> supports android. >> >>> - com.google.cordova.admob (Note: not published by com.google..) >> >>> - Same as above >> >>> - plugin.google.maps >> >>> - Same as above >> >>> - also depends on android.support.v4 for android only (but its also >> an >> >>> android only plugin) >> >>> - also depends on com.googlemaps.ios for ios only (but its an ios >> only >> >>> plugin) >> >>> - net.yoik.cordova.plugins.screenorientation >> >>> - Depends on com.blackberry.app only for BB (but its BB only plugin) >> >>> >> >>> >> >>> So.. this is not an uncommon use, but it seems unnecessary in all >> cases >> >>> I've found so far. >> >>> >> >>> -Michal >> >>> >> >>> On Mon, Feb 23, 2015 at 4:10 PM, Michal Mocny <mmo...@chromium.org> >> >>> wrote: >> >>> >> >>> > >> >>> > >> >>> > On Mon, Feb 23, 2015 at 3:36 PM, Andrew Grieve < >> agri...@chromium.org> >> >>> > wrote: >> >>> > >> >>> >> You can use plugin.xml <info> to print a message upon installation. >> >>> >> >> >>> >> Plugins can specify dependencies on a per-platform basis. Don't >> think >> >>> we >> >>> >> can capture this with package.json without using custom keys. >> >>> >> >> >>> > >> >>> > Do we need to? I mean, this is a breaking change, but perhaps once >> >>> that >> >>> > is acceptable in practice. I.e. Contacts depends on >> >>> com.blackberry.utils, >> >>> > but that plugin only supports the BB <platform> and so shouldn't be >> >>> > installed on others. >> >>> > >> >>> > In theory there exists a plugin which supports all platforms but is >> >>> only >> >>> > explicitly needed for one platform as a dependency.. But I don't >> know. >> >>> > Does the issue come up in practice? >> >>> > >> >>> > >> >>> >> >> >>> >> >> >>> >> >> >>> >> On Mon, Feb 23, 2015 at 2:42 PM, Michal Mocny <mmo...@chromium.org >> > >> >>> >> wrote: >> >>> >> >> >>> >> > On Mon, Feb 23, 2015 at 2:22 PM, Steven Gill < >> >>> stevengil...@gmail.com> >> >>> >> > wrote: >> >>> >> > >> >>> >> > > +1 to giving plugins major version bump >> >>> >> > > +1 to publishing old versions to npm >> >>> >> > > >> >>> >> > > Short term we can keep dependency tag using plugin ids. >> Wouldn't >> >>> it >> >>> >> make >> >>> >> > > more sense long term to move those dependencies into >> package.json >> >>> >> file of >> >>> >> > > each plugin? >> >>> >> > > >> >>> >> > >> >>> >> > Probably peerDependencies not dependencies. I forgot about >> that.. >> >>> >> Indeed >> >>> >> > that was the plan. >> >>> >> > >> >>> >> > I think one current benefit of <dependency> tag over >> package.json is >> >>> >> that >> >>> >> > the latter only guarantees that the plugins are downloaded, while >> >>> the >> >>> >> > former guarantees that they are installed. We could update our >> >>> tools >> >>> >> to do >> >>> >> > an install time check for a package.json and then scan the >> locally >> >>> >> > installed packages which are listed in its peerDependencies to >> see >> >>> if >> >>> >> any >> >>> >> > are cordova plugins and install those automatically, but I'm not >> >>> quite >> >>> >> sure >> >>> >> > thats the right voodoo.. >> >>> >> > >> >>> >> > Anyway, assuming we can come up with a sensible plan, I would >> >>> rather do >> >>> >> it >> >>> >> > all at once with the upcoming Major version bump. >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > > >> >>> >> > > I am going to begin the process of adding package.json to all >> of >> >>> our >> >>> >> > > plugins today and will look into publishing older versions to >> npm. >> >>> >> > >> >>> >> > >> >>> >> > > Third-party plugins can either keep their package-id as >> >>> package-name >> >>> >> or >> >>> >> > > rename. It will be up to them. If they keep it, no need to >> send a >> >>> PR >> >>> >> to >> >>> >> > > mapper module. If they decide on a new package-name, it is >> >>> probably in >> >>> >> > > their best interest to send a PR. >> >>> >> > >> >>> >> > >> >>> >> > Sounds good, though I'm hoping to provide guidance that renames >> are >> >>> >> better >> >>> >> > by doing it for core plugins. The need for the mapper is >> probably a >> >>> >> bit of >> >>> >> > an exaggeration anyway. Once CPR goes deprecated, we should >> start >> >>> >> warning >> >>> >> > that plugins should be fetched from npm. Users will then search >> >>> for the >> >>> >> > name of the npm package and the plugin author can rename freely >> by >> >>> just >> >>> >> > documenting accordingly. Once the CPR goes down, this will be >> even >> >>> more >> >>> >> > true. >> >>> >> > >> >>> >> > (Additionally, authors can publish a CPR plugin before CPR goes >> down >> >>> >> that >> >>> >> > has an install hook which says "This plugin has moved to npm >> under >> >>> the >> >>> >> > name..". I'm less and less convinced the mapper is needed at >> all..) >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > > >> >>> >> > > >> >>> >> > > >> >>> >> > > >> >>> >> > > On Thu, Feb 19, 2015 at 6:50 AM, Carlos Santana < >> >>> csantan...@gmail.com >> >>> >> > >> >>> >> > > wrote: >> >>> >> > > >> >>> >> > > > Lets consider to take this time and make our plugins 1.0.0 >> and >> >>> start >> >>> >> > > > following semver 2.0 more strict. The community is starting >> to >> >>> >> accept >> >>> >> > > that >> >>> >> > > > is ok if the major number is not zero, and a number means >> >>> something >> >>> >> > that >> >>> >> > > > can be use in production. >> >>> >> > > > I understand that people might have their own opinion on what >> >>> is a >> >>> >> > MAJOR, >> >>> >> > > > meaning an API brake when the plugin is running on the device >> >>> and >> >>> >> the >> >>> >> > API >> >>> >> > > > of the javascript API to the plugin. >> >>> >> > > > But I want to consider how a plugin is manage in terms of >> >>> tooling, >> >>> >> > > > declaring and resolving dependencies, plugin.xml schema, >> >>> >> > > > browersify/bootstrapjs, we could say that this consider an >> API >> >>> for >> >>> >> the >> >>> >> > > > plugin. >> >>> >> > > > Another point is if the plugin are going to change in terms >> how >> >>> they >> >>> >> > are >> >>> >> > > > manage, we can take an opportunity to take the developers >> >>> attention >> >>> >> > with >> >>> >> > > > the major version number change to easy distinguish that >> there >> >>> >> > something >> >>> >> > > > new going with plugins since 1.0.0 and up. >> >>> >> > > > >> >>> >> > > > On Tue, Feb 17, 2015 at 4:02 PM, Chuck Lantz < >> >>> cla...@microsoft.com> >> >>> >> > > wrote: >> >>> >> > > > >> >>> >> > > > > I think the incident over the weekend pointed out that >> people >> >>> are >> >>> >> in >> >>> >> > > fact >> >>> >> > > > > pinning versions in plugin dependencies to avoid unexpected >> >>> >> > regressions >> >>> >> > > > or >> >>> >> > > > > in apps due to things like security reviews. (Ex: Each >> >>> version >> >>> >> of a >> >>> >> > > > piece >> >>> >> > > > > of software that is published inside an app needs to go >> >>> through a >> >>> >> > legal >> >>> >> > > > > review at some companies.) So, I think it will be critical >> >>> that >> >>> >> > people >> >>> >> > > > can >> >>> >> > > > > get back to older versions of plugins beyond the 3 + 6 = 9 >> >>> month >> >>> >> CPR >> >>> >> > > > > window. Big time +1 to back publishing versions npm for >> that >> >>> >> reason >> >>> >> > > > unless >> >>> >> > > > > we intend to keep the CPR around for a long time. We also >> >>> will >> >>> >> want >> >>> >> > to >> >>> >> > > > > tell plugin authors that they will want to do the same. >> (Note >> >>> >> that >> >>> >> > I'm >> >>> >> > > > > less worried about IDEs than I am app and plugin authors >> >>> here.) >> >>> >> > > > > >> >>> >> > > > > >> >>> >> > > > > >> >>> >> > > > > What we're talking about so far has been around changing >> the >> >>> >> behavior >> >>> >> > > of >> >>> >> > > > > cordova-lib over this period. A few questions assuming we >> go >> >>> with >> >>> >> > > > having a >> >>> >> > > > > mapper module: >> >>> >> > > > > >> >>> >> > > > > >> >>> >> > > > > >> >>> >> > > > > 1. During and after the transition period, should we >> >>> >> recommend >> >>> >> > > that >> >>> >> > > > > 3rd party plugin authors contribute their IDs to the mapper >> >>> >> module to >> >>> >> > > > > maintain compat as the CPR shuts down if they want/need to >> >>> >> publish to >> >>> >> > > npm >> >>> >> > > > > with a different name? Is there a process we want to setup >> to >> >>> make >> >>> >> > this >> >>> >> > > > > easy? >> >>> >> > > > > >> >>> >> > > > > 2. What about apps using old versions of Cordova that >> >>> >> pre-date >> >>> >> > npm >> >>> >> > > > > support being present? Given it sounds like Nodejitsu will >> >>> help >> >>> >> with >> >>> >> > > any >> >>> >> > > > > migration needed, is there an urgency to shut down the CPR >> >>> itself >> >>> >> > > > > (regardless of what cordova-lib itself does) in this time >> >>> window? >> >>> >> Or >> >>> >> > > are >> >>> >> > > > we >> >>> >> > > > > simply telling people they have to upgrade to install any >> new >> >>> >> > plugins? >> >>> >> > > > > >> >>> >> > > > > >> >>> >> > > > > >> >>> >> > > > > -Chuck >> >>> >> > > > > >> >>> >> > > > > >> >>> >> > > > > >> >>> >> > > > > -----Original Message----- >> >>> >> > > > > From: mmo...@google.com [mailto:mmo...@google.com] On >> Behalf >> >>> Of >> >>> >> > Michal >> >>> >> > > > > Mocny >> >>> >> > > > > Sent: Tuesday, February 17, 2015 9:32 AM >> >>> >> > > > > To: dev >> >>> >> > > > > Subject: Re: Schedule for npm transition >> >>> >> > > > > >> >>> >> > > > > >> >>> >> > > > > >> >>> >> > > > > FYI since its perhaps relevant to npm transition (from npm >> >>> weekly >> >>> >> > > notes): >> >>> >> > > > > >> >>> >> > > > > >> >>> >> > > > > >> >>> >> > > > > "We will also be changing the behavior of peerDependencies >> in >> >>> >> npm@3. >> >>> >> > > We >> >>> >> > > > > won't be automatically downloading the peer dependency >> >>> anymore. >> >>> >> > > Instead, >> >>> >> > > > > we'll warn you if the peer dependency isn't already >> installed. >> >>> >> This >> >>> >> > > > > requires you to resolve peerDependency conflicts yourself, >> >>> >> manually, >> >>> >> > > but >> >>> >> > > > in >> >>> >> > > > > the long run this should make it less likely that you'll >> end >> >>> up >> >>> >> in a >> >>> >> > > > tricky >> >>> >> > > > > spot with your packages' dependencies." >> >>> >> > > > > >> >>> >> > > > > >> >>> >> > > > > >> >>> >> > > > > -Michal >> >>> >> > > > > >> >>> >> > > > > >> >>> >> > > > > >> >>> >> > > > > On Tue, Feb 17, 2015 at 12:13 PM, Andrew Grieve < >> >>> >> > agri...@chromium.org >> >>> >> > > > > <mailto:agri...@chromium.org>> >> >>> >> > > > > >> >>> >> > > > > wrote: >> >>> >> > > > > >> >>> >> > > > > >> >>> >> > > > > >> >>> >> > > > > > On Tue, Feb 17, 2015 at 11:28 AM, Michal Mocny < >> >>> >> > mmo...@chromium.org >> >>> >> > > > > <mailto:mmo...@chromium.org>> >> >>> >> > > > > >> >>> >> > > > > > wrote: >> >>> >> > > > > >> >>> >> > > > > > >> >>> >> > > > > >> >>> >> > > > > > > On Tue, Feb 17, 2015 at 10:09 AM, Andrew Grieve >> >>> >> > > > > >> >>> >> > > > > > > <agri...@chromium.org<mailto:agri...@chromium.org>> >> >>> >> > > > > >> >>> >> > > > > > > wrote: >> >>> >> > > > > >> >>> >> > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > > Sorry to be dragging this out, but I think it's >> >>> important >> >>> >> that >> >>> >> > > the >> >>> >> > > > > >> >>> >> > > > > > > > plan here is crystal clear. >> >>> >> > > > > >> >>> >> > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > > On Wed, Feb 11, 2015 at 4:56 PM, Michal Mocny >> >>> >> > > > > >> >>> >> > > > > > > > <mmo...@chromium.org<mailto:mmo...@chromium.org>> >> >>> >> > > > > >> >>> >> > > > > > > wrote: >> >>> >> > > > > >> >>> >> > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > > > I would agree that we should change plugin ID as >> well >> >>> as >> >>> >> > > package >> >>> >> > > > > >> >>> >> > > > > > name, >> >>> >> > > > > >> >>> >> > > > > > > > but >> >>> >> > > > > >> >>> >> > > > > > > > > I don't think that affects the results. >> >>> >> > > > > >> >>> >> > > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > > > All 3 of those use cases you mentioned I think are >> >>> >> addressed >> >>> >> > > > > >> >>> >> > > > > > > > equivalently. >> >>> >> > > > > >> >>> >> > > > > > > > > Whether the plugin is added as a dependency, with >> >>> >> > save/restore, >> >>> >> > > > > >> >>> >> > > > > > > > > or explicitly from the command line, cordova-lib >> would >> >>> >> first >> >>> >> > > > > >> >>> >> > > > > > > > > check if >> >>> >> > > > > >> >>> >> > > > > > > there >> >>> >> > > > > >> >>> >> > > > > > > > is >> >>> >> > > > > >> >>> >> > > > > > > > > a mapping from old ID -> new package name, or use >> >>> what's >> >>> >> > given >> >>> >> > > > > >> >>> >> > > > > > > verbatim. >> >>> >> > > > > >> >>> >> > > > > > > > > So the only concern is with third party plugin >> >>> authors who >> >>> >> > > chose >> >>> >> > > > > >> >>> >> > > > > > > > > to >> >>> >> > > > > >> >>> >> > > > > > > > rename >> >>> >> > > > > >> >>> >> > > > > > > > > plugins, and already have dependants, and don't >> >>> register a >> >>> >> > > > > >> >>> >> > > > > > > > > mapping >> >>> >> > > > > >> >>> >> > > > > > with >> >>> >> > > > > >> >>> >> > > > > > > > us. >> >>> >> > > > > >> >>> >> > > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > > There is a runtime dependency on plugin ID. It's used >> >>> when >> >>> >> > > > > >> >>> >> > > > > > > > require()ing other JS modules, and on Android it's >> used >> >>> to >> >>> >> > access >> >>> >> > > > > >> >>> >> > > > > > > > the plugin's >> >>> >> > > > > >> >>> >> > > > > > native >> >>> >> > > > > >> >>> >> > > > > > > > side (pluginManager.getPlugin("ID")). >> >>> >> > > > > >> >>> >> > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > > We could have a mapper that knows that I type "plugin >> >>> add >> >>> >> "", >> >>> >> > to >> >>> >> > > > > >> >>> >> > > > > > > > fetch "cordova-plugin-file", but if we also change >> the >> >>> >> plugin >> >>> >> > ID, >> >>> >> > > > > >> >>> >> > > > > > > > then we'll >> >>> >> > > > > >> >>> >> > > > > > > get >> >>> >> > > > > >> >>> >> > > > > > > > runtime problems. So... if we have a mapper, then no >> >>> >> changing >> >>> >> > > > > >> >>> >> > > > > > > > plugin >> >>> >> > > > > >> >>> >> > > > > > IDs. >> >>> >> > > > > >> >>> >> > > > > > > > Correct? >> >>> >> > > > > >> >>> >> > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > I agree at first, but after sleeping on it, perhaps >> this >> >>> is >> >>> >> not >> >>> >> > > > > >> >>> >> > > > > > necessarily >> >>> >> > > > > >> >>> >> > > > > > > true. Perhaps changing plugin ID could just be a >> semver >> >>> >> breaking >> >>> >> > > > > change? >> >>> >> > > > > >> >>> >> > > > > > > Then, even if it was installed using old plugin-id and >> the >> >>> >> mapper >> >>> >> > > > > >> >>> >> > > > > > > mapped >> >>> >> > > > > >> >>> >> > > > > > to >> >>> >> > > > > >> >>> >> > > > > > > the npm package-name, any plugin compatible with this >> >>> MAJOR >> >>> >> > version >> >>> >> > > > > >> >>> >> > > > > > > of >> >>> >> > > > > >> >>> >> > > > > > the >> >>> >> > > > > >> >>> >> > > > > > > plugin would know to use the new plugin id. >> >>> >> > > > > >> >>> >> > > > > > > >> >>> >> > > > > >> >>> >> > > > > > That'd probably work. In practice I haven't seen plugins >> pin >> >>> >> > versions >> >>> >> > > > > >> >>> >> > > > > > within <dependency>, but they probably should. >> >>> >> > > > > >> >>> >> > > > > > >> >>> >> > > > > >> >>> >> > > > > > >> >>> >> > > > > >> >>> >> > > > > > >> >>> >> > > > > >> >>> >> > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > For old versions of the plugin published to npm, we do >> >>> have to >> >>> >> > > leave >> >>> >> > > > > >> >>> >> > > > > > > the plugin id as-is. >> >>> >> > > > > >> >>> >> > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > > Okay, so we don't change the plugin ID, just the >> package >> >>> >> name. >> >>> >> > > > > >> >>> >> > > > > > > > - When people use <dependency>, they should still use >> >>> >> plugin ID >> >>> >> > > > > >> >>> >> > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > Nit: why? <dependency> (and config.xml <plugin>) >> should >> >>> use >> >>> >> the >> >>> >> > > > > >> >>> >> > > > > > > same target as "cordova plugin add", which at this >> point >> >>> >> should >> >>> >> > > > > >> >>> >> > > > > > > change to package-name. If we do leave plugin-id >> >>> different >> >>> >> from >> >>> >> > > > > >> >>> >> > > > > > > package-name, it should only be used internally by >> plugin >> >>> >> authors >> >>> >> > > > > >> >>> >> > > > > > > who depend on other plugins. >> >>> >> > > > > >> >>> >> > > > > > > >> >>> >> > > > > >> >>> >> > > > > > >> >>> >> > > > > >> >>> >> > > > > > "plugin add" can take git URLs, local directory paths. >> >>> >> <dependency >> >>> >> > > > > >> >>> >> > > > > > id="" /> is pretty clear that it's an ID, and in this >> form >> >>> it >> >>> >> > doesn't >> >>> >> > > > > >> >>> >> > > > > > specify where to get the plugin from >> >>> >> > > > > >> >>> >> > > > > > >> >>> >> > > > > >> >>> >> > > > > > The logic for dependency in plugman is to: >> >>> >> > > > > >> >>> >> > > > > > 1. Fetch it (e.g. use search paths, or find-by-id from >> the >> >>> >> > > registry). >> >>> >> > > > > >> >>> >> > > > > > 2. Validate that the plugin.xml we fetched matches the ID >> >>> from >> >>> >> > > > > >> >>> >> > > > > > <dependency> 3. Install it >> >>> >> > > > > >> >>> >> > > > > > >> >>> >> > > > > >> >>> >> > > > > > I don't think we can do the validation step if we allow >> >>> >> > package-name >> >>> >> > > > > >> >>> >> > > > > > within <dependency>. Plus, except for core plugins that >> >>> have a >> >>> >> > > mapper, >> >>> >> > > > > >> >>> >> > > > > > you couldn't do the search-path logic correctly without >> the >> >>> >> plugin >> >>> >> > > ID. >> >>> >> > > > > >> >>> >> > > > > > >> >>> >> > > > > >> >>> >> > > > > > >> >>> >> > > > > >> >>> >> > > > > > >> >>> >> > > > > >> >>> >> > > > > > >> >>> >> > > > > >> >>> >> > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > > - If they "cordova plugin add", we'll allow them to >> >>> specify >> >>> >> NPM >> >>> >> > > > > >> >>> >> > > > > > > > package name *or* plugin ID. >> >>> >> > > > > >> >>> >> > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > Possibly only support plugin-id for some deprecation >> time? >> >>> >> > (Though >> >>> >> > > > > >> >>> >> > > > > > > if we publish old versions to npm, maybe we just leave >> it >> >>> >> > supported >> >>> >> > > > > >> >>> >> > > > > > > + warning >> >>> >> > > > > >> >>> >> > > > > > > always) >> >>> >> > > > > >> >>> >> > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > - We'd use the reverse-mapping so that plugin search >> path >> >>> will >> >>> >> > work >> >>> >> > > > > >> >>> >> > > > > > > if >> >>> >> > > > > >> >>> >> > > > > > they >> >>> >> > > > > >> >>> >> > > > > > > > specify package name. >> >>> >> > > > > >> >>> >> > > > > > > > - E.g. "cordova plugin add cordova-plugin-file", >> will >> >>> >> need to >> >>> >> > > > > >> >>> >> > > > > > > > know to scan search-path directories for >> >>> >> > > "org.apache.cordova.file". >> >>> >> > > > > >> >>> >> > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > Indeed! >> >>> >> > > > > >> >>> >> > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > > I think the different-IDs-than-package-name approach >> >>> will >> >>> >> work, >> >>> >> > > > > >> >>> >> > > > > > > > but I >> >>> >> > > > > >> >>> >> > > > > > > think >> >>> >> > > > > >> >>> >> > > > > > > > it's too much of a hassle to be used by third-party >> >>> plugins, >> >>> >> > > > > >> >>> >> > > > > > > > because >> >>> >> > > > > >> >>> >> > > > > > it's >> >>> >> > > > > >> >>> >> > > > > > > > more work to have the names be different: >> >>> >> > > > > >> >>> >> > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > I tend to agree. I think it *could* work, but we >> should >> >>> think >> >>> >> > > > > >> >>> >> > > > > > > through if it is necessary. >> >>> >> > > > > >> >>> >> > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > > - If their ID is the same as the package name: >> >>> >> > > > > >> >>> >> > > > > > > > - They fit in more naturally with NPM >> >>> >> > > > > >> >>> >> > > > > > > > - The fetching logic will be faster (since we >> know we >> >>> >> don't >> >>> >> > > > > >> >>> >> > > > > > > > need to check CPR first) >> >>> >> > > > > >> >>> >> > > > > > > > - They don't need to send a pull request and wait >> >>> for a >> >>> >> > > release >> >>> >> > > > > >> >>> >> > > > > > > > so >> >>> >> > > > > >> >>> >> > > > > > > that >> >>> >> > > > > >> >>> >> > > > > > > > people can install their plugin (mapper) >> >>> >> > > > > >> >>> >> > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > > If third-parties don't opt into having different >> package >> >>> >> names >> >>> >> > > > > >> >>> >> > > > > > > > from >> >>> >> > > > > >> >>> >> > > > > > > plugin >> >>> >> > > > > >> >>> >> > > > > > > > IDs, then down the road the only plugins that will >> be in >> >>> >> this >> >>> >> > > > > >> >>> >> > > > > > > > state are >> >>> >> > > > > >> >>> >> > > > > > > the >> >>> >> > > > > >> >>> >> > > > > > > > core plugins. Maybe that's fine? >> >>> >> > > > > >> >>> >> > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > > > I believe the only real question is: do we prefer a >> >>> >> minimally >> >>> >> > > > > >> >>> >> > > > > > > > > easier transition by leaving all names as they are, >> >>> or do >> >>> >> we >> >>> >> > > > > >> >>> >> > > > > > > > > prefer to have package names on npm that don't look >> >>> out of >> >>> >> > > place. >> >>> >> > > > > >> >>> >> > > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > > > I think any argument that there is a technical >> >>> preference >> >>> >> for >> >>> >> > > > > >> >>> >> > > > > > > > > one way >> >>> >> > > > > >> >>> >> > > > > > > > over >> >>> >> > > > > >> >>> >> > > > > > > > > the other hasn't really held up (but now would be a >> >>> great >> >>> >> > time >> >>> >> > > > > >> >>> >> > > > > > > > > to >> >>> >> > > > > >> >>> >> > > > > > > mention >> >>> >> > > > > >> >>> >> > > > > > > > > if that isn't true). >> >>> >> > > > > >> >>> >> > > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > > > (Note: choosing leaving names as they are still >> only >> >>> >> > guarantees >> >>> >> > > > > >> >>> >> > > > > > > > > core plugins do this, 3rd party authors may not >> >>> >> re-publish at >> >>> >> > > > > >> >>> >> > > > > > > > > all, or >> >>> >> > > > > >> >>> >> > > > > > rename >> >>> >> > > > > >> >>> >> > > > > > > > > however they want) >> >>> >> > > > > >> >>> >> > > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > > > -Michal >> >>> >> > > > > >> >>> >> > > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > > > On Wed, Feb 11, 2015 at 4:07 PM, Andrew Grieve >> >>> >> > > > > >> >>> >> > > > > > > > > <agri...@chromium.org >> >>> >> > > > > >> >>> >> > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > > > wrote: >> >>> >> > > > > >> >>> >> > > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > > > > Going to try and summarize my concerns with the >> >>> proposal >> >>> >> > > here: >> >>> >> > > > > >> >>> >> > > > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > > > > On Wed, Feb 11, 2015 at 2:39 PM, Steven Gill < >> >>> >> > > > > >> >>> >> > > > > > stevengil...@gmail.com<mailto:stevengil...@gmail.com> >> >>> >> > > > > >> >>> >> > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > > > > wrote: >> >>> >> > > > > >> >>> >> > > > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > > > > > Correct! For the first 3 months, all requests >> >>> will hit >> >>> >> > CPR >> >>> >> > > > > >> >>> >> > > > > > > > > > > first, >> >>> >> > > > > >> >>> >> > > > > > > if >> >>> >> > > > > >> >>> >> > > > > > > > > CPR >> >>> >> > > > > >> >>> >> > > > > > > > > > > fails, we will try to fetch from npm. >> >>> >> > > > > >> >>> >> > > > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > > > > > If users run "cordova plugin add >> >>> >> cordova-plugin-device", >> >>> >> > it >> >>> >> > > > > >> >>> >> > > > > > > > > > > would >> >>> >> > > > > >> >>> >> > > > > > > hit >> >>> >> > > > > >> >>> >> > > > > > > > > > CPR, >> >>> >> > > > > >> >>> >> > > > > > > > > > > fail, go to npm, succeed. >> >>> >> > > > > >> >>> >> > > > > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > > > > CPR doesn't allow non-reverse dns names. There'd >> be >> >>> no >> >>> >> > reason >> >>> >> > > > > >> >>> >> > > > > > > > > > to >> >>> >> > > > > >> >>> >> > > > > > > check >> >>> >> > > > > >> >>> >> > > > > > > > it >> >>> >> > > > > >> >>> >> > > > > > > > > > unless the name had at least 2 periods in it. >> >>> >> > > > > >> >>> >> > > > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > > > > If we're not using package names to detect which >> >>> >> registry >> >>> >> > to >> >>> >> > > > > >> >>> >> > > > > > > > > > use, I >> >>> >> > > > > >> >>> >> > > > > > > > don't >> >>> >> > > > > >> >>> >> > > > > > > > > > actually see any benefit in changing names. >> >>> >> > > > > >> >>> >> > > > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > > > > > If we use the mapper module, "cordova plugin >> add >> >>> >> > > > > >> >>> >> > > > > > > > > > > org.apache.cordova.device" would be converted >> to >> >>> >> > > > > >> >>> >> > > > > > > > cordova-plugin-device, >> >>> >> > > > > >> >>> >> > > > > > > > > > hit >> >>> >> > > > > >> >>> >> > > > > > > > > > > CPR, fail, go to npm, succeed. >> >>> >> > > > > >> >>> >> > > > > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > > > > While this works fine for our modules, I don't >> think >> >>> >> it'll >> >>> >> > > > > >> >>> >> > > > > > > > > > work >> >>> >> > > > > >> >>> >> > > > > > well >> >>> >> > > > > >> >>> >> > > > > > > > for >> >>> >> > > > > >> >>> >> > > > > > > > > > others'. Three use-cases for them: >> >>> >> > > > > >> >>> >> > > > > > > > > > 1. <dependency> within plugin.xml. >> >>> >> > > > > >> >>> >> > > > > > > > > > 2. <plugin> within config.xml (for cordova plugin >> >>> >> restore). >> >>> >> > > > > >> >>> >> > > > > > > > > > 3. cordova plugin add FOO >> >>> >> > > > > >> >>> >> > > > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > > > > All three would be solved if we enforce that >> >>> >> packageName == >> >>> >> > > > > >> >>> >> > > > > > pluginId. >> >>> >> > > > > >> >>> >> > > > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > > > > I think we should either: >> >>> >> > > > > >> >>> >> > > > > > > > > > - publish under npm under our existing IDs >> >>> >> > > > > >> >>> >> > > > > > > > > > or: >> >>> >> > > > > >> >>> >> > > > > > > > > > - publish under npm under cordova-plugin-FOO, and >> >>> change >> >>> >> > > > > >> >>> >> > > > > > > > > > plugin IDs >> >>> >> > > > > >> >>> >> > > > > > > to >> >>> >> > > > > >> >>> >> > > > > > > > be >> >>> >> > > > > >> >>> >> > > > > > > > > > cordova-plugin-FOO >> >>> >> > > > > >> >>> >> > > > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > > > > > After 3 months, "cordova plugin add >> >>> >> > cordova-plugin-device" >> >>> >> > > > > >> >>> >> > > > > > > > > > > would >> >>> >> > > > > >> >>> >> > > > > > > hit >> >>> >> > > > > >> >>> >> > > > > > > > > npm >> >>> >> > > > > >> >>> >> > > > > > > > > > > first and succeed. >> >>> >> > > > > >> >>> >> > > > > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > > > > > We want to use these 3 months to get our >> >>> developers to >> >>> >> > > > > >> >>> >> > > > > > > > > > > update >> >>> >> > > > > >> >>> >> > > > > > their >> >>> >> > > > > >> >>> >> > > > > > > > > tools >> >>> >> > > > > >> >>> >> > > > > > > > > > > and use the new names for plugins to install. >> >>> >> > > > > >> >>> >> > > > > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > > > > > On Wed, Feb 11, 2015 at 10:36 AM, Michal Mocny >> < >> >>> >> > > > > >> >>> >> > > > > > > mmo...@chromium.org<mailto:mmo...@chromium.org>> >> >>> >> > > > > >> >>> >> > > > > > > > > > > wrote: >> >>> >> > > > > >> >>> >> > > > > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > > > > > > Steve, npm fetch default only affects plugins >> >>> that >> >>> >> use >> >>> >> > > > > >> >>> >> > > > > > > > > > > > same >> >>> >> > > > > >> >>> >> > > > > > name >> >>> >> > > > > >> >>> >> > > > > > > in >> >>> >> > > > > >> >>> >> > > > > > > > > > both >> >>> >> > > > > >> >>> >> > > > > > > > > > > > places, right? >> >>> >> > > > > >> >>> >> > > > > > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > > > > > > If we create cordova-plugin-device today, and >> >>> tell >> >>> >> > users >> >>> >> > > > > >> >>> >> > > > > > > > > > > > to >> >>> >> > > > > >> >>> >> > > > > > start >> >>> >> > > > > >> >>> >> > > > > > > > > using >> >>> >> > > > > >> >>> >> > > > > > > > > > > > cordova plugin add cordova-plugin-device, >> then >> >>> we >> >>> >> will >> >>> >> > > get >> >>> >> > > > > >> >>> >> > > > > > > > > > > > much >> >>> >> > > > > >> >>> >> > > > > > > > user >> >>> >> > > > > >> >>> >> > > > > > > > > > > > feedback on npm fetching far before May 18th, >> >>> right? >> >>> >> > > > > >> >>> >> > > > > > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > > > > > > On Wed, Feb 11, 2015 at 1:09 PM, Steven Gill >> < >> >>> >> > > > > >> >>> >> > > > > > > > stevengil...@gmail.com<mailto:stevengil...@gmail.com >> > >> >>> >> > > > > >> >>> >> > > > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > > > > > > wrote: >> >>> >> > > > > >> >>> >> > > > > > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > > > > > > > We don't have one yet but we should pick >> dates >> >>> >> soon. >> >>> >> > > > > >> >>> >> > > > > > > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > > > > > > > How about: >> >>> >> > > > > >> >>> >> > > > > > > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > > > > > > > CPR Switch to read only: Monday, May 18th >> NPM >> >>> >> fetch >> >>> >> > > > > >> >>> >> > > > > > > > > > > > > becomes default: Monday, May 18th CPR >> offline: >> >>> >> > Monday, >> >>> >> > > > > >> >>> >> > > > > > > > > > > > > August 17th >> >>> >> > > > > >> >>> >> > > > > > > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > > > > > > > Based on the following proposal: >> >>> >> > > > > >> >>> >> > > > > > > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > >> >>> >> > > > > >> >>> >> > > > > > >> >>> >> > > >> >>> >> >> >>> >> https://docs.google.com/document/d/12WAXJa6jfY3BnNHGieK9QOqvZ6cl3OXmP- >> >>> >> > > > > >> >>> >> > > > > > 9DpYkcmfs/edit?usp=sharing >> >>> >> > > > > >> >>> >> > > > > > > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > > > > > > > - Need to start educating plugin >> developers >> >>> to >> >>> >> > publish >> >>> >> > > > > >> >>> >> > > > > > > > > > > > > to >> >>> >> > > > > >> >>> >> > > > > > npm >> >>> >> > > > > >> >>> >> > > > > > > as >> >>> >> > > > > >> >>> >> > > > > > > > > > well >> >>> >> > > > > >> >>> >> > > > > > > > > > > as >> >>> >> > > > > >> >>> >> > > > > > > > > > > > > CPR for next three months. (blog post) >> >>> >> > > > > >> >>> >> > > > > > > > > > > > > - Need to educate users to install plugins >> >>> via >> >>> >> new >> >>> >> > > > > >> >>> >> > > > > > > > > > > > > names (if >> >>> >> > > > > >> >>> >> > > > > > > > > > > > package-name >> >>> >> > > > > >> >>> >> > > > > > > > > > > > > is different than id). Our core plugins are >> >>> being >> >>> >> > > > > >> >>> >> > > > > > > > > > > > > renamed >> >>> >> > > > > >> >>> >> > > > > > from >> >>> >> > > > > >> >>> >> > > > > > > > > > > > > org.apache.cordova.device to >> >>> cordova-plugin-device >> >>> >> > > > > >> >>> >> > > > > > > > > > > > > - Inform devs who are working with registry >> >>> >> directly >> >>> >> > to >> >>> >> > > > > >> >>> >> > > > > > > > > > > > > pull >> >>> >> > > > > >> >>> >> > > > > > > > > plugins >> >>> >> > > > > >> >>> >> > > > > > > > > > > from >> >>> >> > > > > >> >>> >> > > > > > > > > > > > > npm instead of CPR. After 3 months, CPR >> >>> plugins >> >>> >> will >> >>> >> > > > > >> >>> >> > > > > > > > > > > > > start to >> >>> >> > > > > >> >>> >> > > > > > > > > become >> >>> >> > > > > >> >>> >> > > > > > > > > > > out >> >>> >> > > > > >> >>> >> > > > > > > > > > > > of >> >>> >> > > > > >> >>> >> > > > > > > > > > > > > date compared to npm versions. >> >>> >> > > > > >> >>> >> > > > > > > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > > > > > > > Our next plugins release (after the one >> >>> currently >> >>> >> > > > > >> >>> >> > > > > > > > > > > > > ongoing) >> >>> >> > > > > >> >>> >> > > > > > will >> >>> >> > > > > >> >>> >> > > > > > > > be >> >>> >> > > > > >> >>> >> > > > > > > > > > > > > published to npm as well as cpr. >> >>> >> > > > > >> >>> >> > > > > > > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > > > > > > > On Wed, Feb 11, 2015 at 9:10 AM, Gorkem >> Ercan >> >>> < >> >>> >> > > > > >> >>> >> > > > > > > > > > gorkem.er...@gmail.com<mailto: >> >>> gorkem.er...@gmail.com>> >> >>> >> > > > > >> >>> >> > > > > > > > > > > > > wrote: >> >>> >> > > > > >> >>> >> > > > > > > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > > > > > > > > Is there a determined calendar for the >> npm >> >>> move >> >>> >> of >> >>> >> > > the >> >>> >> > > > > >> >>> >> > > > > > > plugins? >> >>> >> > > > > >> >>> >> > > > > > > > > > > > > > I think the scheduling of the transition >> is >> >>> >> crucial >> >>> >> > > > > >> >>> >> > > > > > > > > > > > > > for >> >>> >> > > > > >> >>> >> > > > > > those >> >>> >> > > > > >> >>> >> > > > > > > > who >> >>> >> > > > > >> >>> >> > > > > > > > > > are >> >>> >> > > > > >> >>> >> > > > > > > > > > > > > > using the plugin registry directly. >> >>> >> > > > > >> >>> >> > > > > > > > > > > > > > -- >> >>> >> > > > > >> >>> >> > > > > > > > > > > > > > Gorkem >> >>> >> > > > > >> >>> >> > > > > > > > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > >> >>> >> > >> >>> --------------------------------------------------------------------- >> >>> >> > > > > >> >>> >> > > > > > > > > > > > > > To unsubscribe, e-mail: >> >>> >> > > > > >> >>> >> > > > > > > > > > > > > > dev-unsubscr...@cordova.apache.org >> <mailto: >> >>> >> > > > > dev-unsubscr...@cordova.apache.org> >> >>> >> > > > > >> >>> >> > > > > > > > > > > > > > For additional commands, e-mail: >> >>> >> > > > > >> >>> >> > > > > > dev-h...@cordova.apache.org<mailto: >> >>> dev-h...@cordova.apache.org> >> >>> >> > > > > >> >>> >> > > > > > > > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > > >> >>> >> > > > > >> >>> >> > > > > > > >> >>> >> > > > > >> >>> >> > > > > > >> >>> >> > > > > >> >>> >> > > > >> >>> >> > > > >> >>> >> > > > >> >>> >> > > > -- >> >>> >> > > > Carlos Santana >> >>> >> > > > <csantan...@gmail.com> >> >>> >> > > > >> >>> >> > > >> >>> >> > >> >>> >> >> >>> > >> >>> > >> >>> >> >> >> >> >> > >> > >
