cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Mocny <mmo...@chromium.org>
Subject Re: Success with Cordova CLI and custom plugin
Date Thu, 04 Jul 2013 17:40:09 GMT
Either way, I now think real symlinking is a bad idea.  We currently must
keep a copy of the files as they existed at "fetch" time so that we can use
them for upgrade/uninstall.  Symlinks break that.  Conceptually, we already
have "links" in that we remember the original source locations, and we
could improve the "prepare" step to add the ability to auto-upgrade all
plugins.

Not sure if that is the best solution, but seems feasible.


On Thu, Jul 4, 2013 at 1:27 PM, Filip Maj <fil@adobe.com> wrote:

> The --link options actually exists in plugman, but it is only an option
> for the `fetch` command. All it does is copy the plugin code from <your
> location or URL> to a plugins directory. With --link, instead it will
> symlink. It does not actually create symlinks for native or web plugin
> code.
>
> Would that even work, I wonder? For compiling, etc.
>
> On 7/3/13 10:32 AM, "Michal Mocny" <mmocny@chromium.org> wrote:
>
> >On Wed, Jul 3, 2013 at 1:13 PM, Tyler Wilson
> ><twilson@pulse-robotics.com>wrote:
> >
> >> Good day,
> >>
> >> Just wanted to publicise that I have had success with the cli, a custom
> >> plugin and an iOS build. I must say once everything is set up it is
> >>pretty
> >> nice being able to add/remove components and it appears to handle things
> >> just fine. Just a couple notes:
> >>
> >
> >Awesome!
> >
> >
> >>
> >> - The default build created has two config.xml files in the project (I
> >>am
> >> using Xcode) - one at the root, and one within the www folder. Is this
> >> expected?
> >>
> >
> >This is expected, but not desired.  It is a result of us having a
> >config.xml inside your www/ folder and copying that whole folder on
> >prepare.  For now, if you can add it to your workflow, I would remove the
> >config.xml from "platforms/ios/www" after every "cordova prepare"
> > (actually, not removing it causes a race condition that rarely but
> >occasionally causes an app launch failure, so we will need to solve this
> >issue upstream).
> >
> >
> >>
> >> - I was having issue installing my plugin with plugman. Then I realized
> >> that the cordova cli command handles plugin installs and removal. It is
> >> confusing with many references to plugman. Perhaps there should be a
> >> 'modern' Getting Started guide for the CLI version that also installs a
> >> plugin as an example? I have read this one -
> >>
> >>
> http://cordova.apache.org/docs/en/2.9.0/guide_cli_index.md.html#The%20Cor
> >>dova%20Command-line%20Interface- but perhaps another matching one for
> >>plugin developers? (And put a NOTE
> >> on this page about the issue with npm 1.3.x versionsÅ )
> >>
> >
> >Thanks for pointing that out.
> >
> >
> >>
> >> - I referenced this before, but I think an option to install a plugin
> >>via
> >> symlinks would make development a lot easier, since in most cases you
> >>will
> >> be editing the copy that was created during the install, not the
> >>original.
> >> I will do it manually for now of course.
> >>
> >
> >We discussed adding a --link option to plugin add before, but since we
> >need
> >to have the original assets around in order to do proper install, I think
> >the current plan was to support in-place upgrading (sorta like cordova
> >prepare, but for plugins).  Fil/Braden, maybe you can add more on this.
> >
> >For now, (cordova plugin rm ... && cordova plugin add ...) as a form of
> >in-place plugin upgrade works only for updating web assets at the moment.
> >
> >As far as modifying the copy -- yes, during plugin development I do that
> >too, its just a lot easier to get rapid iteration -- but after I'm done I
> >*do* copy those assets back out to the original location.  Also, for
> >plugin
> >consumers, not the original authors, they will not be making changes to
> >the
> >plugin copies.
> >
> >
> >>
> >> Great job everybody.
> >>
> >> Thank you,
> >> Tyler
> >>
> >>
> >>
> >>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message