On Thu, Mar 26, 2015 at 12:05 PM, Victor Sosa <sosah.vic...@gmail.com> wrote:
> With regarding this Plugins to NPM topic... > > This is a change that will impact to IDEs who rely on > http://registry.plugins.io to show available plugins to users. Even though > there will be a window for this change, CPR will have a 6-months window (at > least this is my understanding) to let plugin developers to migrate their > plugins to NPM and also let users to use in the old way (I mean the current > plugin IDs), there will be the point that this will be unsupported by > Cordova, hence support in IDEs will break. > > I've been doing a little research and collecting some information and here > the summary of my findings: > 1. The plugins will be hosted in http://registry.npmjs.org/ > 2. All NPM documents can be listed by querying the server with the > following URL: http://registry.npmjs.org/-/all > 3. If you are interested on the Cordova plugins only (as will be the case), > use the keyword "ecosystem:cordova" to filter out the contents in this > list. Here is an error prone point, if the plugin doesn't have this keyword > it will never be found making hard to developers to know it in fact exists > (this is one of the major plus sides on CPR imho). If plugin authors want their plugins to be discoverable, they will have to include "ecosystem:cordova" for now. > 4. The only way to get such filtered list is to fetching all documents in > NPMJS registry and then do the filter locally using the keyword > "ecosystem:cordova", i.e. there is no way to get a filtered list directly > from the registry (I looked at NPM code and this is what they do. See in > NPM module, <cordova_install_dir>/node_modules/npm/lib/search.js file, > around line 60 "getFilteredData" function). > When we chatted with npm folks last month, they told us they could help us expose the plugins. I'm sure we can figure out a way that would be easier than filtering locally. > > With those steps, I'm able to retrieve the list of plugins that follow the > "ecosystem:cordova" contract that was proposed before in a headless way, > i.e. no web browser, just a small script. > > If any of you have suggestions on how better do this Cordova plugins > discovery on NPMJS, please let me know. > I'll send them a email to see what solutions they have. "ecosystem:cordova" will start returning platforms + tools as well (not reserved just for plugins). We may need to build a better search on our own (like http://browserifysearch.org/). Hopefully it doesn't come down to that though. > > > 2015-03-25 15:36 GMT-06:00 Horn, Julian C <julian.c.h...@intel.com>: > > > I'd like to add some more questions to what Leo asked. > > > > Can anyone explain how the hundreds of plugins that are published in git > > repos are supposed to transition to CLI 5 (and beyond)? It seems like > the > > answer is that they don't change anything. What if they want to (or > > already do) publish via the registry? It seems like you can win if you > > keep the id unchanged and add yourself to the mapping table. But if > that's > > true, then why are we renaming the core plugins? > > > > I don't think repo-resident plugins need to update any <dependency> tags > > that refer to core plugins. That is, you can continue to ask for > > "org.apache.cordova.file". If you use CLI 5, then the rename logic will > > get you the corresponding plugin from npm. Or is there some reason why > you > > will eventually have to change your <dependency> tags to use the new > > names. Of course you better not change a <dependency> tag in your > > repo-resident plugin before October 1, because that will break projects > > that use your plugin but aren't yet using CLI 5. > > > > I haven't been able to come up with any strategy for changing the id of a > > repo-resident plugin without great pain. It's basically equivalent to > > discontinuing your plugin and creating a new one in its place. So it > seems > > to me that if I have any users I would probably want to stick with my > > existing id and repo URL, even if it meant that I couldn't publish my > > plugin in npm format. Is that a viable strategy, or is there a long term > > plan that EVERY plugin must eventually publish via npm? > > > > One final question. Suppose I have a CLI 4.x project and I want to > > transition to CLI 5. Do I have to start over at "cordova create > project"? > > > > Julian > > > > -----Original Message----- > > From: Treggiari, Leo [mailto:leo.treggi...@intel.com] > > Sent: Wednesday, March 25, 2015 3:53 PM > > To: dev@cordova.apache.org > > Subject: RE: Plugins to NPM (Phase 1) > > > > Thanks for the information Steve. That helps with our planning. I have > a > > couple of follow-ups. > > > > > We don't necessarily have to do a major bump for the CLI. We could > > > easily save the major jump until we switch npm fetching as default > > > (approx July 1) > > > > Re: the major bump. This seems like a "delayed" breaking change. That > > is, when CPR is removed, all prior CLI releases will be "crippled" to a > > significant degree since no <pluginid> reference will be able to be > > resolved. > > > > Re: ~July 1: Would you verify my understanding? For a <pluginid> > > reference which is not in the mapping table, from ~Apr to ~July 1, CPR > will > > be tried first and if that fails then npm. From ~July 1 to ~Oct 1, npm > > will be tried first and if that fails then the CPR. After ~Oct 1, only > npm. > > > > Thanks, > > Leo > > > > -----Original Message----- > > From: Steven Gill [mailto:stevengil...@gmail.com] > > Sent: Wednesday, March 25, 2015 11:13 AM > > To: dev@cordova.apache.org > > Subject: Re: Plugins to NPM (Phase 1) > > > > Thanks for answering tony. More comments below. > > > > On Tue, Mar 24, 2015 at 12:45 PM, Homer, Tony <tony.ho...@intel.com> > > wrote: > > > > > I¹ll try to answer some of Leo¹s questions, but it would be great if > > > someone else (Steve?) could comment. > > > > > > First, though, I¹ll ask a question of my own. > > > Is there a doc or JIRA task for tracking all of the activity related > > > to moving plugins to NPM? > > > There was the Google Doc that was created last hangout for tracking > > > the proposal, but it doesn¹t list JIRAs and hasn¹t been updated since > > > January. > > > I found CB-8529, CB-8538 and CB-8551 but they are not linked to a > > > master task JIRA. > > > This is not a jab at Steve at all, I¹m just wondering if there is or > > > should be a reference for this set of tasks (other than staying caught > > > up with reading the list)? > > > > > > > Good point. I have created a master issue at > > https://issues.apache.org/jira/browse/CB-8743 > > > > > > > On to Leo¹s questions- > > > > > > Will the release be named Cordova 5.0? > > > Unknown at this time? It seems like this will require a co-ordinated > > > release of CLI, Tools and Plugins, with major version bumps for all. > > > > > > > We haven't discussed this yet. We don't necessarily have to do a major > bump > > for the CLI. We could easily save the major jump until we switch npm > > fetching as default (approx July 1) > > > > > > > > Will it trigger a major revision bump? > > > Yes. > > > > > > > For plugins, yes. All of the core plugins will be getting a major version > > bump shortly. > > > > > > > > What is the current estimate for the release? > > > > > > I would say ³when it¹s done² but it would be great to get a more > specific > > > answer. > > > I¹m not sure if that¹s possible? > > > > > > > Aiming for April 1st. > > > > > > > > If release of Phase 1 occurs on April 1 does this mean that the CPR > > > becomes read-only on July 1 and is > > > deleted on Oct 1? > > > > I think the real driver was that there is an external hosting issue with > > > CPR after Oct. 1. > > > The 3 month period was adopted so provide a transition window, but > there > > > is a hard stop on or around Oct. 1. > > > Steve had mentioned this somewhere but I can¹t find it now. > > > > > > > - CPR becomes read-only July 1st (if we release April 1st) > > - Tools fetch from NPM by default on July 1st (currently checks CPR > first, > > npm as fallback) > > - We will try to keep CPR open as read-only for as long as possible. > > Nodejitsu people told us they could give us the 6 months but we will see > if > > we can stretch it. A day will come when we will have to shut down CPR > > though. > > > > > > > > - On Oct 1, all previous releases of Cordova CLI (< 5.0) will > > immediately > > > be "broken"? > > > > > > > Yes, that is my understanding, although in reading back over the > > > discussion I don¹t see where it is explicitly addressed. > > > I was assuming that this is intended in part as a forcing function. > > > > > > > Yes. We could look into setting up some redirect service to keep old > > versions working. But for now, we are saying users will have to upgrade. > > > > > > > > Tony > > > > > > > > > On 3/20/15, 11:05 AM, "Treggiari, Leo" <leo.treggi...@intel.com> > wrote: > > > > > > >I have a few questions about Phase 1 (and beyond) as I plan how to > > > >migrate the Intel XDK and existing user projects through this change. > > > > > > > >- Will the release be named Cordova 5.0? This seems worthy of a > major > > > >bump for the CLI in addition to the plugins. > > > > > > > >- What is the current estimate for the release? I assume soon. > > > > > > > >- For the purpose of my questions, I'll assume the release occurs on > > > >April 1. This means that the CPR becomes read-only on July 1 and is > > > >deleted on Oct 1? > > > > > > > >- On Oct 1, all previous releases of Cordova CLI (< 5.0) will > > > >immediately be "broken"? That is, they cannot add new plugins, they > > > >cannot "restore" plugins, etc. "Local" and "git repo" plugins > continue > > > >to work, but my assumption is that the vast majority of plugins come > > from > > > >CPR (soon to be npm). > > > > > > > >Thanks, > > > >Leo > > > > > > > >-----Original Message----- > > > >From: Steven Gill [mailto:stevengil...@gmail.com] > > > >Sent: Monday, March 09, 2015 5:20 PM > > > >To: dev@cordova.apache.org > > > >Cc: sosah.vic...@gmail.com > > > >Subject: Update: Plugins to NPM (Phase 1) > > > > > > > >Our master branch has plugin fetching from npm set as the fallback > now. > > It > > > >will go directly to npm if the plugin-id entered isn't reverse domain > > name > > > >style. Cordova-lib also warns users to use the package-name instead of > > > >plugin-id when adding plugins that we have renamed and are in > > > >https://github.com/stevengill/cordova-registry-mapper > > > > > > > >Plugins TODO: > > > > > > > >- README: Move doc/en/index.md into README.md. Delete doc/en/index.md > . > > > Add > > > >links in README.md that point to github page of translated docs for > > > >plugin. > > > >(ex. > > > > > > > > > > https://github.com/apache/cordova-plugin-device/blob/master/doc/es/index.m > > > >d). > > > >I'd love to hear from someone (Victor?) working on docs translations > > about > > > >how this change will impact them. > > > > > > > >- Rename plugin-ids to new plugin names in plugin.xml. Anything we > > should > > > >be aware of before we do this? (Ex. rename org.apache.cordova.device > to > > > >cordova-plugin-device in plugin.xml) > > > > > > > >- Add peer dependencies to plugins that depend on other plugins (file, > > > >media-capture, etc) > > > > > > > >- Paramedic support for every plugin > > > > > > > >- Major version bump for all core plugins > > > > > > > >- Update plugins release process to use package.json version as main > > > >version and have it update plugin.xml's version. Will do this when we > do > > > >next release > > > > > > > >Migration TODO: > > > > > > > >- Create blog post talking about migration to npm for community > > > > > > > >- include how we are renaming, suggest they do so if they want to. > Will > > > >suggest they follow the pattern cordova-plugin-* > > > > > > > >- mention https://github.com/stevengill/cordova-registry-mapper for > > > >warning > > > >purposes > > > >- include potential lifespan of CPR (publishing and read only) > > > >- Discuss plugman createpackage.json command > > > >- Discuss keyword: 'ecosystem:cordova' > > > > > > > > > > > >Thoughts? Missing anything? > > > > > > > >--------------------------------------------------------------------- > > > >To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > > > >For additional commands, e-mail: dev-h...@cordova.apache.org > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > > > For additional commands, e-mail: dev-h...@cordova.apache.org > > > > > > > > -Steve > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > > For additional commands, e-mail: dev-h...@cordova.apache.org > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > > For additional commands, e-mail: dev-h...@cordova.apache.org > > > > > > > -- > Victor Adrian Sosa Herrera > IBM Software Engineer > Guadalajara, Jalisco >
