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
>

Reply via email to