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.
Plugin TODO:
- Rename id to package-name in package.json files and plugin.xml
- move english documentation into readme, add links for other languages
into readme pointing to github markdown files
- Add peer dependencies to package.json
- Major bump plugin versions
Tools TODO:
- NPM fetch as fallback
- 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.
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>
> >>> >> > > >
> >>> >> > >
> >>> >> >
> >>> >>
> >>> >
> >>> >
> >>>
> >>
> >>
> >
>
