Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (nike.apache.org: domain of braden@google.com designates
 209.85.214.44 as permitted sender)
MIME-Version: 1.0
Sender: braden@google.com
Date: Tue, 24 Sep 2013 14:58:53 -0400
Message-ID: 
 <CAMk5LLn2AUk55UDFeWghu=GszBJ1bnH-mBQXkHsHA+OEULnXhQ@mail.gmail.com>
Subject: Updating plugin code on prepare
From: Braden Shepherdson <braden@chromium.org>
To: "dev@cordova.apache.org" <dev@cordova.apache.org>
Content-Type: multipart/alternative; boundary=001a11334a3c63ee2d04e725bac5

--001a11334a3c63ee2d04e725bac5
Content-Type: text/plain; charset=ISO-8859-1

Michal and I were discussing how to make the plugin developer experience
better, by having `cordova prepare` update the platform projects properly
when you change a plugin in place.

I propose the following changes:

1. On plugin install, we cache the plugin.xml in $PROJECT/.cordova
somewhere.
2. On 'cordova prepare', compare each plugin's plugin.xml against the
cached one.
    a. If they have changed, uninstall the plugin using the old plugin.xml,
then reinstall using the new one (and update the cached plugin.xml).
    b. If they are identical, copy all the native code files from the
plugin into the project again.

The idea is that you can change your plugin's native code, JS modules, or
assets, and after a prepare you'll be running the latest. We already have
cordova plugin add foo --link, but it wasn't very useful. This will make
plugin development a much smoother flow, without too much implementation
effort.

Checking for changes to plugin.xml lets us know that no files have been
added or removed, that <config-file> edits haven't changed, and so on,
meaning that simply copying the native code again will be sufficient.

What do people think? Any gotchas that I overlooked?

Braden

--001a11334a3c63ee2d04e725bac5--