Updating plugin code on prepare

[Braden Shepherdson <br...@chromium.org>]

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

Re: Updating plugin code on prepare

[Braden Shepherdson <br...@chromium.org>]

This feature has not received any work yet, largely because I was away most
of last week. It will land in 3.2, or possibly earlier - CLI releases are
not tied to Cordova releases.

Braden


On Mon, Oct 7, 2013 at 10:57 AM, Michael Gauthier <mi...@silverorange.com>wrote:

> Did this feature land in 3.1.0 or is it targeted for 3.2.0?
>
> On 2013-10-03 11:30, Michal Mocny wrote:
>
>> Yeah Braden we've diverged sorry, lets focus.
>>
>> Big +1 for your proposal to make prepare step do what users expect.
>>
>> -Michal
>>
>>
>> On Thu, Oct 3, 2013 at 10:20 AM, Braden Shepherdson <braden@chromium.org
>> >wrote:
>>
>>  I agree that the syncing solutions are too complex and confusing.
>>>
>>> I return, then, to my original proposal all those emails ago: updating
>>> the
>>> native plugin files in platforms/foo when you prepare, to make life
>>> easier
>>> for plugin developers. When coupled with the present cordova plugin add
>>> --link, and future cordova watch, I think this makes the plugin developer
>>> flow pretty good, and without making it too magical or harder to
>>> understand. I think it simplifies prepare: on prepare, your native
>>> projects
>>> are updated to reflect the state of plugins/ and www/. Right now, only
>>> www/, <asset>s and <js-module>s get updated, but not native code.
>>>
>>> As to Xcode and symlinks and all the rest of the borderline thread
>>> hijacking, I think that regardless of what editor you use, you have to be
>>> editing the right file. Xcode and Eclipse make this harder than it needs
>>> to
>>> be, but our job is not to make them suck less.
>>>
>>> Braden
>>>
>>>
>>> On Sun, Sep 29, 2013 at 1:43 PM, Carlos Santana <csantana23@gmail.com
>>>
>>>> wrote:
>>>>
>>>
>>>  +1 Anis
>>>> corodova-cli/plugman should be building block components to higher level
>>>> Tools/IDE.
>>>>
>>>> That we can do better sure, lets provide a few examples using blog pots
>>>>
>>> and
>>>
>>>> maybe videos tutorials vs. trying to support every use case with code.
>>>>
>>>> A watch function could be as simple as using "grunt-contrib-watch" to a
>>>> more complicated environment like "rsync/Eclipse"
>>>>
>>>> I agree lets put emphasis on documenting use cases and the correct
>>>> approach.
>>>> When to get the best out of using prepare,  merges, and hooks
>>>>
>>>> All I said applies when you have the "Web Developer" hat.
>>>>
>>>> For people that have the "Native Plugin Developer" hat then we can do
>>>> things first for cordova-contributors than others can choose to use on
>>>> their own risk since it could be changing too fast and maybe too narrow
>>>>
>>> use
>>>
>>>> case.
>>>>
>>>> --Carlos
>>>>
>>>> --Carlos
>>>>
>>>>
>>>>
>>>> On Sun, Sep 29, 2013 at 9:18 AM, Anis KADRI <an...@gmail.com>
>>>>
>>> wrote:
>>>
>>>>
>>>>  I gave some thought to this problem and I think we should just leave
>>>>> everything as is. Here's my reasoning:
>>>>>
>>>>> - Most web developers use a text editor (vim, sublime text, text mate,
>>>>> notepad++, ....) to edit their HTML/CSS/Javascript. I've never seen
>>>>> anyone use a fully fledged IDE to edit web assets. It would be like
>>>>> using Microsoft Word to edit a simple .TXT or .MD file
>>>>> - Other developers, people who write Java or Objective C, etc.. use
>>>>> Xcode, Eclipse, IntelliJ, ...and I think these people are not good
>>>>> candidates for cordova-cli.
>>>>>
>>>>> The original PhoneGap promise (now Apache Cordova) was to make it easy
>>>>> for Web Developers to write Mobile Apps using web technologies and I
>>>>> believe that promise is fulfilled with cordova-cli. You have a folder
>>>>> where you drop in your web assets and you can build/deploy to a device
>>>>> or simulate.
>>>>>
>>>>> If people want to use an IDE, then they should be creating native
>>>>> projects with our create scripts and use plugman to manage their
>>>>> plugins.
>>>>>
>>>>> Our documentation should point our users to the right approach
>>>>> depending on the use case. For example:
>>>>>
>>>>> - Building for only one platform ? Building a hybrid app ? Want to use
>>>>> an IDE (Eclipse, Xcode) ? You should use the create scripts and
>>>>> plugman to manage plugins
>>>>>
>>>>> - Building a cross-platform app ? Like managing your project from the
>>>>> command-line ? Want to use your favo(u)rite text editor ? Use
>>>>> cordova-cli
>>>>>
>>>>> These double symlinking, backsyncing solutions will be a source of
>>>>> confusion and issues in my humble opinion. I've said it before but
>>>>> sometimes by trying to please everyone you end up pleasing no one.
>>>>>
>>>>> my .02c
>>>>>
>>>>> -a
>>>>>
>>>>> On Fri, Sep 27, 2013 at 8:20 PM, Michal Mocny <mm...@chromium.org>
>>>>>
>>>> wrote:
>>>>
>>>>> On Fri, Sep 27, 2013 at 2:10 PM, Andrew Grieve <agrieve@chromium.org
>>>>>>
>>>>>
>>>>  wrote:
>>>>>
>>>>>>
>>>>>>  Just tried some symlinks in Xcode 5:
>>>>>>> - Copying assets work (due to our custom build step)
>>>>>>> - Building works (compiler follows links just fine)
>>>>>>> - Editing a fail (big fail. Files open but changes cannot be saved.)
>>>>>>>
>>>>>>>
>>>>>> Hmm, changes via xcode to symlinks fail, you mean?  That would be
>>>>>>
>>>>> hard
>>>
>>>> to
>>>>
>>>>> fix, but perhaps at least its feedback to the user not to make direct
>>>>>>
>>>>> edits
>>>>>
>>>>>> there, when using CLI workflow ;) so may still be a valid change to
>>>>>>
>>>>> make.
>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>> For Xcode though, it is an option to change our installation step to
>>>>>>>
>>>>>> have
>>>>>
>>>>>> Xcode reference the native files within plugins/ rather than within
>>>>>>> platforms/.
>>>>>>>
>>>>>>>
>>>>>>> Symlinks in Eclipse:
>>>>>>> - Copying assets works out-of-the-box
>>>>>>> - Build works fine
>>>>>>> - Editing seems to work fine (edits saved to symlinked location).
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Still though, maybe the best solution would be a combination of the
>>>>>>>
>>>>>> two?
>>>>
>>>>> Have prepare know when an remove+add is necessary?
>>>>>>>
>>>>>>>
>>>>>> Yes, I think thats what we are suggesting.
>>>>>>
>>>>>> The original email mentioned prepare knowing when remove+add are
>>>>>>
>>>>> necessary,
>>>>>
>>>>>> which I think is already settled as a good idea.  Not sure if you had
>>>>>>
>>>>> more
>>>>>
>>>>>> to add about how prepare should know when to do this (currently, its
>>>>>>
>>>>> only
>>>>
>>>>> on plugin.xml changes).
>>>>>> The more recent suggestions about making links between
>>>>>>
>>>>> platform&plugins
>>>
>>>> were additional requests to address the rest of the workflow issues
>>>>>>
>>>>> (ie,
>>>>
>>>>> most users prefer to edit inside platforms/ folder because of IDE
>>>>>> integration etc).
>>>>>>
>>>>>> Were you implying anything different here?
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On Fri, Sep 27, 2013 at 6:25 PM, Michal Mocny <mm...@chromium.org>
>>>>>>>
>>>>>> wrote:
>>>>>
>>>>>>
>>>>>>>  Have we not previously solved the symlink problem in xcode with a
>>>>>>>>
>>>>>>> build
>>>>>
>>>>>> hook, or was that for prepare step?
>>>>>>>>
>>>>>>>> The --link concept doesn't do anything for that platforms ->
>>>>>>>>
>>>>>>> plugins
>>>
>>>> file
>>>>>
>>>>>> mapping.  Its useful for mapping plugins/ to local source, but it
>>>>>>>>
>>>>>>> doesn't
>>>>>
>>>>>> help with the problem Tyler mentions, right?
>>>>>>>>
>>>>>>>> -Michal
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Sep 27, 2013 at 1:20 PM, Braden Shepherdson <
>>>>>>>>
>>>>>>> braden@chromium.org
>>>>>
>>>>>> wrote:
>>>>>>>>>
>>>>>>>>
>>>>>>>>  Symlinks in platforms/ are a problem because Xcode doesn't
>>>>>>>>>
>>>>>>>> honour
>>>
>>>> them,
>>>>>
>>>>>> at
>>>>>>>>
>>>>>>>>> least last time we tried it.
>>>>>>>>>
>>>>>>>>> I'm much more enthused about the --link concept than any
>>>>>>>>>
>>>>>>>> syncing,
>>>
>>>> though.
>>>>>>>
>>>>>>>> Also if someone wants to sync, they can already use rsync to do
>>>>>>>>>
>>>>>>>> it
>>>
>>>> manually.
>>>>>>>>>
>>>>>>>>> Braden
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Fri, Sep 27, 2013 at 11:45 AM, Andrew Grieve <
>>>>>>>>>
>>>>>>>> agrieve@chromium.org
>>>>>
>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>  I think it'd be good to enumerate our options for workflow
>>>>>>>>>>
>>>>>>>>> before
>>>>
>>>>> we
>>>>>
>>>>>> decided on which to implement (or maybe choose multiple).
>>>>>>>>>>
>>>>>>>>>> Tyler's idea about a sync command seems like it would be
>>>>>>>>>>
>>>>>>>>> handy.
>>>
>>>> Edit
>>>>>
>>>>>> your
>>>>>>>>
>>>>>>>>> plugin files within platforms/, and then run `cordova plugin
>>>>>>>>>>
>>>>>>>>> copychanges
>>>>>>>>
>>>>>>>>> org.my.plugin` to do a reverse copy of the source files back
>>>>>>>>>>
>>>>>>>>> to
>>>
>>>> the
>>>>>
>>>>>> install
>>>>>>>>>
>>>>>>>>>> source location of the plugin. Big caveat though is that you
>>>>>>>>>>
>>>>>>>>> run
>>>
>>>> the
>>>>>
>>>>>> risk
>>>>>>>>
>>>>>>>>> of prepare clobbering your changes. I think that's too killer
>>>>>>>>>>
>>>>>>>>> a
>>>
>>>> risk.
>>>>>
>>>>>>
>>>>>>>>>> Another thought is that we could use symlinks when running
>>>>>>>>>>
>>>>>>>>> prepare.
>>>>>
>>>>>> Have
>>>>>>>>
>>>>>>>>> files within platforms/ symlink to files within plugins/, then
>>>>>>>>>>
>>>>>>>>> symlink
>>>>>>>
>>>>>>>> again back to their original sources. Would this work with
>>>>>>>>>>
>>>>>>>>> editors in
>>>>>
>>>>>> practice? I don't know, but worth exploring. Wikipedia says
>>>>>>>>>>
>>>>>>>>> symlinks
>>>>>
>>>>>> work
>>>>>>>>
>>>>>>>>> on NTFS as of Vista.
>>>>>>>>>>
>>>>>>>>>> Braden / Michael - I think yours is a good idea as well.
>>>>>>>>>>
>>>>>>>>> Although, I
>>>>>
>>>>>> don't
>>>>>>>>>
>>>>>>>>>> think we should encourage people to edit files within
>>>>>>>>>>
>>>>>>>>> plugins/.
>>>
>>>> They
>>>>>
>>>>>> should
>>>>>>>>>
>>>>>>>>>> edit their plugins from install point. We should record the
>>>>>>>>>>
>>>>>>>>> install
>>>>>
>>>>>> path,
>>>>>>>>
>>>>>>>>> and maybe have prepare have a prepare --update-local-plugins.
>>>>>>>>>>
>>>>>>>>>> Any other ideas?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Fri, Sep 27, 2013 at 3:13 PM, Michael Sierra <
>>>>>>>>>>
>>>>>>>>> msierra@adobe.com>
>>>>>
>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>  Can you please file JIRAs on doc problems like this?
>>>>>>>>>>>
>>>>>>>>>> Existing
>>>>
>>>>> overview
>>>>>>>>>
>>>>>>>>>> doc says you can use the CLI to bootstrap & hand off to an
>>>>>>>>>>>
>>>>>>>>>> SDK &
>>>>
>>>>> supporting
>>>>>>>>>>
>>>>>>>>>>> platform command-line utilities.  I take your comment to
>>>>>>>>>>>
>>>>>>>>>> mean
>>>
>>>> doc
>>>>>
>>>>>> should
>>>>>>>>>
>>>>>>>>>> better stress that once you start working with platform
>>>>>>>>>>>
>>>>>>>>>> tools
>>>
>>>> downstream,
>>>>>>>>>
>>>>>>>>>> you can't go back to the CLI. Correct?
>>>>>>>>>>>
>>>>>>>>>>> --Mike Sierra
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ______________________________**__________
>>>>>>>>>>> From: Tyler Wilson [twilson@pulse-robotics.com]
>>>>>>>>>>> Sent: Thursday, September 26, 2013 8:19 PM
>>>>>>>>>>> To: dev@cordova.apache.org
>>>>>>>>>>> Subject: Re: Updating plugin code on prepare
>>>>>>>>>>>
>>>>>>>>>>> Re: IDEs: if it is the case that the CLI should not be used
>>>>>>>>>>>
>>>>>>>>>> along
>>>>>
>>>>>> with
>>>>>>>>
>>>>>>>>> an
>>>>>>>>>
>>>>>>>>>> IDE, perhaps the documentation - including Getting Started
>>>>>>>>>>>
>>>>>>>>>> Guides,
>>>>>
>>>>>> etc. -
>>>>>>>>>
>>>>>>>>>> ought to be much clearer about this. Perhaps a big warning
>>>>>>>>>>>
>>>>>>>>>> that
>>>>
>>>>> "Xcode
>>>>>>>>
>>>>>>>>> project files are created by the CLI, but they should not be
>>>>>>>>>>>
>>>>>>>>>> opened
>>>>>
>>>>>> and
>>>>>>>>
>>>>>>>>> used by Xcode. And you definitely should not edit code
>>>>>>>>>>>
>>>>>>>>>> within
>>>
>>>> the
>>>>>
>>>>>> IDE".
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> I just went to the main documentation site here -
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>  http://cordova.apache.org/**docs/en/3.0.0/guide_overview_**
>>> index.md.html#Overview-**anditappearsitonlymentionsthe<http://cordova.apache.org/docs/en/3.0.0/guide_overview_index.md.html#Overview-anditappearsitonlymentionsthe>new CLI interface. No mention of the
>>>
>>>> old bin/create method. Seems to me there may be
>>>>>>>>>>>
>>>>>>>>>> communication
>>>
>>>> problem
>>>>>>>
>>>>>>>> here.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Tyler
>>>>>>>>>>>
>>>>>>>>>>> On Sep 26, 2013, at 6:11 PM, Anis KADRI <
>>>>>>>>>>>
>>>>>>>>>> anis.kadri@gmail.com
>>>
>>>>
>>>>>  wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>  @purplecabbage: I have the same workflow but I think the
>>>>>>>>>>>>
>>>>>>>>>>> proposed
>>>>>
>>>>>> solution is a step in the right direction. It would allow
>>>>>>>>>>>>
>>>>>>>>>>> us
>>>
>>>> to
>>>>>
>>>>>> easily
>>>>>>>>>
>>>>>>>>>> develop platform plugins without having to delete
>>>>>>>>>>>>
>>>>>>>>>>> project/create
>>>>>
>>>>>> project/install plugin/uninstall plugin constantly. The
>>>>>>>>>>>>
>>>>>>>>>>> plugin
>>>>
>>>>> would
>>>>>>>>
>>>>>>>>> be packaged (plugin.xml) from day 1 and one can only focus
>>>>>>>>>>>>
>>>>>>>>>>> on
>>>>
>>>>> development.
>>>>>>>>>>>>
>>>>>>>>>>>> As far as IDEs, the answer is simple. You should not use
>>>>>>>>>>>>
>>>>>>>>>>> IDEs
>>>>
>>>>> and
>>>>>
>>>>>> cordova-cli at the same time. Until IDEs are aware of
>>>>>>>>>>>>
>>>>>>>>>>> cordova-cli
>>>>>
>>>>>> there is no point in creating projects with cordova-cli
>>>>>>>>>>>>
>>>>>>>>>>> because
>>>>>
>>>>>> everything gets blown on every build. I am not even sure
>>>>>>>>>>>>
>>>>>>>>>>> we
>>>
>>>> can
>>>>>
>>>>>> make
>>>>>>>>
>>>>>>>>> Xcode aware of cordova-cli. We've already talked about
>>>>>>>>>>>>
>>>>>>>>>>> this
>>>
>>>> prior
>>>>>
>>>>>> to
>>>>>>>>
>>>>>>>>> the 3.0 release and that is why we have the create scripts
>>>>>>>>>>>>
>>>>>>>>>>> and
>>>>
>>>>> plugman
>>>>>>>>>
>>>>>>>>>> approach. You should not be using cordova-cli either if
>>>>>>>>>>>>
>>>>>>>>>>> you're
>>>>
>>>>> doing
>>>>>>>>
>>>>>>>>> some custom native dev that can't be pluginized (changing
>>>>>>>>>>>>
>>>>>>>>>>> the
>>>>
>>>>> main
>>>>>>>
>>>>>>>> Activity.java or AppDelegate.m or whatever). If you're
>>>>>>>>>>>>
>>>>>>>>>>> using
>>>
>>>> cordova-cli just to create a project and then open an IDE
>>>>>>>>>>>>
>>>>>>>>>>> to
>>>
>>>> develop,
>>>>>>>>
>>>>>>>>> you're probably doing it wrong. You should be creating a
>>>>>>>>>>>>
>>>>>>>>>>> native
>>>>>
>>>>>> project and using plugman instead.
>>>>>>>>>>>>
>>>>>>>>>>>> On Thu, Sep 26, 2013 at 9:01 PM, Michal Mocny <
>>>>>>>>>>>>
>>>>>>>>>>> mmocny@chromium.org
>>>>>>>
>>>>>>>>
>>>>>>>>>  wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On Thu, Sep 26, 2013 at 1:39 PM, Jesse <
>>>>>>>>>>>>>
>>>>>>>>>>>> purplecabbage@gmail.com
>>>>>
>>>>>>
>>>>>>>>  wrote:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>  What does a watch mean?
>>>>>>>>>>>>>> - if I reboot, is it still watched?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>> No, this would start a process that lives until you
>>>>>>>>>>>>>
>>>>>>>>>>>> CTRL+C.
>>>
>>>>   You
>>>>>
>>>>>> could
>>>>>>>>>
>>>>>>>>>> have
>>>>>>>>>>>
>>>>>>>>>>>> it run it in the background, or set it to start of
>>>>>>>>>>>>>
>>>>>>>>>>>> startup,
>>>
>>>> but
>>>>>
>>>>>> that
>>>>>>>>
>>>>>>>>> would
>>>>>>>>>>>
>>>>>>>>>>>> be using local system tools, not part of the command
>>>>>>>>>>>>>
>>>>>>>>>>>> itself.
>>>>
>>>>>
>>>>>>>>>>>>> Ideally, "watch" should run "prepare" whenever you would
>>>>>>>>>>>>>
>>>>>>>>>>>> have
>>>>
>>>>> wanted
>>>>>>>>
>>>>>>>>> it
>>>>>>>>>>
>>>>>>>>>>> to.
>>>>>>>>>>>
>>>>>>>>>>>> Though obviously that cannot be perfect, it can be a
>>>>>>>>>>>>>
>>>>>>>>>>>> useful
>>>
>>>> tool
>>>>>
>>>>>> when
>>>>>>>>>
>>>>>>>>>> iterating.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> I think it would be best to consider separating
>>>>>>>>>>>>>>
>>>>>>>>>>>>> development
>>>>
>>>>> from
>>>>>>>
>>>>>>>> packaging
>>>>>>>>>>>
>>>>>>>>>>>> in your use-case for workflow.
>>>>>>>>>>>>>> If I am going to develop featureX as a plugin I would :
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 1. create a project for a single cordova platform, and
>>>>>>>>>>>>>>
>>>>>>>>>>>>> develop
>>>>>
>>>>>> the
>>>>>>>>
>>>>>>>>> feature
>>>>>>>>>>>
>>>>>>>>>>>> as a native piece, and a js piece.
>>>>>>>>>>>>>> 2. test thoroughly
>>>>>>>>>>>>>> 3. create a project for a second cordova platform, and
>>>>>>>>>>>>>>
>>>>>>>>>>>>> develop
>>>>>
>>>>>> the
>>>>>>>>
>>>>>>>>> native
>>>>>>>>>>>
>>>>>>>>>>>> bit, preserving the js from 1
>>>>>>>>>>>>>> 4. test thoroughly
>>>>>>>>>>>>>> 5. repeat steps 3+4 for any remaining platforms
>>>>>>>>>>>>>> 6. package featureX as a plugin by organizing relevant
>>>>>>>>>>>>>>
>>>>>>>>>>>>> bits
>>>>
>>>>> in
>>>>>
>>>>>> the
>>>>>>>>
>>>>>>>>> correct
>>>>>>>>>>>
>>>>>>>>>>>> folder structure, and adding a plugin.xml
>>>>>>>>>>>>>> 7. test each platform by installing with plugman
>>>>>>>>>>>>>> 8. publish
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>> As a plugin developer, that is not my workflow.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Typically for me its:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Write a sample app/manual test for some new feature that
>>>>>>>>>>>>>
>>>>>>>>>>>> isn't
>>>>>
>>>>>> implemented
>>>>>>>>>>>
>>>>>>>>>>>> yet.
>>>>>>>>>>>>> Create a new plugin Foo for iOS & Android, and stub the
>>>>>>>>>>>>>
>>>>>>>>>>>> implementation.
>>>>>>>>>>
>>>>>>>>>>> Implement feature A of plugin Foo for iOS, test, add it
>>>>>>>>>>>>>
>>>>>>>>>>>> for
>>>
>>>> Android,
>>>>>>>>
>>>>>>>>> test.
>>>>>>>>>>>
>>>>>>>>>>>> Implement feature B of plugin Foo for iOS, test, add it
>>>>>>>>>>>>>
>>>>>>>>>>>> for
>>>
>>>> Android,
>>>>>>>>
>>>>>>>>> test.
>>>>>>>>>>>
>>>>>>>>>>>> ...
>>>>>>>>>>>>>
>>>>>>>>>>>>> Usually the js implementation is shared, the auto tests
>>>>>>>>>>>>>
>>>>>>>>>>>> are
>>>
>>>> shared,
>>>>>>>>
>>>>>>>>> and
>>>>>>>>>>
>>>>>>>>>>> the
>>>>>>>>>>>
>>>>>>>>>>>> sample test app is shared.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Sure, I do platform specific stuff for testing and
>>>>>>>>>>>>>
>>>>>>>>>>>> implementation,
>>>>>>>
>>>>>>>> but I
>>>>>>>>>>
>>>>>>>>>>> certainly wouldn't say I do plugin development in
>>>>>>>>>>>>>
>>>>>>>>>>>> platform
>>>
>>>> isolation.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>> Also, right now we do not have a "plugin create" command,
>>>>>>>>>>>>>
>>>>>>>>>>>> and so
>>>>>
>>>>>> leaving
>>>>>>>>>>
>>>>>>>>>>> the "packaging" step for last doesn't add affect total
>>>>>>>>>>>>>
>>>>>>>>>>>> work.
>>>>
>>>>>   But
>>>>>>>
>>>>>>>> once
>>>>>>>>>
>>>>>>>>>> we
>>>>>>>>>>>
>>>>>>>>>>>> do have such a command, plugins could start packaged, and
>>>>>>>>>>>>>
>>>>>>>>>>>> adding
>>>>>
>>>>>> the
>>>>>>>>
>>>>>>>>> small
>>>>>>>>>>>
>>>>>>>>>>>> changes to plugin.xml as you need them is likely a good
>>>>>>>>>>>>>
>>>>>>>>>>>> way
>>>
>>>> to
>>>>>
>>>>>> go.
>>>>>>>
>>>>>>>>
>>>>>>>>>>>>> Finally, this workflow would get people out of the habit
>>>>>>>>>>>>>
>>>>>>>>>>>> of
>>>
>>>> making
>>>>>>>
>>>>>>>> changes
>>>>>>>>>>>
>>>>>>>>>>>> to the platform artifacts directly.  I'm not sure that
>>>>>>>>>>>>>
>>>>>>>>>>>> can
>>>
>>>> be
>>>>
>>>>> entirely
>>>>>>>>>
>>>>>>>>>> avoided in all cases, but why shouldn't we work towards
>>>>>>>>>>>>>
>>>>>>>>>>>> making
>>>>>
>>>>>> that
>>>>>>>>
>>>>>>>>> easier?
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>  We seem to have this notion come up repeatedly that our
>>>>>>>>>>>>>>
>>>>>>>>>>>>> users +
>>>>>
>>>>>> plugin
>>>>>>>>>>
>>>>>>>>>>> developers are working on multiple platforms at the same
>>>>>>>>>>>>>>
>>>>>>>>>>>>> time,
>>>>>
>>>>>> which
>>>>>>>>>
>>>>>>>>>> I
>>>>>>>>>>
>>>>>>>>>>> think is entirely false.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>> Since we differ in opinion, how can we put this to the
>>>>>>>>>>>>>
>>>>>>>>>>>> test?
>>>>
>>>>>
>>>>>>>>>>>>> Also, we specifically make sure all our features address
>>>>>>>>>>>>>
>>>>>>>>>>>> the
>>>>
>>>>> needs
>>>>>>>
>>>>>>>> of
>>>>>>>>>
>>>>>>>>>> those
>>>>>>>>>>>
>>>>>>>>>>>> doing single platform development, so in a world of 3.0+
>>>>>>>>>>>>>
>>>>>>>>>>>> cli, I
>>>>>
>>>>>> really
>>>>>>>>>
>>>>>>>>>> don't see how we can not do the same to address the needs
>>>>>>>>>>>>>
>>>>>>>>>>>> of
>>>>
>>>>> those
>>>>>>>
>>>>>>>> who
>>>>>>>>>
>>>>>>>>>> do
>>>>>>>>>>>
>>>>>>>>>>>> do multi-platform development, especially when we have a
>>>>>>>>>>>>>
>>>>>>>>>>>> good
>>>>
>>>>> proposal
>>>>>>>>>
>>>>>>>>>> of
>>>>>>>>>>>
>>>>>>>>>>>> how to do so and someone willing to do it.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>  I also think we're trying to help the wrong people; If I
>>>>>>>>>>>>>>
>>>>>>>>>>>>> am
>>>>
>>>>> a
>>>>>
>>>>>> developer who
>>>>>>>>>>>
>>>>>>>>>>>> is working on multiple platforms at once, and I have a
>>>>>>>>>>>>>>
>>>>>>>>>>>>> bunch of
>>>>>
>>>>>> devices
>>>>>>>>>>
>>>>>>>>>>> attached, I probably also have the skills to set up my
>>>>>>>>>>>>>>
>>>>>>>>>>>>> own
>>>
>>>> grunt
>>>>>>>
>>>>>>>> continuous
>>>>>>>>>>>
>>>>>>>>>>>> integration system. Setting up tooling for potential
>>>>>>>>>>>>>>
>>>>>>>>>>>>> plugin
>>>>
>>>>> developers
>>>>>>>>>>
>>>>>>>>>>> is
>>>>>>>>>>>
>>>>>>>>>>>> the wrong approach, imho. We should actually just go and
>>>>>>>>>>>>>>
>>>>>>>>>>>>> implement
>>>>>>>>
>>>>>>>>> some new
>>>>>>>>>>>
>>>>>>>>>>>> plugin and evaluate the process instead of creating and
>>>>>>>>>>>>>>
>>>>>>>>>>>>> imposing
>>>>>>>
>>>>>>>> a
>>>>>>>>
>>>>>>>>> specific
>>>>>>>>>>>
>>>>>>>>>>>> workflow.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>> The first part of this argument has some merit, I agree.
>>>>>>>>>>>>>
>>>>>>>>>>>>   We
>>>>
>>>>> the
>>>>>
>>>>>> power-users have found ways to address our problems.
>>>>>>>>>>>>>
>>>>>>>>>>>>   However, I
>>>>>
>>>>>> think
>>>>>>>>>
>>>>>>>>>> that
>>>>>>>>>>>
>>>>>>>>>>>> with this change it means that even the end user can make
>>>>>>>>>>>>>
>>>>>>>>>>>> changes
>>>>>>>
>>>>>>>> to
>>>>>>>>
>>>>>>>>> plugin
>>>>>>>>>>>
>>>>>>>>>>>> folder as they find bugs/etc, and expect to see the
>>>>>>>>>>>>>
>>>>>>>>>>>> change
>>>
>>>> reflected
>>>>>>>>
>>>>>>>>> after
>>>>>>>>>>>
>>>>>>>>>>>> running prepare.  This is principle of least surprise,
>>>>>>>>>>>>>
>>>>>>>>>>>> and
>>>
>>>> just
>>>>
>>>>

Re: Updating plugin code on prepare

[Michael Gauthier <mi...@silverorange.com>]

Did this feature land in 3.1.0 or is it targeted for 3.2.0?

On 2013-10-03 11:30, Michal Mocny wrote:
> Yeah Braden we've diverged sorry, lets focus.
>
> Big +1 for your proposal to make prepare step do what users expect.
>
> -Michal
>
>
> On Thu, Oct 3, 2013 at 10:20 AM, Braden Shepherdson <br...@chromium.org>wrote:
>
>> I agree that the syncing solutions are too complex and confusing.
>>
>> I return, then, to my original proposal all those emails ago: updating the
>> native plugin files in platforms/foo when you prepare, to make life easier
>> for plugin developers. When coupled with the present cordova plugin add
>> --link, and future cordova watch, I think this makes the plugin developer
>> flow pretty good, and without making it too magical or harder to
>> understand. I think it simplifies prepare: on prepare, your native projects
>> are updated to reflect the state of plugins/ and www/. Right now, only
>> www/, <asset>s and <js-module>s get updated, but not native code.
>>
>> As to Xcode and symlinks and all the rest of the borderline thread
>> hijacking, I think that regardless of what editor you use, you have to be
>> editing the right file. Xcode and Eclipse make this harder than it needs to
>> be, but our job is not to make them suck less.
>>
>> Braden
>>
>>
>> On Sun, Sep 29, 2013 at 1:43 PM, Carlos Santana <csantana23@gmail.com
>>> wrote:
>>
>>> +1 Anis
>>> corodova-cli/plugman should be building block components to higher level
>>> Tools/IDE.
>>>
>>> That we can do better sure, lets provide a few examples using blog pots
>> and
>>> maybe videos tutorials vs. trying to support every use case with code.
>>>
>>> A watch function could be as simple as using "grunt-contrib-watch" to a
>>> more complicated environment like "rsync/Eclipse"
>>>
>>> I agree lets put emphasis on documenting use cases and the correct
>>> approach.
>>> When to get the best out of using prepare,  merges, and hooks
>>>
>>> All I said applies when you have the "Web Developer" hat.
>>>
>>> For people that have the "Native Plugin Developer" hat then we can do
>>> things first for cordova-contributors than others can choose to use on
>>> their own risk since it could be changing too fast and maybe too narrow
>> use
>>> case.
>>>
>>> --Carlos
>>>
>>> --Carlos
>>>
>>>
>>>
>>> On Sun, Sep 29, 2013 at 9:18 AM, Anis KADRI <an...@gmail.com>
>> wrote:
>>>
>>>> I gave some thought to this problem and I think we should just leave
>>>> everything as is. Here's my reasoning:
>>>>
>>>> - Most web developers use a text editor (vim, sublime text, text mate,
>>>> notepad++, ....) to edit their HTML/CSS/Javascript. I've never seen
>>>> anyone use a fully fledged IDE to edit web assets. It would be like
>>>> using Microsoft Word to edit a simple .TXT or .MD file
>>>> - Other developers, people who write Java or Objective C, etc.. use
>>>> Xcode, Eclipse, IntelliJ, ...and I think these people are not good
>>>> candidates for cordova-cli.
>>>>
>>>> The original PhoneGap promise (now Apache Cordova) was to make it easy
>>>> for Web Developers to write Mobile Apps using web technologies and I
>>>> believe that promise is fulfilled with cordova-cli. You have a folder
>>>> where you drop in your web assets and you can build/deploy to a device
>>>> or simulate.
>>>>
>>>> If people want to use an IDE, then they should be creating native
>>>> projects with our create scripts and use plugman to manage their
>>>> plugins.
>>>>
>>>> Our documentation should point our users to the right approach
>>>> depending on the use case. For example:
>>>>
>>>> - Building for only one platform ? Building a hybrid app ? Want to use
>>>> an IDE (Eclipse, Xcode) ? You should use the create scripts and
>>>> plugman to manage plugins
>>>>
>>>> - Building a cross-platform app ? Like managing your project from the
>>>> command-line ? Want to use your favo(u)rite text editor ? Use
>>>> cordova-cli
>>>>
>>>> These double symlinking, backsyncing solutions will be a source of
>>>> confusion and issues in my humble opinion. I've said it before but
>>>> sometimes by trying to please everyone you end up pleasing no one.
>>>>
>>>> my .02c
>>>>
>>>> -a
>>>>
>>>> On Fri, Sep 27, 2013 at 8:20 PM, Michal Mocny <mm...@chromium.org>
>>> wrote:
>>>>> On Fri, Sep 27, 2013 at 2:10 PM, Andrew Grieve <agrieve@chromium.org
>>>
>>>> wrote:
>>>>>
>>>>>> Just tried some symlinks in Xcode 5:
>>>>>> - Copying assets work (due to our custom build step)
>>>>>> - Building works (compiler follows links just fine)
>>>>>> - Editing a fail (big fail. Files open but changes cannot be saved.)
>>>>>>
>>>>>
>>>>> Hmm, changes via xcode to symlinks fail, you mean?  That would be
>> hard
>>> to
>>>>> fix, but perhaps at least its feedback to the user not to make direct
>>>> edits
>>>>> there, when using CLI workflow ;) so may still be a valid change to
>>> make.
>>>>>
>>>>>
>>>>>>
>>>>>> For Xcode though, it is an option to change our installation step to
>>>> have
>>>>>> Xcode reference the native files within plugins/ rather than within
>>>>>> platforms/.
>>>>>>
>>>>>>
>>>>>> Symlinks in Eclipse:
>>>>>> - Copying assets works out-of-the-box
>>>>>> - Build works fine
>>>>>> - Editing seems to work fine (edits saved to symlinked location).
>>>>>>
>>>>>>
>>>>>>
>>>>>> Still though, maybe the best solution would be a combination of the
>>> two?
>>>>>> Have prepare know when an remove+add is necessary?
>>>>>>
>>>>>
>>>>> Yes, I think thats what we are suggesting.
>>>>>
>>>>> The original email mentioned prepare knowing when remove+add are
>>>> necessary,
>>>>> which I think is already settled as a good idea.  Not sure if you had
>>>> more
>>>>> to add about how prepare should know when to do this (currently, its
>>> only
>>>>> on plugin.xml changes).
>>>>> The more recent suggestions about making links between
>> platform&plugins
>>>>> were additional requests to address the rest of the workflow issues
>>> (ie,
>>>>> most users prefer to edit inside platforms/ folder because of IDE
>>>>> integration etc).
>>>>>
>>>>> Were you implying anything different here?
>>>>>
>>>>>
>>>>>>
>>>>>> On Fri, Sep 27, 2013 at 6:25 PM, Michal Mocny <mm...@chromium.org>
>>>> wrote:
>>>>>>
>>>>>>> Have we not previously solved the symlink problem in xcode with a
>>>> build
>>>>>>> hook, or was that for prepare step?
>>>>>>>
>>>>>>> The --link concept doesn't do anything for that platforms ->
>> plugins
>>>> file
>>>>>>> mapping.  Its useful for mapping plugins/ to local source, but it
>>>> doesn't
>>>>>>> help with the problem Tyler mentions, right?
>>>>>>>
>>>>>>> -Michal
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Sep 27, 2013 at 1:20 PM, Braden Shepherdson <
>>>> braden@chromium.org
>>>>>>>> wrote:
>>>>>>>
>>>>>>>> Symlinks in platforms/ are a problem because Xcode doesn't
>> honour
>>>> them,
>>>>>>> at
>>>>>>>> least last time we tried it.
>>>>>>>>
>>>>>>>> I'm much more enthused about the --link concept than any
>> syncing,
>>>>>> though.
>>>>>>>> Also if someone wants to sync, they can already use rsync to do
>> it
>>>>>>>> manually.
>>>>>>>>
>>>>>>>> Braden
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Sep 27, 2013 at 11:45 AM, Andrew Grieve <
>>>> agrieve@chromium.org
>>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> I think it'd be good to enumerate our options for workflow
>>> before
>>>> we
>>>>>>>>> decided on which to implement (or maybe choose multiple).
>>>>>>>>>
>>>>>>>>> Tyler's idea about a sync command seems like it would be
>> handy.
>>>> Edit
>>>>>>> your
>>>>>>>>> plugin files within platforms/, and then run `cordova plugin
>>>>>>> copychanges
>>>>>>>>> org.my.plugin` to do a reverse copy of the source files back
>> to
>>>> the
>>>>>>>> install
>>>>>>>>> source location of the plugin. Big caveat though is that you
>> run
>>>> the
>>>>>>> risk
>>>>>>>>> of prepare clobbering your changes. I think that's too killer
>> a
>>>> risk.
>>>>>>>>>
>>>>>>>>> Another thought is that we could use symlinks when running
>>>> prepare.
>>>>>>> Have
>>>>>>>>> files within platforms/ symlink to files within plugins/, then
>>>>>> symlink
>>>>>>>>> again back to their original sources. Would this work with
>>>> editors in
>>>>>>>>> practice? I don't know, but worth exploring. Wikipedia says
>>>> symlinks
>>>>>>> work
>>>>>>>>> on NTFS as of Vista.
>>>>>>>>>
>>>>>>>>> Braden / Michael - I think yours is a good idea as well.
>>>> Although, I
>>>>>>>> don't
>>>>>>>>> think we should encourage people to edit files within
>> plugins/.
>>>> They
>>>>>>>> should
>>>>>>>>> edit their plugins from install point. We should record the
>>>> install
>>>>>>> path,
>>>>>>>>> and maybe have prepare have a prepare --update-local-plugins.
>>>>>>>>>
>>>>>>>>> Any other ideas?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Fri, Sep 27, 2013 at 3:13 PM, Michael Sierra <
>>>> msierra@adobe.com>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Can you please file JIRAs on doc problems like this?
>>> Existing
>>>>>>>> overview
>>>>>>>>>> doc says you can use the CLI to bootstrap & hand off to an
>>> SDK &
>>>>>>>>> supporting
>>>>>>>>>> platform command-line utilities.  I take your comment to
>> mean
>>>> doc
>>>>>>>> should
>>>>>>>>>> better stress that once you start working with platform
>> tools
>>>>>>>> downstream,
>>>>>>>>>> you can't go back to the CLI. Correct?
>>>>>>>>>>
>>>>>>>>>> --Mike Sierra
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ________________________________________
>>>>>>>>>> From: Tyler Wilson [twilson@pulse-robotics.com]
>>>>>>>>>> Sent: Thursday, September 26, 2013 8:19 PM
>>>>>>>>>> To: dev@cordova.apache.org
>>>>>>>>>> Subject: Re: Updating plugin code on prepare
>>>>>>>>>>
>>>>>>>>>> Re: IDEs: if it is the case that the CLI should not be used
>>>> along
>>>>>>> with
>>>>>>>> an
>>>>>>>>>> IDE, perhaps the documentation - including Getting Started
>>>> Guides,
>>>>>>>> etc. -
>>>>>>>>>> ought to be much clearer about this. Perhaps a big warning
>>> that
>>>>>>> "Xcode
>>>>>>>>>> project files are created by the CLI, but they should not be
>>>> opened
>>>>>>> and
>>>>>>>>>> used by Xcode. And you definitely should not edit code
>> within
>>>> the
>>>>>>> IDE".
>>>>>>>>>>
>>>>>>>>>> I just went to the main documentation site here -
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>
>> http://cordova.apache.org/docs/en/3.0.0/guide_overview_index.md.html#Overview-anditappearsitonlymentionsthe new CLI interface. No mention of the
>>>>>>>>>> old bin/create method. Seems to me there may be
>> communication
>>>>>> problem
>>>>>>>>> here.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Tyler
>>>>>>>>>>
>>>>>>>>>> On Sep 26, 2013, at 6:11 PM, Anis KADRI <
>> anis.kadri@gmail.com
>>>>
>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> @purplecabbage: I have the same workflow but I think the
>>>> proposed
>>>>>>>>>>> solution is a step in the right direction. It would allow
>> us
>>>> to
>>>>>>>> easily
>>>>>>>>>>> develop platform plugins without having to delete
>>>> project/create
>>>>>>>>>>> project/install plugin/uninstall plugin constantly. The
>>> plugin
>>>>>>> would
>>>>>>>>>>> be packaged (plugin.xml) from day 1 and one can only focus
>>> on
>>>>>>>>>>> development.
>>>>>>>>>>>
>>>>>>>>>>> As far as IDEs, the answer is simple. You should not use
>>> IDEs
>>>> and
>>>>>>>>>>> cordova-cli at the same time. Until IDEs are aware of
>>>> cordova-cli
>>>>>>>>>>> there is no point in creating projects with cordova-cli
>>>> because
>>>>>>>>>>> everything gets blown on every build. I am not even sure
>> we
>>>> can
>>>>>>> make
>>>>>>>>>>> Xcode aware of cordova-cli. We've already talked about
>> this
>>>> prior
>>>>>>> to
>>>>>>>>>>> the 3.0 release and that is why we have the create scripts
>>> and
>>>>>>>> plugman
>>>>>>>>>>> approach. You should not be using cordova-cli either if
>>> you're
>>>>>>> doing
>>>>>>>>>>> some custom native dev that can't be pluginized (changing
>>> the
>>>>>> main
>>>>>>>>>>> Activity.java or AppDelegate.m or whatever). If you're
>> using
>>>>>>>>>>> cordova-cli just to create a project and then open an IDE
>> to
>>>>>>> develop,
>>>>>>>>>>> you're probably doing it wrong. You should be creating a
>>>> native
>>>>>>>>>>> project and using plugman instead.
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Sep 26, 2013 at 9:01 PM, Michal Mocny <
>>>>>> mmocny@chromium.org
>>>>>>>>
>>>>>>>>>> wrote:
>>>>>>>>>>>> On Thu, Sep 26, 2013 at 1:39 PM, Jesse <
>>>> purplecabbage@gmail.com
>>>>>>>
>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> What does a watch mean?
>>>>>>>>>>>>> - if I reboot, is it still watched?
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> No, this would start a process that lives until you
>> CTRL+C.
>>>>   You
>>>>>>>> could
>>>>>>>>>> have
>>>>>>>>>>>> it run it in the background, or set it to start of
>> startup,
>>>> but
>>>>>>> that
>>>>>>>>>> would
>>>>>>>>>>>> be using local system tools, not part of the command
>>> itself.
>>>>>>>>>>>>
>>>>>>>>>>>> Ideally, "watch" should run "prepare" whenever you would
>>> have
>>>>>>> wanted
>>>>>>>>> it
>>>>>>>>>> to.
>>>>>>>>>>>> Though obviously that cannot be perfect, it can be a
>> useful
>>>> tool
>>>>>>>> when
>>>>>>>>>>>> iterating.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I think it would be best to consider separating
>>> development
>>>>>> from
>>>>>>>>>> packaging
>>>>>>>>>>>>> in your use-case for workflow.
>>>>>>>>>>>>> If I am going to develop featureX as a plugin I would :
>>>>>>>>>>>>>
>>>>>>>>>>>>> 1. create a project for a single cordova platform, and
>>>> develop
>>>>>>> the
>>>>>>>>>> feature
>>>>>>>>>>>>> as a native piece, and a js piece.
>>>>>>>>>>>>> 2. test thoroughly
>>>>>>>>>>>>> 3. create a project for a second cordova platform, and
>>>> develop
>>>>>>> the
>>>>>>>>>> native
>>>>>>>>>>>>> bit, preserving the js from 1
>>>>>>>>>>>>> 4. test thoroughly
>>>>>>>>>>>>> 5. repeat steps 3+4 for any remaining platforms
>>>>>>>>>>>>> 6. package featureX as a plugin by organizing relevant
>>> bits
>>>> in
>>>>>>> the
>>>>>>>>>> correct
>>>>>>>>>>>>> folder structure, and adding a plugin.xml
>>>>>>>>>>>>> 7. test each platform by installing with plugman
>>>>>>>>>>>>> 8. publish
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> As a plugin developer, that is not my workflow.
>>>>>>>>>>>>
>>>>>>>>>>>> Typically for me its:
>>>>>>>>>>>>
>>>>>>>>>>>> Write a sample app/manual test for some new feature that
>>>> isn't
>>>>>>>>>> implemented
>>>>>>>>>>>> yet.
>>>>>>>>>>>> Create a new plugin Foo for iOS & Android, and stub the
>>>>>>>>> implementation.
>>>>>>>>>>>> Implement feature A of plugin Foo for iOS, test, add it
>> for
>>>>>>> Android,
>>>>>>>>>> test.
>>>>>>>>>>>> Implement feature B of plugin Foo for iOS, test, add it
>> for
>>>>>>> Android,
>>>>>>>>>> test.
>>>>>>>>>>>> ...
>>>>>>>>>>>>
>>>>>>>>>>>> Usually the js implementation is shared, the auto tests
>> are
>>>>>>> shared,
>>>>>>>>> and
>>>>>>>>>> the
>>>>>>>>>>>> sample test app is shared.
>>>>>>>>>>>>
>>>>>>>>>>>> Sure, I do platform specific stuff for testing and
>>>>>> implementation,
>>>>>>>>> but I
>>>>>>>>>>>> certainly wouldn't say I do plugin development in
>> platform
>>>>>>>> isolation.
>>>>>>>>>>>>
>>>>>>>>>>>> Also, right now we do not have a "plugin create" command,
>>>> and so
>>>>>>>>> leaving
>>>>>>>>>>>> the "packaging" step for last doesn't add affect total
>>> work.
>>>>>>   But
>>>>>>>> once
>>>>>>>>>> we
>>>>>>>>>>>> do have such a command, plugins could start packaged, and
>>>> adding
>>>>>>> the
>>>>>>>>>> small
>>>>>>>>>>>> changes to plugin.xml as you need them is likely a good
>> way
>>>> to
>>>>>> go.
>>>>>>>>>>>>
>>>>>>>>>>>> Finally, this workflow would get people out of the habit
>> of
>>>>>> making
>>>>>>>>>> changes
>>>>>>>>>>>> to the platform artifacts directly.  I'm not sure that
>> can
>>> be
>>>>>>>> entirely
>>>>>>>>>>>> avoided in all cases, but why shouldn't we work towards
>>>> making
>>>>>>> that
>>>>>>>>>> easier?
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> We seem to have this notion come up repeatedly that our
>>>> users +
>>>>>>>>> plugin
>>>>>>>>>>>>> developers are working on multiple platforms at the same
>>>> time,
>>>>>>>> which
>>>>>>>>> I
>>>>>>>>>>>>> think is entirely false.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Since we differ in opinion, how can we put this to the
>>> test?
>>>>>>>>>>>>
>>>>>>>>>>>> Also, we specifically make sure all our features address
>>> the
>>>>>> needs
>>>>>>>> of
>>>>>>>>>> those
>>>>>>>>>>>> doing single platform development, so in a world of 3.0+
>>>> cli, I
>>>>>>>> really
>>>>>>>>>>>> don't see how we can not do the same to address the needs
>>> of
>>>>>> those
>>>>>>>> who
>>>>>>>>>> do
>>>>>>>>>>>> do multi-platform development, especially when we have a
>>> good
>>>>>>>> proposal
>>>>>>>>>> of
>>>>>>>>>>>> how to do so and someone willing to do it.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> I also think we're trying to help the wrong people; If I
>>> am
>>>> a
>>>>>>>>>> developer who
>>>>>>>>>>>>> is working on multiple platforms at once, and I have a
>>>> bunch of
>>>>>>>>> devices
>>>>>>>>>>>>> attached, I probably also have the skills to set up my
>> own
>>>>>> grunt
>>>>>>>>>> continuous
>>>>>>>>>>>>> integration system. Setting up tooling for potential
>>> plugin
>>>>>>>>> developers
>>>>>>>>>> is
>>>>>>>>>>>>> the wrong approach, imho. We should actually just go and
>>>>>>> implement
>>>>>>>>>> some new
>>>>>>>>>>>>> plugin and evaluate the process instead of creating and
>>>>>> imposing
>>>>>>> a
>>>>>>>>>> specific
>>>>>>>>>>>>> workflow.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> The first part of this argument has some merit, I agree.
>>>   We
>>>> the
>>>>>>>>>>>> power-users have found ways to address our problems.
>>>>   However, I
>>>>>>>> think
>>>>>>>>>> that
>>>>>>>>>>>> with this change it means that even the end user can make
>>>>>> changes
>>>>>>> to
>>>>>>>>>> plugin
>>>>>>>>>>>> folder as they find bugs/etc, and expect to see the
>> change
>>>>>>> reflected
>>>>>>>>>> after
>>>>>>>>>>>> running prepare.  This is principle of least surprise,
>> and
>>>> just
>>>>>>> good
>>>>>>>>>> design.
>>>>>>>>>>>>
>>>>>>>>>>>> I also don't think we are imposing any specific workflow
>>>> here,
>>>>>>> just
>>>>>>>>>>>> enabling a new one.  Personally I think that its quite
>>>>>> surprising
>>>>>>>> and
>>>>>>>>>>>> embarrassing that we haven't enabled this workflow since
>>> 3.0.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> @purplecabbage
>>>>>>>>>>>>> risingj.com
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Thu, Sep 26, 2013 at 10:09 AM, Brian LeRoux <
>>> b@brian.io>
>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> I love the idea of a watch command.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Thu, Sep 26, 2013 at 4:48 PM, Anis KADRI <
>>>>>>> anis.kadri@gmail.com
>>>>>>>>>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Forgot about the existence of --link for a second. I
>>> think
>>>>>> this
>>>>>>>> is
>>>>>>>>> a
>>>>>>>>>>>>>>> good solution (not temporary). watch can be an
>>>> enhancement to
>>>>>>>> this
>>>>>>>>>>>>>>> solution. This might get people like Joe Bowser and
>>> other
>>>>>>> people
>>>>>>>>> who
>>>>>>>>>>>>>>> do native dev to give cordova-cli a try (only maybe
>>>> though).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Thu, Sep 26, 2013 at 4:25 PM, Braden Shepherdson <
>>>>>>>>>>>>> braden@chromium.org
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>> If the proposal above is temporary, what's permanent?
>>>>>> cordova
>>>>>>>>> watch?
>>>>>>>>>>>>> I
>>>>>>>>>>>>>>> want
>>>>>>>>>>>>>>>> to make sure we're on the same page.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Braden
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Thu, Sep 26, 2013 at 6:08 AM, Anis KADRI <
>>>>>>>> anis.kadri@gmail.com
>>>>>>>>>>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> No I didn't mean implement `plugman --watch`. I
>> don't
>>>> think
>>>>>>>>> plugman
>>>>>>>>>>>>>>>>> needs a `watch` command.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I was indeed talking about `cordova watch` which
>>> should
>>>>>> watch
>>>>>>>> for
>>>>>>>>>>>>>>>>> changes in plugins/ (and maybe in merges/ and www/
>> as
>>>> well)
>>>>>>> and
>>>>>>>>>>>>> update
>>>>>>>>>>>>>>>>> the platform projects (prepare?) on every change.  I
>>> am
>>>>>> happy
>>>>>>>> to
>>>>>>>>>>>>> know
>>>>>>>>>>>>>>>>> that it's on the wish list.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> As far as the original proposal, I believe it is a
>>>> descent
>>>>>>>>>> temporary
>>>>>>>>>>>>>>>>> solution for plugin developers who want to use
>>>> cordova-cli.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Wed, Sep 25, 2013 at 7:17 PM, Michal Mocny <
>>>>>>>>> mmocny@chromium.org
>>>>>>>>>>>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>> Braden, thats has been on the wish list (cordova
>>>> watch),
>>>>>>> but I
>>>>>>>>>>>>>> suspect
>>>>>>>>>>>>>>>>> Anis
>>>>>>>>>>>>>>>>>> was suggesting something different with plugman
>>>> --watch,
>>>>>> to
>>>>>>> do
>>>>>>>>>>>>>>>>> specifically
>>>>>>>>>>>>>>>>>> with plugin development.  Am I right, Anis?  How
>> does
>>>> your
>>>>>>>> idea
>>>>>>>>>>>>>>> compare
>>>>>>>>>>>>>>>>>> with using --link with cordova watch?  Would
>> plugman
>>>>>> --watch
>>>>>>>> be
>>>>>>>>>>>>>> useful
>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>> non cli projects?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> -Michal
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Wed, Sep 25, 2013 at 10:31 AM, Braden
>> Shepherdson
>>> <
>>>>>>>>>>>>>>>>> braden@chromium.org>wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> We've had a vague feature planned for a while now
>> to
>>>> do a
>>>>>>>>> cordova
>>>>>>>>>>>>>>>>> watch. It
>>>>>>>>>>>>>>>>>>> would watch your plugins/, www/, and merges/* for
>>> any
>>>>>>>> changes.
>>>>>>>>> If
>>>>>>>>>>>>>> any
>>>>>>>>>>>>>>>>>>> changes are detected, it would re-run cordova
>>>> prepare, so
>>>>>>>> that
>>>>>>>>>>>>> your
>>>>>>>>>>>>>>>>> native
>>>>>>>>>>>>>>>>>>> projects are always up-to-date.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I'm open to checking (hashes?) which files have
>>>> changed
>>>>>> and
>>>>>>>>> which
>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>> not,
>>>>>>>>>>>>>>>>>>> but hashing them all is touching them all anyway,
>>> and
>>>> it
>>>>>>>> might
>>>>>>>>> be
>>>>>>>>>>>>>>> faster
>>>>>>>>>>>>>>>>>>> for small files to just copy them instead of
>>> checking
>>>>>>> first.
>>>>>>>>>>>>> We'll
>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>> try it and see; for v1 I'm going with the simple
>>>> option
>>>>>> of
>>>>>>>>>>>>> copying
>>>>>>>>>>>>>>>>>>> everything.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Braden
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Wed, Sep 25, 2013 at 9:44 AM, Michal Mocny <
>>>>>>>>>>>>> mmocny@chromium.org
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> The idea for plugin dev outside of plugins/
>> folder
>>>> was
>>>>>> to
>>>>>>>> use
>>>>>>>>>>>>>>> "plugin
>>>>>>>>>>>>>>>>> add
>>>>>>>>>>>>>>>>>>>> --link".  Matter of fact, braden suggested that
>>>> "plugin
>>>>>>>>> create"
>>>>>>>>>>>>>>> should
>>>>>>>>>>>>>>>>>>>> default to --link-ing to some external location
>> so
>>>> that
>>>>>>> you
>>>>>>>>>>>>> don't
>>>>>>>>>>>>>>> risk
>>>>>>>>>>>>>>>>>>>> deleting your only copy inside plugins/.  (I
>>>> personally
>>>>>>>> don't
>>>>>>>>>>>>>> think
>>>>>>>>>>>>>>>>>>> thats a
>>>>>>>>>>>>>>>>>>>> necessary concern, but I think its a conversation
>>> for
>>>>>>>> later).
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I'm not even sure what a 'watch' would do, just
>>>>>> uninstall
>>>>>>> &
>>>>>>>>>>>>>> install
>>>>>>>>>>>>>>>>> each
>>>>>>>>>>>>>>>>>>>> time the plugin changes?  I think that ends up
>>> being
>>>>>> just
>>>>>>>>>>>>>> slightly
>>>>>>>>>>>>>>>>> worse
>>>>>>>>>>>>>>>>>>>> than the current proposal if you factor in that
>> we
>>>>>> already
>>>>>>>> do
>>>>>>>>>>>>>>> support
>>>>>>>>>>>>>>>>>>>> --link (except without the above change its been
>>>>>> useless).
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> However, we may still want some form of 'watch'
>>>> command
>>>>>>> for
>>>>>>>>>>>>> devs
>>>>>>>>>>>>>>> using
>>>>>>>>>>>>>>>>>>>> plugman directly.  I had assumed that those devs
>>> just
>>>>>> edit
>>>>>>>> in
>>>>>>>>>>>>>>> place,
>>>>>>>>>>>>>>>>>>> since
>>>>>>>>>>>>>>>>>>>> they don't use a prepare step anyway.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> -Michal
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On Wed, Sep 25, 2013 at 7:50 AM, Anis KADRI <
>>>>>>>>>>>>>> anis.kadri@gmail.com>
>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> If we're talking about developing plugins inside
>>> the
>>>>>>>>>>>>>>>>>>>>> plugins/org.myplugin.id folder than I think
>> it's
>>> a
>>>>>> great
>>>>>>>>>>>>>>> workflow
>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>> I would just hide the cached version of
>> plugin.xml
>>>>>> inside
>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>> plugins/org.myplugin.id folder.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> However, if you're developing a plugin outside
>> of
>>> a
>>>>>>> cordova
>>>>>>>>>>>>> CLI
>>>>>>>>>>>>>>>>>>>>> project, I think a `watch` (and add --watch)
>>>> command is
>>>>>>>> more
>>>>>>>>>>>>>>>>>>>>> appropriate. One of the reasons you would
>> develop
>>> a
>>>>>>> plugin
>>>>>>>>>>>>>>> outside
>>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>>>>> a cordova CLI project is for easier version
>>> control
>>>>>> (each
>>>>>>>>>>>>>> plugin
>>>>>>>>>>>>>>>>> would
>>>>>>>>>>>>>>>>>>>>> have its own repository). The other cool thing
>>> about
>>>>>>>> `watch`
>>>>>>>>>>>>> is
>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>> it would copy the files that have actually
>> changed
>>>> and
>>>>>>> not
>>>>>>>>>>>>>>>>> everything
>>>>>>>>>>>>>>>>>>>>> (some plugins have a LOT of files [1]).
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> [1]
>>>>>> https://github.com/phonegap/phonegap-facebook-plugin
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On Wed, Sep 25, 2013 at 3:30 AM, James Jong <
>>>>>>>>>>>>>>> wjamesjong@gmail.com>
>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>> +1 This is a cleaner workflow and should reduce
>>>> some
>>>>>>>>>>>>>> confusion.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> -James Jong
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On Sep 24, 2013, at 3:09 PM, Michal Mocny <
>>>>>>>>>>>>>> mmocny@chromium.org
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Just to add, the reason for the "if" statement
>>> in
>>>>>> step
>>>>>>>> (2)
>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>>>> uninstall & reinstall take a lot longer than
>>> just
>>>>>>> moving
>>>>>>>> a
>>>>>>>>>>>>>> few
>>>>>>>>>>>>>>>>>>> files,
>>>>>>>>>>>>>>>>>>>>> which
>>>>>>>>>>>>>>>>>>>>>>> is the 99.9% case for most end users who
>> aren't
>>>>>> making
>>>>>>>>>>>>>>>>> modifications
>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>> plugins.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> This way, we only do the heavy lifting if your
>>>> plugin
>>>>>>>>>>>>>>> structure
>>>>>>>>>>>>>>>>>>>> actually
>>>>>>>>>>>>>>>>>>>>>>> changed.  Doing it automatically means we no
>>>> longer
>>>>>>> have
>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>> advise
>>>>>>>>>>>>>>>>>>>> users
>>>>>>>>>>>>>>>>>>>>>>> that making edits inside plugin/ folder is
>>>> useless.
>>>>>>>   Now
>>>>>>>>>>>>> we
>>>>>>>>>>>>>>> just
>>>>>>>>>>>>>>>>>>>> advise
>>>>>>>>>>>>>>>>>>>>>>> them to run "prepare" after making changes to
>>>> either
>>>>>>> www/
>>>>>>>>>>>>> or
>>>>>>>>>>>>>>>>>>> plugins/.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> This key insight was Braden's idea and I think
>>> its
>>>>>> just
>>>>>>>> an
>>>>>>>>>>>>>>>>> awesome
>>>>>>>>>>>>>>>>>>>>> change
>>>>>>>>>>>>>>>>>>>>>>> for workflow.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> -Michal
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On Tue, Sep 24, 2013 at 2:58 PM, Braden
>>>> Shepherdson <
>>>>>>>>>>>>>>>>>>>>> braden@chromium.org>wrote:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Carlos Santana
>>> <cs...@gmail.com>
>>>
>>
>

Re: Updating plugin code on prepare

[Michal Mocny <mm...@chromium.org>]

On Fri, Sep 27, 2013 at 11:45 AM, Andrew Grieve <ag...@chromium.org>wrote:

> I think it'd be good to enumerate our options for workflow before we
> decided on which to implement (or maybe choose multiple).
>
> Tyler's idea about a sync command seems like it would be handy. Edit your
> plugin files within platforms/, and then run `cordova plugin copychanges
> org.my.plugin` to do a reverse copy of the source files back to the install
> source location of the plugin. Big caveat though is that you run the risk
> of prepare clobbering your changes. I think that's too killer a risk.
>
> Another thought is that we could use symlinks when running prepare. Have
> files within platforms/ symlink to files within plugins/, then symlink
> again back to their original sources. Would this work with editors in
> practice? I don't know, but worth exploring. Wikipedia says symlinks work
> on NTFS as of Vista.
>

I would love to see this explored.  Its not quite perfect, since you cannot
add/remove files to your plugins from within platform/ copy (i.e. from
IDE), but at least you can edit what's already there.


>
> Braden / Michael - I think yours is a good idea as well. Although, I don't
> think we should encourage people to edit files within plugins/. They should
> edit their plugins from install point. We should record the install path,
> and maybe have prepare have a prepare --update-local-plugins.
>

I agree you should edit the source location of your plugin, but this
happens to be plugins/ quite often:

- When you fetch from registry.  Sure, its not the canonical source, but
its probably too much overhead to tell the dev to clone the original repo
somewhere local and reinstall from path just to try a local change.  They
can do that once they have a patch ready to share/etc.
- When you install with --link, which we should do by default for local
paths
- When you 'plugin create' using CLI, which is not implemented yet, but
we've got on our list

Basically, in almost all cases, I think it should be fine to make edits
inside plugins, and expect to see them reflected after a prepare.


>
> Any other ideas?
>
>
>
> On Fri, Sep 27, 2013 at 3:13 PM, Michael Sierra <ms...@adobe.com> wrote:
>
> > Can you please file JIRAs on doc problems like this?   Existing overview
> > doc says you can use the CLI to bootstrap & hand off to an SDK &
> supporting
> > platform command-line utilities.  I take your comment to mean doc should
> > better stress that once you start working with platform tools downstream,
> > you can't go back to the CLI. Correct?
> >
> > --Mike Sierra
> >
> >
> > ________________________________________
> > From: Tyler Wilson [twilson@pulse-robotics.com]
> > Sent: Thursday, September 26, 2013 8:19 PM
> > To: dev@cordova.apache.org
> > Subject: Re: Updating plugin code on prepare
> >
> > Re: IDEs: if it is the case that the CLI should not be used along with an
> > IDE, perhaps the documentation - including Getting Started Guides, etc. -
> > ought to be much clearer about this. Perhaps a big warning that "Xcode
> > project files are created by the CLI, but they should not be opened and
> > used by Xcode. And you definitely should not edit code within the IDE".
> >
> > I just went to the main documentation site here -
> >
> http://cordova.apache.org/docs/en/3.0.0/guide_overview_index.md.html#Overview-and it appears it only mentions the new CLI interface. No mention of the
> > old bin/create method. Seems to me there may be communication problem
> here.
> >
> > Thanks,
> > Tyler
> >
> > On Sep 26, 2013, at 6:11 PM, Anis KADRI <an...@gmail.com> wrote:
> >
> > > @purplecabbage: I have the same workflow but I think the proposed
> > > solution is a step in the right direction. It would allow us to easily
> > > develop platform plugins without having to delete project/create
> > > project/install plugin/uninstall plugin constantly. The plugin would
> > > be packaged (plugin.xml) from day 1 and one can only focus on
> > > development.
> > >
> > > As far as IDEs, the answer is simple. You should not use IDEs and
> > > cordova-cli at the same time. Until IDEs are aware of cordova-cli
> > > there is no point in creating projects with cordova-cli because
> > > everything gets blown on every build. I am not even sure we can make
> > > Xcode aware of cordova-cli. We've already talked about this prior to
> > > the 3.0 release and that is why we have the create scripts and plugman
> > > approach. You should not be using cordova-cli either if you're doing
> > > some custom native dev that can't be pluginized (changing the main
> > > Activity.java or AppDelegate.m or whatever). If you're using
> > > cordova-cli just to create a project and then open an IDE to develop,
> > > you're probably doing it wrong. You should be creating a native
> > > project and using plugman instead.
> > >
> > > On Thu, Sep 26, 2013 at 9:01 PM, Michal Mocny <mm...@chromium.org>
> > wrote:
> > >> On Thu, Sep 26, 2013 at 1:39 PM, Jesse <pu...@gmail.com>
> wrote:
> > >>
> > >>> What does a watch mean?
> > >>> - if I reboot, is it still watched?
> > >>>
> > >>
> > >> No, this would start a process that lives until you CTRL+C.  You could
> > have
> > >> it run it in the background, or set it to start of startup, but that
> > would
> > >> be using local system tools, not part of the command itself.
> > >>
> > >> Ideally, "watch" should run "prepare" whenever you would have wanted
> it
> > to.
> > >> Though obviously that cannot be perfect, it can be a useful tool when
> > >> iterating.
> > >>
> > >>
> > >>>
> > >>> I think it would be best to consider separating development from
> > packaging
> > >>> in your use-case for workflow.
> > >>> If I am going to develop featureX as a plugin I would :
> > >>>
> > >>> 1. create a project for a single cordova platform, and develop the
> > feature
> > >>> as a native piece, and a js piece.
> > >>> 2. test thoroughly
> > >>> 3. create a project for a second cordova platform, and develop the
> > native
> > >>> bit, preserving the js from 1
> > >>> 4. test thoroughly
> > >>> 5. repeat steps 3+4 for any remaining platforms
> > >>> 6. package featureX as a plugin by organizing relevant bits in the
> > correct
> > >>> folder structure, and adding a plugin.xml
> > >>> 7. test each platform by installing with plugman
> > >>> 8. publish
> > >>>
> > >>
> > >> As a plugin developer, that is not my workflow.
> > >>
> > >> Typically for me its:
> > >>
> > >> Write a sample app/manual test for some new feature that isn't
> > implemented
> > >> yet.
> > >> Create a new plugin Foo for iOS & Android, and stub the
> implementation.
> > >> Implement feature A of plugin Foo for iOS, test, add it for Android,
> > test.
> > >> Implement feature B of plugin Foo for iOS, test, add it for Android,
> > test.
> > >> ...
> > >>
> > >> Usually the js implementation is shared, the auto tests are shared,
> and
> > the
> > >> sample test app is shared.
> > >>
> > >> Sure, I do platform specific stuff for testing and implementation,
> but I
> > >> certainly wouldn't say I do plugin development in platform isolation.
> > >>
> > >> Also, right now we do not have a "plugin create" command, and so
> leaving
> > >> the "packaging" step for last doesn't add affect total work.  But once
> > we
> > >> do have such a command, plugins could start packaged, and adding the
> > small
> > >> changes to plugin.xml as you need them is likely a good way to go.
> > >>
> > >> Finally, this workflow would get people out of the habit of making
> > changes
> > >> to the platform artifacts directly.  I'm not sure that can be entirely
> > >> avoided in all cases, but why shouldn't we work towards making that
> > easier?
> > >>
> > >>
> > >>> We seem to have this notion come up repeatedly that our users +
> plugin
> > >>> developers are working on multiple platforms at the same time, which
> I
> > >>> think is entirely false.
> > >>>
> > >>
> > >> Since we differ in opinion, how can we put this to the test?
> > >>
> > >> Also, we specifically make sure all our features address the needs of
> > those
> > >> doing single platform development, so in a world of 3.0+ cli, I really
> > >> don't see how we can not do the same to address the needs of those who
> > do
> > >> do multi-platform development, especially when we have a good proposal
> > of
> > >> how to do so and someone willing to do it.
> > >>
> > >>
> > >>> I also think we're trying to help the wrong people; If I am a
> > developer who
> > >>> is working on multiple platforms at once, and I have a bunch of
> devices
> > >>> attached, I probably also have the skills to set up my own grunt
> > continuous
> > >>> integration system. Setting up tooling for potential plugin
> developers
> > is
> > >>> the wrong approach, imho. We should actually just go and implement
> > some new
> > >>> plugin and evaluate the process instead of creating and imposing a
> > specific
> > >>> workflow.
> > >>>
> > >>
> > >> The first part of this argument has some merit, I agree.  We the
> > >> power-users have found ways to address our problems.  However, I think
> > that
> > >> with this change it means that even the end user can make changes to
> > plugin
> > >> folder as they find bugs/etc, and expect to see the change reflected
> > after
> > >> running prepare.  This is principle of least surprise, and just good
> > design.
> > >>
> > >> I also don't think we are imposing any specific workflow here, just
> > >> enabling a new one.  Personally I think that its quite surprising and
> > >> embarrassing that we haven't enabled this workflow since 3.0.
> > >>
> > >>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> @purplecabbage
> > >>> risingj.com
> > >>>
> > >>>
> > >>> On Thu, Sep 26, 2013 at 10:09 AM, Brian LeRoux <b...@brian.io> wrote:
> > >>>
> > >>>> I love the idea of a watch command.
> > >>>>
> > >>>>
> > >>>> On Thu, Sep 26, 2013 at 4:48 PM, Anis KADRI <an...@gmail.com>
> > >>> wrote:
> > >>>>
> > >>>>> Forgot about the existence of --link for a second. I think this is
> a
> > >>>>> good solution (not temporary). watch can be an enhancement to this
> > >>>>> solution. This might get people like Joe Bowser and other people
> who
> > >>>>> do native dev to give cordova-cli a try (only maybe though).
> > >>>>>
> > >>>>> On Thu, Sep 26, 2013 at 4:25 PM, Braden Shepherdson <
> > >>> braden@chromium.org
> > >>>>>
> > >>>>> wrote:
> > >>>>>> If the proposal above is temporary, what's permanent? cordova
> watch?
> > >>> I
> > >>>>> want
> > >>>>>> to make sure we're on the same page.
> > >>>>>>
> > >>>>>> Braden
> > >>>>>>
> > >>>>>>
> > >>>>>> On Thu, Sep 26, 2013 at 6:08 AM, Anis KADRI <anis.kadri@gmail.com
> >
> > >>>>> wrote:
> > >>>>>>
> > >>>>>>> No I didn't mean implement `plugman --watch`. I don't think
> plugman
> > >>>>>>> needs a `watch` command.
> > >>>>>>>
> > >>>>>>> I was indeed talking about `cordova watch` which should watch for
> > >>>>>>> changes in plugins/ (and maybe in merges/ and www/ as well) and
> > >>> update
> > >>>>>>> the platform projects (prepare?) on every change.  I am happy to
> > >>> know
> > >>>>>>> that it's on the wish list.
> > >>>>>>>
> > >>>>>>> As far as the original proposal, I believe it is a descent
> > temporary
> > >>>>>>> solution for plugin developers who want to use cordova-cli.
> > >>>>>>>
> > >>>>>>> On Wed, Sep 25, 2013 at 7:17 PM, Michal Mocny <
> mmocny@chromium.org
> > >
> > >>>>> wrote:
> > >>>>>>>> Braden, thats has been on the wish list (cordova watch), but I
> > >>>> suspect
> > >>>>>>> Anis
> > >>>>>>>> was suggesting something different with plugman --watch, to do
> > >>>>>>> specifically
> > >>>>>>>> with plugin development.  Am I right, Anis?  How does your idea
> > >>>>> compare
> > >>>>>>>> with using --link with cordova watch?  Would plugman --watch be
> > >>>> useful
> > >>>>>>> for
> > >>>>>>>> non cli projects?
> > >>>>>>>>
> > >>>>>>>> -Michal
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> On Wed, Sep 25, 2013 at 10:31 AM, Braden Shepherdson <
> > >>>>>>> braden@chromium.org>wrote:
> > >>>>>>>>
> > >>>>>>>>> We've had a vague feature planned for a while now to do a
> cordova
> > >>>>>>> watch. It
> > >>>>>>>>> would watch your plugins/, www/, and merges/* for any changes.
> If
> > >>>> any
> > >>>>>>>>> changes are detected, it would re-run cordova prepare, so that
> > >>> your
> > >>>>>>> native
> > >>>>>>>>> projects are always up-to-date.
> > >>>>>>>>>
> > >>>>>>>>> I'm open to checking (hashes?) which files have changed and
> which
> > >>>>> have
> > >>>>>>> not,
> > >>>>>>>>> but hashing them all is touching them all anyway, and it might
> be
> > >>>>> faster
> > >>>>>>>>> for small files to just copy them instead of checking first.
> > >>> We'll
> > >>>>> have
> > >>>>>>> to
> > >>>>>>>>> try it and see; for v1 I'm going with the simple option of
> > >>> copying
> > >>>>>>>>> everything.
> > >>>>>>>>>
> > >>>>>>>>> Braden
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> On Wed, Sep 25, 2013 at 9:44 AM, Michal Mocny <
> > >>> mmocny@chromium.org
> > >>>>>
> > >>>>>>> wrote:
> > >>>>>>>>>
> > >>>>>>>>>> The idea for plugin dev outside of plugins/ folder was to use
> > >>>>> "plugin
> > >>>>>>> add
> > >>>>>>>>>> --link".  Matter of fact, braden suggested that "plugin
> create"
> > >>>>> should
> > >>>>>>>>>> default to --link-ing to some external location so that you
> > >>> don't
> > >>>>> risk
> > >>>>>>>>>> deleting your only copy inside plugins/.  (I personally don't
> > >>>> think
> > >>>>>>>>> thats a
> > >>>>>>>>>> necessary concern, but I think its a conversation for later).
> > >>>>>>>>>>
> > >>>>>>>>>> I'm not even sure what a 'watch' would do, just uninstall &
> > >>>> install
> > >>>>>>> each
> > >>>>>>>>>> time the plugin changes?  I think that ends up being just
> > >>>> slightly
> > >>>>>>> worse
> > >>>>>>>>>> than the current proposal if you factor in that we already do
> > >>>>> support
> > >>>>>>>>>> --link (except without the above change its been useless).
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>> However, we may still want some form of 'watch' command for
> > >>> devs
> > >>>>> using
> > >>>>>>>>>> plugman directly.  I had assumed that those devs just edit in
> > >>>>> place,
> > >>>>>>>>> since
> > >>>>>>>>>> they don't use a prepare step anyway.
> > >>>>>>>>>>
> > >>>>>>>>>> -Michal
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>> On Wed, Sep 25, 2013 at 7:50 AM, Anis KADRI <
> > >>>> anis.kadri@gmail.com>
> > >>>>>>>>> wrote:
> > >>>>>>>>>>
> > >>>>>>>>>>> If we're talking about developing plugins inside the
> > >>>>>>>>>>> plugins/org.myplugin.id folder than I think it's a great
> > >>>>> workflow
> > >>>>>>> and
> > >>>>>>>>>>> I would just hide the cached version of plugin.xml inside
> > >>> that
> > >>>>>>>>>>> plugins/org.myplugin.id folder.
> > >>>>>>>>>>>
> > >>>>>>>>>>> However, if you're developing a plugin outside of a cordova
> > >>> CLI
> > >>>>>>>>>>> project, I think a `watch` (and add --watch) command is more
> > >>>>>>>>>>> appropriate. One of the reasons you would develop a plugin
> > >>>>> outside
> > >>>>>>> of
> > >>>>>>>>>>> a cordova CLI project is for easier version control (each
> > >>>> plugin
> > >>>>>>> would
> > >>>>>>>>>>> have its own repository). The other cool thing about `watch`
> > >>> is
> > >>>>> that
> > >>>>>>>>>>> it would copy the files that have actually changed and not
> > >>>>>>> everything
> > >>>>>>>>>>> (some plugins have a LOT of files [1]).
> > >>>>>>>>>>>
> > >>>>>>>>>>> [1] https://github.com/phonegap/phonegap-facebook-plugin
> > >>>>>>>>>>>
> > >>>>>>>>>>> On Wed, Sep 25, 2013 at 3:30 AM, James Jong <
> > >>>>> wjamesjong@gmail.com>
> > >>>>>>>>>> wrote:
> > >>>>>>>>>>>> +1 This is a cleaner workflow and should reduce some
> > >>>> confusion.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> -James Jong
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> On Sep 24, 2013, at 3:09 PM, Michal Mocny <
> > >>>> mmocny@chromium.org
> > >>>>>>
> > >>>>>>>>> wrote:
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>> Just to add, the reason for the "if" statement in step (2)
> > >>>> is
> > >>>>>>> that
> > >>>>>>>>>>>>> uninstall & reinstall take a lot longer than just moving a
> > >>>> few
> > >>>>>>>>> files,
> > >>>>>>>>>>> which
> > >>>>>>>>>>>>> is the 99.9% case for most end users who aren't making
> > >>>>>>> modifications
> > >>>>>>>>>> to
> > >>>>>>>>>>>>> plugins.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> This way, we only do the heavy lifting if your plugin
> > >>>>> structure
> > >>>>>>>>>> actually
> > >>>>>>>>>>>>> changed.  Doing it automatically means we no longer have
> > >>> to
> > >>>>>>> advise
> > >>>>>>>>>> users
> > >>>>>>>>>>>>> that making edits inside plugin/ folder is useless.  Now
> > >>> we
> > >>>>> just
> > >>>>>>>>>> advise
> > >>>>>>>>>>>>> them to run "prepare" after making changes to either www/
> > >>> or
> > >>>>>>>>> plugins/.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> This key insight was Braden's idea and I think its just an
> > >>>>>>> awesome
> > >>>>>>>>>>> change
> > >>>>>>>>>>>>> for workflow.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> -Michal
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> On Tue, Sep 24, 2013 at 2:58 PM, Braden Shepherdson <
> > >>>>>>>>>>> braden@chromium.org>wrote:
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>> 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
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>
> > >>>>>
> > >>>>
> > >>>
> >
>

Re: Updating plugin code on prepare

[Anis KADRI <an...@gmail.com>]

+1!

On Thu, Oct 3, 2013 at 4:30 PM, Michal Mocny <mm...@chromium.org> wrote:
> Yeah Braden we've diverged sorry, lets focus.
>
> Big +1 for your proposal to make prepare step do what users expect.
>
> -Michal
>
>
> On Thu, Oct 3, 2013 at 10:20 AM, Braden Shepherdson <br...@chromium.org>wrote:
>
>> I agree that the syncing solutions are too complex and confusing.
>>
>> I return, then, to my original proposal all those emails ago: updating the
>> native plugin files in platforms/foo when you prepare, to make life easier
>> for plugin developers. When coupled with the present cordova plugin add
>> --link, and future cordova watch, I think this makes the plugin developer
>> flow pretty good, and without making it too magical or harder to
>> understand. I think it simplifies prepare: on prepare, your native projects
>> are updated to reflect the state of plugins/ and www/. Right now, only
>> www/, <asset>s and <js-module>s get updated, but not native code.
>>
>> As to Xcode and symlinks and all the rest of the borderline thread
>> hijacking, I think that regardless of what editor you use, you have to be
>> editing the right file. Xcode and Eclipse make this harder than it needs to
>> be, but our job is not to make them suck less.
>>
>> Braden
>>
>>
>> On Sun, Sep 29, 2013 at 1:43 PM, Carlos Santana <csantana23@gmail.com
>> >wrote:
>>
>> > +1 Anis
>> > corodova-cli/plugman should be building block components to higher level
>> > Tools/IDE.
>> >
>> > That we can do better sure, lets provide a few examples using blog pots
>> and
>> > maybe videos tutorials vs. trying to support every use case with code.
>> >
>> > A watch function could be as simple as using "grunt-contrib-watch" to a
>> > more complicated environment like "rsync/Eclipse"
>> >
>> > I agree lets put emphasis on documenting use cases and the correct
>> > approach.
>> > When to get the best out of using prepare,  merges, and hooks
>> >
>> > All I said applies when you have the "Web Developer" hat.
>> >
>> > For people that have the "Native Plugin Developer" hat then we can do
>> > things first for cordova-contributors than others can choose to use on
>> > their own risk since it could be changing too fast and maybe too narrow
>> use
>> > case.
>> >
>> > --Carlos
>> >
>> > --Carlos
>> >
>> >
>> >
>> > On Sun, Sep 29, 2013 at 9:18 AM, Anis KADRI <an...@gmail.com>
>> wrote:
>> >
>> > > I gave some thought to this problem and I think we should just leave
>> > > everything as is. Here's my reasoning:
>> > >
>> > > - Most web developers use a text editor (vim, sublime text, text mate,
>> > > notepad++, ....) to edit their HTML/CSS/Javascript. I've never seen
>> > > anyone use a fully fledged IDE to edit web assets. It would be like
>> > > using Microsoft Word to edit a simple .TXT or .MD file
>> > > - Other developers, people who write Java or Objective C, etc.. use
>> > > Xcode, Eclipse, IntelliJ, ...and I think these people are not good
>> > > candidates for cordova-cli.
>> > >
>> > > The original PhoneGap promise (now Apache Cordova) was to make it easy
>> > > for Web Developers to write Mobile Apps using web technologies and I
>> > > believe that promise is fulfilled with cordova-cli. You have a folder
>> > > where you drop in your web assets and you can build/deploy to a device
>> > > or simulate.
>> > >
>> > > If people want to use an IDE, then they should be creating native
>> > > projects with our create scripts and use plugman to manage their
>> > > plugins.
>> > >
>> > > Our documentation should point our users to the right approach
>> > > depending on the use case. For example:
>> > >
>> > > - Building for only one platform ? Building a hybrid app ? Want to use
>> > > an IDE (Eclipse, Xcode) ? You should use the create scripts and
>> > > plugman to manage plugins
>> > >
>> > > - Building a cross-platform app ? Like managing your project from the
>> > > command-line ? Want to use your favo(u)rite text editor ? Use
>> > > cordova-cli
>> > >
>> > > These double symlinking, backsyncing solutions will be a source of
>> > > confusion and issues in my humble opinion. I've said it before but
>> > > sometimes by trying to please everyone you end up pleasing no one.
>> > >
>> > > my .02c
>> > >
>> > > -a
>> > >
>> > > On Fri, Sep 27, 2013 at 8:20 PM, Michal Mocny <mm...@chromium.org>
>> > wrote:
>> > > > On Fri, Sep 27, 2013 at 2:10 PM, Andrew Grieve <agrieve@chromium.org
>> >
>> > > wrote:
>> > > >
>> > > >> Just tried some symlinks in Xcode 5:
>> > > >> - Copying assets work (due to our custom build step)
>> > > >> - Building works (compiler follows links just fine)
>> > > >> - Editing a fail (big fail. Files open but changes cannot be saved.)
>> > > >>
>> > > >
>> > > > Hmm, changes via xcode to symlinks fail, you mean?  That would be
>> hard
>> > to
>> > > > fix, but perhaps at least its feedback to the user not to make direct
>> > > edits
>> > > > there, when using CLI workflow ;) so may still be a valid change to
>> > make.
>> > > >
>> > > >
>> > > >>
>> > > >> For Xcode though, it is an option to change our installation step to
>> > > have
>> > > >> Xcode reference the native files within plugins/ rather than within
>> > > >> platforms/.
>> > > >>
>> > > >>
>> > > >> Symlinks in Eclipse:
>> > > >> - Copying assets works out-of-the-box
>> > > >> - Build works fine
>> > > >> - Editing seems to work fine (edits saved to symlinked location).
>> > > >>
>> > > >>
>> > > >>
>> > > >> Still though, maybe the best solution would be a combination of the
>> > two?
>> > > >> Have prepare know when an remove+add is necessary?
>> > > >>
>> > > >
>> > > > Yes, I think thats what we are suggesting.
>> > > >
>> > > > The original email mentioned prepare knowing when remove+add are
>> > > necessary,
>> > > > which I think is already settled as a good idea.  Not sure if you had
>> > > more
>> > > > to add about how prepare should know when to do this (currently, its
>> > only
>> > > > on plugin.xml changes).
>> > > > The more recent suggestions about making links between
>> platform&plugins
>> > > > were additional requests to address the rest of the workflow issues
>> > (ie,
>> > > > most users prefer to edit inside platforms/ folder because of IDE
>> > > > integration etc).
>> > > >
>> > > > Were you implying anything different here?
>> > > >
>> > > >
>> > > >>
>> > > >> On Fri, Sep 27, 2013 at 6:25 PM, Michal Mocny <mm...@chromium.org>
>> > > wrote:
>> > > >>
>> > > >> > Have we not previously solved the symlink problem in xcode with a
>> > > build
>> > > >> > hook, or was that for prepare step?
>> > > >> >
>> > > >> > The --link concept doesn't do anything for that platforms ->
>> plugins
>> > > file
>> > > >> > mapping.  Its useful for mapping plugins/ to local source, but it
>> > > doesn't
>> > > >> > help with the problem Tyler mentions, right?
>> > > >> >
>> > > >> > -Michal
>> > > >> >
>> > > >> >
>> > > >> > On Fri, Sep 27, 2013 at 1:20 PM, Braden Shepherdson <
>> > > braden@chromium.org
>> > > >> > >wrote:
>> > > >> >
>> > > >> > > Symlinks in platforms/ are a problem because Xcode doesn't
>> honour
>> > > them,
>> > > >> > at
>> > > >> > > least last time we tried it.
>> > > >> > >
>> > > >> > > I'm much more enthused about the --link concept than any
>> syncing,
>> > > >> though.
>> > > >> > > Also if someone wants to sync, they can already use rsync to do
>> it
>> > > >> > > manually.
>> > > >> > >
>> > > >> > > Braden
>> > > >> > >
>> > > >> > >
>> > > >> > > On Fri, Sep 27, 2013 at 11:45 AM, Andrew Grieve <
>> > > agrieve@chromium.org
>> > > >> > > >wrote:
>> > > >> > >
>> > > >> > > > I think it'd be good to enumerate our options for workflow
>> > before
>> > > we
>> > > >> > > > decided on which to implement (or maybe choose multiple).
>> > > >> > > >
>> > > >> > > > Tyler's idea about a sync command seems like it would be
>> handy.
>> > > Edit
>> > > >> > your
>> > > >> > > > plugin files within platforms/, and then run `cordova plugin
>> > > >> > copychanges
>> > > >> > > > org.my.plugin` to do a reverse copy of the source files back
>> to
>> > > the
>> > > >> > > install
>> > > >> > > > source location of the plugin. Big caveat though is that you
>> run
>> > > the
>> > > >> > risk
>> > > >> > > > of prepare clobbering your changes. I think that's too killer
>> a
>> > > risk.
>> > > >> > > >
>> > > >> > > > Another thought is that we could use symlinks when running
>> > > prepare.
>> > > >> > Have
>> > > >> > > > files within platforms/ symlink to files within plugins/, then
>> > > >> symlink
>> > > >> > > > again back to their original sources. Would this work with
>> > > editors in
>> > > >> > > > practice? I don't know, but worth exploring. Wikipedia says
>> > > symlinks
>> > > >> > work
>> > > >> > > > on NTFS as of Vista.
>> > > >> > > >
>> > > >> > > > Braden / Michael - I think yours is a good idea as well.
>> > > Although, I
>> > > >> > > don't
>> > > >> > > > think we should encourage people to edit files within
>> plugins/.
>> > > They
>> > > >> > > should
>> > > >> > > > edit their plugins from install point. We should record the
>> > > install
>> > > >> > path,
>> > > >> > > > and maybe have prepare have a prepare --update-local-plugins.
>> > > >> > > >
>> > > >> > > > Any other ideas?
>> > > >> > > >
>> > > >> > > >
>> > > >> > > >
>> > > >> > > > On Fri, Sep 27, 2013 at 3:13 PM, Michael Sierra <
>> > > msierra@adobe.com>
>> > > >> > > wrote:
>> > > >> > > >
>> > > >> > > > > Can you please file JIRAs on doc problems like this?
>> > Existing
>> > > >> > > overview
>> > > >> > > > > doc says you can use the CLI to bootstrap & hand off to an
>> > SDK &
>> > > >> > > > supporting
>> > > >> > > > > platform command-line utilities.  I take your comment to
>> mean
>> > > doc
>> > > >> > > should
>> > > >> > > > > better stress that once you start working with platform
>> tools
>> > > >> > > downstream,
>> > > >> > > > > you can't go back to the CLI. Correct?
>> > > >> > > > >
>> > > >> > > > > --Mike Sierra
>> > > >> > > > >
>> > > >> > > > >
>> > > >> > > > > ________________________________________
>> > > >> > > > > From: Tyler Wilson [twilson@pulse-robotics.com]
>> > > >> > > > > Sent: Thursday, September 26, 2013 8:19 PM
>> > > >> > > > > To: dev@cordova.apache.org
>> > > >> > > > > Subject: Re: Updating plugin code on prepare
>> > > >> > > > >
>> > > >> > > > > Re: IDEs: if it is the case that the CLI should not be used
>> > > along
>> > > >> > with
>> > > >> > > an
>> > > >> > > > > IDE, perhaps the documentation - including Getting Started
>> > > Guides,
>> > > >> > > etc. -
>> > > >> > > > > ought to be much clearer about this. Perhaps a big warning
>> > that
>> > > >> > "Xcode
>> > > >> > > > > project files are created by the CLI, but they should not be
>> > > opened
>> > > >> > and
>> > > >> > > > > used by Xcode. And you definitely should not edit code
>> within
>> > > the
>> > > >> > IDE".
>> > > >> > > > >
>> > > >> > > > > I just went to the main documentation site here -
>> > > >> > > > >
>> > > >> > > >
>> > > >> > >
>> > > >> >
>> > > >>
>> > >
>> >
>> http://cordova.apache.org/docs/en/3.0.0/guide_overview_index.md.html#Overview-anditappearsitonlymentionsthe new CLI interface. No mention of the
>> > > >> > > > > old bin/create method. Seems to me there may be
>> communication
>> > > >> problem
>> > > >> > > > here.
>> > > >> > > > >
>> > > >> > > > > Thanks,
>> > > >> > > > > Tyler
>> > > >> > > > >
>> > > >> > > > > On Sep 26, 2013, at 6:11 PM, Anis KADRI <
>> anis.kadri@gmail.com
>> > >
>> > > >> > wrote:
>> > > >> > > > >
>> > > >> > > > > > @purplecabbage: I have the same workflow but I think the
>> > > proposed
>> > > >> > > > > > solution is a step in the right direction. It would allow
>> us
>> > > to
>> > > >> > > easily
>> > > >> > > > > > develop platform plugins without having to delete
>> > > project/create
>> > > >> > > > > > project/install plugin/uninstall plugin constantly. The
>> > plugin
>> > > >> > would
>> > > >> > > > > > be packaged (plugin.xml) from day 1 and one can only focus
>> > on
>> > > >> > > > > > development.
>> > > >> > > > > >
>> > > >> > > > > > As far as IDEs, the answer is simple. You should not use
>> > IDEs
>> > > and
>> > > >> > > > > > cordova-cli at the same time. Until IDEs are aware of
>> > > cordova-cli
>> > > >> > > > > > there is no point in creating projects with cordova-cli
>> > > because
>> > > >> > > > > > everything gets blown on every build. I am not even sure
>> we
>> > > can
>> > > >> > make
>> > > >> > > > > > Xcode aware of cordova-cli. We've already talked about
>> this
>> > > prior
>> > > >> > to
>> > > >> > > > > > the 3.0 release and that is why we have the create scripts
>> > and
>> > > >> > > plugman
>> > > >> > > > > > approach. You should not be using cordova-cli either if
>> > you're
>> > > >> > doing
>> > > >> > > > > > some custom native dev that can't be pluginized (changing
>> > the
>> > > >> main
>> > > >> > > > > > Activity.java or AppDelegate.m or whatever). If you're
>> using
>> > > >> > > > > > cordova-cli just to create a project and then open an IDE
>> to
>> > > >> > develop,
>> > > >> > > > > > you're probably doing it wrong. You should be creating a
>> > > native
>> > > >> > > > > > project and using plugman instead.
>> > > >> > > > > >
>> > > >> > > > > > On Thu, Sep 26, 2013 at 9:01 PM, Michal Mocny <
>> > > >> mmocny@chromium.org
>> > > >> > >
>> > > >> > > > > wrote:
>> > > >> > > > > >> On Thu, Sep 26, 2013 at 1:39 PM, Jesse <
>> > > purplecabbage@gmail.com
>> > > >> >
>> > > >> > > > wrote:
>> > > >> > > > > >>
>> > > >> > > > > >>> What does a watch mean?
>> > > >> > > > > >>> - if I reboot, is it still watched?
>> > > >> > > > > >>>
>> > > >> > > > > >>
>> > > >> > > > > >> No, this would start a process that lives until you
>> CTRL+C.
>> > >  You
>> > > >> > > could
>> > > >> > > > > have
>> > > >> > > > > >> it run it in the background, or set it to start of
>> startup,
>> > > but
>> > > >> > that
>> > > >> > > > > would
>> > > >> > > > > >> be using local system tools, not part of the command
>> > itself.
>> > > >> > > > > >>
>> > > >> > > > > >> Ideally, "watch" should run "prepare" whenever you would
>> > have
>> > > >> > wanted
>> > > >> > > > it
>> > > >> > > > > to.
>> > > >> > > > > >> Though obviously that cannot be perfect, it can be a
>> useful
>> > > tool
>> > > >> > > when
>> > > >> > > > > >> iterating.
>> > > >> > > > > >>
>> > > >> > > > > >>
>> > > >> > > > > >>>
>> > > >> > > > > >>> I think it would be best to consider separating
>> > development
>> > > >> from
>> > > >> > > > > packaging
>> > > >> > > > > >>> in your use-case for workflow.
>> > > >> > > > > >>> If I am going to develop featureX as a plugin I would :
>> > > >> > > > > >>>
>> > > >> > > > > >>> 1. create a project for a single cordova platform, and
>> > > develop
>> > > >> > the
>> > > >> > > > > feature
>> > > >> > > > > >>> as a native piece, and a js piece.
>> > > >> > > > > >>> 2. test thoroughly
>> > > >> > > > > >>> 3. create a project for a second cordova platform, and
>> > > develop
>> > > >> > the
>> > > >> > > > > native
>> > > >> > > > > >>> bit, preserving the js from 1
>> > > >> > > > > >>> 4. test thoroughly
>> > > >> > > > > >>> 5. repeat steps 3+4 for any remaining platforms
>> > > >> > > > > >>> 6. package featureX as a plugin by organizing relevant
>> > bits
>> > > in
>> > > >> > the
>> > > >> > > > > correct
>> > > >> > > > > >>> folder structure, and adding a plugin.xml
>> > > >> > > > > >>> 7. test each platform by installing with plugman
>> > > >> > > > > >>> 8. publish
>> > > >> > > > > >>>
>> > > >> > > > > >>
>> > > >> > > > > >> As a plugin developer, that is not my workflow.
>> > > >> > > > > >>
>> > > >> > > > > >> Typically for me its:
>> > > >> > > > > >>
>> > > >> > > > > >> Write a sample app/manual test for some new feature that
>> > > isn't
>> > > >> > > > > implemented
>> > > >> > > > > >> yet.
>> > > >> > > > > >> Create a new plugin Foo for iOS & Android, and stub the
>> > > >> > > > implementation.
>> > > >> > > > > >> Implement feature A of plugin Foo for iOS, test, add it
>> for
>> > > >> > Android,
>> > > >> > > > > test.
>> > > >> > > > > >> Implement feature B of plugin Foo for iOS, test, add it
>> for
>> > > >> > Android,
>> > > >> > > > > test.
>> > > >> > > > > >> ...
>> > > >> > > > > >>
>> > > >> > > > > >> Usually the js implementation is shared, the auto tests
>> are
>> > > >> > shared,
>> > > >> > > > and
>> > > >> > > > > the
>> > > >> > > > > >> sample test app is shared.
>> > > >> > > > > >>
>> > > >> > > > > >> Sure, I do platform specific stuff for testing and
>> > > >> implementation,
>> > > >> > > > but I
>> > > >> > > > > >> certainly wouldn't say I do plugin development in
>> platform
>> > > >> > > isolation.
>> > > >> > > > > >>
>> > > >> > > > > >> Also, right now we do not have a "plugin create" command,
>> > > and so
>> > > >> > > > leaving
>> > > >> > > > > >> the "packaging" step for last doesn't add affect total
>> > work.
>> > > >>  But
>> > > >> > > once
>> > > >> > > > > we
>> > > >> > > > > >> do have such a command, plugins could start packaged, and
>> > > adding
>> > > >> > the
>> > > >> > > > > small
>> > > >> > > > > >> changes to plugin.xml as you need them is likely a good
>> way
>> > > to
>> > > >> go.
>> > > >> > > > > >>
>> > > >> > > > > >> Finally, this workflow would get people out of the habit
>> of
>> > > >> making
>> > > >> > > > > changes
>> > > >> > > > > >> to the platform artifacts directly.  I'm not sure that
>> can
>> > be
>> > > >> > > entirely
>> > > >> > > > > >> avoided in all cases, but why shouldn't we work towards
>> > > making
>> > > >> > that
>> > > >> > > > > easier?
>> > > >> > > > > >>
>> > > >> > > > > >>
>> > > >> > > > > >>> We seem to have this notion come up repeatedly that our
>> > > users +
>> > > >> > > > plugin
>> > > >> > > > > >>> developers are working on multiple platforms at the same
>> > > time,
>> > > >> > > which
>> > > >> > > > I
>> > > >> > > > > >>> think is entirely false.
>> > > >> > > > > >>>
>> > > >> > > > > >>
>> > > >> > > > > >> Since we differ in opinion, how can we put this to the
>> > test?
>> > > >> > > > > >>
>> > > >> > > > > >> Also, we specifically make sure all our features address
>> > the
>> > > >> needs
>> > > >> > > of
>> > > >> > > > > those
>> > > >> > > > > >> doing single platform development, so in a world of 3.0+
>> > > cli, I
>> > > >> > > really
>> > > >> > > > > >> don't see how we can not do the same to address the needs
>> > of
>> > > >> those
>> > > >> > > who
>> > > >> > > > > do
>> > > >> > > > > >> do multi-platform development, especially when we have a
>> > good
>> > > >> > > proposal
>> > > >> > > > > of
>> > > >> > > > > >> how to do so and someone willing to do it.
>> > > >> > > > > >>
>> > > >> > > > > >>
>> > > >> > > > > >>> I also think we're trying to help the wrong people; If I
>> > am
>> > > a
>> > > >> > > > > developer who
>> > > >> > > > > >>> is working on multiple platforms at once, and I have a
>> > > bunch of
>> > > >> > > > devices
>> > > >> > > > > >>> attached, I probably also have the skills to set up my
>> own
>> > > >> grunt
>> > > >> > > > > continuous
>> > > >> > > > > >>> integration system. Setting up tooling for potential
>> > plugin
>> > > >> > > > developers
>> > > >> > > > > is
>> > > >> > > > > >>> the wrong approach, imho. We should actually just go and
>> > > >> > implement
>> > > >> > > > > some new
>> > > >> > > > > >>> plugin and evaluate the process instead of creating and
>> > > >> imposing
>> > > >> > a
>> > > >> > > > > specific
>> > > >> > > > > >>> workflow.
>> > > >> > > > > >>>
>> > > >> > > > > >>
>> > > >> > > > > >> The first part of this argument has some merit, I agree.
>> >  We
>> > > the
>> > > >> > > > > >> power-users have found ways to address our problems.
>> > >  However, I
>> > > >> > > think
>> > > >> > > > > that
>> > > >> > > > > >> with this change it means that even the end user can make
>> > > >> changes
>> > > >> > to
>> > > >> > > > > plugin
>> > > >> > > > > >> folder as they find bugs/etc, and expect to see the
>> change
>> > > >> > reflected
>> > > >> > > > > after
>> > > >> > > > > >> running prepare.  This is principle of least surprise,
>> and
>> > > just
>> > > >> > good
>> > > >> > > > > design.
>> > > >> > > > > >>
>> > > >> > > > > >> I also don't think we are imposing any specific workflow
>> > > here,
>> > > >> > just
>> > > >> > > > > >> enabling a new one.  Personally I think that its quite
>> > > >> surprising
>> > > >> > > and
>> > > >> > > > > >> embarrassing that we haven't enabled this workflow since
>> > 3.0.
>> > > >> > > > > >>
>> > > >> > > > > >>
>> > > >> > > > > >>>
>> > > >> > > > > >>>
>> > > >> > > > > >>>
>> > > >> > > > > >>>
>> > > >> > > > > >>>
>> > > >> > > > > >>>
>> > > >> > > > > >>>
>> > > >> > > > > >>>
>> > > >> > > > > >>>
>> > > >> > > > > >>> @purplecabbage
>> > > >> > > > > >>> risingj.com
>> > > >> > > > > >>>
>> > > >> > > > > >>>
>> > > >> > > > > >>> On Thu, Sep 26, 2013 at 10:09 AM, Brian LeRoux <
>> > b@brian.io>
>> > > >> > wrote:
>> > > >> > > > > >>>
>> > > >> > > > > >>>> I love the idea of a watch command.
>> > > >> > > > > >>>>
>> > > >> > > > > >>>>
>> > > >> > > > > >>>> On Thu, Sep 26, 2013 at 4:48 PM, Anis KADRI <
>> > > >> > anis.kadri@gmail.com
>> > > >> > > >
>> > > >> > > > > >>> wrote:
>> > > >> > > > > >>>>
>> > > >> > > > > >>>>> Forgot about the existence of --link for a second. I
>> > think
>> > > >> this
>> > > >> > > is
>> > > >> > > > a
>> > > >> > > > > >>>>> good solution (not temporary). watch can be an
>> > > enhancement to
>> > > >> > > this
>> > > >> > > > > >>>>> solution. This might get people like Joe Bowser and
>> > other
>> > > >> > people
>> > > >> > > > who
>> > > >> > > > > >>>>> do native dev to give cordova-cli a try (only maybe
>> > > though).
>> > > >> > > > > >>>>>
>> > > >> > > > > >>>>> On Thu, Sep 26, 2013 at 4:25 PM, Braden Shepherdson <
>> > > >> > > > > >>> braden@chromium.org
>> > > >> > > > > >>>>>
>> > > >> > > > > >>>>> wrote:
>> > > >> > > > > >>>>>> If the proposal above is temporary, what's permanent?
>> > > >> cordova
>> > > >> > > > watch?
>> > > >> > > > > >>> I
>> > > >> > > > > >>>>> want
>> > > >> > > > > >>>>>> to make sure we're on the same page.
>> > > >> > > > > >>>>>>
>> > > >> > > > > >>>>>> Braden
>> > > >> > > > > >>>>>>
>> > > >> > > > > >>>>>>
>> > > >> > > > > >>>>>> On Thu, Sep 26, 2013 at 6:08 AM, Anis KADRI <
>> > > >> > > anis.kadri@gmail.com
>> > > >> > > > >
>> > > >> > > > > >>>>> wrote:
>> > > >> > > > > >>>>>>
>> > > >> > > > > >>>>>>> No I didn't mean implement `plugman --watch`. I
>> don't
>> > > think
>> > > >> > > > plugman
>> > > >> > > > > >>>>>>> needs a `watch` command.
>> > > >> > > > > >>>>>>>
>> > > >> > > > > >>>>>>> I was indeed talking about `cordova watch` which
>> > should
>> > > >> watch
>> > > >> > > for
>> > > >> > > > > >>>>>>> changes in plugins/ (and maybe in merges/ and www/
>> as
>> > > well)
>> > > >> > and
>> > > >> > > > > >>> update
>> > > >> > > > > >>>>>>> the platform projects (prepare?) on every change.  I
>> > am
>> > > >> happy
>> > > >> > > to
>> > > >> > > > > >>> know
>> > > >> > > > > >>>>>>> that it's on the wish list.
>> > > >> > > > > >>>>>>>
>> > > >> > > > > >>>>>>> As far as the original proposal, I believe it is a
>> > > descent
>> > > >> > > > > temporary
>> > > >> > > > > >>>>>>> solution for plugin developers who want to use
>> > > cordova-cli.
>> > > >> > > > > >>>>>>>
>> > > >> > > > > >>>>>>> On Wed, Sep 25, 2013 at 7:17 PM, Michal Mocny <
>> > > >> > > > mmocny@chromium.org
>> > > >> > > > > >
>> > > >> > > > > >>>>> wrote:
>> > > >> > > > > >>>>>>>> Braden, thats has been on the wish list (cordova
>> > > watch),
>> > > >> > but I
>> > > >> > > > > >>>> suspect
>> > > >> > > > > >>>>>>> Anis
>> > > >> > > > > >>>>>>>> was suggesting something different with plugman
>> > > --watch,
>> > > >> to
>> > > >> > do
>> > > >> > > > > >>>>>>> specifically
>> > > >> > > > > >>>>>>>> with plugin development.  Am I right, Anis?  How
>> does
>> > > your
>> > > >> > > idea
>> > > >> > > > > >>>>> compare
>> > > >> > > > > >>>>>>>> with using --link with cordova watch?  Would
>> plugman
>> > > >> --watch
>> > > >> > > be
>> > > >> > > > > >>>> useful
>> > > >> > > > > >>>>>>> for
>> > > >> > > > > >>>>>>>> non cli projects?
>> > > >> > > > > >>>>>>>>
>> > > >> > > > > >>>>>>>> -Michal
>> > > >> > > > > >>>>>>>>
>> > > >> > > > > >>>>>>>>
>> > > >> > > > > >>>>>>>> On Wed, Sep 25, 2013 at 10:31 AM, Braden
>> Shepherdson
>> > <
>> > > >> > > > > >>>>>>> braden@chromium.org>wrote:
>> > > >> > > > > >>>>>>>>
>> > > >> > > > > >>>>>>>>> We've had a vague feature planned for a while now
>> to
>> > > do a
>> > > >> > > > cordova
>> > > >> > > > > >>>>>>> watch. It
>> > > >> > > > > >>>>>>>>> would watch your plugins/, www/, and merges/* for
>> > any
>> > > >> > > changes.
>> > > >> > > > If
>> > > >> > > > > >>>> any
>> > > >> > > > > >>>>>>>>> changes are detected, it would re-run cordova
>> > > prepare, so
>> > > >> > > that
>> > > >> > > > > >>> your
>> > > >> > > > > >>>>>>> native
>> > > >> > > > > >>>>>>>>> projects are always up-to-date.
>> > > >> > > > > >>>>>>>>>
>> > > >> > > > > >>>>>>>>> I'm open to checking (hashes?) which files have
>> > > changed
>> > > >> and
>> > > >> > > > which
>> > > >> > > > > >>>>> have
>> > > >> > > > > >>>>>>> not,
>> > > >> > > > > >>>>>>>>> but hashing them all is touching them all anyway,
>> > and
>> > > it
>> > > >> > > might
>> > > >> > > > be
>> > > >> > > > > >>>>> faster
>> > > >> > > > > >>>>>>>>> for small files to just copy them instead of
>> > checking
>> > > >> > first.
>> > > >> > > > > >>> We'll
>> > > >> > > > > >>>>> have
>> > > >> > > > > >>>>>>> to
>> > > >> > > > > >>>>>>>>> try it and see; for v1 I'm going with the simple
>> > > option
>> > > >> of
>> > > >> > > > > >>> copying
>> > > >> > > > > >>>>>>>>> everything.
>> > > >> > > > > >>>>>>>>>
>> > > >> > > > > >>>>>>>>> Braden
>> > > >> > > > > >>>>>>>>>
>> > > >> > > > > >>>>>>>>>
>> > > >> > > > > >>>>>>>>> On Wed, Sep 25, 2013 at 9:44 AM, Michal Mocny <
>> > > >> > > > > >>> mmocny@chromium.org
>> > > >> > > > > >>>>>
>> > > >> > > > > >>>>>>> wrote:
>> > > >> > > > > >>>>>>>>>
>> > > >> > > > > >>>>>>>>>> The idea for plugin dev outside of plugins/
>> folder
>> > > was
>> > > >> to
>> > > >> > > use
>> > > >> > > > > >>>>> "plugin
>> > > >> > > > > >>>>>>> add
>> > > >> > > > > >>>>>>>>>> --link".  Matter of fact, braden suggested that
>> > > "plugin
>> > > >> > > > create"
>> > > >> > > > > >>>>> should
>> > > >> > > > > >>>>>>>>>> default to --link-ing to some external location
>> so
>> > > that
>> > > >> > you
>> > > >> > > > > >>> don't
>> > > >> > > > > >>>>> risk
>> > > >> > > > > >>>>>>>>>> deleting your only copy inside plugins/.  (I
>> > > personally
>> > > >> > > don't
>> > > >> > > > > >>>> think
>> > > >> > > > > >>>>>>>>> thats a
>> > > >> > > > > >>>>>>>>>> necessary concern, but I think its a conversation
>> > for
>> > > >> > > later).
>> > > >> > > > > >>>>>>>>>>
>> > > >> > > > > >>>>>>>>>> I'm not even sure what a 'watch' would do, just
>> > > >> uninstall
>> > > >> > &
>> > > >> > > > > >>>> install
>> > > >> > > > > >>>>>>> each
>> > > >> > > > > >>>>>>>>>> time the plugin changes?  I think that ends up
>> > being
>> > > >> just
>> > > >> > > > > >>>> slightly
>> > > >> > > > > >>>>>>> worse
>> > > >> > > > > >>>>>>>>>> than the current proposal if you factor in that
>> we
>> > > >> already
>> > > >> > > do
>> > > >> > > > > >>>>> support
>> > > >> > > > > >>>>>>>>>> --link (except without the above change its been
>> > > >> useless).
>> > > >> > > > > >>>>>>>>>>
>> > > >> > > > > >>>>>>>>>>
>> > > >> > > > > >>>>>>>>>> However, we may still want some form of 'watch'
>> > > command
>> > > >> > for
>> > > >> > > > > >>> devs
>> > > >> > > > > >>>>> using
>> > > >> > > > > >>>>>>>>>> plugman directly.  I had assumed that those devs
>> > just
>> > > >> edit
>> > > >> > > in
>> > > >> > > > > >>>>> place,
>> > > >> > > > > >>>>>>>>> since
>> > > >> > > > > >>>>>>>>>> they don't use a prepare step anyway.
>> > > >> > > > > >>>>>>>>>>
>> > > >> > > > > >>>>>>>>>> -Michal
>> > > >> > > > > >>>>>>>>>>
>> > > >> > > > > >>>>>>>>>>
>> > > >> > > > > >>>>>>>>>>
>> > > >> > > > > >>>>>>>>>> On Wed, Sep 25, 2013 at 7:50 AM, Anis KADRI <
>> > > >> > > > > >>>> anis.kadri@gmail.com>
>> > > >> > > > > >>>>>>>>> wrote:
>> > > >> > > > > >>>>>>>>>>
>> > > >> > > > > >>>>>>>>>>> If we're talking about developing plugins inside
>> > the
>> > > >> > > > > >>>>>>>>>>> plugins/org.myplugin.id folder than I think
>> it's
>> > a
>> > > >> great
>> > > >> > > > > >>>>> workflow
>> > > >> > > > > >>>>>>> and
>> > > >> > > > > >>>>>>>>>>> I would just hide the cached version of
>> plugin.xml
>> > > >> inside
>> > > >> > > > > >>> that
>> > > >> > > > > >>>>>>>>>>> plugins/org.myplugin.id folder.
>> > > >> > > > > >>>>>>>>>>>
>> > > >> > > > > >>>>>>>>>>> However, if you're developing a plugin outside
>> of
>> > a
>> > > >> > cordova
>> > > >> > > > > >>> CLI
>> > > >> > > > > >>>>>>>>>>> project, I think a `watch` (and add --watch)
>> > > command is
>> > > >> > > more
>> > > >> > > > > >>>>>>>>>>> appropriate. One of the reasons you would
>> develop
>> > a
>> > > >> > plugin
>> > > >> > > > > >>>>> outside
>> > > >> > > > > >>>>>>> of
>> > > >> > > > > >>>>>>>>>>> a cordova CLI project is for easier version
>> > control
>> > > >> (each
>> > > >> > > > > >>>> plugin
>> > > >> > > > > >>>>>>> would
>> > > >> > > > > >>>>>>>>>>> have its own repository). The other cool thing
>> > about
>> > > >> > > `watch`
>> > > >> > > > > >>> is
>> > > >> > > > > >>>>> that
>> > > >> > > > > >>>>>>>>>>> it would copy the files that have actually
>> changed
>> > > and
>> > > >> > not
>> > > >> > > > > >>>>>>> everything
>> > > >> > > > > >>>>>>>>>>> (some plugins have a LOT of files [1]).
>> > > >> > > > > >>>>>>>>>>>
>> > > >> > > > > >>>>>>>>>>> [1]
>> > > >> https://github.com/phonegap/phonegap-facebook-plugin
>> > > >> > > > > >>>>>>>>>>>
>> > > >> > > > > >>>>>>>>>>> On Wed, Sep 25, 2013 at 3:30 AM, James Jong <
>> > > >> > > > > >>>>> wjamesjong@gmail.com>
>> > > >> > > > > >>>>>>>>>> wrote:
>> > > >> > > > > >>>>>>>>>>>> +1 This is a cleaner workflow and should reduce
>> > > some
>> > > >> > > > > >>>> confusion.
>> > > >> > > > > >>>>>>>>>>>>
>> > > >> > > > > >>>>>>>>>>>> -James Jong
>> > > >> > > > > >>>>>>>>>>>>
>> > > >> > > > > >>>>>>>>>>>> On Sep 24, 2013, at 3:09 PM, Michal Mocny <
>> > > >> > > > > >>>> mmocny@chromium.org
>> > > >> > > > > >>>>>>
>> > > >> > > > > >>>>>>>>> wrote:
>> > > >> > > > > >>>>>>>>>>>>
>> > > >> > > > > >>>>>>>>>>>>> Just to add, the reason for the "if" statement
>> > in
>> > > >> step
>> > > >> > > (2)
>> > > >> > > > > >>>> is
>> > > >> > > > > >>>>>>> that
>> > > >> > > > > >>>>>>>>>>>>> uninstall & reinstall take a lot longer than
>> > just
>> > > >> > moving
>> > > >> > > a
>> > > >> > > > > >>>> few
>> > > >> > > > > >>>>>>>>> files,
>> > > >> > > > > >>>>>>>>>>> which
>> > > >> > > > > >>>>>>>>>>>>> is the 99.9% case for most end users who
>> aren't
>> > > >> making
>> > > >> > > > > >>>>>>> modifications
>> > > >> > > > > >>>>>>>>>> to
>> > > >> > > > > >>>>>>>>>>>>> plugins.
>> > > >> > > > > >>>>>>>>>>>>>
>> > > >> > > > > >>>>>>>>>>>>> This way, we only do the heavy lifting if your
>> > > plugin
>> > > >> > > > > >>>>> structure
>> > > >> > > > > >>>>>>>>>> actually
>> > > >> > > > > >>>>>>>>>>>>> changed.  Doing it automatically means we no
>> > > longer
>> > > >> > have
>> > > >> > > > > >>> to
>> > > >> > > > > >>>>>>> advise
>> > > >> > > > > >>>>>>>>>> users
>> > > >> > > > > >>>>>>>>>>>>> that making edits inside plugin/ folder is
>> > > useless.
>> > > >> >  Now
>> > > >> > > > > >>> we
>> > > >> > > > > >>>>> just
>> > > >> > > > > >>>>>>>>>> advise
>> > > >> > > > > >>>>>>>>>>>>> them to run "prepare" after making changes to
>> > > either
>> > > >> > www/
>> > > >> > > > > >>> or
>> > > >> > > > > >>>>>>>>> plugins/.
>> > > >> > > > > >>>>>>>>>>>>>
>> > > >> > > > > >>>>>>>>>>>>> This key insight was Braden's idea and I think
>> > its
>> > > >> just
>> > > >> > > an
>> > > >> > > > > >>>>>>> awesome
>> > > >> > > > > >>>>>>>>>>> change
>> > > >> > > > > >>>>>>>>>>>>> for workflow.
>> > > >> > > > > >>>>>>>>>>>>>
>> > > >> > > > > >>>>>>>>>>>>> -Michal
>> > > >> > > > > >>>>>>>>>>>>>
>> > > >> > > > > >>>>>>>>>>>>>
>> > > >> > > > > >>>>>>>>>>>>> On Tue, Sep 24, 2013 at 2:58 PM, Braden
>> > > Shepherdson <
>> > > >> > > > > >>>>>>>>>>> braden@chromium.org>wrote:
>> > > >> > > > > >>>>>>>>>>>>>
>> > > >> > > > > >>>>>>>>>>>>>> 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
>> > > >> > > > > >>>>>>>>>>>>>>
>> > > >> > > > > >>>>>>>>>>>>
>> > > >> > > > > >>>>>>>>>>>
>> > > >> > > > > >>>>>>>>>>
>> > > >> > > > > >>>>>>>>>
>> > > >> > > > > >>>>>>>
>> > > >> > > > > >>>>>
>> > > >> > > > > >>>>
>> > > >> > > > > >>>
>> > > >> > > > >
>> > > >> > > >
>> > > >> > >
>> > > >> >
>> > > >>
>> > >
>> >
>> >
>> >
>> > --
>> > Carlos Santana
>> > <cs...@gmail.com>
>> >
>>

Re: Updating plugin code on prepare

[Michal Mocny <mm...@chromium.org>]

Yeah Braden we've diverged sorry, lets focus.

Big +1 for your proposal to make prepare step do what users expect.

-Michal


On Thu, Oct 3, 2013 at 10:20 AM, Braden Shepherdson <br...@chromium.org>wrote:

> I agree that the syncing solutions are too complex and confusing.
>
> I return, then, to my original proposal all those emails ago: updating the
> native plugin files in platforms/foo when you prepare, to make life easier
> for plugin developers. When coupled with the present cordova plugin add
> --link, and future cordova watch, I think this makes the plugin developer
> flow pretty good, and without making it too magical or harder to
> understand. I think it simplifies prepare: on prepare, your native projects
> are updated to reflect the state of plugins/ and www/. Right now, only
> www/, <asset>s and <js-module>s get updated, but not native code.
>
> As to Xcode and symlinks and all the rest of the borderline thread
> hijacking, I think that regardless of what editor you use, you have to be
> editing the right file. Xcode and Eclipse make this harder than it needs to
> be, but our job is not to make them suck less.
>
> Braden
>
>
> On Sun, Sep 29, 2013 at 1:43 PM, Carlos Santana <csantana23@gmail.com
> >wrote:
>
> > +1 Anis
> > corodova-cli/plugman should be building block components to higher level
> > Tools/IDE.
> >
> > That we can do better sure, lets provide a few examples using blog pots
> and
> > maybe videos tutorials vs. trying to support every use case with code.
> >
> > A watch function could be as simple as using "grunt-contrib-watch" to a
> > more complicated environment like "rsync/Eclipse"
> >
> > I agree lets put emphasis on documenting use cases and the correct
> > approach.
> > When to get the best out of using prepare,  merges, and hooks
> >
> > All I said applies when you have the "Web Developer" hat.
> >
> > For people that have the "Native Plugin Developer" hat then we can do
> > things first for cordova-contributors than others can choose to use on
> > their own risk since it could be changing too fast and maybe too narrow
> use
> > case.
> >
> > --Carlos
> >
> > --Carlos
> >
> >
> >
> > On Sun, Sep 29, 2013 at 9:18 AM, Anis KADRI <an...@gmail.com>
> wrote:
> >
> > > I gave some thought to this problem and I think we should just leave
> > > everything as is. Here's my reasoning:
> > >
> > > - Most web developers use a text editor (vim, sublime text, text mate,
> > > notepad++, ....) to edit their HTML/CSS/Javascript. I've never seen
> > > anyone use a fully fledged IDE to edit web assets. It would be like
> > > using Microsoft Word to edit a simple .TXT or .MD file
> > > - Other developers, people who write Java or Objective C, etc.. use
> > > Xcode, Eclipse, IntelliJ, ...and I think these people are not good
> > > candidates for cordova-cli.
> > >
> > > The original PhoneGap promise (now Apache Cordova) was to make it easy
> > > for Web Developers to write Mobile Apps using web technologies and I
> > > believe that promise is fulfilled with cordova-cli. You have a folder
> > > where you drop in your web assets and you can build/deploy to a device
> > > or simulate.
> > >
> > > If people want to use an IDE, then they should be creating native
> > > projects with our create scripts and use plugman to manage their
> > > plugins.
> > >
> > > Our documentation should point our users to the right approach
> > > depending on the use case. For example:
> > >
> > > - Building for only one platform ? Building a hybrid app ? Want to use
> > > an IDE (Eclipse, Xcode) ? You should use the create scripts and
> > > plugman to manage plugins
> > >
> > > - Building a cross-platform app ? Like managing your project from the
> > > command-line ? Want to use your favo(u)rite text editor ? Use
> > > cordova-cli
> > >
> > > These double symlinking, backsyncing solutions will be a source of
> > > confusion and issues in my humble opinion. I've said it before but
> > > sometimes by trying to please everyone you end up pleasing no one.
> > >
> > > my .02c
> > >
> > > -a
> > >
> > > On Fri, Sep 27, 2013 at 8:20 PM, Michal Mocny <mm...@chromium.org>
> > wrote:
> > > > On Fri, Sep 27, 2013 at 2:10 PM, Andrew Grieve <agrieve@chromium.org
> >
> > > wrote:
> > > >
> > > >> Just tried some symlinks in Xcode 5:
> > > >> - Copying assets work (due to our custom build step)
> > > >> - Building works (compiler follows links just fine)
> > > >> - Editing a fail (big fail. Files open but changes cannot be saved.)
> > > >>
> > > >
> > > > Hmm, changes via xcode to symlinks fail, you mean?  That would be
> hard
> > to
> > > > fix, but perhaps at least its feedback to the user not to make direct
> > > edits
> > > > there, when using CLI workflow ;) so may still be a valid change to
> > make.
> > > >
> > > >
> > > >>
> > > >> For Xcode though, it is an option to change our installation step to
> > > have
> > > >> Xcode reference the native files within plugins/ rather than within
> > > >> platforms/.
> > > >>
> > > >>
> > > >> Symlinks in Eclipse:
> > > >> - Copying assets works out-of-the-box
> > > >> - Build works fine
> > > >> - Editing seems to work fine (edits saved to symlinked location).
> > > >>
> > > >>
> > > >>
> > > >> Still though, maybe the best solution would be a combination of the
> > two?
> > > >> Have prepare know when an remove+add is necessary?
> > > >>
> > > >
> > > > Yes, I think thats what we are suggesting.
> > > >
> > > > The original email mentioned prepare knowing when remove+add are
> > > necessary,
> > > > which I think is already settled as a good idea.  Not sure if you had
> > > more
> > > > to add about how prepare should know when to do this (currently, its
> > only
> > > > on plugin.xml changes).
> > > > The more recent suggestions about making links between
> platform&plugins
> > > > were additional requests to address the rest of the workflow issues
> > (ie,
> > > > most users prefer to edit inside platforms/ folder because of IDE
> > > > integration etc).
> > > >
> > > > Were you implying anything different here?
> > > >
> > > >
> > > >>
> > > >> On Fri, Sep 27, 2013 at 6:25 PM, Michal Mocny <mm...@chromium.org>
> > > wrote:
> > > >>
> > > >> > Have we not previously solved the symlink problem in xcode with a
> > > build
> > > >> > hook, or was that for prepare step?
> > > >> >
> > > >> > The --link concept doesn't do anything for that platforms ->
> plugins
> > > file
> > > >> > mapping.  Its useful for mapping plugins/ to local source, but it
> > > doesn't
> > > >> > help with the problem Tyler mentions, right?
> > > >> >
> > > >> > -Michal
> > > >> >
> > > >> >
> > > >> > On Fri, Sep 27, 2013 at 1:20 PM, Braden Shepherdson <
> > > braden@chromium.org
> > > >> > >wrote:
> > > >> >
> > > >> > > Symlinks in platforms/ are a problem because Xcode doesn't
> honour
> > > them,
> > > >> > at
> > > >> > > least last time we tried it.
> > > >> > >
> > > >> > > I'm much more enthused about the --link concept than any
> syncing,
> > > >> though.
> > > >> > > Also if someone wants to sync, they can already use rsync to do
> it
> > > >> > > manually.
> > > >> > >
> > > >> > > Braden
> > > >> > >
> > > >> > >
> > > >> > > On Fri, Sep 27, 2013 at 11:45 AM, Andrew Grieve <
> > > agrieve@chromium.org
> > > >> > > >wrote:
> > > >> > >
> > > >> > > > I think it'd be good to enumerate our options for workflow
> > before
> > > we
> > > >> > > > decided on which to implement (or maybe choose multiple).
> > > >> > > >
> > > >> > > > Tyler's idea about a sync command seems like it would be
> handy.
> > > Edit
> > > >> > your
> > > >> > > > plugin files within platforms/, and then run `cordova plugin
> > > >> > copychanges
> > > >> > > > org.my.plugin` to do a reverse copy of the source files back
> to
> > > the
> > > >> > > install
> > > >> > > > source location of the plugin. Big caveat though is that you
> run
> > > the
> > > >> > risk
> > > >> > > > of prepare clobbering your changes. I think that's too killer
> a
> > > risk.
> > > >> > > >
> > > >> > > > Another thought is that we could use symlinks when running
> > > prepare.
> > > >> > Have
> > > >> > > > files within platforms/ symlink to files within plugins/, then
> > > >> symlink
> > > >> > > > again back to their original sources. Would this work with
> > > editors in
> > > >> > > > practice? I don't know, but worth exploring. Wikipedia says
> > > symlinks
> > > >> > work
> > > >> > > > on NTFS as of Vista.
> > > >> > > >
> > > >> > > > Braden / Michael - I think yours is a good idea as well.
> > > Although, I
> > > >> > > don't
> > > >> > > > think we should encourage people to edit files within
> plugins/.
> > > They
> > > >> > > should
> > > >> > > > edit their plugins from install point. We should record the
> > > install
> > > >> > path,
> > > >> > > > and maybe have prepare have a prepare --update-local-plugins.
> > > >> > > >
> > > >> > > > Any other ideas?
> > > >> > > >
> > > >> > > >
> > > >> > > >
> > > >> > > > On Fri, Sep 27, 2013 at 3:13 PM, Michael Sierra <
> > > msierra@adobe.com>
> > > >> > > wrote:
> > > >> > > >
> > > >> > > > > Can you please file JIRAs on doc problems like this?
> > Existing
> > > >> > > overview
> > > >> > > > > doc says you can use the CLI to bootstrap & hand off to an
> > SDK &
> > > >> > > > supporting
> > > >> > > > > platform command-line utilities.  I take your comment to
> mean
> > > doc
> > > >> > > should
> > > >> > > > > better stress that once you start working with platform
> tools
> > > >> > > downstream,
> > > >> > > > > you can't go back to the CLI. Correct?
> > > >> > > > >
> > > >> > > > > --Mike Sierra
> > > >> > > > >
> > > >> > > > >
> > > >> > > > > ________________________________________
> > > >> > > > > From: Tyler Wilson [twilson@pulse-robotics.com]
> > > >> > > > > Sent: Thursday, September 26, 2013 8:19 PM
> > > >> > > > > To: dev@cordova.apache.org
> > > >> > > > > Subject: Re: Updating plugin code on prepare
> > > >> > > > >
> > > >> > > > > Re: IDEs: if it is the case that the CLI should not be used
> > > along
> > > >> > with
> > > >> > > an
> > > >> > > > > IDE, perhaps the documentation - including Getting Started
> > > Guides,
> > > >> > > etc. -
> > > >> > > > > ought to be much clearer about this. Perhaps a big warning
> > that
> > > >> > "Xcode
> > > >> > > > > project files are created by the CLI, but they should not be
> > > opened
> > > >> > and
> > > >> > > > > used by Xcode. And you definitely should not edit code
> within
> > > the
> > > >> > IDE".
> > > >> > > > >
> > > >> > > > > I just went to the main documentation site here -
> > > >> > > > >
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > >
> >
> http://cordova.apache.org/docs/en/3.0.0/guide_overview_index.md.html#Overview-anditappearsitonlymentionsthe new CLI interface. No mention of the
> > > >> > > > > old bin/create method. Seems to me there may be
> communication
> > > >> problem
> > > >> > > > here.
> > > >> > > > >
> > > >> > > > > Thanks,
> > > >> > > > > Tyler
> > > >> > > > >
> > > >> > > > > On Sep 26, 2013, at 6:11 PM, Anis KADRI <
> anis.kadri@gmail.com
> > >
> > > >> > wrote:
> > > >> > > > >
> > > >> > > > > > @purplecabbage: I have the same workflow but I think the
> > > proposed
> > > >> > > > > > solution is a step in the right direction. It would allow
> us
> > > to
> > > >> > > easily
> > > >> > > > > > develop platform plugins without having to delete
> > > project/create
> > > >> > > > > > project/install plugin/uninstall plugin constantly. The
> > plugin
> > > >> > would
> > > >> > > > > > be packaged (plugin.xml) from day 1 and one can only focus
> > on
> > > >> > > > > > development.
> > > >> > > > > >
> > > >> > > > > > As far as IDEs, the answer is simple. You should not use
> > IDEs
> > > and
> > > >> > > > > > cordova-cli at the same time. Until IDEs are aware of
> > > cordova-cli
> > > >> > > > > > there is no point in creating projects with cordova-cli
> > > because
> > > >> > > > > > everything gets blown on every build. I am not even sure
> we
> > > can
> > > >> > make
> > > >> > > > > > Xcode aware of cordova-cli. We've already talked about
> this
> > > prior
> > > >> > to
> > > >> > > > > > the 3.0 release and that is why we have the create scripts
> > and
> > > >> > > plugman
> > > >> > > > > > approach. You should not be using cordova-cli either if
> > you're
> > > >> > doing
> > > >> > > > > > some custom native dev that can't be pluginized (changing
> > the
> > > >> main
> > > >> > > > > > Activity.java or AppDelegate.m or whatever). If you're
> using
> > > >> > > > > > cordova-cli just to create a project and then open an IDE
> to
> > > >> > develop,
> > > >> > > > > > you're probably doing it wrong. You should be creating a
> > > native
> > > >> > > > > > project and using plugman instead.
> > > >> > > > > >
> > > >> > > > > > On Thu, Sep 26, 2013 at 9:01 PM, Michal Mocny <
> > > >> mmocny@chromium.org
> > > >> > >
> > > >> > > > > wrote:
> > > >> > > > > >> On Thu, Sep 26, 2013 at 1:39 PM, Jesse <
> > > purplecabbage@gmail.com
> > > >> >
> > > >> > > > wrote:
> > > >> > > > > >>
> > > >> > > > > >>> What does a watch mean?
> > > >> > > > > >>> - if I reboot, is it still watched?
> > > >> > > > > >>>
> > > >> > > > > >>
> > > >> > > > > >> No, this would start a process that lives until you
> CTRL+C.
> > >  You
> > > >> > > could
> > > >> > > > > have
> > > >> > > > > >> it run it in the background, or set it to start of
> startup,
> > > but
> > > >> > that
> > > >> > > > > would
> > > >> > > > > >> be using local system tools, not part of the command
> > itself.
> > > >> > > > > >>
> > > >> > > > > >> Ideally, "watch" should run "prepare" whenever you would
> > have
> > > >> > wanted
> > > >> > > > it
> > > >> > > > > to.
> > > >> > > > > >> Though obviously that cannot be perfect, it can be a
> useful
> > > tool
> > > >> > > when
> > > >> > > > > >> iterating.
> > > >> > > > > >>
> > > >> > > > > >>
> > > >> > > > > >>>
> > > >> > > > > >>> I think it would be best to consider separating
> > development
> > > >> from
> > > >> > > > > packaging
> > > >> > > > > >>> in your use-case for workflow.
> > > >> > > > > >>> If I am going to develop featureX as a plugin I would :
> > > >> > > > > >>>
> > > >> > > > > >>> 1. create a project for a single cordova platform, and
> > > develop
> > > >> > the
> > > >> > > > > feature
> > > >> > > > > >>> as a native piece, and a js piece.
> > > >> > > > > >>> 2. test thoroughly
> > > >> > > > > >>> 3. create a project for a second cordova platform, and
> > > develop
> > > >> > the
> > > >> > > > > native
> > > >> > > > > >>> bit, preserving the js from 1
> > > >> > > > > >>> 4. test thoroughly
> > > >> > > > > >>> 5. repeat steps 3+4 for any remaining platforms
> > > >> > > > > >>> 6. package featureX as a plugin by organizing relevant
> > bits
> > > in
> > > >> > the
> > > >> > > > > correct
> > > >> > > > > >>> folder structure, and adding a plugin.xml
> > > >> > > > > >>> 7. test each platform by installing with plugman
> > > >> > > > > >>> 8. publish
> > > >> > > > > >>>
> > > >> > > > > >>
> > > >> > > > > >> As a plugin developer, that is not my workflow.
> > > >> > > > > >>
> > > >> > > > > >> Typically for me its:
> > > >> > > > > >>
> > > >> > > > > >> Write a sample app/manual test for some new feature that
> > > isn't
> > > >> > > > > implemented
> > > >> > > > > >> yet.
> > > >> > > > > >> Create a new plugin Foo for iOS & Android, and stub the
> > > >> > > > implementation.
> > > >> > > > > >> Implement feature A of plugin Foo for iOS, test, add it
> for
> > > >> > Android,
> > > >> > > > > test.
> > > >> > > > > >> Implement feature B of plugin Foo for iOS, test, add it
> for
> > > >> > Android,
> > > >> > > > > test.
> > > >> > > > > >> ...
> > > >> > > > > >>
> > > >> > > > > >> Usually the js implementation is shared, the auto tests
> are
> > > >> > shared,
> > > >> > > > and
> > > >> > > > > the
> > > >> > > > > >> sample test app is shared.
> > > >> > > > > >>
> > > >> > > > > >> Sure, I do platform specific stuff for testing and
> > > >> implementation,
> > > >> > > > but I
> > > >> > > > > >> certainly wouldn't say I do plugin development in
> platform
> > > >> > > isolation.
> > > >> > > > > >>
> > > >> > > > > >> Also, right now we do not have a "plugin create" command,
> > > and so
> > > >> > > > leaving
> > > >> > > > > >> the "packaging" step for last doesn't add affect total
> > work.
> > > >>  But
> > > >> > > once
> > > >> > > > > we
> > > >> > > > > >> do have such a command, plugins could start packaged, and
> > > adding
> > > >> > the
> > > >> > > > > small
> > > >> > > > > >> changes to plugin.xml as you need them is likely a good
> way
> > > to
> > > >> go.
> > > >> > > > > >>
> > > >> > > > > >> Finally, this workflow would get people out of the habit
> of
> > > >> making
> > > >> > > > > changes
> > > >> > > > > >> to the platform artifacts directly.  I'm not sure that
> can
> > be
> > > >> > > entirely
> > > >> > > > > >> avoided in all cases, but why shouldn't we work towards
> > > making
> > > >> > that
> > > >> > > > > easier?
> > > >> > > > > >>
> > > >> > > > > >>
> > > >> > > > > >>> We seem to have this notion come up repeatedly that our
> > > users +
> > > >> > > > plugin
> > > >> > > > > >>> developers are working on multiple platforms at the same
> > > time,
> > > >> > > which
> > > >> > > > I
> > > >> > > > > >>> think is entirely false.
> > > >> > > > > >>>
> > > >> > > > > >>
> > > >> > > > > >> Since we differ in opinion, how can we put this to the
> > test?
> > > >> > > > > >>
> > > >> > > > > >> Also, we specifically make sure all our features address
> > the
> > > >> needs
> > > >> > > of
> > > >> > > > > those
> > > >> > > > > >> doing single platform development, so in a world of 3.0+
> > > cli, I
> > > >> > > really
> > > >> > > > > >> don't see how we can not do the same to address the needs
> > of
> > > >> those
> > > >> > > who
> > > >> > > > > do
> > > >> > > > > >> do multi-platform development, especially when we have a
> > good
> > > >> > > proposal
> > > >> > > > > of
> > > >> > > > > >> how to do so and someone willing to do it.
> > > >> > > > > >>
> > > >> > > > > >>
> > > >> > > > > >>> I also think we're trying to help the wrong people; If I
> > am
> > > a
> > > >> > > > > developer who
> > > >> > > > > >>> is working on multiple platforms at once, and I have a
> > > bunch of
> > > >> > > > devices
> > > >> > > > > >>> attached, I probably also have the skills to set up my
> own
> > > >> grunt
> > > >> > > > > continuous
> > > >> > > > > >>> integration system. Setting up tooling for potential
> > plugin
> > > >> > > > developers
> > > >> > > > > is
> > > >> > > > > >>> the wrong approach, imho. We should actually just go and
> > > >> > implement
> > > >> > > > > some new
> > > >> > > > > >>> plugin and evaluate the process instead of creating and
> > > >> imposing
> > > >> > a
> > > >> > > > > specific
> > > >> > > > > >>> workflow.
> > > >> > > > > >>>
> > > >> > > > > >>
> > > >> > > > > >> The first part of this argument has some merit, I agree.
> >  We
> > > the
> > > >> > > > > >> power-users have found ways to address our problems.
> > >  However, I
> > > >> > > think
> > > >> > > > > that
> > > >> > > > > >> with this change it means that even the end user can make
> > > >> changes
> > > >> > to
> > > >> > > > > plugin
> > > >> > > > > >> folder as they find bugs/etc, and expect to see the
> change
> > > >> > reflected
> > > >> > > > > after
> > > >> > > > > >> running prepare.  This is principle of least surprise,
> and
> > > just
> > > >> > good
> > > >> > > > > design.
> > > >> > > > > >>
> > > >> > > > > >> I also don't think we are imposing any specific workflow
> > > here,
> > > >> > just
> > > >> > > > > >> enabling a new one.  Personally I think that its quite
> > > >> surprising
> > > >> > > and
> > > >> > > > > >> embarrassing that we haven't enabled this workflow since
> > 3.0.
> > > >> > > > > >>
> > > >> > > > > >>
> > > >> > > > > >>>
> > > >> > > > > >>>
> > > >> > > > > >>>
> > > >> > > > > >>>
> > > >> > > > > >>>
> > > >> > > > > >>>
> > > >> > > > > >>>
> > > >> > > > > >>>
> > > >> > > > > >>>
> > > >> > > > > >>> @purplecabbage
> > > >> > > > > >>> risingj.com
> > > >> > > > > >>>
> > > >> > > > > >>>
> > > >> > > > > >>> On Thu, Sep 26, 2013 at 10:09 AM, Brian LeRoux <
> > b@brian.io>
> > > >> > wrote:
> > > >> > > > > >>>
> > > >> > > > > >>>> I love the idea of a watch command.
> > > >> > > > > >>>>
> > > >> > > > > >>>>
> > > >> > > > > >>>> On Thu, Sep 26, 2013 at 4:48 PM, Anis KADRI <
> > > >> > anis.kadri@gmail.com
> > > >> > > >
> > > >> > > > > >>> wrote:
> > > >> > > > > >>>>
> > > >> > > > > >>>>> Forgot about the existence of --link for a second. I
> > think
> > > >> this
> > > >> > > is
> > > >> > > > a
> > > >> > > > > >>>>> good solution (not temporary). watch can be an
> > > enhancement to
> > > >> > > this
> > > >> > > > > >>>>> solution. This might get people like Joe Bowser and
> > other
> > > >> > people
> > > >> > > > who
> > > >> > > > > >>>>> do native dev to give cordova-cli a try (only maybe
> > > though).
> > > >> > > > > >>>>>
> > > >> > > > > >>>>> On Thu, Sep 26, 2013 at 4:25 PM, Braden Shepherdson <
> > > >> > > > > >>> braden@chromium.org
> > > >> > > > > >>>>>
> > > >> > > > > >>>>> wrote:
> > > >> > > > > >>>>>> If the proposal above is temporary, what's permanent?
> > > >> cordova
> > > >> > > > watch?
> > > >> > > > > >>> I
> > > >> > > > > >>>>> want
> > > >> > > > > >>>>>> to make sure we're on the same page.
> > > >> > > > > >>>>>>
> > > >> > > > > >>>>>> Braden
> > > >> > > > > >>>>>>
> > > >> > > > > >>>>>>
> > > >> > > > > >>>>>> On Thu, Sep 26, 2013 at 6:08 AM, Anis KADRI <
> > > >> > > anis.kadri@gmail.com
> > > >> > > > >
> > > >> > > > > >>>>> wrote:
> > > >> > > > > >>>>>>
> > > >> > > > > >>>>>>> No I didn't mean implement `plugman --watch`. I
> don't
> > > think
> > > >> > > > plugman
> > > >> > > > > >>>>>>> needs a `watch` command.
> > > >> > > > > >>>>>>>
> > > >> > > > > >>>>>>> I was indeed talking about `cordova watch` which
> > should
> > > >> watch
> > > >> > > for
> > > >> > > > > >>>>>>> changes in plugins/ (and maybe in merges/ and www/
> as
> > > well)
> > > >> > and
> > > >> > > > > >>> update
> > > >> > > > > >>>>>>> the platform projects (prepare?) on every change.  I
> > am
> > > >> happy
> > > >> > > to
> > > >> > > > > >>> know
> > > >> > > > > >>>>>>> that it's on the wish list.
> > > >> > > > > >>>>>>>
> > > >> > > > > >>>>>>> As far as the original proposal, I believe it is a
> > > descent
> > > >> > > > > temporary
> > > >> > > > > >>>>>>> solution for plugin developers who want to use
> > > cordova-cli.
> > > >> > > > > >>>>>>>
> > > >> > > > > >>>>>>> On Wed, Sep 25, 2013 at 7:17 PM, Michal Mocny <
> > > >> > > > mmocny@chromium.org
> > > >> > > > > >
> > > >> > > > > >>>>> wrote:
> > > >> > > > > >>>>>>>> Braden, thats has been on the wish list (cordova
> > > watch),
> > > >> > but I
> > > >> > > > > >>>> suspect
> > > >> > > > > >>>>>>> Anis
> > > >> > > > > >>>>>>>> was suggesting something different with plugman
> > > --watch,
> > > >> to
> > > >> > do
> > > >> > > > > >>>>>>> specifically
> > > >> > > > > >>>>>>>> with plugin development.  Am I right, Anis?  How
> does
> > > your
> > > >> > > idea
> > > >> > > > > >>>>> compare
> > > >> > > > > >>>>>>>> with using --link with cordova watch?  Would
> plugman
> > > >> --watch
> > > >> > > be
> > > >> > > > > >>>> useful
> > > >> > > > > >>>>>>> for
> > > >> > > > > >>>>>>>> non cli projects?
> > > >> > > > > >>>>>>>>
> > > >> > > > > >>>>>>>> -Michal
> > > >> > > > > >>>>>>>>
> > > >> > > > > >>>>>>>>
> > > >> > > > > >>>>>>>> On Wed, Sep 25, 2013 at 10:31 AM, Braden
> Shepherdson
> > <
> > > >> > > > > >>>>>>> braden@chromium.org>wrote:
> > > >> > > > > >>>>>>>>
> > > >> > > > > >>>>>>>>> We've had a vague feature planned for a while now
> to
> > > do a
> > > >> > > > cordova
> > > >> > > > > >>>>>>> watch. It
> > > >> > > > > >>>>>>>>> would watch your plugins/, www/, and merges/* for
> > any
> > > >> > > changes.
> > > >> > > > If
> > > >> > > > > >>>> any
> > > >> > > > > >>>>>>>>> changes are detected, it would re-run cordova
> > > prepare, so
> > > >> > > that
> > > >> > > > > >>> your
> > > >> > > > > >>>>>>> native
> > > >> > > > > >>>>>>>>> projects are always up-to-date.
> > > >> > > > > >>>>>>>>>
> > > >> > > > > >>>>>>>>> I'm open to checking (hashes?) which files have
> > > changed
> > > >> and
> > > >> > > > which
> > > >> > > > > >>>>> have
> > > >> > > > > >>>>>>> not,
> > > >> > > > > >>>>>>>>> but hashing them all is touching them all anyway,
> > and
> > > it
> > > >> > > might
> > > >> > > > be
> > > >> > > > > >>>>> faster
> > > >> > > > > >>>>>>>>> for small files to just copy them instead of
> > checking
> > > >> > first.
> > > >> > > > > >>> We'll
> > > >> > > > > >>>>> have
> > > >> > > > > >>>>>>> to
> > > >> > > > > >>>>>>>>> try it and see; for v1 I'm going with the simple
> > > option
> > > >> of
> > > >> > > > > >>> copying
> > > >> > > > > >>>>>>>>> everything.
> > > >> > > > > >>>>>>>>>
> > > >> > > > > >>>>>>>>> Braden
> > > >> > > > > >>>>>>>>>
> > > >> > > > > >>>>>>>>>
> > > >> > > > > >>>>>>>>> On Wed, Sep 25, 2013 at 9:44 AM, Michal Mocny <
> > > >> > > > > >>> mmocny@chromium.org
> > > >> > > > > >>>>>
> > > >> > > > > >>>>>>> wrote:
> > > >> > > > > >>>>>>>>>
> > > >> > > > > >>>>>>>>>> The idea for plugin dev outside of plugins/
> folder
> > > was
> > > >> to
> > > >> > > use
> > > >> > > > > >>>>> "plugin
> > > >> > > > > >>>>>>> add
> > > >> > > > > >>>>>>>>>> --link".  Matter of fact, braden suggested that
> > > "plugin
> > > >> > > > create"
> > > >> > > > > >>>>> should
> > > >> > > > > >>>>>>>>>> default to --link-ing to some external location
> so
> > > that
> > > >> > you
> > > >> > > > > >>> don't
> > > >> > > > > >>>>> risk
> > > >> > > > > >>>>>>>>>> deleting your only copy inside plugins/.  (I
> > > personally
> > > >> > > don't
> > > >> > > > > >>>> think
> > > >> > > > > >>>>>>>>> thats a
> > > >> > > > > >>>>>>>>>> necessary concern, but I think its a conversation
> > for
> > > >> > > later).
> > > >> > > > > >>>>>>>>>>
> > > >> > > > > >>>>>>>>>> I'm not even sure what a 'watch' would do, just
> > > >> uninstall
> > > >> > &
> > > >> > > > > >>>> install
> > > >> > > > > >>>>>>> each
> > > >> > > > > >>>>>>>>>> time the plugin changes?  I think that ends up
> > being
> > > >> just
> > > >> > > > > >>>> slightly
> > > >> > > > > >>>>>>> worse
> > > >> > > > > >>>>>>>>>> than the current proposal if you factor in that
> we
> > > >> already
> > > >> > > do
> > > >> > > > > >>>>> support
> > > >> > > > > >>>>>>>>>> --link (except without the above change its been
> > > >> useless).
> > > >> > > > > >>>>>>>>>>
> > > >> > > > > >>>>>>>>>>
> > > >> > > > > >>>>>>>>>> However, we may still want some form of 'watch'
> > > command
> > > >> > for
> > > >> > > > > >>> devs
> > > >> > > > > >>>>> using
> > > >> > > > > >>>>>>>>>> plugman directly.  I had assumed that those devs
> > just
> > > >> edit
> > > >> > > in
> > > >> > > > > >>>>> place,
> > > >> > > > > >>>>>>>>> since
> > > >> > > > > >>>>>>>>>> they don't use a prepare step anyway.
> > > >> > > > > >>>>>>>>>>
> > > >> > > > > >>>>>>>>>> -Michal
> > > >> > > > > >>>>>>>>>>
> > > >> > > > > >>>>>>>>>>
> > > >> > > > > >>>>>>>>>>
> > > >> > > > > >>>>>>>>>> On Wed, Sep 25, 2013 at 7:50 AM, Anis KADRI <
> > > >> > > > > >>>> anis.kadri@gmail.com>
> > > >> > > > > >>>>>>>>> wrote:
> > > >> > > > > >>>>>>>>>>
> > > >> > > > > >>>>>>>>>>> If we're talking about developing plugins inside
> > the
> > > >> > > > > >>>>>>>>>>> plugins/org.myplugin.id folder than I think
> it's
> > a
> > > >> great
> > > >> > > > > >>>>> workflow
> > > >> > > > > >>>>>>> and
> > > >> > > > > >>>>>>>>>>> I would just hide the cached version of
> plugin.xml
> > > >> inside
> > > >> > > > > >>> that
> > > >> > > > > >>>>>>>>>>> plugins/org.myplugin.id folder.
> > > >> > > > > >>>>>>>>>>>
> > > >> > > > > >>>>>>>>>>> However, if you're developing a plugin outside
> of
> > a
> > > >> > cordova
> > > >> > > > > >>> CLI
> > > >> > > > > >>>>>>>>>>> project, I think a `watch` (and add --watch)
> > > command is
> > > >> > > more
> > > >> > > > > >>>>>>>>>>> appropriate. One of the reasons you would
> develop
> > a
> > > >> > plugin
> > > >> > > > > >>>>> outside
> > > >> > > > > >>>>>>> of
> > > >> > > > > >>>>>>>>>>> a cordova CLI project is for easier version
> > control
> > > >> (each
> > > >> > > > > >>>> plugin
> > > >> > > > > >>>>>>> would
> > > >> > > > > >>>>>>>>>>> have its own repository). The other cool thing
> > about
> > > >> > > `watch`
> > > >> > > > > >>> is
> > > >> > > > > >>>>> that
> > > >> > > > > >>>>>>>>>>> it would copy the files that have actually
> changed
> > > and
> > > >> > not
> > > >> > > > > >>>>>>> everything
> > > >> > > > > >>>>>>>>>>> (some plugins have a LOT of files [1]).
> > > >> > > > > >>>>>>>>>>>
> > > >> > > > > >>>>>>>>>>> [1]
> > > >> https://github.com/phonegap/phonegap-facebook-plugin
> > > >> > > > > >>>>>>>>>>>
> > > >> > > > > >>>>>>>>>>> On Wed, Sep 25, 2013 at 3:30 AM, James Jong <
> > > >> > > > > >>>>> wjamesjong@gmail.com>
> > > >> > > > > >>>>>>>>>> wrote:
> > > >> > > > > >>>>>>>>>>>> +1 This is a cleaner workflow and should reduce
> > > some
> > > >> > > > > >>>> confusion.
> > > >> > > > > >>>>>>>>>>>>
> > > >> > > > > >>>>>>>>>>>> -James Jong
> > > >> > > > > >>>>>>>>>>>>
> > > >> > > > > >>>>>>>>>>>> On Sep 24, 2013, at 3:09 PM, Michal Mocny <
> > > >> > > > > >>>> mmocny@chromium.org
> > > >> > > > > >>>>>>
> > > >> > > > > >>>>>>>>> wrote:
> > > >> > > > > >>>>>>>>>>>>
> > > >> > > > > >>>>>>>>>>>>> Just to add, the reason for the "if" statement
> > in
> > > >> step
> > > >> > > (2)
> > > >> > > > > >>>> is
> > > >> > > > > >>>>>>> that
> > > >> > > > > >>>>>>>>>>>>> uninstall & reinstall take a lot longer than
> > just
> > > >> > moving
> > > >> > > a
> > > >> > > > > >>>> few
> > > >> > > > > >>>>>>>>> files,
> > > >> > > > > >>>>>>>>>>> which
> > > >> > > > > >>>>>>>>>>>>> is the 99.9% case for most end users who
> aren't
> > > >> making
> > > >> > > > > >>>>>>> modifications
> > > >> > > > > >>>>>>>>>> to
> > > >> > > > > >>>>>>>>>>>>> plugins.
> > > >> > > > > >>>>>>>>>>>>>
> > > >> > > > > >>>>>>>>>>>>> This way, we only do the heavy lifting if your
> > > plugin
> > > >> > > > > >>>>> structure
> > > >> > > > > >>>>>>>>>> actually
> > > >> > > > > >>>>>>>>>>>>> changed.  Doing it automatically means we no
> > > longer
> > > >> > have
> > > >> > > > > >>> to
> > > >> > > > > >>>>>>> advise
> > > >> > > > > >>>>>>>>>> users
> > > >> > > > > >>>>>>>>>>>>> that making edits inside plugin/ folder is
> > > useless.
> > > >> >  Now
> > > >> > > > > >>> we
> > > >> > > > > >>>>> just
> > > >> > > > > >>>>>>>>>> advise
> > > >> > > > > >>>>>>>>>>>>> them to run "prepare" after making changes to
> > > either
> > > >> > www/
> > > >> > > > > >>> or
> > > >> > > > > >>>>>>>>> plugins/.
> > > >> > > > > >>>>>>>>>>>>>
> > > >> > > > > >>>>>>>>>>>>> This key insight was Braden's idea and I think
> > its
> > > >> just
> > > >> > > an
> > > >> > > > > >>>>>>> awesome
> > > >> > > > > >>>>>>>>>>> change
> > > >> > > > > >>>>>>>>>>>>> for workflow.
> > > >> > > > > >>>>>>>>>>>>>
> > > >> > > > > >>>>>>>>>>>>> -Michal
> > > >> > > > > >>>>>>>>>>>>>
> > > >> > > > > >>>>>>>>>>>>>
> > > >> > > > > >>>>>>>>>>>>> On Tue, Sep 24, 2013 at 2:58 PM, Braden
> > > Shepherdson <
> > > >> > > > > >>>>>>>>>>> braden@chromium.org>wrote:
> > > >> > > > > >>>>>>>>>>>>>
> > > >> > > > > >>>>>>>>>>>>>> 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
> > > >> > > > > >>>>>>>>>>>>>>
> > > >> > > > > >>>>>>>>>>>>
> > > >> > > > > >>>>>>>>>>>
> > > >> > > > > >>>>>>>>>>
> > > >> > > > > >>>>>>>>>
> > > >> > > > > >>>>>>>
> > > >> > > > > >>>>>
> > > >> > > > > >>>>
> > > >> > > > > >>>
> > > >> > > > >
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > >
> >
> >
> >
> > --
> > Carlos Santana
> > <cs...@gmail.com>
> >
>

Re: Updating plugin code on prepare

[Braden Shepherdson <br...@chromium.org>]

I agree that the syncing solutions are too complex and confusing.

I return, then, to my original proposal all those emails ago: updating the
native plugin files in platforms/foo when you prepare, to make life easier
for plugin developers. When coupled with the present cordova plugin add
--link, and future cordova watch, I think this makes the plugin developer
flow pretty good, and without making it too magical or harder to
understand. I think it simplifies prepare: on prepare, your native projects
are updated to reflect the state of plugins/ and www/. Right now, only
www/, <asset>s and <js-module>s get updated, but not native code.

As to Xcode and symlinks and all the rest of the borderline thread
hijacking, I think that regardless of what editor you use, you have to be
editing the right file. Xcode and Eclipse make this harder than it needs to
be, but our job is not to make them suck less.

Braden


On Sun, Sep 29, 2013 at 1:43 PM, Carlos Santana <cs...@gmail.com>wrote:

> +1 Anis
> corodova-cli/plugman should be building block components to higher level
> Tools/IDE.
>
> That we can do better sure, lets provide a few examples using blog pots and
> maybe videos tutorials vs. trying to support every use case with code.
>
> A watch function could be as simple as using "grunt-contrib-watch" to a
> more complicated environment like "rsync/Eclipse"
>
> I agree lets put emphasis on documenting use cases and the correct
> approach.
> When to get the best out of using prepare,  merges, and hooks
>
> All I said applies when you have the "Web Developer" hat.
>
> For people that have the "Native Plugin Developer" hat then we can do
> things first for cordova-contributors than others can choose to use on
> their own risk since it could be changing too fast and maybe too narrow use
> case.
>
> --Carlos
>
> --Carlos
>
>
>
> On Sun, Sep 29, 2013 at 9:18 AM, Anis KADRI <an...@gmail.com> wrote:
>
> > I gave some thought to this problem and I think we should just leave
> > everything as is. Here's my reasoning:
> >
> > - Most web developers use a text editor (vim, sublime text, text mate,
> > notepad++, ....) to edit their HTML/CSS/Javascript. I've never seen
> > anyone use a fully fledged IDE to edit web assets. It would be like
> > using Microsoft Word to edit a simple .TXT or .MD file
> > - Other developers, people who write Java or Objective C, etc.. use
> > Xcode, Eclipse, IntelliJ, ...and I think these people are not good
> > candidates for cordova-cli.
> >
> > The original PhoneGap promise (now Apache Cordova) was to make it easy
> > for Web Developers to write Mobile Apps using web technologies and I
> > believe that promise is fulfilled with cordova-cli. You have a folder
> > where you drop in your web assets and you can build/deploy to a device
> > or simulate.
> >
> > If people want to use an IDE, then they should be creating native
> > projects with our create scripts and use plugman to manage their
> > plugins.
> >
> > Our documentation should point our users to the right approach
> > depending on the use case. For example:
> >
> > - Building for only one platform ? Building a hybrid app ? Want to use
> > an IDE (Eclipse, Xcode) ? You should use the create scripts and
> > plugman to manage plugins
> >
> > - Building a cross-platform app ? Like managing your project from the
> > command-line ? Want to use your favo(u)rite text editor ? Use
> > cordova-cli
> >
> > These double symlinking, backsyncing solutions will be a source of
> > confusion and issues in my humble opinion. I've said it before but
> > sometimes by trying to please everyone you end up pleasing no one.
> >
> > my .02c
> >
> > -a
> >
> > On Fri, Sep 27, 2013 at 8:20 PM, Michal Mocny <mm...@chromium.org>
> wrote:
> > > On Fri, Sep 27, 2013 at 2:10 PM, Andrew Grieve <ag...@chromium.org>
> > wrote:
> > >
> > >> Just tried some symlinks in Xcode 5:
> > >> - Copying assets work (due to our custom build step)
> > >> - Building works (compiler follows links just fine)
> > >> - Editing a fail (big fail. Files open but changes cannot be saved.)
> > >>
> > >
> > > Hmm, changes via xcode to symlinks fail, you mean?  That would be hard
> to
> > > fix, but perhaps at least its feedback to the user not to make direct
> > edits
> > > there, when using CLI workflow ;) so may still be a valid change to
> make.
> > >
> > >
> > >>
> > >> For Xcode though, it is an option to change our installation step to
> > have
> > >> Xcode reference the native files within plugins/ rather than within
> > >> platforms/.
> > >>
> > >>
> > >> Symlinks in Eclipse:
> > >> - Copying assets works out-of-the-box
> > >> - Build works fine
> > >> - Editing seems to work fine (edits saved to symlinked location).
> > >>
> > >>
> > >>
> > >> Still though, maybe the best solution would be a combination of the
> two?
> > >> Have prepare know when an remove+add is necessary?
> > >>
> > >
> > > Yes, I think thats what we are suggesting.
> > >
> > > The original email mentioned prepare knowing when remove+add are
> > necessary,
> > > which I think is already settled as a good idea.  Not sure if you had
> > more
> > > to add about how prepare should know when to do this (currently, its
> only
> > > on plugin.xml changes).
> > > The more recent suggestions about making links between platform&plugins
> > > were additional requests to address the rest of the workflow issues
> (ie,
> > > most users prefer to edit inside platforms/ folder because of IDE
> > > integration etc).
> > >
> > > Were you implying anything different here?
> > >
> > >
> > >>
> > >> On Fri, Sep 27, 2013 at 6:25 PM, Michal Mocny <mm...@chromium.org>
> > wrote:
> > >>
> > >> > Have we not previously solved the symlink problem in xcode with a
> > build
> > >> > hook, or was that for prepare step?
> > >> >
> > >> > The --link concept doesn't do anything for that platforms -> plugins
> > file
> > >> > mapping.  Its useful for mapping plugins/ to local source, but it
> > doesn't
> > >> > help with the problem Tyler mentions, right?
> > >> >
> > >> > -Michal
> > >> >
> > >> >
> > >> > On Fri, Sep 27, 2013 at 1:20 PM, Braden Shepherdson <
> > braden@chromium.org
> > >> > >wrote:
> > >> >
> > >> > > Symlinks in platforms/ are a problem because Xcode doesn't honour
> > them,
> > >> > at
> > >> > > least last time we tried it.
> > >> > >
> > >> > > I'm much more enthused about the --link concept than any syncing,
> > >> though.
> > >> > > Also if someone wants to sync, they can already use rsync to do it
> > >> > > manually.
> > >> > >
> > >> > > Braden
> > >> > >
> > >> > >
> > >> > > On Fri, Sep 27, 2013 at 11:45 AM, Andrew Grieve <
> > agrieve@chromium.org
> > >> > > >wrote:
> > >> > >
> > >> > > > I think it'd be good to enumerate our options for workflow
> before
> > we
> > >> > > > decided on which to implement (or maybe choose multiple).
> > >> > > >
> > >> > > > Tyler's idea about a sync command seems like it would be handy.
> > Edit
> > >> > your
> > >> > > > plugin files within platforms/, and then run `cordova plugin
> > >> > copychanges
> > >> > > > org.my.plugin` to do a reverse copy of the source files back to
> > the
> > >> > > install
> > >> > > > source location of the plugin. Big caveat though is that you run
> > the
> > >> > risk
> > >> > > > of prepare clobbering your changes. I think that's too killer a
> > risk.
> > >> > > >
> > >> > > > Another thought is that we could use symlinks when running
> > prepare.
> > >> > Have
> > >> > > > files within platforms/ symlink to files within plugins/, then
> > >> symlink
> > >> > > > again back to their original sources. Would this work with
> > editors in
> > >> > > > practice? I don't know, but worth exploring. Wikipedia says
> > symlinks
> > >> > work
> > >> > > > on NTFS as of Vista.
> > >> > > >
> > >> > > > Braden / Michael - I think yours is a good idea as well.
> > Although, I
> > >> > > don't
> > >> > > > think we should encourage people to edit files within plugins/.
> > They
> > >> > > should
> > >> > > > edit their plugins from install point. We should record the
> > install
> > >> > path,
> > >> > > > and maybe have prepare have a prepare --update-local-plugins.
> > >> > > >
> > >> > > > Any other ideas?
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > > On Fri, Sep 27, 2013 at 3:13 PM, Michael Sierra <
> > msierra@adobe.com>
> > >> > > wrote:
> > >> > > >
> > >> > > > > Can you please file JIRAs on doc problems like this?
> Existing
> > >> > > overview
> > >> > > > > doc says you can use the CLI to bootstrap & hand off to an
> SDK &
> > >> > > > supporting
> > >> > > > > platform command-line utilities.  I take your comment to mean
> > doc
> > >> > > should
> > >> > > > > better stress that once you start working with platform tools
> > >> > > downstream,
> > >> > > > > you can't go back to the CLI. Correct?
> > >> > > > >
> > >> > > > > --Mike Sierra
> > >> > > > >
> > >> > > > >
> > >> > > > > ________________________________________
> > >> > > > > From: Tyler Wilson [twilson@pulse-robotics.com]
> > >> > > > > Sent: Thursday, September 26, 2013 8:19 PM
> > >> > > > > To: dev@cordova.apache.org
> > >> > > > > Subject: Re: Updating plugin code on prepare
> > >> > > > >
> > >> > > > > Re: IDEs: if it is the case that the CLI should not be used
> > along
> > >> > with
> > >> > > an
> > >> > > > > IDE, perhaps the documentation - including Getting Started
> > Guides,
> > >> > > etc. -
> > >> > > > > ought to be much clearer about this. Perhaps a big warning
> that
> > >> > "Xcode
> > >> > > > > project files are created by the CLI, but they should not be
> > opened
> > >> > and
> > >> > > > > used by Xcode. And you definitely should not edit code within
> > the
> > >> > IDE".
> > >> > > > >
> > >> > > > > I just went to the main documentation site here -
> > >> > > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> >
> http://cordova.apache.org/docs/en/3.0.0/guide_overview_index.md.html#Overview-anditappearsitonlymentions the new CLI interface. No mention of the
> > >> > > > > old bin/create method. Seems to me there may be communication
> > >> problem
> > >> > > > here.
> > >> > > > >
> > >> > > > > Thanks,
> > >> > > > > Tyler
> > >> > > > >
> > >> > > > > On Sep 26, 2013, at 6:11 PM, Anis KADRI <anis.kadri@gmail.com
> >
> > >> > wrote:
> > >> > > > >
> > >> > > > > > @purplecabbage: I have the same workflow but I think the
> > proposed
> > >> > > > > > solution is a step in the right direction. It would allow us
> > to
> > >> > > easily
> > >> > > > > > develop platform plugins without having to delete
> > project/create
> > >> > > > > > project/install plugin/uninstall plugin constantly. The
> plugin
> > >> > would
> > >> > > > > > be packaged (plugin.xml) from day 1 and one can only focus
> on
> > >> > > > > > development.
> > >> > > > > >
> > >> > > > > > As far as IDEs, the answer is simple. You should not use
> IDEs
> > and
> > >> > > > > > cordova-cli at the same time. Until IDEs are aware of
> > cordova-cli
> > >> > > > > > there is no point in creating projects with cordova-cli
> > because
> > >> > > > > > everything gets blown on every build. I am not even sure we
> > can
> > >> > make
> > >> > > > > > Xcode aware of cordova-cli. We've already talked about this
> > prior
> > >> > to
> > >> > > > > > the 3.0 release and that is why we have the create scripts
> and
> > >> > > plugman
> > >> > > > > > approach. You should not be using cordova-cli either if
> you're
> > >> > doing
> > >> > > > > > some custom native dev that can't be pluginized (changing
> the
> > >> main
> > >> > > > > > Activity.java or AppDelegate.m or whatever). If you're using
> > >> > > > > > cordova-cli just to create a project and then open an IDE to
> > >> > develop,
> > >> > > > > > you're probably doing it wrong. You should be creating a
> > native
> > >> > > > > > project and using plugman instead.
> > >> > > > > >
> > >> > > > > > On Thu, Sep 26, 2013 at 9:01 PM, Michal Mocny <
> > >> mmocny@chromium.org
> > >> > >
> > >> > > > > wrote:
> > >> > > > > >> On Thu, Sep 26, 2013 at 1:39 PM, Jesse <
> > purplecabbage@gmail.com
> > >> >
> > >> > > > wrote:
> > >> > > > > >>
> > >> > > > > >>> What does a watch mean?
> > >> > > > > >>> - if I reboot, is it still watched?
> > >> > > > > >>>
> > >> > > > > >>
> > >> > > > > >> No, this would start a process that lives until you CTRL+C.
> >  You
> > >> > > could
> > >> > > > > have
> > >> > > > > >> it run it in the background, or set it to start of startup,
> > but
> > >> > that
> > >> > > > > would
> > >> > > > > >> be using local system tools, not part of the command
> itself.
> > >> > > > > >>
> > >> > > > > >> Ideally, "watch" should run "prepare" whenever you would
> have
> > >> > wanted
> > >> > > > it
> > >> > > > > to.
> > >> > > > > >> Though obviously that cannot be perfect, it can be a useful
> > tool
> > >> > > when
> > >> > > > > >> iterating.
> > >> > > > > >>
> > >> > > > > >>
> > >> > > > > >>>
> > >> > > > > >>> I think it would be best to consider separating
> development
> > >> from
> > >> > > > > packaging
> > >> > > > > >>> in your use-case for workflow.
> > >> > > > > >>> If I am going to develop featureX as a plugin I would :
> > >> > > > > >>>
> > >> > > > > >>> 1. create a project for a single cordova platform, and
> > develop
> > >> > the
> > >> > > > > feature
> > >> > > > > >>> as a native piece, and a js piece.
> > >> > > > > >>> 2. test thoroughly
> > >> > > > > >>> 3. create a project for a second cordova platform, and
> > develop
> > >> > the
> > >> > > > > native
> > >> > > > > >>> bit, preserving the js from 1
> > >> > > > > >>> 4. test thoroughly
> > >> > > > > >>> 5. repeat steps 3+4 for any remaining platforms
> > >> > > > > >>> 6. package featureX as a plugin by organizing relevant
> bits
> > in
> > >> > the
> > >> > > > > correct
> > >> > > > > >>> folder structure, and adding a plugin.xml
> > >> > > > > >>> 7. test each platform by installing with plugman
> > >> > > > > >>> 8. publish
> > >> > > > > >>>
> > >> > > > > >>
> > >> > > > > >> As a plugin developer, that is not my workflow.
> > >> > > > > >>
> > >> > > > > >> Typically for me its:
> > >> > > > > >>
> > >> > > > > >> Write a sample app/manual test for some new feature that
> > isn't
> > >> > > > > implemented
> > >> > > > > >> yet.
> > >> > > > > >> Create a new plugin Foo for iOS & Android, and stub the
> > >> > > > implementation.
> > >> > > > > >> Implement feature A of plugin Foo for iOS, test, add it for
> > >> > Android,
> > >> > > > > test.
> > >> > > > > >> Implement feature B of plugin Foo for iOS, test, add it for
> > >> > Android,
> > >> > > > > test.
> > >> > > > > >> ...
> > >> > > > > >>
> > >> > > > > >> Usually the js implementation is shared, the auto tests are
> > >> > shared,
> > >> > > > and
> > >> > > > > the
> > >> > > > > >> sample test app is shared.
> > >> > > > > >>
> > >> > > > > >> Sure, I do platform specific stuff for testing and
> > >> implementation,
> > >> > > > but I
> > >> > > > > >> certainly wouldn't say I do plugin development in platform
> > >> > > isolation.
> > >> > > > > >>
> > >> > > > > >> Also, right now we do not have a "plugin create" command,
> > and so
> > >> > > > leaving
> > >> > > > > >> the "packaging" step for last doesn't add affect total
> work.
> > >>  But
> > >> > > once
> > >> > > > > we
> > >> > > > > >> do have such a command, plugins could start packaged, and
> > adding
> > >> > the
> > >> > > > > small
> > >> > > > > >> changes to plugin.xml as you need them is likely a good way
> > to
> > >> go.
> > >> > > > > >>
> > >> > > > > >> Finally, this workflow would get people out of the habit of
> > >> making
> > >> > > > > changes
> > >> > > > > >> to the platform artifacts directly.  I'm not sure that can
> be
> > >> > > entirely
> > >> > > > > >> avoided in all cases, but why shouldn't we work towards
> > making
> > >> > that
> > >> > > > > easier?
> > >> > > > > >>
> > >> > > > > >>
> > >> > > > > >>> We seem to have this notion come up repeatedly that our
> > users +
> > >> > > > plugin
> > >> > > > > >>> developers are working on multiple platforms at the same
> > time,
> > >> > > which
> > >> > > > I
> > >> > > > > >>> think is entirely false.
> > >> > > > > >>>
> > >> > > > > >>
> > >> > > > > >> Since we differ in opinion, how can we put this to the
> test?
> > >> > > > > >>
> > >> > > > > >> Also, we specifically make sure all our features address
> the
> > >> needs
> > >> > > of
> > >> > > > > those
> > >> > > > > >> doing single platform development, so in a world of 3.0+
> > cli, I
> > >> > > really
> > >> > > > > >> don't see how we can not do the same to address the needs
> of
> > >> those
> > >> > > who
> > >> > > > > do
> > >> > > > > >> do multi-platform development, especially when we have a
> good
> > >> > > proposal
> > >> > > > > of
> > >> > > > > >> how to do so and someone willing to do it.
> > >> > > > > >>
> > >> > > > > >>
> > >> > > > > >>> I also think we're trying to help the wrong people; If I
> am
> > a
> > >> > > > > developer who
> > >> > > > > >>> is working on multiple platforms at once, and I have a
> > bunch of
> > >> > > > devices
> > >> > > > > >>> attached, I probably also have the skills to set up my own
> > >> grunt
> > >> > > > > continuous
> > >> > > > > >>> integration system. Setting up tooling for potential
> plugin
> > >> > > > developers
> > >> > > > > is
> > >> > > > > >>> the wrong approach, imho. We should actually just go and
> > >> > implement
> > >> > > > > some new
> > >> > > > > >>> plugin and evaluate the process instead of creating and
> > >> imposing
> > >> > a
> > >> > > > > specific
> > >> > > > > >>> workflow.
> > >> > > > > >>>
> > >> > > > > >>
> > >> > > > > >> The first part of this argument has some merit, I agree.
>  We
> > the
> > >> > > > > >> power-users have found ways to address our problems.
> >  However, I
> > >> > > think
> > >> > > > > that
> > >> > > > > >> with this change it means that even the end user can make
> > >> changes
> > >> > to
> > >> > > > > plugin
> > >> > > > > >> folder as they find bugs/etc, and expect to see the change
> > >> > reflected
> > >> > > > > after
> > >> > > > > >> running prepare.  This is principle of least surprise, and
> > just
> > >> > good
> > >> > > > > design.
> > >> > > > > >>
> > >> > > > > >> I also don't think we are imposing any specific workflow
> > here,
> > >> > just
> > >> > > > > >> enabling a new one.  Personally I think that its quite
> > >> surprising
> > >> > > and
> > >> > > > > >> embarrassing that we haven't enabled this workflow since
> 3.0.
> > >> > > > > >>
> > >> > > > > >>
> > >> > > > > >>>
> > >> > > > > >>>
> > >> > > > > >>>
> > >> > > > > >>>
> > >> > > > > >>>
> > >> > > > > >>>
> > >> > > > > >>>
> > >> > > > > >>>
> > >> > > > > >>>
> > >> > > > > >>> @purplecabbage
> > >> > > > > >>> risingj.com
> > >> > > > > >>>
> > >> > > > > >>>
> > >> > > > > >>> On Thu, Sep 26, 2013 at 10:09 AM, Brian LeRoux <
> b@brian.io>
> > >> > wrote:
> > >> > > > > >>>
> > >> > > > > >>>> I love the idea of a watch command.
> > >> > > > > >>>>
> > >> > > > > >>>>
> > >> > > > > >>>> On Thu, Sep 26, 2013 at 4:48 PM, Anis KADRI <
> > >> > anis.kadri@gmail.com
> > >> > > >
> > >> > > > > >>> wrote:
> > >> > > > > >>>>
> > >> > > > > >>>>> Forgot about the existence of --link for a second. I
> think
> > >> this
> > >> > > is
> > >> > > > a
> > >> > > > > >>>>> good solution (not temporary). watch can be an
> > enhancement to
> > >> > > this
> > >> > > > > >>>>> solution. This might get people like Joe Bowser and
> other
> > >> > people
> > >> > > > who
> > >> > > > > >>>>> do native dev to give cordova-cli a try (only maybe
> > though).
> > >> > > > > >>>>>
> > >> > > > > >>>>> On Thu, Sep 26, 2013 at 4:25 PM, Braden Shepherdson <
> > >> > > > > >>> braden@chromium.org
> > >> > > > > >>>>>
> > >> > > > > >>>>> wrote:
> > >> > > > > >>>>>> If the proposal above is temporary, what's permanent?
> > >> cordova
> > >> > > > watch?
> > >> > > > > >>> I
> > >> > > > > >>>>> want
> > >> > > > > >>>>>> to make sure we're on the same page.
> > >> > > > > >>>>>>
> > >> > > > > >>>>>> Braden
> > >> > > > > >>>>>>
> > >> > > > > >>>>>>
> > >> > > > > >>>>>> On Thu, Sep 26, 2013 at 6:08 AM, Anis KADRI <
> > >> > > anis.kadri@gmail.com
> > >> > > > >
> > >> > > > > >>>>> wrote:
> > >> > > > > >>>>>>
> > >> > > > > >>>>>>> No I didn't mean implement `plugman --watch`. I don't
> > think
> > >> > > > plugman
> > >> > > > > >>>>>>> needs a `watch` command.
> > >> > > > > >>>>>>>
> > >> > > > > >>>>>>> I was indeed talking about `cordova watch` which
> should
> > >> watch
> > >> > > for
> > >> > > > > >>>>>>> changes in plugins/ (and maybe in merges/ and www/ as
> > well)
> > >> > and
> > >> > > > > >>> update
> > >> > > > > >>>>>>> the platform projects (prepare?) on every change.  I
> am
> > >> happy
> > >> > > to
> > >> > > > > >>> know
> > >> > > > > >>>>>>> that it's on the wish list.
> > >> > > > > >>>>>>>
> > >> > > > > >>>>>>> As far as the original proposal, I believe it is a
> > descent
> > >> > > > > temporary
> > >> > > > > >>>>>>> solution for plugin developers who want to use
> > cordova-cli.
> > >> > > > > >>>>>>>
> > >> > > > > >>>>>>> On Wed, Sep 25, 2013 at 7:17 PM, Michal Mocny <
> > >> > > > mmocny@chromium.org
> > >> > > > > >
> > >> > > > > >>>>> wrote:
> > >> > > > > >>>>>>>> Braden, thats has been on the wish list (cordova
> > watch),
> > >> > but I
> > >> > > > > >>>> suspect
> > >> > > > > >>>>>>> Anis
> > >> > > > > >>>>>>>> was suggesting something different with plugman
> > --watch,
> > >> to
> > >> > do
> > >> > > > > >>>>>>> specifically
> > >> > > > > >>>>>>>> with plugin development.  Am I right, Anis?  How does
> > your
> > >> > > idea
> > >> > > > > >>>>> compare
> > >> > > > > >>>>>>>> with using --link with cordova watch?  Would plugman
> > >> --watch
> > >> > > be
> > >> > > > > >>>> useful
> > >> > > > > >>>>>>> for
> > >> > > > > >>>>>>>> non cli projects?
> > >> > > > > >>>>>>>>
> > >> > > > > >>>>>>>> -Michal
> > >> > > > > >>>>>>>>
> > >> > > > > >>>>>>>>
> > >> > > > > >>>>>>>> On Wed, Sep 25, 2013 at 10:31 AM, Braden Shepherdson
> <
> > >> > > > > >>>>>>> braden@chromium.org>wrote:
> > >> > > > > >>>>>>>>
> > >> > > > > >>>>>>>>> We've had a vague feature planned for a while now to
> > do a
> > >> > > > cordova
> > >> > > > > >>>>>>> watch. It
> > >> > > > > >>>>>>>>> would watch your plugins/, www/, and merges/* for
> any
> > >> > > changes.
> > >> > > > If
> > >> > > > > >>>> any
> > >> > > > > >>>>>>>>> changes are detected, it would re-run cordova
> > prepare, so
> > >> > > that
> > >> > > > > >>> your
> > >> > > > > >>>>>>> native
> > >> > > > > >>>>>>>>> projects are always up-to-date.
> > >> > > > > >>>>>>>>>
> > >> > > > > >>>>>>>>> I'm open to checking (hashes?) which files have
> > changed
> > >> and
> > >> > > > which
> > >> > > > > >>>>> have
> > >> > > > > >>>>>>> not,
> > >> > > > > >>>>>>>>> but hashing them all is touching them all anyway,
> and
> > it
> > >> > > might
> > >> > > > be
> > >> > > > > >>>>> faster
> > >> > > > > >>>>>>>>> for small files to just copy them instead of
> checking
> > >> > first.
> > >> > > > > >>> We'll
> > >> > > > > >>>>> have
> > >> > > > > >>>>>>> to
> > >> > > > > >>>>>>>>> try it and see; for v1 I'm going with the simple
> > option
> > >> of
> > >> > > > > >>> copying
> > >> > > > > >>>>>>>>> everything.
> > >> > > > > >>>>>>>>>
> > >> > > > > >>>>>>>>> Braden
> > >> > > > > >>>>>>>>>
> > >> > > > > >>>>>>>>>
> > >> > > > > >>>>>>>>> On Wed, Sep 25, 2013 at 9:44 AM, Michal Mocny <
> > >> > > > > >>> mmocny@chromium.org
> > >> > > > > >>>>>
> > >> > > > > >>>>>>> wrote:
> > >> > > > > >>>>>>>>>
> > >> > > > > >>>>>>>>>> The idea for plugin dev outside of plugins/ folder
> > was
> > >> to
> > >> > > use
> > >> > > > > >>>>> "plugin
> > >> > > > > >>>>>>> add
> > >> > > > > >>>>>>>>>> --link".  Matter of fact, braden suggested that
> > "plugin
> > >> > > > create"
> > >> > > > > >>>>> should
> > >> > > > > >>>>>>>>>> default to --link-ing to some external location so
> > that
> > >> > you
> > >> > > > > >>> don't
> > >> > > > > >>>>> risk
> > >> > > > > >>>>>>>>>> deleting your only copy inside plugins/.  (I
> > personally
> > >> > > don't
> > >> > > > > >>>> think
> > >> > > > > >>>>>>>>> thats a
> > >> > > > > >>>>>>>>>> necessary concern, but I think its a conversation
> for
> > >> > > later).
> > >> > > > > >>>>>>>>>>
> > >> > > > > >>>>>>>>>> I'm not even sure what a 'watch' would do, just
> > >> uninstall
> > >> > &
> > >> > > > > >>>> install
> > >> > > > > >>>>>>> each
> > >> > > > > >>>>>>>>>> time the plugin changes?  I think that ends up
> being
> > >> just
> > >> > > > > >>>> slightly
> > >> > > > > >>>>>>> worse
> > >> > > > > >>>>>>>>>> than the current proposal if you factor in that we
> > >> already
> > >> > > do
> > >> > > > > >>>>> support
> > >> > > > > >>>>>>>>>> --link (except without the above change its been
> > >> useless).
> > >> > > > > >>>>>>>>>>
> > >> > > > > >>>>>>>>>>
> > >> > > > > >>>>>>>>>> However, we may still want some form of 'watch'
> > command
> > >> > for
> > >> > > > > >>> devs
> > >> > > > > >>>>> using
> > >> > > > > >>>>>>>>>> plugman directly.  I had assumed that those devs
> just
> > >> edit
> > >> > > in
> > >> > > > > >>>>> place,
> > >> > > > > >>>>>>>>> since
> > >> > > > > >>>>>>>>>> they don't use a prepare step anyway.
> > >> > > > > >>>>>>>>>>
> > >> > > > > >>>>>>>>>> -Michal
> > >> > > > > >>>>>>>>>>
> > >> > > > > >>>>>>>>>>
> > >> > > > > >>>>>>>>>>
> > >> > > > > >>>>>>>>>> On Wed, Sep 25, 2013 at 7:50 AM, Anis KADRI <
> > >> > > > > >>>> anis.kadri@gmail.com>
> > >> > > > > >>>>>>>>> wrote:
> > >> > > > > >>>>>>>>>>
> > >> > > > > >>>>>>>>>>> If we're talking about developing plugins inside
> the
> > >> > > > > >>>>>>>>>>> plugins/org.myplugin.id folder than I think it's
> a
> > >> great
> > >> > > > > >>>>> workflow
> > >> > > > > >>>>>>> and
> > >> > > > > >>>>>>>>>>> I would just hide the cached version of plugin.xml
> > >> inside
> > >> > > > > >>> that
> > >> > > > > >>>>>>>>>>> plugins/org.myplugin.id folder.
> > >> > > > > >>>>>>>>>>>
> > >> > > > > >>>>>>>>>>> However, if you're developing a plugin outside of
> a
> > >> > cordova
> > >> > > > > >>> CLI
> > >> > > > > >>>>>>>>>>> project, I think a `watch` (and add --watch)
> > command is
> > >> > > more
> > >> > > > > >>>>>>>>>>> appropriate. One of the reasons you would develop
> a
> > >> > plugin
> > >> > > > > >>>>> outside
> > >> > > > > >>>>>>> of
> > >> > > > > >>>>>>>>>>> a cordova CLI project is for easier version
> control
> > >> (each
> > >> > > > > >>>> plugin
> > >> > > > > >>>>>>> would
> > >> > > > > >>>>>>>>>>> have its own repository). The other cool thing
> about
> > >> > > `watch`
> > >> > > > > >>> is
> > >> > > > > >>>>> that
> > >> > > > > >>>>>>>>>>> it would copy the files that have actually changed
> > and
> > >> > not
> > >> > > > > >>>>>>> everything
> > >> > > > > >>>>>>>>>>> (some plugins have a LOT of files [1]).
> > >> > > > > >>>>>>>>>>>
> > >> > > > > >>>>>>>>>>> [1]
> > >> https://github.com/phonegap/phonegap-facebook-plugin
> > >> > > > > >>>>>>>>>>>
> > >> > > > > >>>>>>>>>>> On Wed, Sep 25, 2013 at 3:30 AM, James Jong <
> > >> > > > > >>>>> wjamesjong@gmail.com>
> > >> > > > > >>>>>>>>>> wrote:
> > >> > > > > >>>>>>>>>>>> +1 This is a cleaner workflow and should reduce
> > some
> > >> > > > > >>>> confusion.
> > >> > > > > >>>>>>>>>>>>
> > >> > > > > >>>>>>>>>>>> -James Jong
> > >> > > > > >>>>>>>>>>>>
> > >> > > > > >>>>>>>>>>>> On Sep 24, 2013, at 3:09 PM, Michal Mocny <
> > >> > > > > >>>> mmocny@chromium.org
> > >> > > > > >>>>>>
> > >> > > > > >>>>>>>>> wrote:
> > >> > > > > >>>>>>>>>>>>
> > >> > > > > >>>>>>>>>>>>> Just to add, the reason for the "if" statement
> in
> > >> step
> > >> > > (2)
> > >> > > > > >>>> is
> > >> > > > > >>>>>>> that
> > >> > > > > >>>>>>>>>>>>> uninstall & reinstall take a lot longer than
> just
> > >> > moving
> > >> > > a
> > >> > > > > >>>> few
> > >> > > > > >>>>>>>>> files,
> > >> > > > > >>>>>>>>>>> which
> > >> > > > > >>>>>>>>>>>>> is the 99.9% case for most end users who aren't
> > >> making
> > >> > > > > >>>>>>> modifications
> > >> > > > > >>>>>>>>>> to
> > >> > > > > >>>>>>>>>>>>> plugins.
> > >> > > > > >>>>>>>>>>>>>
> > >> > > > > >>>>>>>>>>>>> This way, we only do the heavy lifting if your
> > plugin
> > >> > > > > >>>>> structure
> > >> > > > > >>>>>>>>>> actually
> > >> > > > > >>>>>>>>>>>>> changed.  Doing it automatically means we no
> > longer
> > >> > have
> > >> > > > > >>> to
> > >> > > > > >>>>>>> advise
> > >> > > > > >>>>>>>>>> users
> > >> > > > > >>>>>>>>>>>>> that making edits inside plugin/ folder is
> > useless.
> > >> >  Now
> > >> > > > > >>> we
> > >> > > > > >>>>> just
> > >> > > > > >>>>>>>>>> advise
> > >> > > > > >>>>>>>>>>>>> them to run "prepare" after making changes to
> > either
> > >> > www/
> > >> > > > > >>> or
> > >> > > > > >>>>>>>>> plugins/.
> > >> > > > > >>>>>>>>>>>>>
> > >> > > > > >>>>>>>>>>>>> This key insight was Braden's idea and I think
> its
> > >> just
> > >> > > an
> > >> > > > > >>>>>>> awesome
> > >> > > > > >>>>>>>>>>> change
> > >> > > > > >>>>>>>>>>>>> for workflow.
> > >> > > > > >>>>>>>>>>>>>
> > >> > > > > >>>>>>>>>>>>> -Michal
> > >> > > > > >>>>>>>>>>>>>
> > >> > > > > >>>>>>>>>>>>>
> > >> > > > > >>>>>>>>>>>>> On Tue, Sep 24, 2013 at 2:58 PM, Braden
> > Shepherdson <
> > >> > > > > >>>>>>>>>>> braden@chromium.org>wrote:
> > >> > > > > >>>>>>>>>>>>>
> > >> > > > > >>>>>>>>>>>>>> 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
> > >> > > > > >>>>>>>>>>>>>>
> > >> > > > > >>>>>>>>>>>>
> > >> > > > > >>>>>>>>>>>
> > >> > > > > >>>>>>>>>>
> > >> > > > > >>>>>>>>>
> > >> > > > > >>>>>>>
> > >> > > > > >>>>>
> > >> > > > > >>>>
> > >> > > > > >>>
> > >> > > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> >
>
>
>
> --
> Carlos Santana
> <cs...@gmail.com>
>

Re: Updating plugin code on prepare

[Carlos Santana <cs...@gmail.com>]

+1 Anis
corodova-cli/plugman should be building block components to higher level
Tools/IDE.

That we can do better sure, lets provide a few examples using blog pots and
maybe videos tutorials vs. trying to support every use case with code.

A watch function could be as simple as using "grunt-contrib-watch" to a
more complicated environment like "rsync/Eclipse"

I agree lets put emphasis on documenting use cases and the correct approach.
When to get the best out of using prepare,  merges, and hooks

All I said applies when you have the "Web Developer" hat.

For people that have the "Native Plugin Developer" hat then we can do
things first for cordova-contributors than others can choose to use on
their own risk since it could be changing too fast and maybe too narrow use
case.

--Carlos

--Carlos



On Sun, Sep 29, 2013 at 9:18 AM, Anis KADRI <an...@gmail.com> wrote:

> I gave some thought to this problem and I think we should just leave
> everything as is. Here's my reasoning:
>
> - Most web developers use a text editor (vim, sublime text, text mate,
> notepad++, ....) to edit their HTML/CSS/Javascript. I've never seen
> anyone use a fully fledged IDE to edit web assets. It would be like
> using Microsoft Word to edit a simple .TXT or .MD file
> - Other developers, people who write Java or Objective C, etc.. use
> Xcode, Eclipse, IntelliJ, ...and I think these people are not good
> candidates for cordova-cli.
>
> The original PhoneGap promise (now Apache Cordova) was to make it easy
> for Web Developers to write Mobile Apps using web technologies and I
> believe that promise is fulfilled with cordova-cli. You have a folder
> where you drop in your web assets and you can build/deploy to a device
> or simulate.
>
> If people want to use an IDE, then they should be creating native
> projects with our create scripts and use plugman to manage their
> plugins.
>
> Our documentation should point our users to the right approach
> depending on the use case. For example:
>
> - Building for only one platform ? Building a hybrid app ? Want to use
> an IDE (Eclipse, Xcode) ? You should use the create scripts and
> plugman to manage plugins
>
> - Building a cross-platform app ? Like managing your project from the
> command-line ? Want to use your favo(u)rite text editor ? Use
> cordova-cli
>
> These double symlinking, backsyncing solutions will be a source of
> confusion and issues in my humble opinion. I've said it before but
> sometimes by trying to please everyone you end up pleasing no one.
>
> my .02c
>
> -a
>
> On Fri, Sep 27, 2013 at 8:20 PM, Michal Mocny <mm...@chromium.org> wrote:
> > On Fri, Sep 27, 2013 at 2:10 PM, Andrew Grieve <ag...@chromium.org>
> wrote:
> >
> >> Just tried some symlinks in Xcode 5:
> >> - Copying assets work (due to our custom build step)
> >> - Building works (compiler follows links just fine)
> >> - Editing a fail (big fail. Files open but changes cannot be saved.)
> >>
> >
> > Hmm, changes via xcode to symlinks fail, you mean?  That would be hard to
> > fix, but perhaps at least its feedback to the user not to make direct
> edits
> > there, when using CLI workflow ;) so may still be a valid change to make.
> >
> >
> >>
> >> For Xcode though, it is an option to change our installation step to
> have
> >> Xcode reference the native files within plugins/ rather than within
> >> platforms/.
> >>
> >>
> >> Symlinks in Eclipse:
> >> - Copying assets works out-of-the-box
> >> - Build works fine
> >> - Editing seems to work fine (edits saved to symlinked location).
> >>
> >>
> >>
> >> Still though, maybe the best solution would be a combination of the two?
> >> Have prepare know when an remove+add is necessary?
> >>
> >
> > Yes, I think thats what we are suggesting.
> >
> > The original email mentioned prepare knowing when remove+add are
> necessary,
> > which I think is already settled as a good idea.  Not sure if you had
> more
> > to add about how prepare should know when to do this (currently, its only
> > on plugin.xml changes).
> > The more recent suggestions about making links between platform&plugins
> > were additional requests to address the rest of the workflow issues (ie,
> > most users prefer to edit inside platforms/ folder because of IDE
> > integration etc).
> >
> > Were you implying anything different here?
> >
> >
> >>
> >> On Fri, Sep 27, 2013 at 6:25 PM, Michal Mocny <mm...@chromium.org>
> wrote:
> >>
> >> > Have we not previously solved the symlink problem in xcode with a
> build
> >> > hook, or was that for prepare step?
> >> >
> >> > The --link concept doesn't do anything for that platforms -> plugins
> file
> >> > mapping.  Its useful for mapping plugins/ to local source, but it
> doesn't
> >> > help with the problem Tyler mentions, right?
> >> >
> >> > -Michal
> >> >
> >> >
> >> > On Fri, Sep 27, 2013 at 1:20 PM, Braden Shepherdson <
> braden@chromium.org
> >> > >wrote:
> >> >
> >> > > Symlinks in platforms/ are a problem because Xcode doesn't honour
> them,
> >> > at
> >> > > least last time we tried it.
> >> > >
> >> > > I'm much more enthused about the --link concept than any syncing,
> >> though.
> >> > > Also if someone wants to sync, they can already use rsync to do it
> >> > > manually.
> >> > >
> >> > > Braden
> >> > >
> >> > >
> >> > > On Fri, Sep 27, 2013 at 11:45 AM, Andrew Grieve <
> agrieve@chromium.org
> >> > > >wrote:
> >> > >
> >> > > > I think it'd be good to enumerate our options for workflow before
> we
> >> > > > decided on which to implement (or maybe choose multiple).
> >> > > >
> >> > > > Tyler's idea about a sync command seems like it would be handy.
> Edit
> >> > your
> >> > > > plugin files within platforms/, and then run `cordova plugin
> >> > copychanges
> >> > > > org.my.plugin` to do a reverse copy of the source files back to
> the
> >> > > install
> >> > > > source location of the plugin. Big caveat though is that you run
> the
> >> > risk
> >> > > > of prepare clobbering your changes. I think that's too killer a
> risk.
> >> > > >
> >> > > > Another thought is that we could use symlinks when running
> prepare.
> >> > Have
> >> > > > files within platforms/ symlink to files within plugins/, then
> >> symlink
> >> > > > again back to their original sources. Would this work with
> editors in
> >> > > > practice? I don't know, but worth exploring. Wikipedia says
> symlinks
> >> > work
> >> > > > on NTFS as of Vista.
> >> > > >
> >> > > > Braden / Michael - I think yours is a good idea as well.
> Although, I
> >> > > don't
> >> > > > think we should encourage people to edit files within plugins/.
> They
> >> > > should
> >> > > > edit their plugins from install point. We should record the
> install
> >> > path,
> >> > > > and maybe have prepare have a prepare --update-local-plugins.
> >> > > >
> >> > > > Any other ideas?
> >> > > >
> >> > > >
> >> > > >
> >> > > > On Fri, Sep 27, 2013 at 3:13 PM, Michael Sierra <
> msierra@adobe.com>
> >> > > wrote:
> >> > > >
> >> > > > > Can you please file JIRAs on doc problems like this?   Existing
> >> > > overview
> >> > > > > doc says you can use the CLI to bootstrap & hand off to an SDK &
> >> > > > supporting
> >> > > > > platform command-line utilities.  I take your comment to mean
> doc
> >> > > should
> >> > > > > better stress that once you start working with platform tools
> >> > > downstream,
> >> > > > > you can't go back to the CLI. Correct?
> >> > > > >
> >> > > > > --Mike Sierra
> >> > > > >
> >> > > > >
> >> > > > > ________________________________________
> >> > > > > From: Tyler Wilson [twilson@pulse-robotics.com]
> >> > > > > Sent: Thursday, September 26, 2013 8:19 PM
> >> > > > > To: dev@cordova.apache.org
> >> > > > > Subject: Re: Updating plugin code on prepare
> >> > > > >
> >> > > > > Re: IDEs: if it is the case that the CLI should not be used
> along
> >> > with
> >> > > an
> >> > > > > IDE, perhaps the documentation - including Getting Started
> Guides,
> >> > > etc. -
> >> > > > > ought to be much clearer about this. Perhaps a big warning that
> >> > "Xcode
> >> > > > > project files are created by the CLI, but they should not be
> opened
> >> > and
> >> > > > > used by Xcode. And you definitely should not edit code within
> the
> >> > IDE".
> >> > > > >
> >> > > > > I just went to the main documentation site here -
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> http://cordova.apache.org/docs/en/3.0.0/guide_overview_index.md.html#Overview-anditappearsitonly mentions the new CLI interface. No mention of the
> >> > > > > old bin/create method. Seems to me there may be communication
> >> problem
> >> > > > here.
> >> > > > >
> >> > > > > Thanks,
> >> > > > > Tyler
> >> > > > >
> >> > > > > On Sep 26, 2013, at 6:11 PM, Anis KADRI <an...@gmail.com>
> >> > wrote:
> >> > > > >
> >> > > > > > @purplecabbage: I have the same workflow but I think the
> proposed
> >> > > > > > solution is a step in the right direction. It would allow us
> to
> >> > > easily
> >> > > > > > develop platform plugins without having to delete
> project/create
> >> > > > > > project/install plugin/uninstall plugin constantly. The plugin
> >> > would
> >> > > > > > be packaged (plugin.xml) from day 1 and one can only focus on
> >> > > > > > development.
> >> > > > > >
> >> > > > > > As far as IDEs, the answer is simple. You should not use IDEs
> and
> >> > > > > > cordova-cli at the same time. Until IDEs are aware of
> cordova-cli
> >> > > > > > there is no point in creating projects with cordova-cli
> because
> >> > > > > > everything gets blown on every build. I am not even sure we
> can
> >> > make
> >> > > > > > Xcode aware of cordova-cli. We've already talked about this
> prior
> >> > to
> >> > > > > > the 3.0 release and that is why we have the create scripts and
> >> > > plugman
> >> > > > > > approach. You should not be using cordova-cli either if you're
> >> > doing
> >> > > > > > some custom native dev that can't be pluginized (changing the
> >> main
> >> > > > > > Activity.java or AppDelegate.m or whatever). If you're using
> >> > > > > > cordova-cli just to create a project and then open an IDE to
> >> > develop,
> >> > > > > > you're probably doing it wrong. You should be creating a
> native
> >> > > > > > project and using plugman instead.
> >> > > > > >
> >> > > > > > On Thu, Sep 26, 2013 at 9:01 PM, Michal Mocny <
> >> mmocny@chromium.org
> >> > >
> >> > > > > wrote:
> >> > > > > >> On Thu, Sep 26, 2013 at 1:39 PM, Jesse <
> purplecabbage@gmail.com
> >> >
> >> > > > wrote:
> >> > > > > >>
> >> > > > > >>> What does a watch mean?
> >> > > > > >>> - if I reboot, is it still watched?
> >> > > > > >>>
> >> > > > > >>
> >> > > > > >> No, this would start a process that lives until you CTRL+C.
>  You
> >> > > could
> >> > > > > have
> >> > > > > >> it run it in the background, or set it to start of startup,
> but
> >> > that
> >> > > > > would
> >> > > > > >> be using local system tools, not part of the command itself.
> >> > > > > >>
> >> > > > > >> Ideally, "watch" should run "prepare" whenever you would have
> >> > wanted
> >> > > > it
> >> > > > > to.
> >> > > > > >> Though obviously that cannot be perfect, it can be a useful
> tool
> >> > > when
> >> > > > > >> iterating.
> >> > > > > >>
> >> > > > > >>
> >> > > > > >>>
> >> > > > > >>> I think it would be best to consider separating development
> >> from
> >> > > > > packaging
> >> > > > > >>> in your use-case for workflow.
> >> > > > > >>> If I am going to develop featureX as a plugin I would :
> >> > > > > >>>
> >> > > > > >>> 1. create a project for a single cordova platform, and
> develop
> >> > the
> >> > > > > feature
> >> > > > > >>> as a native piece, and a js piece.
> >> > > > > >>> 2. test thoroughly
> >> > > > > >>> 3. create a project for a second cordova platform, and
> develop
> >> > the
> >> > > > > native
> >> > > > > >>> bit, preserving the js from 1
> >> > > > > >>> 4. test thoroughly
> >> > > > > >>> 5. repeat steps 3+4 for any remaining platforms
> >> > > > > >>> 6. package featureX as a plugin by organizing relevant bits
> in
> >> > the
> >> > > > > correct
> >> > > > > >>> folder structure, and adding a plugin.xml
> >> > > > > >>> 7. test each platform by installing with plugman
> >> > > > > >>> 8. publish
> >> > > > > >>>
> >> > > > > >>
> >> > > > > >> As a plugin developer, that is not my workflow.
> >> > > > > >>
> >> > > > > >> Typically for me its:
> >> > > > > >>
> >> > > > > >> Write a sample app/manual test for some new feature that
> isn't
> >> > > > > implemented
> >> > > > > >> yet.
> >> > > > > >> Create a new plugin Foo for iOS & Android, and stub the
> >> > > > implementation.
> >> > > > > >> Implement feature A of plugin Foo for iOS, test, add it for
> >> > Android,
> >> > > > > test.
> >> > > > > >> Implement feature B of plugin Foo for iOS, test, add it for
> >> > Android,
> >> > > > > test.
> >> > > > > >> ...
> >> > > > > >>
> >> > > > > >> Usually the js implementation is shared, the auto tests are
> >> > shared,
> >> > > > and
> >> > > > > the
> >> > > > > >> sample test app is shared.
> >> > > > > >>
> >> > > > > >> Sure, I do platform specific stuff for testing and
> >> implementation,
> >> > > > but I
> >> > > > > >> certainly wouldn't say I do plugin development in platform
> >> > > isolation.
> >> > > > > >>
> >> > > > > >> Also, right now we do not have a "plugin create" command,
> and so
> >> > > > leaving
> >> > > > > >> the "packaging" step for last doesn't add affect total work.
> >>  But
> >> > > once
> >> > > > > we
> >> > > > > >> do have such a command, plugins could start packaged, and
> adding
> >> > the
> >> > > > > small
> >> > > > > >> changes to plugin.xml as you need them is likely a good way
> to
> >> go.
> >> > > > > >>
> >> > > > > >> Finally, this workflow would get people out of the habit of
> >> making
> >> > > > > changes
> >> > > > > >> to the platform artifacts directly.  I'm not sure that can be
> >> > > entirely
> >> > > > > >> avoided in all cases, but why shouldn't we work towards
> making
> >> > that
> >> > > > > easier?
> >> > > > > >>
> >> > > > > >>
> >> > > > > >>> We seem to have this notion come up repeatedly that our
> users +
> >> > > > plugin
> >> > > > > >>> developers are working on multiple platforms at the same
> time,
> >> > > which
> >> > > > I
> >> > > > > >>> think is entirely false.
> >> > > > > >>>
> >> > > > > >>
> >> > > > > >> Since we differ in opinion, how can we put this to the test?
> >> > > > > >>
> >> > > > > >> Also, we specifically make sure all our features address the
> >> needs
> >> > > of
> >> > > > > those
> >> > > > > >> doing single platform development, so in a world of 3.0+
> cli, I
> >> > > really
> >> > > > > >> don't see how we can not do the same to address the needs of
> >> those
> >> > > who
> >> > > > > do
> >> > > > > >> do multi-platform development, especially when we have a good
> >> > > proposal
> >> > > > > of
> >> > > > > >> how to do so and someone willing to do it.
> >> > > > > >>
> >> > > > > >>
> >> > > > > >>> I also think we're trying to help the wrong people; If I am
> a
> >> > > > > developer who
> >> > > > > >>> is working on multiple platforms at once, and I have a
> bunch of
> >> > > > devices
> >> > > > > >>> attached, I probably also have the skills to set up my own
> >> grunt
> >> > > > > continuous
> >> > > > > >>> integration system. Setting up tooling for potential plugin
> >> > > > developers
> >> > > > > is
> >> > > > > >>> the wrong approach, imho. We should actually just go and
> >> > implement
> >> > > > > some new
> >> > > > > >>> plugin and evaluate the process instead of creating and
> >> imposing
> >> > a
> >> > > > > specific
> >> > > > > >>> workflow.
> >> > > > > >>>
> >> > > > > >>
> >> > > > > >> The first part of this argument has some merit, I agree.  We
> the
> >> > > > > >> power-users have found ways to address our problems.
>  However, I
> >> > > think
> >> > > > > that
> >> > > > > >> with this change it means that even the end user can make
> >> changes
> >> > to
> >> > > > > plugin
> >> > > > > >> folder as they find bugs/etc, and expect to see the change
> >> > reflected
> >> > > > > after
> >> > > > > >> running prepare.  This is principle of least surprise, and
> just
> >> > good
> >> > > > > design.
> >> > > > > >>
> >> > > > > >> I also don't think we are imposing any specific workflow
> here,
> >> > just
> >> > > > > >> enabling a new one.  Personally I think that its quite
> >> surprising
> >> > > and
> >> > > > > >> embarrassing that we haven't enabled this workflow since 3.0.
> >> > > > > >>
> >> > > > > >>
> >> > > > > >>>
> >> > > > > >>>
> >> > > > > >>>
> >> > > > > >>>
> >> > > > > >>>
> >> > > > > >>>
> >> > > > > >>>
> >> > > > > >>>
> >> > > > > >>>
> >> > > > > >>> @purplecabbage
> >> > > > > >>> risingj.com
> >> > > > > >>>
> >> > > > > >>>
> >> > > > > >>> On Thu, Sep 26, 2013 at 10:09 AM, Brian LeRoux <b...@brian.io>
> >> > wrote:
> >> > > > > >>>
> >> > > > > >>>> I love the idea of a watch command.
> >> > > > > >>>>
> >> > > > > >>>>
> >> > > > > >>>> On Thu, Sep 26, 2013 at 4:48 PM, Anis KADRI <
> >> > anis.kadri@gmail.com
> >> > > >
> >> > > > > >>> wrote:
> >> > > > > >>>>
> >> > > > > >>>>> Forgot about the existence of --link for a second. I think
> >> this
> >> > > is
> >> > > > a
> >> > > > > >>>>> good solution (not temporary). watch can be an
> enhancement to
> >> > > this
> >> > > > > >>>>> solution. This might get people like Joe Bowser and other
> >> > people
> >> > > > who
> >> > > > > >>>>> do native dev to give cordova-cli a try (only maybe
> though).
> >> > > > > >>>>>
> >> > > > > >>>>> On Thu, Sep 26, 2013 at 4:25 PM, Braden Shepherdson <
> >> > > > > >>> braden@chromium.org
> >> > > > > >>>>>
> >> > > > > >>>>> wrote:
> >> > > > > >>>>>> If the proposal above is temporary, what's permanent?
> >> cordova
> >> > > > watch?
> >> > > > > >>> I
> >> > > > > >>>>> want
> >> > > > > >>>>>> to make sure we're on the same page.
> >> > > > > >>>>>>
> >> > > > > >>>>>> Braden
> >> > > > > >>>>>>
> >> > > > > >>>>>>
> >> > > > > >>>>>> On Thu, Sep 26, 2013 at 6:08 AM, Anis KADRI <
> >> > > anis.kadri@gmail.com
> >> > > > >
> >> > > > > >>>>> wrote:
> >> > > > > >>>>>>
> >> > > > > >>>>>>> No I didn't mean implement `plugman --watch`. I don't
> think
> >> > > > plugman
> >> > > > > >>>>>>> needs a `watch` command.
> >> > > > > >>>>>>>
> >> > > > > >>>>>>> I was indeed talking about `cordova watch` which should
> >> watch
> >> > > for
> >> > > > > >>>>>>> changes in plugins/ (and maybe in merges/ and www/ as
> well)
> >> > and
> >> > > > > >>> update
> >> > > > > >>>>>>> the platform projects (prepare?) on every change.  I am
> >> happy
> >> > > to
> >> > > > > >>> know
> >> > > > > >>>>>>> that it's on the wish list.
> >> > > > > >>>>>>>
> >> > > > > >>>>>>> As far as the original proposal, I believe it is a
> descent
> >> > > > > temporary
> >> > > > > >>>>>>> solution for plugin developers who want to use
> cordova-cli.
> >> > > > > >>>>>>>
> >> > > > > >>>>>>> On Wed, Sep 25, 2013 at 7:17 PM, Michal Mocny <
> >> > > > mmocny@chromium.org
> >> > > > > >
> >> > > > > >>>>> wrote:
> >> > > > > >>>>>>>> Braden, thats has been on the wish list (cordova
> watch),
> >> > but I
> >> > > > > >>>> suspect
> >> > > > > >>>>>>> Anis
> >> > > > > >>>>>>>> was suggesting something different with plugman
> --watch,
> >> to
> >> > do
> >> > > > > >>>>>>> specifically
> >> > > > > >>>>>>>> with plugin development.  Am I right, Anis?  How does
> your
> >> > > idea
> >> > > > > >>>>> compare
> >> > > > > >>>>>>>> with using --link with cordova watch?  Would plugman
> >> --watch
> >> > > be
> >> > > > > >>>> useful
> >> > > > > >>>>>>> for
> >> > > > > >>>>>>>> non cli projects?
> >> > > > > >>>>>>>>
> >> > > > > >>>>>>>> -Michal
> >> > > > > >>>>>>>>
> >> > > > > >>>>>>>>
> >> > > > > >>>>>>>> On Wed, Sep 25, 2013 at 10:31 AM, Braden Shepherdson <
> >> > > > > >>>>>>> braden@chromium.org>wrote:
> >> > > > > >>>>>>>>
> >> > > > > >>>>>>>>> We've had a vague feature planned for a while now to
> do a
> >> > > > cordova
> >> > > > > >>>>>>> watch. It
> >> > > > > >>>>>>>>> would watch your plugins/, www/, and merges/* for any
> >> > > changes.
> >> > > > If
> >> > > > > >>>> any
> >> > > > > >>>>>>>>> changes are detected, it would re-run cordova
> prepare, so
> >> > > that
> >> > > > > >>> your
> >> > > > > >>>>>>> native
> >> > > > > >>>>>>>>> projects are always up-to-date.
> >> > > > > >>>>>>>>>
> >> > > > > >>>>>>>>> I'm open to checking (hashes?) which files have
> changed
> >> and
> >> > > > which
> >> > > > > >>>>> have
> >> > > > > >>>>>>> not,
> >> > > > > >>>>>>>>> but hashing them all is touching them all anyway, and
> it
> >> > > might
> >> > > > be
> >> > > > > >>>>> faster
> >> > > > > >>>>>>>>> for small files to just copy them instead of checking
> >> > first.
> >> > > > > >>> We'll
> >> > > > > >>>>> have
> >> > > > > >>>>>>> to
> >> > > > > >>>>>>>>> try it and see; for v1 I'm going with the simple
> option
> >> of
> >> > > > > >>> copying
> >> > > > > >>>>>>>>> everything.
> >> > > > > >>>>>>>>>
> >> > > > > >>>>>>>>> Braden
> >> > > > > >>>>>>>>>
> >> > > > > >>>>>>>>>
> >> > > > > >>>>>>>>> On Wed, Sep 25, 2013 at 9:44 AM, Michal Mocny <
> >> > > > > >>> mmocny@chromium.org
> >> > > > > >>>>>
> >> > > > > >>>>>>> wrote:
> >> > > > > >>>>>>>>>
> >> > > > > >>>>>>>>>> The idea for plugin dev outside of plugins/ folder
> was
> >> to
> >> > > use
> >> > > > > >>>>> "plugin
> >> > > > > >>>>>>> add
> >> > > > > >>>>>>>>>> --link".  Matter of fact, braden suggested that
> "plugin
> >> > > > create"
> >> > > > > >>>>> should
> >> > > > > >>>>>>>>>> default to --link-ing to some external location so
> that
> >> > you
> >> > > > > >>> don't
> >> > > > > >>>>> risk
> >> > > > > >>>>>>>>>> deleting your only copy inside plugins/.  (I
> personally
> >> > > don't
> >> > > > > >>>> think
> >> > > > > >>>>>>>>> thats a
> >> > > > > >>>>>>>>>> necessary concern, but I think its a conversation for
> >> > > later).
> >> > > > > >>>>>>>>>>
> >> > > > > >>>>>>>>>> I'm not even sure what a 'watch' would do, just
> >> uninstall
> >> > &
> >> > > > > >>>> install
> >> > > > > >>>>>>> each
> >> > > > > >>>>>>>>>> time the plugin changes?  I think that ends up being
> >> just
> >> > > > > >>>> slightly
> >> > > > > >>>>>>> worse
> >> > > > > >>>>>>>>>> than the current proposal if you factor in that we
> >> already
> >> > > do
> >> > > > > >>>>> support
> >> > > > > >>>>>>>>>> --link (except without the above change its been
> >> useless).
> >> > > > > >>>>>>>>>>
> >> > > > > >>>>>>>>>>
> >> > > > > >>>>>>>>>> However, we may still want some form of 'watch'
> command
> >> > for
> >> > > > > >>> devs
> >> > > > > >>>>> using
> >> > > > > >>>>>>>>>> plugman directly.  I had assumed that those devs just
> >> edit
> >> > > in
> >> > > > > >>>>> place,
> >> > > > > >>>>>>>>> since
> >> > > > > >>>>>>>>>> they don't use a prepare step anyway.
> >> > > > > >>>>>>>>>>
> >> > > > > >>>>>>>>>> -Michal
> >> > > > > >>>>>>>>>>
> >> > > > > >>>>>>>>>>
> >> > > > > >>>>>>>>>>
> >> > > > > >>>>>>>>>> On Wed, Sep 25, 2013 at 7:50 AM, Anis KADRI <
> >> > > > > >>>> anis.kadri@gmail.com>
> >> > > > > >>>>>>>>> wrote:
> >> > > > > >>>>>>>>>>
> >> > > > > >>>>>>>>>>> If we're talking about developing plugins inside the
> >> > > > > >>>>>>>>>>> plugins/org.myplugin.id folder than I think it's a
> >> great
> >> > > > > >>>>> workflow
> >> > > > > >>>>>>> and
> >> > > > > >>>>>>>>>>> I would just hide the cached version of plugin.xml
> >> inside
> >> > > > > >>> that
> >> > > > > >>>>>>>>>>> plugins/org.myplugin.id folder.
> >> > > > > >>>>>>>>>>>
> >> > > > > >>>>>>>>>>> However, if you're developing a plugin outside of a
> >> > cordova
> >> > > > > >>> CLI
> >> > > > > >>>>>>>>>>> project, I think a `watch` (and add --watch)
> command is
> >> > > more
> >> > > > > >>>>>>>>>>> appropriate. One of the reasons you would develop a
> >> > plugin
> >> > > > > >>>>> outside
> >> > > > > >>>>>>> of
> >> > > > > >>>>>>>>>>> a cordova CLI project is for easier version control
> >> (each
> >> > > > > >>>> plugin
> >> > > > > >>>>>>> would
> >> > > > > >>>>>>>>>>> have its own repository). The other cool thing about
> >> > > `watch`
> >> > > > > >>> is
> >> > > > > >>>>> that
> >> > > > > >>>>>>>>>>> it would copy the files that have actually changed
> and
> >> > not
> >> > > > > >>>>>>> everything
> >> > > > > >>>>>>>>>>> (some plugins have a LOT of files [1]).
> >> > > > > >>>>>>>>>>>
> >> > > > > >>>>>>>>>>> [1]
> >> https://github.com/phonegap/phonegap-facebook-plugin
> >> > > > > >>>>>>>>>>>
> >> > > > > >>>>>>>>>>> On Wed, Sep 25, 2013 at 3:30 AM, James Jong <
> >> > > > > >>>>> wjamesjong@gmail.com>
> >> > > > > >>>>>>>>>> wrote:
> >> > > > > >>>>>>>>>>>> +1 This is a cleaner workflow and should reduce
> some
> >> > > > > >>>> confusion.
> >> > > > > >>>>>>>>>>>>
> >> > > > > >>>>>>>>>>>> -James Jong
> >> > > > > >>>>>>>>>>>>
> >> > > > > >>>>>>>>>>>> On Sep 24, 2013, at 3:09 PM, Michal Mocny <
> >> > > > > >>>> mmocny@chromium.org
> >> > > > > >>>>>>
> >> > > > > >>>>>>>>> wrote:
> >> > > > > >>>>>>>>>>>>
> >> > > > > >>>>>>>>>>>>> Just to add, the reason for the "if" statement in
> >> step
> >> > > (2)
> >> > > > > >>>> is
> >> > > > > >>>>>>> that
> >> > > > > >>>>>>>>>>>>> uninstall & reinstall take a lot longer than just
> >> > moving
> >> > > a
> >> > > > > >>>> few
> >> > > > > >>>>>>>>> files,
> >> > > > > >>>>>>>>>>> which
> >> > > > > >>>>>>>>>>>>> is the 99.9% case for most end users who aren't
> >> making
> >> > > > > >>>>>>> modifications
> >> > > > > >>>>>>>>>> to
> >> > > > > >>>>>>>>>>>>> plugins.
> >> > > > > >>>>>>>>>>>>>
> >> > > > > >>>>>>>>>>>>> This way, we only do the heavy lifting if your
> plugin
> >> > > > > >>>>> structure
> >> > > > > >>>>>>>>>> actually
> >> > > > > >>>>>>>>>>>>> changed.  Doing it automatically means we no
> longer
> >> > have
> >> > > > > >>> to
> >> > > > > >>>>>>> advise
> >> > > > > >>>>>>>>>> users
> >> > > > > >>>>>>>>>>>>> that making edits inside plugin/ folder is
> useless.
> >> >  Now
> >> > > > > >>> we
> >> > > > > >>>>> just
> >> > > > > >>>>>>>>>> advise
> >> > > > > >>>>>>>>>>>>> them to run "prepare" after making changes to
> either
> >> > www/
> >> > > > > >>> or
> >> > > > > >>>>>>>>> plugins/.
> >> > > > > >>>>>>>>>>>>>
> >> > > > > >>>>>>>>>>>>> This key insight was Braden's idea and I think its
> >> just
> >> > > an
> >> > > > > >>>>>>> awesome
> >> > > > > >>>>>>>>>>> change
> >> > > > > >>>>>>>>>>>>> for workflow.
> >> > > > > >>>>>>>>>>>>>
> >> > > > > >>>>>>>>>>>>> -Michal
> >> > > > > >>>>>>>>>>>>>
> >> > > > > >>>>>>>>>>>>>
> >> > > > > >>>>>>>>>>>>> On Tue, Sep 24, 2013 at 2:58 PM, Braden
> Shepherdson <
> >> > > > > >>>>>>>>>>> braden@chromium.org>wrote:
> >> > > > > >>>>>>>>>>>>>
> >> > > > > >>>>>>>>>>>>>> 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
> >> > > > > >>>>>>>>>>>>>>
> >> > > > > >>>>>>>>>>>>
> >> > > > > >>>>>>>>>>>
> >> > > > > >>>>>>>>>>
> >> > > > > >>>>>>>>>
> >> > > > > >>>>>>>
> >> > > > > >>>>>
> >> > > > > >>>>
> >> > > > > >>>
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
>



-- 
Carlos Santana
<cs...@gmail.com>

Re: Updating plugin code on prepare

[Anis KADRI <an...@gmail.com>]

I gave some thought to this problem and I think we should just leave
everything as is. Here's my reasoning:

- Most web developers use a text editor (vim, sublime text, text mate,
notepad++, ....) to edit their HTML/CSS/Javascript. I've never seen
anyone use a fully fledged IDE to edit web assets. It would be like
using Microsoft Word to edit a simple .TXT or .MD file
- Other developers, people who write Java or Objective C, etc.. use
Xcode, Eclipse, IntelliJ, ...and I think these people are not good
candidates for cordova-cli.

The original PhoneGap promise (now Apache Cordova) was to make it easy
for Web Developers to write Mobile Apps using web technologies and I
believe that promise is fulfilled with cordova-cli. You have a folder
where you drop in your web assets and you can build/deploy to a device
or simulate.

If people want to use an IDE, then they should be creating native
projects with our create scripts and use plugman to manage their
plugins.

Our documentation should point our users to the right approach
depending on the use case. For example:

- Building for only one platform ? Building a hybrid app ? Want to use
an IDE (Eclipse, Xcode) ? You should use the create scripts and
plugman to manage plugins

- Building a cross-platform app ? Like managing your project from the
command-line ? Want to use your favo(u)rite text editor ? Use
cordova-cli

These double symlinking, backsyncing solutions will be a source of
confusion and issues in my humble opinion. I've said it before but
sometimes by trying to please everyone you end up pleasing no one.

my .02c

-a

On Fri, Sep 27, 2013 at 8:20 PM, Michal Mocny <mm...@chromium.org> wrote:
> On Fri, Sep 27, 2013 at 2:10 PM, Andrew Grieve <ag...@chromium.org> wrote:
>
>> Just tried some symlinks in Xcode 5:
>> - Copying assets work (due to our custom build step)
>> - Building works (compiler follows links just fine)
>> - Editing a fail (big fail. Files open but changes cannot be saved.)
>>
>
> Hmm, changes via xcode to symlinks fail, you mean?  That would be hard to
> fix, but perhaps at least its feedback to the user not to make direct edits
> there, when using CLI workflow ;) so may still be a valid change to make.
>
>
>>
>> For Xcode though, it is an option to change our installation step to have
>> Xcode reference the native files within plugins/ rather than within
>> platforms/.
>>
>>
>> Symlinks in Eclipse:
>> - Copying assets works out-of-the-box
>> - Build works fine
>> - Editing seems to work fine (edits saved to symlinked location).
>>
>>
>>
>> Still though, maybe the best solution would be a combination of the two?
>> Have prepare know when an remove+add is necessary?
>>
>
> Yes, I think thats what we are suggesting.
>
> The original email mentioned prepare knowing when remove+add are necessary,
> which I think is already settled as a good idea.  Not sure if you had more
> to add about how prepare should know when to do this (currently, its only
> on plugin.xml changes).
> The more recent suggestions about making links between platform&plugins
> were additional requests to address the rest of the workflow issues (ie,
> most users prefer to edit inside platforms/ folder because of IDE
> integration etc).
>
> Were you implying anything different here?
>
>
>>
>> On Fri, Sep 27, 2013 at 6:25 PM, Michal Mocny <mm...@chromium.org> wrote:
>>
>> > Have we not previously solved the symlink problem in xcode with a build
>> > hook, or was that for prepare step?
>> >
>> > The --link concept doesn't do anything for that platforms -> plugins file
>> > mapping.  Its useful for mapping plugins/ to local source, but it doesn't
>> > help with the problem Tyler mentions, right?
>> >
>> > -Michal
>> >
>> >
>> > On Fri, Sep 27, 2013 at 1:20 PM, Braden Shepherdson <braden@chromium.org
>> > >wrote:
>> >
>> > > Symlinks in platforms/ are a problem because Xcode doesn't honour them,
>> > at
>> > > least last time we tried it.
>> > >
>> > > I'm much more enthused about the --link concept than any syncing,
>> though.
>> > > Also if someone wants to sync, they can already use rsync to do it
>> > > manually.
>> > >
>> > > Braden
>> > >
>> > >
>> > > On Fri, Sep 27, 2013 at 11:45 AM, Andrew Grieve <agrieve@chromium.org
>> > > >wrote:
>> > >
>> > > > I think it'd be good to enumerate our options for workflow before we
>> > > > decided on which to implement (or maybe choose multiple).
>> > > >
>> > > > Tyler's idea about a sync command seems like it would be handy. Edit
>> > your
>> > > > plugin files within platforms/, and then run `cordova plugin
>> > copychanges
>> > > > org.my.plugin` to do a reverse copy of the source files back to the
>> > > install
>> > > > source location of the plugin. Big caveat though is that you run the
>> > risk
>> > > > of prepare clobbering your changes. I think that's too killer a risk.
>> > > >
>> > > > Another thought is that we could use symlinks when running prepare.
>> > Have
>> > > > files within platforms/ symlink to files within plugins/, then
>> symlink
>> > > > again back to their original sources. Would this work with editors in
>> > > > practice? I don't know, but worth exploring. Wikipedia says symlinks
>> > work
>> > > > on NTFS as of Vista.
>> > > >
>> > > > Braden / Michael - I think yours is a good idea as well. Although, I
>> > > don't
>> > > > think we should encourage people to edit files within plugins/. They
>> > > should
>> > > > edit their plugins from install point. We should record the install
>> > path,
>> > > > and maybe have prepare have a prepare --update-local-plugins.
>> > > >
>> > > > Any other ideas?
>> > > >
>> > > >
>> > > >
>> > > > On Fri, Sep 27, 2013 at 3:13 PM, Michael Sierra <ms...@adobe.com>
>> > > wrote:
>> > > >
>> > > > > Can you please file JIRAs on doc problems like this?   Existing
>> > > overview
>> > > > > doc says you can use the CLI to bootstrap & hand off to an SDK &
>> > > > supporting
>> > > > > platform command-line utilities.  I take your comment to mean doc
>> > > should
>> > > > > better stress that once you start working with platform tools
>> > > downstream,
>> > > > > you can't go back to the CLI. Correct?
>> > > > >
>> > > > > --Mike Sierra
>> > > > >
>> > > > >
>> > > > > ________________________________________
>> > > > > From: Tyler Wilson [twilson@pulse-robotics.com]
>> > > > > Sent: Thursday, September 26, 2013 8:19 PM
>> > > > > To: dev@cordova.apache.org
>> > > > > Subject: Re: Updating plugin code on prepare
>> > > > >
>> > > > > Re: IDEs: if it is the case that the CLI should not be used along
>> > with
>> > > an
>> > > > > IDE, perhaps the documentation - including Getting Started Guides,
>> > > etc. -
>> > > > > ought to be much clearer about this. Perhaps a big warning that
>> > "Xcode
>> > > > > project files are created by the CLI, but they should not be opened
>> > and
>> > > > > used by Xcode. And you definitely should not edit code within the
>> > IDE".
>> > > > >
>> > > > > I just went to the main documentation site here -
>> > > > >
>> > > >
>> > >
>> >
>> http://cordova.apache.org/docs/en/3.0.0/guide_overview_index.md.html#Overview-anditappearsit only mentions the new CLI interface. No mention of the
>> > > > > old bin/create method. Seems to me there may be communication
>> problem
>> > > > here.
>> > > > >
>> > > > > Thanks,
>> > > > > Tyler
>> > > > >
>> > > > > On Sep 26, 2013, at 6:11 PM, Anis KADRI <an...@gmail.com>
>> > wrote:
>> > > > >
>> > > > > > @purplecabbage: I have the same workflow but I think the proposed
>> > > > > > solution is a step in the right direction. It would allow us to
>> > > easily
>> > > > > > develop platform plugins without having to delete project/create
>> > > > > > project/install plugin/uninstall plugin constantly. The plugin
>> > would
>> > > > > > be packaged (plugin.xml) from day 1 and one can only focus on
>> > > > > > development.
>> > > > > >
>> > > > > > As far as IDEs, the answer is simple. You should not use IDEs and
>> > > > > > cordova-cli at the same time. Until IDEs are aware of cordova-cli
>> > > > > > there is no point in creating projects with cordova-cli because
>> > > > > > everything gets blown on every build. I am not even sure we can
>> > make
>> > > > > > Xcode aware of cordova-cli. We've already talked about this prior
>> > to
>> > > > > > the 3.0 release and that is why we have the create scripts and
>> > > plugman
>> > > > > > approach. You should not be using cordova-cli either if you're
>> > doing
>> > > > > > some custom native dev that can't be pluginized (changing the
>> main
>> > > > > > Activity.java or AppDelegate.m or whatever). If you're using
>> > > > > > cordova-cli just to create a project and then open an IDE to
>> > develop,
>> > > > > > you're probably doing it wrong. You should be creating a native
>> > > > > > project and using plugman instead.
>> > > > > >
>> > > > > > On Thu, Sep 26, 2013 at 9:01 PM, Michal Mocny <
>> mmocny@chromium.org
>> > >
>> > > > > wrote:
>> > > > > >> On Thu, Sep 26, 2013 at 1:39 PM, Jesse <purplecabbage@gmail.com
>> >
>> > > > wrote:
>> > > > > >>
>> > > > > >>> What does a watch mean?
>> > > > > >>> - if I reboot, is it still watched?
>> > > > > >>>
>> > > > > >>
>> > > > > >> No, this would start a process that lives until you CTRL+C.  You
>> > > could
>> > > > > have
>> > > > > >> it run it in the background, or set it to start of startup, but
>> > that
>> > > > > would
>> > > > > >> be using local system tools, not part of the command itself.
>> > > > > >>
>> > > > > >> Ideally, "watch" should run "prepare" whenever you would have
>> > wanted
>> > > > it
>> > > > > to.
>> > > > > >> Though obviously that cannot be perfect, it can be a useful tool
>> > > when
>> > > > > >> iterating.
>> > > > > >>
>> > > > > >>
>> > > > > >>>
>> > > > > >>> I think it would be best to consider separating development
>> from
>> > > > > packaging
>> > > > > >>> in your use-case for workflow.
>> > > > > >>> If I am going to develop featureX as a plugin I would :
>> > > > > >>>
>> > > > > >>> 1. create a project for a single cordova platform, and develop
>> > the
>> > > > > feature
>> > > > > >>> as a native piece, and a js piece.
>> > > > > >>> 2. test thoroughly
>> > > > > >>> 3. create a project for a second cordova platform, and develop
>> > the
>> > > > > native
>> > > > > >>> bit, preserving the js from 1
>> > > > > >>> 4. test thoroughly
>> > > > > >>> 5. repeat steps 3+4 for any remaining platforms
>> > > > > >>> 6. package featureX as a plugin by organizing relevant bits in
>> > the
>> > > > > correct
>> > > > > >>> folder structure, and adding a plugin.xml
>> > > > > >>> 7. test each platform by installing with plugman
>> > > > > >>> 8. publish
>> > > > > >>>
>> > > > > >>
>> > > > > >> As a plugin developer, that is not my workflow.
>> > > > > >>
>> > > > > >> Typically for me its:
>> > > > > >>
>> > > > > >> Write a sample app/manual test for some new feature that isn't
>> > > > > implemented
>> > > > > >> yet.
>> > > > > >> Create a new plugin Foo for iOS & Android, and stub the
>> > > > implementation.
>> > > > > >> Implement feature A of plugin Foo for iOS, test, add it for
>> > Android,
>> > > > > test.
>> > > > > >> Implement feature B of plugin Foo for iOS, test, add it for
>> > Android,
>> > > > > test.
>> > > > > >> ...
>> > > > > >>
>> > > > > >> Usually the js implementation is shared, the auto tests are
>> > shared,
>> > > > and
>> > > > > the
>> > > > > >> sample test app is shared.
>> > > > > >>
>> > > > > >> Sure, I do platform specific stuff for testing and
>> implementation,
>> > > > but I
>> > > > > >> certainly wouldn't say I do plugin development in platform
>> > > isolation.
>> > > > > >>
>> > > > > >> Also, right now we do not have a "plugin create" command, and so
>> > > > leaving
>> > > > > >> the "packaging" step for last doesn't add affect total work.
>>  But
>> > > once
>> > > > > we
>> > > > > >> do have such a command, plugins could start packaged, and adding
>> > the
>> > > > > small
>> > > > > >> changes to plugin.xml as you need them is likely a good way to
>> go.
>> > > > > >>
>> > > > > >> Finally, this workflow would get people out of the habit of
>> making
>> > > > > changes
>> > > > > >> to the platform artifacts directly.  I'm not sure that can be
>> > > entirely
>> > > > > >> avoided in all cases, but why shouldn't we work towards making
>> > that
>> > > > > easier?
>> > > > > >>
>> > > > > >>
>> > > > > >>> We seem to have this notion come up repeatedly that our users +
>> > > > plugin
>> > > > > >>> developers are working on multiple platforms at the same time,
>> > > which
>> > > > I
>> > > > > >>> think is entirely false.
>> > > > > >>>
>> > > > > >>
>> > > > > >> Since we differ in opinion, how can we put this to the test?
>> > > > > >>
>> > > > > >> Also, we specifically make sure all our features address the
>> needs
>> > > of
>> > > > > those
>> > > > > >> doing single platform development, so in a world of 3.0+ cli, I
>> > > really
>> > > > > >> don't see how we can not do the same to address the needs of
>> those
>> > > who
>> > > > > do
>> > > > > >> do multi-platform development, especially when we have a good
>> > > proposal
>> > > > > of
>> > > > > >> how to do so and someone willing to do it.
>> > > > > >>
>> > > > > >>
>> > > > > >>> I also think we're trying to help the wrong people; If I am a
>> > > > > developer who
>> > > > > >>> is working on multiple platforms at once, and I have a bunch of
>> > > > devices
>> > > > > >>> attached, I probably also have the skills to set up my own
>> grunt
>> > > > > continuous
>> > > > > >>> integration system. Setting up tooling for potential plugin
>> > > > developers
>> > > > > is
>> > > > > >>> the wrong approach, imho. We should actually just go and
>> > implement
>> > > > > some new
>> > > > > >>> plugin and evaluate the process instead of creating and
>> imposing
>> > a
>> > > > > specific
>> > > > > >>> workflow.
>> > > > > >>>
>> > > > > >>
>> > > > > >> The first part of this argument has some merit, I agree.  We the
>> > > > > >> power-users have found ways to address our problems.  However, I
>> > > think
>> > > > > that
>> > > > > >> with this change it means that even the end user can make
>> changes
>> > to
>> > > > > plugin
>> > > > > >> folder as they find bugs/etc, and expect to see the change
>> > reflected
>> > > > > after
>> > > > > >> running prepare.  This is principle of least surprise, and just
>> > good
>> > > > > design.
>> > > > > >>
>> > > > > >> I also don't think we are imposing any specific workflow here,
>> > just
>> > > > > >> enabling a new one.  Personally I think that its quite
>> surprising
>> > > and
>> > > > > >> embarrassing that we haven't enabled this workflow since 3.0.
>> > > > > >>
>> > > > > >>
>> > > > > >>>
>> > > > > >>>
>> > > > > >>>
>> > > > > >>>
>> > > > > >>>
>> > > > > >>>
>> > > > > >>>
>> > > > > >>>
>> > > > > >>>
>> > > > > >>> @purplecabbage
>> > > > > >>> risingj.com
>> > > > > >>>
>> > > > > >>>
>> > > > > >>> On Thu, Sep 26, 2013 at 10:09 AM, Brian LeRoux <b...@brian.io>
>> > wrote:
>> > > > > >>>
>> > > > > >>>> I love the idea of a watch command.
>> > > > > >>>>
>> > > > > >>>>
>> > > > > >>>> On Thu, Sep 26, 2013 at 4:48 PM, Anis KADRI <
>> > anis.kadri@gmail.com
>> > > >
>> > > > > >>> wrote:
>> > > > > >>>>
>> > > > > >>>>> Forgot about the existence of --link for a second. I think
>> this
>> > > is
>> > > > a
>> > > > > >>>>> good solution (not temporary). watch can be an enhancement to
>> > > this
>> > > > > >>>>> solution. This might get people like Joe Bowser and other
>> > people
>> > > > who
>> > > > > >>>>> do native dev to give cordova-cli a try (only maybe though).
>> > > > > >>>>>
>> > > > > >>>>> On Thu, Sep 26, 2013 at 4:25 PM, Braden Shepherdson <
>> > > > > >>> braden@chromium.org
>> > > > > >>>>>
>> > > > > >>>>> wrote:
>> > > > > >>>>>> If the proposal above is temporary, what's permanent?
>> cordova
>> > > > watch?
>> > > > > >>> I
>> > > > > >>>>> want
>> > > > > >>>>>> to make sure we're on the same page.
>> > > > > >>>>>>
>> > > > > >>>>>> Braden
>> > > > > >>>>>>
>> > > > > >>>>>>
>> > > > > >>>>>> On Thu, Sep 26, 2013 at 6:08 AM, Anis KADRI <
>> > > anis.kadri@gmail.com
>> > > > >
>> > > > > >>>>> wrote:
>> > > > > >>>>>>
>> > > > > >>>>>>> No I didn't mean implement `plugman --watch`. I don't think
>> > > > plugman
>> > > > > >>>>>>> needs a `watch` command.
>> > > > > >>>>>>>
>> > > > > >>>>>>> I was indeed talking about `cordova watch` which should
>> watch
>> > > for
>> > > > > >>>>>>> changes in plugins/ (and maybe in merges/ and www/ as well)
>> > and
>> > > > > >>> update
>> > > > > >>>>>>> the platform projects (prepare?) on every change.  I am
>> happy
>> > > to
>> > > > > >>> know
>> > > > > >>>>>>> that it's on the wish list.
>> > > > > >>>>>>>
>> > > > > >>>>>>> As far as the original proposal, I believe it is a descent
>> > > > > temporary
>> > > > > >>>>>>> solution for plugin developers who want to use cordova-cli.
>> > > > > >>>>>>>
>> > > > > >>>>>>> On Wed, Sep 25, 2013 at 7:17 PM, Michal Mocny <
>> > > > mmocny@chromium.org
>> > > > > >
>> > > > > >>>>> wrote:
>> > > > > >>>>>>>> Braden, thats has been on the wish list (cordova watch),
>> > but I
>> > > > > >>>> suspect
>> > > > > >>>>>>> Anis
>> > > > > >>>>>>>> was suggesting something different with plugman --watch,
>> to
>> > do
>> > > > > >>>>>>> specifically
>> > > > > >>>>>>>> with plugin development.  Am I right, Anis?  How does your
>> > > idea
>> > > > > >>>>> compare
>> > > > > >>>>>>>> with using --link with cordova watch?  Would plugman
>> --watch
>> > > be
>> > > > > >>>> useful
>> > > > > >>>>>>> for
>> > > > > >>>>>>>> non cli projects?
>> > > > > >>>>>>>>
>> > > > > >>>>>>>> -Michal
>> > > > > >>>>>>>>
>> > > > > >>>>>>>>
>> > > > > >>>>>>>> On Wed, Sep 25, 2013 at 10:31 AM, Braden Shepherdson <
>> > > > > >>>>>>> braden@chromium.org>wrote:
>> > > > > >>>>>>>>
>> > > > > >>>>>>>>> We've had a vague feature planned for a while now to do a
>> > > > cordova
>> > > > > >>>>>>> watch. It
>> > > > > >>>>>>>>> would watch your plugins/, www/, and merges/* for any
>> > > changes.
>> > > > If
>> > > > > >>>> any
>> > > > > >>>>>>>>> changes are detected, it would re-run cordova prepare, so
>> > > that
>> > > > > >>> your
>> > > > > >>>>>>> native
>> > > > > >>>>>>>>> projects are always up-to-date.
>> > > > > >>>>>>>>>
>> > > > > >>>>>>>>> I'm open to checking (hashes?) which files have changed
>> and
>> > > > which
>> > > > > >>>>> have
>> > > > > >>>>>>> not,
>> > > > > >>>>>>>>> but hashing them all is touching them all anyway, and it
>> > > might
>> > > > be
>> > > > > >>>>> faster
>> > > > > >>>>>>>>> for small files to just copy them instead of checking
>> > first.
>> > > > > >>> We'll
>> > > > > >>>>> have
>> > > > > >>>>>>> to
>> > > > > >>>>>>>>> try it and see; for v1 I'm going with the simple option
>> of
>> > > > > >>> copying
>> > > > > >>>>>>>>> everything.
>> > > > > >>>>>>>>>
>> > > > > >>>>>>>>> Braden
>> > > > > >>>>>>>>>
>> > > > > >>>>>>>>>
>> > > > > >>>>>>>>> On Wed, Sep 25, 2013 at 9:44 AM, Michal Mocny <
>> > > > > >>> mmocny@chromium.org
>> > > > > >>>>>
>> > > > > >>>>>>> wrote:
>> > > > > >>>>>>>>>
>> > > > > >>>>>>>>>> The idea for plugin dev outside of plugins/ folder was
>> to
>> > > use
>> > > > > >>>>> "plugin
>> > > > > >>>>>>> add
>> > > > > >>>>>>>>>> --link".  Matter of fact, braden suggested that "plugin
>> > > > create"
>> > > > > >>>>> should
>> > > > > >>>>>>>>>> default to --link-ing to some external location so that
>> > you
>> > > > > >>> don't
>> > > > > >>>>> risk
>> > > > > >>>>>>>>>> deleting your only copy inside plugins/.  (I personally
>> > > don't
>> > > > > >>>> think
>> > > > > >>>>>>>>> thats a
>> > > > > >>>>>>>>>> necessary concern, but I think its a conversation for
>> > > later).
>> > > > > >>>>>>>>>>
>> > > > > >>>>>>>>>> I'm not even sure what a 'watch' would do, just
>> uninstall
>> > &
>> > > > > >>>> install
>> > > > > >>>>>>> each
>> > > > > >>>>>>>>>> time the plugin changes?  I think that ends up being
>> just
>> > > > > >>>> slightly
>> > > > > >>>>>>> worse
>> > > > > >>>>>>>>>> than the current proposal if you factor in that we
>> already
>> > > do
>> > > > > >>>>> support
>> > > > > >>>>>>>>>> --link (except without the above change its been
>> useless).
>> > > > > >>>>>>>>>>
>> > > > > >>>>>>>>>>
>> > > > > >>>>>>>>>> However, we may still want some form of 'watch' command
>> > for
>> > > > > >>> devs
>> > > > > >>>>> using
>> > > > > >>>>>>>>>> plugman directly.  I had assumed that those devs just
>> edit
>> > > in
>> > > > > >>>>> place,
>> > > > > >>>>>>>>> since
>> > > > > >>>>>>>>>> they don't use a prepare step anyway.
>> > > > > >>>>>>>>>>
>> > > > > >>>>>>>>>> -Michal
>> > > > > >>>>>>>>>>
>> > > > > >>>>>>>>>>
>> > > > > >>>>>>>>>>
>> > > > > >>>>>>>>>> On Wed, Sep 25, 2013 at 7:50 AM, Anis KADRI <
>> > > > > >>>> anis.kadri@gmail.com>
>> > > > > >>>>>>>>> wrote:
>> > > > > >>>>>>>>>>
>> > > > > >>>>>>>>>>> If we're talking about developing plugins inside the
>> > > > > >>>>>>>>>>> plugins/org.myplugin.id folder than I think it's a
>> great
>> > > > > >>>>> workflow
>> > > > > >>>>>>> and
>> > > > > >>>>>>>>>>> I would just hide the cached version of plugin.xml
>> inside
>> > > > > >>> that
>> > > > > >>>>>>>>>>> plugins/org.myplugin.id folder.
>> > > > > >>>>>>>>>>>
>> > > > > >>>>>>>>>>> However, if you're developing a plugin outside of a
>> > cordova
>> > > > > >>> CLI
>> > > > > >>>>>>>>>>> project, I think a `watch` (and add --watch) command is
>> > > more
>> > > > > >>>>>>>>>>> appropriate. One of the reasons you would develop a
>> > plugin
>> > > > > >>>>> outside
>> > > > > >>>>>>> of
>> > > > > >>>>>>>>>>> a cordova CLI project is for easier version control
>> (each
>> > > > > >>>> plugin
>> > > > > >>>>>>> would
>> > > > > >>>>>>>>>>> have its own repository). The other cool thing about
>> > > `watch`
>> > > > > >>> is
>> > > > > >>>>> that
>> > > > > >>>>>>>>>>> it would copy the files that have actually changed and
>> > not
>> > > > > >>>>>>> everything
>> > > > > >>>>>>>>>>> (some plugins have a LOT of files [1]).
>> > > > > >>>>>>>>>>>
>> > > > > >>>>>>>>>>> [1]
>> https://github.com/phonegap/phonegap-facebook-plugin
>> > > > > >>>>>>>>>>>
>> > > > > >>>>>>>>>>> On Wed, Sep 25, 2013 at 3:30 AM, James Jong <
>> > > > > >>>>> wjamesjong@gmail.com>
>> > > > > >>>>>>>>>> wrote:
>> > > > > >>>>>>>>>>>> +1 This is a cleaner workflow and should reduce some
>> > > > > >>>> confusion.
>> > > > > >>>>>>>>>>>>
>> > > > > >>>>>>>>>>>> -James Jong
>> > > > > >>>>>>>>>>>>
>> > > > > >>>>>>>>>>>> On Sep 24, 2013, at 3:09 PM, Michal Mocny <
>> > > > > >>>> mmocny@chromium.org
>> > > > > >>>>>>
>> > > > > >>>>>>>>> wrote:
>> > > > > >>>>>>>>>>>>
>> > > > > >>>>>>>>>>>>> Just to add, the reason for the "if" statement in
>> step
>> > > (2)
>> > > > > >>>> is
>> > > > > >>>>>>> that
>> > > > > >>>>>>>>>>>>> uninstall & reinstall take a lot longer than just
>> > moving
>> > > a
>> > > > > >>>> few
>> > > > > >>>>>>>>> files,
>> > > > > >>>>>>>>>>> which
>> > > > > >>>>>>>>>>>>> is the 99.9% case for most end users who aren't
>> making
>> > > > > >>>>>>> modifications
>> > > > > >>>>>>>>>> to
>> > > > > >>>>>>>>>>>>> plugins.
>> > > > > >>>>>>>>>>>>>
>> > > > > >>>>>>>>>>>>> This way, we only do the heavy lifting if your plugin
>> > > > > >>>>> structure
>> > > > > >>>>>>>>>> actually
>> > > > > >>>>>>>>>>>>> changed.  Doing it automatically means we no longer
>> > have
>> > > > > >>> to
>> > > > > >>>>>>> advise
>> > > > > >>>>>>>>>> users
>> > > > > >>>>>>>>>>>>> that making edits inside plugin/ folder is useless.
>> >  Now
>> > > > > >>> we
>> > > > > >>>>> just
>> > > > > >>>>>>>>>> advise
>> > > > > >>>>>>>>>>>>> them to run "prepare" after making changes to either
>> > www/
>> > > > > >>> or
>> > > > > >>>>>>>>> plugins/.
>> > > > > >>>>>>>>>>>>>
>> > > > > >>>>>>>>>>>>> This key insight was Braden's idea and I think its
>> just
>> > > an
>> > > > > >>>>>>> awesome
>> > > > > >>>>>>>>>>> change
>> > > > > >>>>>>>>>>>>> for workflow.
>> > > > > >>>>>>>>>>>>>
>> > > > > >>>>>>>>>>>>> -Michal
>> > > > > >>>>>>>>>>>>>
>> > > > > >>>>>>>>>>>>>
>> > > > > >>>>>>>>>>>>> On Tue, Sep 24, 2013 at 2:58 PM, Braden Shepherdson <
>> > > > > >>>>>>>>>>> braden@chromium.org>wrote:
>> > > > > >>>>>>>>>>>>>
>> > > > > >>>>>>>>>>>>>> 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
>> > > > > >>>>>>>>>>>>>>
>> > > > > >>>>>>>>>>>>
>> > > > > >>>>>>>>>>>
>> > > > > >>>>>>>>>>
>> > > > > >>>>>>>>>
>> > > > > >>>>>>>
>> > > > > >>>>>
>> > > > > >>>>
>> > > > > >>>
>> > > > >
>> > > >
>> > >
>> >
>>

Re: Updating plugin code on prepare

[Michal Mocny <mm...@chromium.org>]

On Fri, Sep 27, 2013 at 2:10 PM, Andrew Grieve <ag...@chromium.org> wrote:

> Just tried some symlinks in Xcode 5:
> - Copying assets work (due to our custom build step)
> - Building works (compiler follows links just fine)
> - Editing a fail (big fail. Files open but changes cannot be saved.)
>

Hmm, changes via xcode to symlinks fail, you mean?  That would be hard to
fix, but perhaps at least its feedback to the user not to make direct edits
there, when using CLI workflow ;) so may still be a valid change to make.


>
> For Xcode though, it is an option to change our installation step to have
> Xcode reference the native files within plugins/ rather than within
> platforms/.
>
>
> Symlinks in Eclipse:
> - Copying assets works out-of-the-box
> - Build works fine
> - Editing seems to work fine (edits saved to symlinked location).
>
>
>
> Still though, maybe the best solution would be a combination of the two?
> Have prepare know when an remove+add is necessary?
>

Yes, I think thats what we are suggesting.

The original email mentioned prepare knowing when remove+add are necessary,
which I think is already settled as a good idea.  Not sure if you had more
to add about how prepare should know when to do this (currently, its only
on plugin.xml changes).
The more recent suggestions about making links between platform&plugins
were additional requests to address the rest of the workflow issues (ie,
most users prefer to edit inside platforms/ folder because of IDE
integration etc).

Were you implying anything different here?


>
> On Fri, Sep 27, 2013 at 6:25 PM, Michal Mocny <mm...@chromium.org> wrote:
>
> > Have we not previously solved the symlink problem in xcode with a build
> > hook, or was that for prepare step?
> >
> > The --link concept doesn't do anything for that platforms -> plugins file
> > mapping.  Its useful for mapping plugins/ to local source, but it doesn't
> > help with the problem Tyler mentions, right?
> >
> > -Michal
> >
> >
> > On Fri, Sep 27, 2013 at 1:20 PM, Braden Shepherdson <braden@chromium.org
> > >wrote:
> >
> > > Symlinks in platforms/ are a problem because Xcode doesn't honour them,
> > at
> > > least last time we tried it.
> > >
> > > I'm much more enthused about the --link concept than any syncing,
> though.
> > > Also if someone wants to sync, they can already use rsync to do it
> > > manually.
> > >
> > > Braden
> > >
> > >
> > > On Fri, Sep 27, 2013 at 11:45 AM, Andrew Grieve <agrieve@chromium.org
> > > >wrote:
> > >
> > > > I think it'd be good to enumerate our options for workflow before we
> > > > decided on which to implement (or maybe choose multiple).
> > > >
> > > > Tyler's idea about a sync command seems like it would be handy. Edit
> > your
> > > > plugin files within platforms/, and then run `cordova plugin
> > copychanges
> > > > org.my.plugin` to do a reverse copy of the source files back to the
> > > install
> > > > source location of the plugin. Big caveat though is that you run the
> > risk
> > > > of prepare clobbering your changes. I think that's too killer a risk.
> > > >
> > > > Another thought is that we could use symlinks when running prepare.
> > Have
> > > > files within platforms/ symlink to files within plugins/, then
> symlink
> > > > again back to their original sources. Would this work with editors in
> > > > practice? I don't know, but worth exploring. Wikipedia says symlinks
> > work
> > > > on NTFS as of Vista.
> > > >
> > > > Braden / Michael - I think yours is a good idea as well. Although, I
> > > don't
> > > > think we should encourage people to edit files within plugins/. They
> > > should
> > > > edit their plugins from install point. We should record the install
> > path,
> > > > and maybe have prepare have a prepare --update-local-plugins.
> > > >
> > > > Any other ideas?
> > > >
> > > >
> > > >
> > > > On Fri, Sep 27, 2013 at 3:13 PM, Michael Sierra <ms...@adobe.com>
> > > wrote:
> > > >
> > > > > Can you please file JIRAs on doc problems like this?   Existing
> > > overview
> > > > > doc says you can use the CLI to bootstrap & hand off to an SDK &
> > > > supporting
> > > > > platform command-line utilities.  I take your comment to mean doc
> > > should
> > > > > better stress that once you start working with platform tools
> > > downstream,
> > > > > you can't go back to the CLI. Correct?
> > > > >
> > > > > --Mike Sierra
> > > > >
> > > > >
> > > > > ________________________________________
> > > > > From: Tyler Wilson [twilson@pulse-robotics.com]
> > > > > Sent: Thursday, September 26, 2013 8:19 PM
> > > > > To: dev@cordova.apache.org
> > > > > Subject: Re: Updating plugin code on prepare
> > > > >
> > > > > Re: IDEs: if it is the case that the CLI should not be used along
> > with
> > > an
> > > > > IDE, perhaps the documentation - including Getting Started Guides,
> > > etc. -
> > > > > ought to be much clearer about this. Perhaps a big warning that
> > "Xcode
> > > > > project files are created by the CLI, but they should not be opened
> > and
> > > > > used by Xcode. And you definitely should not edit code within the
> > IDE".
> > > > >
> > > > > I just went to the main documentation site here -
> > > > >
> > > >
> > >
> >
> http://cordova.apache.org/docs/en/3.0.0/guide_overview_index.md.html#Overview-anditappearsit only mentions the new CLI interface. No mention of the
> > > > > old bin/create method. Seems to me there may be communication
> problem
> > > > here.
> > > > >
> > > > > Thanks,
> > > > > Tyler
> > > > >
> > > > > On Sep 26, 2013, at 6:11 PM, Anis KADRI <an...@gmail.com>
> > wrote:
> > > > >
> > > > > > @purplecabbage: I have the same workflow but I think the proposed
> > > > > > solution is a step in the right direction. It would allow us to
> > > easily
> > > > > > develop platform plugins without having to delete project/create
> > > > > > project/install plugin/uninstall plugin constantly. The plugin
> > would
> > > > > > be packaged (plugin.xml) from day 1 and one can only focus on
> > > > > > development.
> > > > > >
> > > > > > As far as IDEs, the answer is simple. You should not use IDEs and
> > > > > > cordova-cli at the same time. Until IDEs are aware of cordova-cli
> > > > > > there is no point in creating projects with cordova-cli because
> > > > > > everything gets blown on every build. I am not even sure we can
> > make
> > > > > > Xcode aware of cordova-cli. We've already talked about this prior
> > to
> > > > > > the 3.0 release and that is why we have the create scripts and
> > > plugman
> > > > > > approach. You should not be using cordova-cli either if you're
> > doing
> > > > > > some custom native dev that can't be pluginized (changing the
> main
> > > > > > Activity.java or AppDelegate.m or whatever). If you're using
> > > > > > cordova-cli just to create a project and then open an IDE to
> > develop,
> > > > > > you're probably doing it wrong. You should be creating a native
> > > > > > project and using plugman instead.
> > > > > >
> > > > > > On Thu, Sep 26, 2013 at 9:01 PM, Michal Mocny <
> mmocny@chromium.org
> > >
> > > > > wrote:
> > > > > >> On Thu, Sep 26, 2013 at 1:39 PM, Jesse <purplecabbage@gmail.com
> >
> > > > wrote:
> > > > > >>
> > > > > >>> What does a watch mean?
> > > > > >>> - if I reboot, is it still watched?
> > > > > >>>
> > > > > >>
> > > > > >> No, this would start a process that lives until you CTRL+C.  You
> > > could
> > > > > have
> > > > > >> it run it in the background, or set it to start of startup, but
> > that
> > > > > would
> > > > > >> be using local system tools, not part of the command itself.
> > > > > >>
> > > > > >> Ideally, "watch" should run "prepare" whenever you would have
> > wanted
> > > > it
> > > > > to.
> > > > > >> Though obviously that cannot be perfect, it can be a useful tool
> > > when
> > > > > >> iterating.
> > > > > >>
> > > > > >>
> > > > > >>>
> > > > > >>> I think it would be best to consider separating development
> from
> > > > > packaging
> > > > > >>> in your use-case for workflow.
> > > > > >>> If I am going to develop featureX as a plugin I would :
> > > > > >>>
> > > > > >>> 1. create a project for a single cordova platform, and develop
> > the
> > > > > feature
> > > > > >>> as a native piece, and a js piece.
> > > > > >>> 2. test thoroughly
> > > > > >>> 3. create a project for a second cordova platform, and develop
> > the
> > > > > native
> > > > > >>> bit, preserving the js from 1
> > > > > >>> 4. test thoroughly
> > > > > >>> 5. repeat steps 3+4 for any remaining platforms
> > > > > >>> 6. package featureX as a plugin by organizing relevant bits in
> > the
> > > > > correct
> > > > > >>> folder structure, and adding a plugin.xml
> > > > > >>> 7. test each platform by installing with plugman
> > > > > >>> 8. publish
> > > > > >>>
> > > > > >>
> > > > > >> As a plugin developer, that is not my workflow.
> > > > > >>
> > > > > >> Typically for me its:
> > > > > >>
> > > > > >> Write a sample app/manual test for some new feature that isn't
> > > > > implemented
> > > > > >> yet.
> > > > > >> Create a new plugin Foo for iOS & Android, and stub the
> > > > implementation.
> > > > > >> Implement feature A of plugin Foo for iOS, test, add it for
> > Android,
> > > > > test.
> > > > > >> Implement feature B of plugin Foo for iOS, test, add it for
> > Android,
> > > > > test.
> > > > > >> ...
> > > > > >>
> > > > > >> Usually the js implementation is shared, the auto tests are
> > shared,
> > > > and
> > > > > the
> > > > > >> sample test app is shared.
> > > > > >>
> > > > > >> Sure, I do platform specific stuff for testing and
> implementation,
> > > > but I
> > > > > >> certainly wouldn't say I do plugin development in platform
> > > isolation.
> > > > > >>
> > > > > >> Also, right now we do not have a "plugin create" command, and so
> > > > leaving
> > > > > >> the "packaging" step for last doesn't add affect total work.
>  But
> > > once
> > > > > we
> > > > > >> do have such a command, plugins could start packaged, and adding
> > the
> > > > > small
> > > > > >> changes to plugin.xml as you need them is likely a good way to
> go.
> > > > > >>
> > > > > >> Finally, this workflow would get people out of the habit of
> making
> > > > > changes
> > > > > >> to the platform artifacts directly.  I'm not sure that can be
> > > entirely
> > > > > >> avoided in all cases, but why shouldn't we work towards making
> > that
> > > > > easier?
> > > > > >>
> > > > > >>
> > > > > >>> We seem to have this notion come up repeatedly that our users +
> > > > plugin
> > > > > >>> developers are working on multiple platforms at the same time,
> > > which
> > > > I
> > > > > >>> think is entirely false.
> > > > > >>>
> > > > > >>
> > > > > >> Since we differ in opinion, how can we put this to the test?
> > > > > >>
> > > > > >> Also, we specifically make sure all our features address the
> needs
> > > of
> > > > > those
> > > > > >> doing single platform development, so in a world of 3.0+ cli, I
> > > really
> > > > > >> don't see how we can not do the same to address the needs of
> those
> > > who
> > > > > do
> > > > > >> do multi-platform development, especially when we have a good
> > > proposal
> > > > > of
> > > > > >> how to do so and someone willing to do it.
> > > > > >>
> > > > > >>
> > > > > >>> I also think we're trying to help the wrong people; If I am a
> > > > > developer who
> > > > > >>> is working on multiple platforms at once, and I have a bunch of
> > > > devices
> > > > > >>> attached, I probably also have the skills to set up my own
> grunt
> > > > > continuous
> > > > > >>> integration system. Setting up tooling for potential plugin
> > > > developers
> > > > > is
> > > > > >>> the wrong approach, imho. We should actually just go and
> > implement
> > > > > some new
> > > > > >>> plugin and evaluate the process instead of creating and
> imposing
> > a
> > > > > specific
> > > > > >>> workflow.
> > > > > >>>
> > > > > >>
> > > > > >> The first part of this argument has some merit, I agree.  We the
> > > > > >> power-users have found ways to address our problems.  However, I
> > > think
> > > > > that
> > > > > >> with this change it means that even the end user can make
> changes
> > to
> > > > > plugin
> > > > > >> folder as they find bugs/etc, and expect to see the change
> > reflected
> > > > > after
> > > > > >> running prepare.  This is principle of least surprise, and just
> > good
> > > > > design.
> > > > > >>
> > > > > >> I also don't think we are imposing any specific workflow here,
> > just
> > > > > >> enabling a new one.  Personally I think that its quite
> surprising
> > > and
> > > > > >> embarrassing that we haven't enabled this workflow since 3.0.
> > > > > >>
> > > > > >>
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>> @purplecabbage
> > > > > >>> risingj.com
> > > > > >>>
> > > > > >>>
> > > > > >>> On Thu, Sep 26, 2013 at 10:09 AM, Brian LeRoux <b...@brian.io>
> > wrote:
> > > > > >>>
> > > > > >>>> I love the idea of a watch command.
> > > > > >>>>
> > > > > >>>>
> > > > > >>>> On Thu, Sep 26, 2013 at 4:48 PM, Anis KADRI <
> > anis.kadri@gmail.com
> > > >
> > > > > >>> wrote:
> > > > > >>>>
> > > > > >>>>> Forgot about the existence of --link for a second. I think
> this
> > > is
> > > > a
> > > > > >>>>> good solution (not temporary). watch can be an enhancement to
> > > this
> > > > > >>>>> solution. This might get people like Joe Bowser and other
> > people
> > > > who
> > > > > >>>>> do native dev to give cordova-cli a try (only maybe though).
> > > > > >>>>>
> > > > > >>>>> On Thu, Sep 26, 2013 at 4:25 PM, Braden Shepherdson <
> > > > > >>> braden@chromium.org
> > > > > >>>>>
> > > > > >>>>> wrote:
> > > > > >>>>>> If the proposal above is temporary, what's permanent?
> cordova
> > > > watch?
> > > > > >>> I
> > > > > >>>>> want
> > > > > >>>>>> to make sure we're on the same page.
> > > > > >>>>>>
> > > > > >>>>>> Braden
> > > > > >>>>>>
> > > > > >>>>>>
> > > > > >>>>>> On Thu, Sep 26, 2013 at 6:08 AM, Anis KADRI <
> > > anis.kadri@gmail.com
> > > > >
> > > > > >>>>> wrote:
> > > > > >>>>>>
> > > > > >>>>>>> No I didn't mean implement `plugman --watch`. I don't think
> > > > plugman
> > > > > >>>>>>> needs a `watch` command.
> > > > > >>>>>>>
> > > > > >>>>>>> I was indeed talking about `cordova watch` which should
> watch
> > > for
> > > > > >>>>>>> changes in plugins/ (and maybe in merges/ and www/ as well)
> > and
> > > > > >>> update
> > > > > >>>>>>> the platform projects (prepare?) on every change.  I am
> happy
> > > to
> > > > > >>> know
> > > > > >>>>>>> that it's on the wish list.
> > > > > >>>>>>>
> > > > > >>>>>>> As far as the original proposal, I believe it is a descent
> > > > > temporary
> > > > > >>>>>>> solution for plugin developers who want to use cordova-cli.
> > > > > >>>>>>>
> > > > > >>>>>>> On Wed, Sep 25, 2013 at 7:17 PM, Michal Mocny <
> > > > mmocny@chromium.org
> > > > > >
> > > > > >>>>> wrote:
> > > > > >>>>>>>> Braden, thats has been on the wish list (cordova watch),
> > but I
> > > > > >>>> suspect
> > > > > >>>>>>> Anis
> > > > > >>>>>>>> was suggesting something different with plugman --watch,
> to
> > do
> > > > > >>>>>>> specifically
> > > > > >>>>>>>> with plugin development.  Am I right, Anis?  How does your
> > > idea
> > > > > >>>>> compare
> > > > > >>>>>>>> with using --link with cordova watch?  Would plugman
> --watch
> > > be
> > > > > >>>> useful
> > > > > >>>>>>> for
> > > > > >>>>>>>> non cli projects?
> > > > > >>>>>>>>
> > > > > >>>>>>>> -Michal
> > > > > >>>>>>>>
> > > > > >>>>>>>>
> > > > > >>>>>>>> On Wed, Sep 25, 2013 at 10:31 AM, Braden Shepherdson <
> > > > > >>>>>>> braden@chromium.org>wrote:
> > > > > >>>>>>>>
> > > > > >>>>>>>>> We've had a vague feature planned for a while now to do a
> > > > cordova
> > > > > >>>>>>> watch. It
> > > > > >>>>>>>>> would watch your plugins/, www/, and merges/* for any
> > > changes.
> > > > If
> > > > > >>>> any
> > > > > >>>>>>>>> changes are detected, it would re-run cordova prepare, so
> > > that
> > > > > >>> your
> > > > > >>>>>>> native
> > > > > >>>>>>>>> projects are always up-to-date.
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> I'm open to checking (hashes?) which files have changed
> and
> > > > which
> > > > > >>>>> have
> > > > > >>>>>>> not,
> > > > > >>>>>>>>> but hashing them all is touching them all anyway, and it
> > > might
> > > > be
> > > > > >>>>> faster
> > > > > >>>>>>>>> for small files to just copy them instead of checking
> > first.
> > > > > >>> We'll
> > > > > >>>>> have
> > > > > >>>>>>> to
> > > > > >>>>>>>>> try it and see; for v1 I'm going with the simple option
> of
> > > > > >>> copying
> > > > > >>>>>>>>> everything.
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> Braden
> > > > > >>>>>>>>>
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> On Wed, Sep 25, 2013 at 9:44 AM, Michal Mocny <
> > > > > >>> mmocny@chromium.org
> > > > > >>>>>
> > > > > >>>>>>> wrote:
> > > > > >>>>>>>>>
> > > > > >>>>>>>>>> The idea for plugin dev outside of plugins/ folder was
> to
> > > use
> > > > > >>>>> "plugin
> > > > > >>>>>>> add
> > > > > >>>>>>>>>> --link".  Matter of fact, braden suggested that "plugin
> > > > create"
> > > > > >>>>> should
> > > > > >>>>>>>>>> default to --link-ing to some external location so that
> > you
> > > > > >>> don't
> > > > > >>>>> risk
> > > > > >>>>>>>>>> deleting your only copy inside plugins/.  (I personally
> > > don't
> > > > > >>>> think
> > > > > >>>>>>>>> thats a
> > > > > >>>>>>>>>> necessary concern, but I think its a conversation for
> > > later).
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>> I'm not even sure what a 'watch' would do, just
> uninstall
> > &
> > > > > >>>> install
> > > > > >>>>>>> each
> > > > > >>>>>>>>>> time the plugin changes?  I think that ends up being
> just
> > > > > >>>> slightly
> > > > > >>>>>>> worse
> > > > > >>>>>>>>>> than the current proposal if you factor in that we
> already
> > > do
> > > > > >>>>> support
> > > > > >>>>>>>>>> --link (except without the above change its been
> useless).
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>> However, we may still want some form of 'watch' command
> > for
> > > > > >>> devs
> > > > > >>>>> using
> > > > > >>>>>>>>>> plugman directly.  I had assumed that those devs just
> edit
> > > in
> > > > > >>>>> place,
> > > > > >>>>>>>>> since
> > > > > >>>>>>>>>> they don't use a prepare step anyway.
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>> -Michal
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>> On Wed, Sep 25, 2013 at 7:50 AM, Anis KADRI <
> > > > > >>>> anis.kadri@gmail.com>
> > > > > >>>>>>>>> wrote:
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>>> If we're talking about developing plugins inside the
> > > > > >>>>>>>>>>> plugins/org.myplugin.id folder than I think it's a
> great
> > > > > >>>>> workflow
> > > > > >>>>>>> and
> > > > > >>>>>>>>>>> I would just hide the cached version of plugin.xml
> inside
> > > > > >>> that
> > > > > >>>>>>>>>>> plugins/org.myplugin.id folder.
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>>>> However, if you're developing a plugin outside of a
> > cordova
> > > > > >>> CLI
> > > > > >>>>>>>>>>> project, I think a `watch` (and add --watch) command is
> > > more
> > > > > >>>>>>>>>>> appropriate. One of the reasons you would develop a
> > plugin
> > > > > >>>>> outside
> > > > > >>>>>>> of
> > > > > >>>>>>>>>>> a cordova CLI project is for easier version control
> (each
> > > > > >>>> plugin
> > > > > >>>>>>> would
> > > > > >>>>>>>>>>> have its own repository). The other cool thing about
> > > `watch`
> > > > > >>> is
> > > > > >>>>> that
> > > > > >>>>>>>>>>> it would copy the files that have actually changed and
> > not
> > > > > >>>>>>> everything
> > > > > >>>>>>>>>>> (some plugins have a LOT of files [1]).
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>>>> [1]
> https://github.com/phonegap/phonegap-facebook-plugin
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>>>> On Wed, Sep 25, 2013 at 3:30 AM, James Jong <
> > > > > >>>>> wjamesjong@gmail.com>
> > > > > >>>>>>>>>> wrote:
> > > > > >>>>>>>>>>>> +1 This is a cleaner workflow and should reduce some
> > > > > >>>> confusion.
> > > > > >>>>>>>>>>>>
> > > > > >>>>>>>>>>>> -James Jong
> > > > > >>>>>>>>>>>>
> > > > > >>>>>>>>>>>> On Sep 24, 2013, at 3:09 PM, Michal Mocny <
> > > > > >>>> mmocny@chromium.org
> > > > > >>>>>>
> > > > > >>>>>>>>> wrote:
> > > > > >>>>>>>>>>>>
> > > > > >>>>>>>>>>>>> Just to add, the reason for the "if" statement in
> step
> > > (2)
> > > > > >>>> is
> > > > > >>>>>>> that
> > > > > >>>>>>>>>>>>> uninstall & reinstall take a lot longer than just
> > moving
> > > a
> > > > > >>>> few
> > > > > >>>>>>>>> files,
> > > > > >>>>>>>>>>> which
> > > > > >>>>>>>>>>>>> is the 99.9% case for most end users who aren't
> making
> > > > > >>>>>>> modifications
> > > > > >>>>>>>>>> to
> > > > > >>>>>>>>>>>>> plugins.
> > > > > >>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>> This way, we only do the heavy lifting if your plugin
> > > > > >>>>> structure
> > > > > >>>>>>>>>> actually
> > > > > >>>>>>>>>>>>> changed.  Doing it automatically means we no longer
> > have
> > > > > >>> to
> > > > > >>>>>>> advise
> > > > > >>>>>>>>>> users
> > > > > >>>>>>>>>>>>> that making edits inside plugin/ folder is useless.
> >  Now
> > > > > >>> we
> > > > > >>>>> just
> > > > > >>>>>>>>>> advise
> > > > > >>>>>>>>>>>>> them to run "prepare" after making changes to either
> > www/
> > > > > >>> or
> > > > > >>>>>>>>> plugins/.
> > > > > >>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>> This key insight was Braden's idea and I think its
> just
> > > an
> > > > > >>>>>>> awesome
> > > > > >>>>>>>>>>> change
> > > > > >>>>>>>>>>>>> for workflow.
> > > > > >>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>> -Michal
> > > > > >>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>> On Tue, Sep 24, 2013 at 2:58 PM, Braden Shepherdson <
> > > > > >>>>>>>>>>> braden@chromium.org>wrote:
> > > > > >>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>> 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
> > > > > >>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>
> > > > > >>>>>>>
> > > > > >>>>>
> > > > > >>>>
> > > > > >>>
> > > > >
> > > >
> > >
> >
>

Re: Updating plugin code on prepare

[Andrew Grieve <ag...@chromium.org>]

Just tried some symlinks in Xcode 5:
- Copying assets work (due to our custom build step)
- Building works (compiler follows links just fine)
- Editing a fail (big fail. Files open but changes cannot be saved.)

For Xcode though, it is an option to change our installation step to have
Xcode reference the native files within plugins/ rather than within
platforms/.


Symlinks in Eclipse:
- Copying assets works out-of-the-box
- Build works fine
- Editing seems to work fine (edits saved to symlinked location).



Still though, maybe the best solution would be a combination of the two?
Have prepare know when an remove+add is necessary?


On Fri, Sep 27, 2013 at 6:25 PM, Michal Mocny <mm...@chromium.org> wrote:

> Have we not previously solved the symlink problem in xcode with a build
> hook, or was that for prepare step?
>
> The --link concept doesn't do anything for that platforms -> plugins file
> mapping.  Its useful for mapping plugins/ to local source, but it doesn't
> help with the problem Tyler mentions, right?
>
> -Michal
>
>
> On Fri, Sep 27, 2013 at 1:20 PM, Braden Shepherdson <braden@chromium.org
> >wrote:
>
> > Symlinks in platforms/ are a problem because Xcode doesn't honour them,
> at
> > least last time we tried it.
> >
> > I'm much more enthused about the --link concept than any syncing, though.
> > Also if someone wants to sync, they can already use rsync to do it
> > manually.
> >
> > Braden
> >
> >
> > On Fri, Sep 27, 2013 at 11:45 AM, Andrew Grieve <agrieve@chromium.org
> > >wrote:
> >
> > > I think it'd be good to enumerate our options for workflow before we
> > > decided on which to implement (or maybe choose multiple).
> > >
> > > Tyler's idea about a sync command seems like it would be handy. Edit
> your
> > > plugin files within platforms/, and then run `cordova plugin
> copychanges
> > > org.my.plugin` to do a reverse copy of the source files back to the
> > install
> > > source location of the plugin. Big caveat though is that you run the
> risk
> > > of prepare clobbering your changes. I think that's too killer a risk.
> > >
> > > Another thought is that we could use symlinks when running prepare.
> Have
> > > files within platforms/ symlink to files within plugins/, then symlink
> > > again back to their original sources. Would this work with editors in
> > > practice? I don't know, but worth exploring. Wikipedia says symlinks
> work
> > > on NTFS as of Vista.
> > >
> > > Braden / Michael - I think yours is a good idea as well. Although, I
> > don't
> > > think we should encourage people to edit files within plugins/. They
> > should
> > > edit their plugins from install point. We should record the install
> path,
> > > and maybe have prepare have a prepare --update-local-plugins.
> > >
> > > Any other ideas?
> > >
> > >
> > >
> > > On Fri, Sep 27, 2013 at 3:13 PM, Michael Sierra <ms...@adobe.com>
> > wrote:
> > >
> > > > Can you please file JIRAs on doc problems like this?   Existing
> > overview
> > > > doc says you can use the CLI to bootstrap & hand off to an SDK &
> > > supporting
> > > > platform command-line utilities.  I take your comment to mean doc
> > should
> > > > better stress that once you start working with platform tools
> > downstream,
> > > > you can't go back to the CLI. Correct?
> > > >
> > > > --Mike Sierra
> > > >
> > > >
> > > > ________________________________________
> > > > From: Tyler Wilson [twilson@pulse-robotics.com]
> > > > Sent: Thursday, September 26, 2013 8:19 PM
> > > > To: dev@cordova.apache.org
> > > > Subject: Re: Updating plugin code on prepare
> > > >
> > > > Re: IDEs: if it is the case that the CLI should not be used along
> with
> > an
> > > > IDE, perhaps the documentation - including Getting Started Guides,
> > etc. -
> > > > ought to be much clearer about this. Perhaps a big warning that
> "Xcode
> > > > project files are created by the CLI, but they should not be opened
> and
> > > > used by Xcode. And you definitely should not edit code within the
> IDE".
> > > >
> > > > I just went to the main documentation site here -
> > > >
> > >
> >
> http://cordova.apache.org/docs/en/3.0.0/guide_overview_index.md.html#Overview-anditappears it only mentions the new CLI interface. No mention of the
> > > > old bin/create method. Seems to me there may be communication problem
> > > here.
> > > >
> > > > Thanks,
> > > > Tyler
> > > >
> > > > On Sep 26, 2013, at 6:11 PM, Anis KADRI <an...@gmail.com>
> wrote:
> > > >
> > > > > @purplecabbage: I have the same workflow but I think the proposed
> > > > > solution is a step in the right direction. It would allow us to
> > easily
> > > > > develop platform plugins without having to delete project/create
> > > > > project/install plugin/uninstall plugin constantly. The plugin
> would
> > > > > be packaged (plugin.xml) from day 1 and one can only focus on
> > > > > development.
> > > > >
> > > > > As far as IDEs, the answer is simple. You should not use IDEs and
> > > > > cordova-cli at the same time. Until IDEs are aware of cordova-cli
> > > > > there is no point in creating projects with cordova-cli because
> > > > > everything gets blown on every build. I am not even sure we can
> make
> > > > > Xcode aware of cordova-cli. We've already talked about this prior
> to
> > > > > the 3.0 release and that is why we have the create scripts and
> > plugman
> > > > > approach. You should not be using cordova-cli either if you're
> doing
> > > > > some custom native dev that can't be pluginized (changing the main
> > > > > Activity.java or AppDelegate.m or whatever). If you're using
> > > > > cordova-cli just to create a project and then open an IDE to
> develop,
> > > > > you're probably doing it wrong. You should be creating a native
> > > > > project and using plugman instead.
> > > > >
> > > > > On Thu, Sep 26, 2013 at 9:01 PM, Michal Mocny <mmocny@chromium.org
> >
> > > > wrote:
> > > > >> On Thu, Sep 26, 2013 at 1:39 PM, Jesse <pu...@gmail.com>
> > > wrote:
> > > > >>
> > > > >>> What does a watch mean?
> > > > >>> - if I reboot, is it still watched?
> > > > >>>
> > > > >>
> > > > >> No, this would start a process that lives until you CTRL+C.  You
> > could
> > > > have
> > > > >> it run it in the background, or set it to start of startup, but
> that
> > > > would
> > > > >> be using local system tools, not part of the command itself.
> > > > >>
> > > > >> Ideally, "watch" should run "prepare" whenever you would have
> wanted
> > > it
> > > > to.
> > > > >> Though obviously that cannot be perfect, it can be a useful tool
> > when
> > > > >> iterating.
> > > > >>
> > > > >>
> > > > >>>
> > > > >>> I think it would be best to consider separating development from
> > > > packaging
> > > > >>> in your use-case for workflow.
> > > > >>> If I am going to develop featureX as a plugin I would :
> > > > >>>
> > > > >>> 1. create a project for a single cordova platform, and develop
> the
> > > > feature
> > > > >>> as a native piece, and a js piece.
> > > > >>> 2. test thoroughly
> > > > >>> 3. create a project for a second cordova platform, and develop
> the
> > > > native
> > > > >>> bit, preserving the js from 1
> > > > >>> 4. test thoroughly
> > > > >>> 5. repeat steps 3+4 for any remaining platforms
> > > > >>> 6. package featureX as a plugin by organizing relevant bits in
> the
> > > > correct
> > > > >>> folder structure, and adding a plugin.xml
> > > > >>> 7. test each platform by installing with plugman
> > > > >>> 8. publish
> > > > >>>
> > > > >>
> > > > >> As a plugin developer, that is not my workflow.
> > > > >>
> > > > >> Typically for me its:
> > > > >>
> > > > >> Write a sample app/manual test for some new feature that isn't
> > > > implemented
> > > > >> yet.
> > > > >> Create a new plugin Foo for iOS & Android, and stub the
> > > implementation.
> > > > >> Implement feature A of plugin Foo for iOS, test, add it for
> Android,
> > > > test.
> > > > >> Implement feature B of plugin Foo for iOS, test, add it for
> Android,
> > > > test.
> > > > >> ...
> > > > >>
> > > > >> Usually the js implementation is shared, the auto tests are
> shared,
> > > and
> > > > the
> > > > >> sample test app is shared.
> > > > >>
> > > > >> Sure, I do platform specific stuff for testing and implementation,
> > > but I
> > > > >> certainly wouldn't say I do plugin development in platform
> > isolation.
> > > > >>
> > > > >> Also, right now we do not have a "plugin create" command, and so
> > > leaving
> > > > >> the "packaging" step for last doesn't add affect total work.  But
> > once
> > > > we
> > > > >> do have such a command, plugins could start packaged, and adding
> the
> > > > small
> > > > >> changes to plugin.xml as you need them is likely a good way to go.
> > > > >>
> > > > >> Finally, this workflow would get people out of the habit of making
> > > > changes
> > > > >> to the platform artifacts directly.  I'm not sure that can be
> > entirely
> > > > >> avoided in all cases, but why shouldn't we work towards making
> that
> > > > easier?
> > > > >>
> > > > >>
> > > > >>> We seem to have this notion come up repeatedly that our users +
> > > plugin
> > > > >>> developers are working on multiple platforms at the same time,
> > which
> > > I
> > > > >>> think is entirely false.
> > > > >>>
> > > > >>
> > > > >> Since we differ in opinion, how can we put this to the test?
> > > > >>
> > > > >> Also, we specifically make sure all our features address the needs
> > of
> > > > those
> > > > >> doing single platform development, so in a world of 3.0+ cli, I
> > really
> > > > >> don't see how we can not do the same to address the needs of those
> > who
> > > > do
> > > > >> do multi-platform development, especially when we have a good
> > proposal
> > > > of
> > > > >> how to do so and someone willing to do it.
> > > > >>
> > > > >>
> > > > >>> I also think we're trying to help the wrong people; If I am a
> > > > developer who
> > > > >>> is working on multiple platforms at once, and I have a bunch of
> > > devices
> > > > >>> attached, I probably also have the skills to set up my own grunt
> > > > continuous
> > > > >>> integration system. Setting up tooling for potential plugin
> > > developers
> > > > is
> > > > >>> the wrong approach, imho. We should actually just go and
> implement
> > > > some new
> > > > >>> plugin and evaluate the process instead of creating and imposing
> a
> > > > specific
> > > > >>> workflow.
> > > > >>>
> > > > >>
> > > > >> The first part of this argument has some merit, I agree.  We the
> > > > >> power-users have found ways to address our problems.  However, I
> > think
> > > > that
> > > > >> with this change it means that even the end user can make changes
> to
> > > > plugin
> > > > >> folder as they find bugs/etc, and expect to see the change
> reflected
> > > > after
> > > > >> running prepare.  This is principle of least surprise, and just
> good
> > > > design.
> > > > >>
> > > > >> I also don't think we are imposing any specific workflow here,
> just
> > > > >> enabling a new one.  Personally I think that its quite surprising
> > and
> > > > >> embarrassing that we haven't enabled this workflow since 3.0.
> > > > >>
> > > > >>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>> @purplecabbage
> > > > >>> risingj.com
> > > > >>>
> > > > >>>
> > > > >>> On Thu, Sep 26, 2013 at 10:09 AM, Brian LeRoux <b...@brian.io>
> wrote:
> > > > >>>
> > > > >>>> I love the idea of a watch command.
> > > > >>>>
> > > > >>>>
> > > > >>>> On Thu, Sep 26, 2013 at 4:48 PM, Anis KADRI <
> anis.kadri@gmail.com
> > >
> > > > >>> wrote:
> > > > >>>>
> > > > >>>>> Forgot about the existence of --link for a second. I think this
> > is
> > > a
> > > > >>>>> good solution (not temporary). watch can be an enhancement to
> > this
> > > > >>>>> solution. This might get people like Joe Bowser and other
> people
> > > who
> > > > >>>>> do native dev to give cordova-cli a try (only maybe though).
> > > > >>>>>
> > > > >>>>> On Thu, Sep 26, 2013 at 4:25 PM, Braden Shepherdson <
> > > > >>> braden@chromium.org
> > > > >>>>>
> > > > >>>>> wrote:
> > > > >>>>>> If the proposal above is temporary, what's permanent? cordova
> > > watch?
> > > > >>> I
> > > > >>>>> want
> > > > >>>>>> to make sure we're on the same page.
> > > > >>>>>>
> > > > >>>>>> Braden
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>> On Thu, Sep 26, 2013 at 6:08 AM, Anis KADRI <
> > anis.kadri@gmail.com
> > > >
> > > > >>>>> wrote:
> > > > >>>>>>
> > > > >>>>>>> No I didn't mean implement `plugman --watch`. I don't think
> > > plugman
> > > > >>>>>>> needs a `watch` command.
> > > > >>>>>>>
> > > > >>>>>>> I was indeed talking about `cordova watch` which should watch
> > for
> > > > >>>>>>> changes in plugins/ (and maybe in merges/ and www/ as well)
> and
> > > > >>> update
> > > > >>>>>>> the platform projects (prepare?) on every change.  I am happy
> > to
> > > > >>> know
> > > > >>>>>>> that it's on the wish list.
> > > > >>>>>>>
> > > > >>>>>>> As far as the original proposal, I believe it is a descent
> > > > temporary
> > > > >>>>>>> solution for plugin developers who want to use cordova-cli.
> > > > >>>>>>>
> > > > >>>>>>> On Wed, Sep 25, 2013 at 7:17 PM, Michal Mocny <
> > > mmocny@chromium.org
> > > > >
> > > > >>>>> wrote:
> > > > >>>>>>>> Braden, thats has been on the wish list (cordova watch),
> but I
> > > > >>>> suspect
> > > > >>>>>>> Anis
> > > > >>>>>>>> was suggesting something different with plugman --watch, to
> do
> > > > >>>>>>> specifically
> > > > >>>>>>>> with plugin development.  Am I right, Anis?  How does your
> > idea
> > > > >>>>> compare
> > > > >>>>>>>> with using --link with cordova watch?  Would plugman --watch
> > be
> > > > >>>> useful
> > > > >>>>>>> for
> > > > >>>>>>>> non cli projects?
> > > > >>>>>>>>
> > > > >>>>>>>> -Michal
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>> On Wed, Sep 25, 2013 at 10:31 AM, Braden Shepherdson <
> > > > >>>>>>> braden@chromium.org>wrote:
> > > > >>>>>>>>
> > > > >>>>>>>>> We've had a vague feature planned for a while now to do a
> > > cordova
> > > > >>>>>>> watch. It
> > > > >>>>>>>>> would watch your plugins/, www/, and merges/* for any
> > changes.
> > > If
> > > > >>>> any
> > > > >>>>>>>>> changes are detected, it would re-run cordova prepare, so
> > that
> > > > >>> your
> > > > >>>>>>> native
> > > > >>>>>>>>> projects are always up-to-date.
> > > > >>>>>>>>>
> > > > >>>>>>>>> I'm open to checking (hashes?) which files have changed and
> > > which
> > > > >>>>> have
> > > > >>>>>>> not,
> > > > >>>>>>>>> but hashing them all is touching them all anyway, and it
> > might
> > > be
> > > > >>>>> faster
> > > > >>>>>>>>> for small files to just copy them instead of checking
> first.
> > > > >>> We'll
> > > > >>>>> have
> > > > >>>>>>> to
> > > > >>>>>>>>> try it and see; for v1 I'm going with the simple option of
> > > > >>> copying
> > > > >>>>>>>>> everything.
> > > > >>>>>>>>>
> > > > >>>>>>>>> Braden
> > > > >>>>>>>>>
> > > > >>>>>>>>>
> > > > >>>>>>>>> On Wed, Sep 25, 2013 at 9:44 AM, Michal Mocny <
> > > > >>> mmocny@chromium.org
> > > > >>>>>
> > > > >>>>>>> wrote:
> > > > >>>>>>>>>
> > > > >>>>>>>>>> The idea for plugin dev outside of plugins/ folder was to
> > use
> > > > >>>>> "plugin
> > > > >>>>>>> add
> > > > >>>>>>>>>> --link".  Matter of fact, braden suggested that "plugin
> > > create"
> > > > >>>>> should
> > > > >>>>>>>>>> default to --link-ing to some external location so that
> you
> > > > >>> don't
> > > > >>>>> risk
> > > > >>>>>>>>>> deleting your only copy inside plugins/.  (I personally
> > don't
> > > > >>>> think
> > > > >>>>>>>>> thats a
> > > > >>>>>>>>>> necessary concern, but I think its a conversation for
> > later).
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> I'm not even sure what a 'watch' would do, just uninstall
> &
> > > > >>>> install
> > > > >>>>>>> each
> > > > >>>>>>>>>> time the plugin changes?  I think that ends up being just
> > > > >>>> slightly
> > > > >>>>>>> worse
> > > > >>>>>>>>>> than the current proposal if you factor in that we already
> > do
> > > > >>>>> support
> > > > >>>>>>>>>> --link (except without the above change its been useless).
> > > > >>>>>>>>>>
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> However, we may still want some form of 'watch' command
> for
> > > > >>> devs
> > > > >>>>> using
> > > > >>>>>>>>>> plugman directly.  I had assumed that those devs just edit
> > in
> > > > >>>>> place,
> > > > >>>>>>>>> since
> > > > >>>>>>>>>> they don't use a prepare step anyway.
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> -Michal
> > > > >>>>>>>>>>
> > > > >>>>>>>>>>
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> On Wed, Sep 25, 2013 at 7:50 AM, Anis KADRI <
> > > > >>>> anis.kadri@gmail.com>
> > > > >>>>>>>>> wrote:
> > > > >>>>>>>>>>
> > > > >>>>>>>>>>> If we're talking about developing plugins inside the
> > > > >>>>>>>>>>> plugins/org.myplugin.id folder than I think it's a great
> > > > >>>>> workflow
> > > > >>>>>>> and
> > > > >>>>>>>>>>> I would just hide the cached version of plugin.xml inside
> > > > >>> that
> > > > >>>>>>>>>>> plugins/org.myplugin.id folder.
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> However, if you're developing a plugin outside of a
> cordova
> > > > >>> CLI
> > > > >>>>>>>>>>> project, I think a `watch` (and add --watch) command is
> > more
> > > > >>>>>>>>>>> appropriate. One of the reasons you would develop a
> plugin
> > > > >>>>> outside
> > > > >>>>>>> of
> > > > >>>>>>>>>>> a cordova CLI project is for easier version control (each
> > > > >>>> plugin
> > > > >>>>>>> would
> > > > >>>>>>>>>>> have its own repository). The other cool thing about
> > `watch`
> > > > >>> is
> > > > >>>>> that
> > > > >>>>>>>>>>> it would copy the files that have actually changed and
> not
> > > > >>>>>>> everything
> > > > >>>>>>>>>>> (some plugins have a LOT of files [1]).
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> [1] https://github.com/phonegap/phonegap-facebook-plugin
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> On Wed, Sep 25, 2013 at 3:30 AM, James Jong <
> > > > >>>>> wjamesjong@gmail.com>
> > > > >>>>>>>>>> wrote:
> > > > >>>>>>>>>>>> +1 This is a cleaner workflow and should reduce some
> > > > >>>> confusion.
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>> -James Jong
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>> On Sep 24, 2013, at 3:09 PM, Michal Mocny <
> > > > >>>> mmocny@chromium.org
> > > > >>>>>>
> > > > >>>>>>>>> wrote:
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>>> Just to add, the reason for the "if" statement in step
> > (2)
> > > > >>>> is
> > > > >>>>>>> that
> > > > >>>>>>>>>>>>> uninstall & reinstall take a lot longer than just
> moving
> > a
> > > > >>>> few
> > > > >>>>>>>>> files,
> > > > >>>>>>>>>>> which
> > > > >>>>>>>>>>>>> is the 99.9% case for most end users who aren't making
> > > > >>>>>>> modifications
> > > > >>>>>>>>>> to
> > > > >>>>>>>>>>>>> plugins.
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>> This way, we only do the heavy lifting if your plugin
> > > > >>>>> structure
> > > > >>>>>>>>>> actually
> > > > >>>>>>>>>>>>> changed.  Doing it automatically means we no longer
> have
> > > > >>> to
> > > > >>>>>>> advise
> > > > >>>>>>>>>> users
> > > > >>>>>>>>>>>>> that making edits inside plugin/ folder is useless.
>  Now
> > > > >>> we
> > > > >>>>> just
> > > > >>>>>>>>>> advise
> > > > >>>>>>>>>>>>> them to run "prepare" after making changes to either
> www/
> > > > >>> or
> > > > >>>>>>>>> plugins/.
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>> This key insight was Braden's idea and I think its just
> > an
> > > > >>>>>>> awesome
> > > > >>>>>>>>>>> change
> > > > >>>>>>>>>>>>> for workflow.
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>> -Michal
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>> On Tue, Sep 24, 2013 at 2:58 PM, Braden Shepherdson <
> > > > >>>>>>>>>>> braden@chromium.org>wrote:
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>> 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
> > > > >>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>
> > > > >>>>>>>>>
> > > > >>>>>>>
> > > > >>>>>
> > > > >>>>
> > > > >>>
> > > >
> > >
> >
>

Re: Updating plugin code on prepare

[Michal Mocny <mm...@chromium.org>]

Have we not previously solved the symlink problem in xcode with a build
hook, or was that for prepare step?

The --link concept doesn't do anything for that platforms -> plugins file
mapping.  Its useful for mapping plugins/ to local source, but it doesn't
help with the problem Tyler mentions, right?

-Michal


On Fri, Sep 27, 2013 at 1:20 PM, Braden Shepherdson <br...@chromium.org>wrote:

> Symlinks in platforms/ are a problem because Xcode doesn't honour them, at
> least last time we tried it.
>
> I'm much more enthused about the --link concept than any syncing, though.
> Also if someone wants to sync, they can already use rsync to do it
> manually.
>
> Braden
>
>
> On Fri, Sep 27, 2013 at 11:45 AM, Andrew Grieve <agrieve@chromium.org
> >wrote:
>
> > I think it'd be good to enumerate our options for workflow before we
> > decided on which to implement (or maybe choose multiple).
> >
> > Tyler's idea about a sync command seems like it would be handy. Edit your
> > plugin files within platforms/, and then run `cordova plugin copychanges
> > org.my.plugin` to do a reverse copy of the source files back to the
> install
> > source location of the plugin. Big caveat though is that you run the risk
> > of prepare clobbering your changes. I think that's too killer a risk.
> >
> > Another thought is that we could use symlinks when running prepare. Have
> > files within platforms/ symlink to files within plugins/, then symlink
> > again back to their original sources. Would this work with editors in
> > practice? I don't know, but worth exploring. Wikipedia says symlinks work
> > on NTFS as of Vista.
> >
> > Braden / Michael - I think yours is a good idea as well. Although, I
> don't
> > think we should encourage people to edit files within plugins/. They
> should
> > edit their plugins from install point. We should record the install path,
> > and maybe have prepare have a prepare --update-local-plugins.
> >
> > Any other ideas?
> >
> >
> >
> > On Fri, Sep 27, 2013 at 3:13 PM, Michael Sierra <ms...@adobe.com>
> wrote:
> >
> > > Can you please file JIRAs on doc problems like this?   Existing
> overview
> > > doc says you can use the CLI to bootstrap & hand off to an SDK &
> > supporting
> > > platform command-line utilities.  I take your comment to mean doc
> should
> > > better stress that once you start working with platform tools
> downstream,
> > > you can't go back to the CLI. Correct?
> > >
> > > --Mike Sierra
> > >
> > >
> > > ________________________________________
> > > From: Tyler Wilson [twilson@pulse-robotics.com]
> > > Sent: Thursday, September 26, 2013 8:19 PM
> > > To: dev@cordova.apache.org
> > > Subject: Re: Updating plugin code on prepare
> > >
> > > Re: IDEs: if it is the case that the CLI should not be used along with
> an
> > > IDE, perhaps the documentation - including Getting Started Guides,
> etc. -
> > > ought to be much clearer about this. Perhaps a big warning that "Xcode
> > > project files are created by the CLI, but they should not be opened and
> > > used by Xcode. And you definitely should not edit code within the IDE".
> > >
> > > I just went to the main documentation site here -
> > >
> >
> http://cordova.apache.org/docs/en/3.0.0/guide_overview_index.md.html#Overview-andit appears it only mentions the new CLI interface. No mention of the
> > > old bin/create method. Seems to me there may be communication problem
> > here.
> > >
> > > Thanks,
> > > Tyler
> > >
> > > On Sep 26, 2013, at 6:11 PM, Anis KADRI <an...@gmail.com> wrote:
> > >
> > > > @purplecabbage: I have the same workflow but I think the proposed
> > > > solution is a step in the right direction. It would allow us to
> easily
> > > > develop platform plugins without having to delete project/create
> > > > project/install plugin/uninstall plugin constantly. The plugin would
> > > > be packaged (plugin.xml) from day 1 and one can only focus on
> > > > development.
> > > >
> > > > As far as IDEs, the answer is simple. You should not use IDEs and
> > > > cordova-cli at the same time. Until IDEs are aware of cordova-cli
> > > > there is no point in creating projects with cordova-cli because
> > > > everything gets blown on every build. I am not even sure we can make
> > > > Xcode aware of cordova-cli. We've already talked about this prior to
> > > > the 3.0 release and that is why we have the create scripts and
> plugman
> > > > approach. You should not be using cordova-cli either if you're doing
> > > > some custom native dev that can't be pluginized (changing the main
> > > > Activity.java or AppDelegate.m or whatever). If you're using
> > > > cordova-cli just to create a project and then open an IDE to develop,
> > > > you're probably doing it wrong. You should be creating a native
> > > > project and using plugman instead.
> > > >
> > > > On Thu, Sep 26, 2013 at 9:01 PM, Michal Mocny <mm...@chromium.org>
> > > wrote:
> > > >> On Thu, Sep 26, 2013 at 1:39 PM, Jesse <pu...@gmail.com>
> > wrote:
> > > >>
> > > >>> What does a watch mean?
> > > >>> - if I reboot, is it still watched?
> > > >>>
> > > >>
> > > >> No, this would start a process that lives until you CTRL+C.  You
> could
> > > have
> > > >> it run it in the background, or set it to start of startup, but that
> > > would
> > > >> be using local system tools, not part of the command itself.
> > > >>
> > > >> Ideally, "watch" should run "prepare" whenever you would have wanted
> > it
> > > to.
> > > >> Though obviously that cannot be perfect, it can be a useful tool
> when
> > > >> iterating.
> > > >>
> > > >>
> > > >>>
> > > >>> I think it would be best to consider separating development from
> > > packaging
> > > >>> in your use-case for workflow.
> > > >>> If I am going to develop featureX as a plugin I would :
> > > >>>
> > > >>> 1. create a project for a single cordova platform, and develop the
> > > feature
> > > >>> as a native piece, and a js piece.
> > > >>> 2. test thoroughly
> > > >>> 3. create a project for a second cordova platform, and develop the
> > > native
> > > >>> bit, preserving the js from 1
> > > >>> 4. test thoroughly
> > > >>> 5. repeat steps 3+4 for any remaining platforms
> > > >>> 6. package featureX as a plugin by organizing relevant bits in the
> > > correct
> > > >>> folder structure, and adding a plugin.xml
> > > >>> 7. test each platform by installing with plugman
> > > >>> 8. publish
> > > >>>
> > > >>
> > > >> As a plugin developer, that is not my workflow.
> > > >>
> > > >> Typically for me its:
> > > >>
> > > >> Write a sample app/manual test for some new feature that isn't
> > > implemented
> > > >> yet.
> > > >> Create a new plugin Foo for iOS & Android, and stub the
> > implementation.
> > > >> Implement feature A of plugin Foo for iOS, test, add it for Android,
> > > test.
> > > >> Implement feature B of plugin Foo for iOS, test, add it for Android,
> > > test.
> > > >> ...
> > > >>
> > > >> Usually the js implementation is shared, the auto tests are shared,
> > and
> > > the
> > > >> sample test app is shared.
> > > >>
> > > >> Sure, I do platform specific stuff for testing and implementation,
> > but I
> > > >> certainly wouldn't say I do plugin development in platform
> isolation.
> > > >>
> > > >> Also, right now we do not have a "plugin create" command, and so
> > leaving
> > > >> the "packaging" step for last doesn't add affect total work.  But
> once
> > > we
> > > >> do have such a command, plugins could start packaged, and adding the
> > > small
> > > >> changes to plugin.xml as you need them is likely a good way to go.
> > > >>
> > > >> Finally, this workflow would get people out of the habit of making
> > > changes
> > > >> to the platform artifacts directly.  I'm not sure that can be
> entirely
> > > >> avoided in all cases, but why shouldn't we work towards making that
> > > easier?
> > > >>
> > > >>
> > > >>> We seem to have this notion come up repeatedly that our users +
> > plugin
> > > >>> developers are working on multiple platforms at the same time,
> which
> > I
> > > >>> think is entirely false.
> > > >>>
> > > >>
> > > >> Since we differ in opinion, how can we put this to the test?
> > > >>
> > > >> Also, we specifically make sure all our features address the needs
> of
> > > those
> > > >> doing single platform development, so in a world of 3.0+ cli, I
> really
> > > >> don't see how we can not do the same to address the needs of those
> who
> > > do
> > > >> do multi-platform development, especially when we have a good
> proposal
> > > of
> > > >> how to do so and someone willing to do it.
> > > >>
> > > >>
> > > >>> I also think we're trying to help the wrong people; If I am a
> > > developer who
> > > >>> is working on multiple platforms at once, and I have a bunch of
> > devices
> > > >>> attached, I probably also have the skills to set up my own grunt
> > > continuous
> > > >>> integration system. Setting up tooling for potential plugin
> > developers
> > > is
> > > >>> the wrong approach, imho. We should actually just go and implement
> > > some new
> > > >>> plugin and evaluate the process instead of creating and imposing a
> > > specific
> > > >>> workflow.
> > > >>>
> > > >>
> > > >> The first part of this argument has some merit, I agree.  We the
> > > >> power-users have found ways to address our problems.  However, I
> think
> > > that
> > > >> with this change it means that even the end user can make changes to
> > > plugin
> > > >> folder as they find bugs/etc, and expect to see the change reflected
> > > after
> > > >> running prepare.  This is principle of least surprise, and just good
> > > design.
> > > >>
> > > >> I also don't think we are imposing any specific workflow here, just
> > > >> enabling a new one.  Personally I think that its quite surprising
> and
> > > >> embarrassing that we haven't enabled this workflow since 3.0.
> > > >>
> > > >>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>> @purplecabbage
> > > >>> risingj.com
> > > >>>
> > > >>>
> > > >>> On Thu, Sep 26, 2013 at 10:09 AM, Brian LeRoux <b...@brian.io> wrote:
> > > >>>
> > > >>>> I love the idea of a watch command.
> > > >>>>
> > > >>>>
> > > >>>> On Thu, Sep 26, 2013 at 4:48 PM, Anis KADRI <anis.kadri@gmail.com
> >
> > > >>> wrote:
> > > >>>>
> > > >>>>> Forgot about the existence of --link for a second. I think this
> is
> > a
> > > >>>>> good solution (not temporary). watch can be an enhancement to
> this
> > > >>>>> solution. This might get people like Joe Bowser and other people
> > who
> > > >>>>> do native dev to give cordova-cli a try (only maybe though).
> > > >>>>>
> > > >>>>> On Thu, Sep 26, 2013 at 4:25 PM, Braden Shepherdson <
> > > >>> braden@chromium.org
> > > >>>>>
> > > >>>>> wrote:
> > > >>>>>> If the proposal above is temporary, what's permanent? cordova
> > watch?
> > > >>> I
> > > >>>>> want
> > > >>>>>> to make sure we're on the same page.
> > > >>>>>>
> > > >>>>>> Braden
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> On Thu, Sep 26, 2013 at 6:08 AM, Anis KADRI <
> anis.kadri@gmail.com
> > >
> > > >>>>> wrote:
> > > >>>>>>
> > > >>>>>>> No I didn't mean implement `plugman --watch`. I don't think
> > plugman
> > > >>>>>>> needs a `watch` command.
> > > >>>>>>>
> > > >>>>>>> I was indeed talking about `cordova watch` which should watch
> for
> > > >>>>>>> changes in plugins/ (and maybe in merges/ and www/ as well) and
> > > >>> update
> > > >>>>>>> the platform projects (prepare?) on every change.  I am happy
> to
> > > >>> know
> > > >>>>>>> that it's on the wish list.
> > > >>>>>>>
> > > >>>>>>> As far as the original proposal, I believe it is a descent
> > > temporary
> > > >>>>>>> solution for plugin developers who want to use cordova-cli.
> > > >>>>>>>
> > > >>>>>>> On Wed, Sep 25, 2013 at 7:17 PM, Michal Mocny <
> > mmocny@chromium.org
> > > >
> > > >>>>> wrote:
> > > >>>>>>>> Braden, thats has been on the wish list (cordova watch), but I
> > > >>>> suspect
> > > >>>>>>> Anis
> > > >>>>>>>> was suggesting something different with plugman --watch, to do
> > > >>>>>>> specifically
> > > >>>>>>>> with plugin development.  Am I right, Anis?  How does your
> idea
> > > >>>>> compare
> > > >>>>>>>> with using --link with cordova watch?  Would plugman --watch
> be
> > > >>>> useful
> > > >>>>>>> for
> > > >>>>>>>> non cli projects?
> > > >>>>>>>>
> > > >>>>>>>> -Michal
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> On Wed, Sep 25, 2013 at 10:31 AM, Braden Shepherdson <
> > > >>>>>>> braden@chromium.org>wrote:
> > > >>>>>>>>
> > > >>>>>>>>> We've had a vague feature planned for a while now to do a
> > cordova
> > > >>>>>>> watch. It
> > > >>>>>>>>> would watch your plugins/, www/, and merges/* for any
> changes.
> > If
> > > >>>> any
> > > >>>>>>>>> changes are detected, it would re-run cordova prepare, so
> that
> > > >>> your
> > > >>>>>>> native
> > > >>>>>>>>> projects are always up-to-date.
> > > >>>>>>>>>
> > > >>>>>>>>> I'm open to checking (hashes?) which files have changed and
> > which
> > > >>>>> have
> > > >>>>>>> not,
> > > >>>>>>>>> but hashing them all is touching them all anyway, and it
> might
> > be
> > > >>>>> faster
> > > >>>>>>>>> for small files to just copy them instead of checking first.
> > > >>> We'll
> > > >>>>> have
> > > >>>>>>> to
> > > >>>>>>>>> try it and see; for v1 I'm going with the simple option of
> > > >>> copying
> > > >>>>>>>>> everything.
> > > >>>>>>>>>
> > > >>>>>>>>> Braden
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>> On Wed, Sep 25, 2013 at 9:44 AM, Michal Mocny <
> > > >>> mmocny@chromium.org
> > > >>>>>
> > > >>>>>>> wrote:
> > > >>>>>>>>>
> > > >>>>>>>>>> The idea for plugin dev outside of plugins/ folder was to
> use
> > > >>>>> "plugin
> > > >>>>>>> add
> > > >>>>>>>>>> --link".  Matter of fact, braden suggested that "plugin
> > create"
> > > >>>>> should
> > > >>>>>>>>>> default to --link-ing to some external location so that you
> > > >>> don't
> > > >>>>> risk
> > > >>>>>>>>>> deleting your only copy inside plugins/.  (I personally
> don't
> > > >>>> think
> > > >>>>>>>>> thats a
> > > >>>>>>>>>> necessary concern, but I think its a conversation for
> later).
> > > >>>>>>>>>>
> > > >>>>>>>>>> I'm not even sure what a 'watch' would do, just uninstall &
> > > >>>> install
> > > >>>>>>> each
> > > >>>>>>>>>> time the plugin changes?  I think that ends up being just
> > > >>>> slightly
> > > >>>>>>> worse
> > > >>>>>>>>>> than the current proposal if you factor in that we already
> do
> > > >>>>> support
> > > >>>>>>>>>> --link (except without the above change its been useless).
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>> However, we may still want some form of 'watch' command for
> > > >>> devs
> > > >>>>> using
> > > >>>>>>>>>> plugman directly.  I had assumed that those devs just edit
> in
> > > >>>>> place,
> > > >>>>>>>>> since
> > > >>>>>>>>>> they don't use a prepare step anyway.
> > > >>>>>>>>>>
> > > >>>>>>>>>> -Michal
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>> On Wed, Sep 25, 2013 at 7:50 AM, Anis KADRI <
> > > >>>> anis.kadri@gmail.com>
> > > >>>>>>>>> wrote:
> > > >>>>>>>>>>
> > > >>>>>>>>>>> If we're talking about developing plugins inside the
> > > >>>>>>>>>>> plugins/org.myplugin.id folder than I think it's a great
> > > >>>>> workflow
> > > >>>>>>> and
> > > >>>>>>>>>>> I would just hide the cached version of plugin.xml inside
> > > >>> that
> > > >>>>>>>>>>> plugins/org.myplugin.id folder.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> However, if you're developing a plugin outside of a cordova
> > > >>> CLI
> > > >>>>>>>>>>> project, I think a `watch` (and add --watch) command is
> more
> > > >>>>>>>>>>> appropriate. One of the reasons you would develop a plugin
> > > >>>>> outside
> > > >>>>>>> of
> > > >>>>>>>>>>> a cordova CLI project is for easier version control (each
> > > >>>> plugin
> > > >>>>>>> would
> > > >>>>>>>>>>> have its own repository). The other cool thing about
> `watch`
> > > >>> is
> > > >>>>> that
> > > >>>>>>>>>>> it would copy the files that have actually changed and not
> > > >>>>>>> everything
> > > >>>>>>>>>>> (some plugins have a LOT of files [1]).
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> [1] https://github.com/phonegap/phonegap-facebook-plugin
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> On Wed, Sep 25, 2013 at 3:30 AM, James Jong <
> > > >>>>> wjamesjong@gmail.com>
> > > >>>>>>>>>> wrote:
> > > >>>>>>>>>>>> +1 This is a cleaner workflow and should reduce some
> > > >>>> confusion.
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> -James Jong
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> On Sep 24, 2013, at 3:09 PM, Michal Mocny <
> > > >>>> mmocny@chromium.org
> > > >>>>>>
> > > >>>>>>>>> wrote:
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>> Just to add, the reason for the "if" statement in step
> (2)
> > > >>>> is
> > > >>>>>>> that
> > > >>>>>>>>>>>>> uninstall & reinstall take a lot longer than just moving
> a
> > > >>>> few
> > > >>>>>>>>> files,
> > > >>>>>>>>>>> which
> > > >>>>>>>>>>>>> is the 99.9% case for most end users who aren't making
> > > >>>>>>> modifications
> > > >>>>>>>>>> to
> > > >>>>>>>>>>>>> plugins.
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> This way, we only do the heavy lifting if your plugin
> > > >>>>> structure
> > > >>>>>>>>>> actually
> > > >>>>>>>>>>>>> changed.  Doing it automatically means we no longer have
> > > >>> to
> > > >>>>>>> advise
> > > >>>>>>>>>> users
> > > >>>>>>>>>>>>> that making edits inside plugin/ folder is useless.  Now
> > > >>> we
> > > >>>>> just
> > > >>>>>>>>>> advise
> > > >>>>>>>>>>>>> them to run "prepare" after making changes to either www/
> > > >>> or
> > > >>>>>>>>> plugins/.
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> This key insight was Braden's idea and I think its just
> an
> > > >>>>>>> awesome
> > > >>>>>>>>>>> change
> > > >>>>>>>>>>>>> for workflow.
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> -Michal
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> On Tue, Sep 24, 2013 at 2:58 PM, Braden Shepherdson <
> > > >>>>>>>>>>> braden@chromium.org>wrote:
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> 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
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>
> > > >>>>>
> > > >>>>
> > > >>>
> > >
> >
>

Re: Updating plugin code on prepare

[Braden Shepherdson <br...@chromium.org>]

Symlinks in platforms/ are a problem because Xcode doesn't honour them, at
least last time we tried it.

I'm much more enthused about the --link concept than any syncing, though.
Also if someone wants to sync, they can already use rsync to do it manually.

Braden


On Fri, Sep 27, 2013 at 11:45 AM, Andrew Grieve <ag...@chromium.org>wrote:

> I think it'd be good to enumerate our options for workflow before we
> decided on which to implement (or maybe choose multiple).
>
> Tyler's idea about a sync command seems like it would be handy. Edit your
> plugin files within platforms/, and then run `cordova plugin copychanges
> org.my.plugin` to do a reverse copy of the source files back to the install
> source location of the plugin. Big caveat though is that you run the risk
> of prepare clobbering your changes. I think that's too killer a risk.
>
> Another thought is that we could use symlinks when running prepare. Have
> files within platforms/ symlink to files within plugins/, then symlink
> again back to their original sources. Would this work with editors in
> practice? I don't know, but worth exploring. Wikipedia says symlinks work
> on NTFS as of Vista.
>
> Braden / Michael - I think yours is a good idea as well. Although, I don't
> think we should encourage people to edit files within plugins/. They should
> edit their plugins from install point. We should record the install path,
> and maybe have prepare have a prepare --update-local-plugins.
>
> Any other ideas?
>
>
>
> On Fri, Sep 27, 2013 at 3:13 PM, Michael Sierra <ms...@adobe.com> wrote:
>
> > Can you please file JIRAs on doc problems like this?   Existing overview
> > doc says you can use the CLI to bootstrap & hand off to an SDK &
> supporting
> > platform command-line utilities.  I take your comment to mean doc should
> > better stress that once you start working with platform tools downstream,
> > you can't go back to the CLI. Correct?
> >
> > --Mike Sierra
> >
> >
> > ________________________________________
> > From: Tyler Wilson [twilson@pulse-robotics.com]
> > Sent: Thursday, September 26, 2013 8:19 PM
> > To: dev@cordova.apache.org
> > Subject: Re: Updating plugin code on prepare
> >
> > Re: IDEs: if it is the case that the CLI should not be used along with an
> > IDE, perhaps the documentation - including Getting Started Guides, etc. -
> > ought to be much clearer about this. Perhaps a big warning that "Xcode
> > project files are created by the CLI, but they should not be opened and
> > used by Xcode. And you definitely should not edit code within the IDE".
> >
> > I just went to the main documentation site here -
> >
> http://cordova.apache.org/docs/en/3.0.0/guide_overview_index.md.html#Overview-and it appears it only mentions the new CLI interface. No mention of the
> > old bin/create method. Seems to me there may be communication problem
> here.
> >
> > Thanks,
> > Tyler
> >
> > On Sep 26, 2013, at 6:11 PM, Anis KADRI <an...@gmail.com> wrote:
> >
> > > @purplecabbage: I have the same workflow but I think the proposed
> > > solution is a step in the right direction. It would allow us to easily
> > > develop platform plugins without having to delete project/create
> > > project/install plugin/uninstall plugin constantly. The plugin would
> > > be packaged (plugin.xml) from day 1 and one can only focus on
> > > development.
> > >
> > > As far as IDEs, the answer is simple. You should not use IDEs and
> > > cordova-cli at the same time. Until IDEs are aware of cordova-cli
> > > there is no point in creating projects with cordova-cli because
> > > everything gets blown on every build. I am not even sure we can make
> > > Xcode aware of cordova-cli. We've already talked about this prior to
> > > the 3.0 release and that is why we have the create scripts and plugman
> > > approach. You should not be using cordova-cli either if you're doing
> > > some custom native dev that can't be pluginized (changing the main
> > > Activity.java or AppDelegate.m or whatever). If you're using
> > > cordova-cli just to create a project and then open an IDE to develop,
> > > you're probably doing it wrong. You should be creating a native
> > > project and using plugman instead.
> > >
> > > On Thu, Sep 26, 2013 at 9:01 PM, Michal Mocny <mm...@chromium.org>
> > wrote:
> > >> On Thu, Sep 26, 2013 at 1:39 PM, Jesse <pu...@gmail.com>
> wrote:
> > >>
> > >>> What does a watch mean?
> > >>> - if I reboot, is it still watched?
> > >>>
> > >>
> > >> No, this would start a process that lives until you CTRL+C.  You could
> > have
> > >> it run it in the background, or set it to start of startup, but that
> > would
> > >> be using local system tools, not part of the command itself.
> > >>
> > >> Ideally, "watch" should run "prepare" whenever you would have wanted
> it
> > to.
> > >> Though obviously that cannot be perfect, it can be a useful tool when
> > >> iterating.
> > >>
> > >>
> > >>>
> > >>> I think it would be best to consider separating development from
> > packaging
> > >>> in your use-case for workflow.
> > >>> If I am going to develop featureX as a plugin I would :
> > >>>
> > >>> 1. create a project for a single cordova platform, and develop the
> > feature
> > >>> as a native piece, and a js piece.
> > >>> 2. test thoroughly
> > >>> 3. create a project for a second cordova platform, and develop the
> > native
> > >>> bit, preserving the js from 1
> > >>> 4. test thoroughly
> > >>> 5. repeat steps 3+4 for any remaining platforms
> > >>> 6. package featureX as a plugin by organizing relevant bits in the
> > correct
> > >>> folder structure, and adding a plugin.xml
> > >>> 7. test each platform by installing with plugman
> > >>> 8. publish
> > >>>
> > >>
> > >> As a plugin developer, that is not my workflow.
> > >>
> > >> Typically for me its:
> > >>
> > >> Write a sample app/manual test for some new feature that isn't
> > implemented
> > >> yet.
> > >> Create a new plugin Foo for iOS & Android, and stub the
> implementation.
> > >> Implement feature A of plugin Foo for iOS, test, add it for Android,
> > test.
> > >> Implement feature B of plugin Foo for iOS, test, add it for Android,
> > test.
> > >> ...
> > >>
> > >> Usually the js implementation is shared, the auto tests are shared,
> and
> > the
> > >> sample test app is shared.
> > >>
> > >> Sure, I do platform specific stuff for testing and implementation,
> but I
> > >> certainly wouldn't say I do plugin development in platform isolation.
> > >>
> > >> Also, right now we do not have a "plugin create" command, and so
> leaving
> > >> the "packaging" step for last doesn't add affect total work.  But once
> > we
> > >> do have such a command, plugins could start packaged, and adding the
> > small
> > >> changes to plugin.xml as you need them is likely a good way to go.
> > >>
> > >> Finally, this workflow would get people out of the habit of making
> > changes
> > >> to the platform artifacts directly.  I'm not sure that can be entirely
> > >> avoided in all cases, but why shouldn't we work towards making that
> > easier?
> > >>
> > >>
> > >>> We seem to have this notion come up repeatedly that our users +
> plugin
> > >>> developers are working on multiple platforms at the same time, which
> I
> > >>> think is entirely false.
> > >>>
> > >>
> > >> Since we differ in opinion, how can we put this to the test?
> > >>
> > >> Also, we specifically make sure all our features address the needs of
> > those
> > >> doing single platform development, so in a world of 3.0+ cli, I really
> > >> don't see how we can not do the same to address the needs of those who
> > do
> > >> do multi-platform development, especially when we have a good proposal
> > of
> > >> how to do so and someone willing to do it.
> > >>
> > >>
> > >>> I also think we're trying to help the wrong people; If I am a
> > developer who
> > >>> is working on multiple platforms at once, and I have a bunch of
> devices
> > >>> attached, I probably also have the skills to set up my own grunt
> > continuous
> > >>> integration system. Setting up tooling for potential plugin
> developers
> > is
> > >>> the wrong approach, imho. We should actually just go and implement
> > some new
> > >>> plugin and evaluate the process instead of creating and imposing a
> > specific
> > >>> workflow.
> > >>>
> > >>
> > >> The first part of this argument has some merit, I agree.  We the
> > >> power-users have found ways to address our problems.  However, I think
> > that
> > >> with this change it means that even the end user can make changes to
> > plugin
> > >> folder as they find bugs/etc, and expect to see the change reflected
> > after
> > >> running prepare.  This is principle of least surprise, and just good
> > design.
> > >>
> > >> I also don't think we are imposing any specific workflow here, just
> > >> enabling a new one.  Personally I think that its quite surprising and
> > >> embarrassing that we haven't enabled this workflow since 3.0.
> > >>
> > >>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> @purplecabbage
> > >>> risingj.com
> > >>>
> > >>>
> > >>> On Thu, Sep 26, 2013 at 10:09 AM, Brian LeRoux <b...@brian.io> wrote:
> > >>>
> > >>>> I love the idea of a watch command.
> > >>>>
> > >>>>
> > >>>> On Thu, Sep 26, 2013 at 4:48 PM, Anis KADRI <an...@gmail.com>
> > >>> wrote:
> > >>>>
> > >>>>> Forgot about the existence of --link for a second. I think this is
> a
> > >>>>> good solution (not temporary). watch can be an enhancement to this
> > >>>>> solution. This might get people like Joe Bowser and other people
> who
> > >>>>> do native dev to give cordova-cli a try (only maybe though).
> > >>>>>
> > >>>>> On Thu, Sep 26, 2013 at 4:25 PM, Braden Shepherdson <
> > >>> braden@chromium.org
> > >>>>>
> > >>>>> wrote:
> > >>>>>> If the proposal above is temporary, what's permanent? cordova
> watch?
> > >>> I
> > >>>>> want
> > >>>>>> to make sure we're on the same page.
> > >>>>>>
> > >>>>>> Braden
> > >>>>>>
> > >>>>>>
> > >>>>>> On Thu, Sep 26, 2013 at 6:08 AM, Anis KADRI <anis.kadri@gmail.com
> >
> > >>>>> wrote:
> > >>>>>>
> > >>>>>>> No I didn't mean implement `plugman --watch`. I don't think
> plugman
> > >>>>>>> needs a `watch` command.
> > >>>>>>>
> > >>>>>>> I was indeed talking about `cordova watch` which should watch for
> > >>>>>>> changes in plugins/ (and maybe in merges/ and www/ as well) and
> > >>> update
> > >>>>>>> the platform projects (prepare?) on every change.  I am happy to
> > >>> know
> > >>>>>>> that it's on the wish list.
> > >>>>>>>
> > >>>>>>> As far as the original proposal, I believe it is a descent
> > temporary
> > >>>>>>> solution for plugin developers who want to use cordova-cli.
> > >>>>>>>
> > >>>>>>> On Wed, Sep 25, 2013 at 7:17 PM, Michal Mocny <
> mmocny@chromium.org
> > >
> > >>>>> wrote:
> > >>>>>>>> Braden, thats has been on the wish list (cordova watch), but I
> > >>>> suspect
> > >>>>>>> Anis
> > >>>>>>>> was suggesting something different with plugman --watch, to do
> > >>>>>>> specifically
> > >>>>>>>> with plugin development.  Am I right, Anis?  How does your idea
> > >>>>> compare
> > >>>>>>>> with using --link with cordova watch?  Would plugman --watch be
> > >>>> useful
> > >>>>>>> for
> > >>>>>>>> non cli projects?
> > >>>>>>>>
> > >>>>>>>> -Michal
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> On Wed, Sep 25, 2013 at 10:31 AM, Braden Shepherdson <
> > >>>>>>> braden@chromium.org>wrote:
> > >>>>>>>>
> > >>>>>>>>> We've had a vague feature planned for a while now to do a
> cordova
> > >>>>>>> watch. It
> > >>>>>>>>> would watch your plugins/, www/, and merges/* for any changes.
> If
> > >>>> any
> > >>>>>>>>> changes are detected, it would re-run cordova prepare, so that
> > >>> your
> > >>>>>>> native
> > >>>>>>>>> projects are always up-to-date.
> > >>>>>>>>>
> > >>>>>>>>> I'm open to checking (hashes?) which files have changed and
> which
> > >>>>> have
> > >>>>>>> not,
> > >>>>>>>>> but hashing them all is touching them all anyway, and it might
> be
> > >>>>> faster
> > >>>>>>>>> for small files to just copy them instead of checking first.
> > >>> We'll
> > >>>>> have
> > >>>>>>> to
> > >>>>>>>>> try it and see; for v1 I'm going with the simple option of
> > >>> copying
> > >>>>>>>>> everything.
> > >>>>>>>>>
> > >>>>>>>>> Braden
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> On Wed, Sep 25, 2013 at 9:44 AM, Michal Mocny <
> > >>> mmocny@chromium.org
> > >>>>>
> > >>>>>>> wrote:
> > >>>>>>>>>
> > >>>>>>>>>> The idea for plugin dev outside of plugins/ folder was to use
> > >>>>> "plugin
> > >>>>>>> add
> > >>>>>>>>>> --link".  Matter of fact, braden suggested that "plugin
> create"
> > >>>>> should
> > >>>>>>>>>> default to --link-ing to some external location so that you
> > >>> don't
> > >>>>> risk
> > >>>>>>>>>> deleting your only copy inside plugins/.  (I personally don't
> > >>>> think
> > >>>>>>>>> thats a
> > >>>>>>>>>> necessary concern, but I think its a conversation for later).
> > >>>>>>>>>>
> > >>>>>>>>>> I'm not even sure what a 'watch' would do, just uninstall &
> > >>>> install
> > >>>>>>> each
> > >>>>>>>>>> time the plugin changes?  I think that ends up being just
> > >>>> slightly
> > >>>>>>> worse
> > >>>>>>>>>> than the current proposal if you factor in that we already do
> > >>>>> support
> > >>>>>>>>>> --link (except without the above change its been useless).
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>> However, we may still want some form of 'watch' command for
> > >>> devs
> > >>>>> using
> > >>>>>>>>>> plugman directly.  I had assumed that those devs just edit in
> > >>>>> place,
> > >>>>>>>>> since
> > >>>>>>>>>> they don't use a prepare step anyway.
> > >>>>>>>>>>
> > >>>>>>>>>> -Michal
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>> On Wed, Sep 25, 2013 at 7:50 AM, Anis KADRI <
> > >>>> anis.kadri@gmail.com>
> > >>>>>>>>> wrote:
> > >>>>>>>>>>
> > >>>>>>>>>>> If we're talking about developing plugins inside the
> > >>>>>>>>>>> plugins/org.myplugin.id folder than I think it's a great
> > >>>>> workflow
> > >>>>>>> and
> > >>>>>>>>>>> I would just hide the cached version of plugin.xml inside
> > >>> that
> > >>>>>>>>>>> plugins/org.myplugin.id folder.
> > >>>>>>>>>>>
> > >>>>>>>>>>> However, if you're developing a plugin outside of a cordova
> > >>> CLI
> > >>>>>>>>>>> project, I think a `watch` (and add --watch) command is more
> > >>>>>>>>>>> appropriate. One of the reasons you would develop a plugin
> > >>>>> outside
> > >>>>>>> of
> > >>>>>>>>>>> a cordova CLI project is for easier version control (each
> > >>>> plugin
> > >>>>>>> would
> > >>>>>>>>>>> have its own repository). The other cool thing about `watch`
> > >>> is
> > >>>>> that
> > >>>>>>>>>>> it would copy the files that have actually changed and not
> > >>>>>>> everything
> > >>>>>>>>>>> (some plugins have a LOT of files [1]).
> > >>>>>>>>>>>
> > >>>>>>>>>>> [1] https://github.com/phonegap/phonegap-facebook-plugin
> > >>>>>>>>>>>
> > >>>>>>>>>>> On Wed, Sep 25, 2013 at 3:30 AM, James Jong <
> > >>>>> wjamesjong@gmail.com>
> > >>>>>>>>>> wrote:
> > >>>>>>>>>>>> +1 This is a cleaner workflow and should reduce some
> > >>>> confusion.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> -James Jong
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> On Sep 24, 2013, at 3:09 PM, Michal Mocny <
> > >>>> mmocny@chromium.org
> > >>>>>>
> > >>>>>>>>> wrote:
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>> Just to add, the reason for the "if" statement in step (2)
> > >>>> is
> > >>>>>>> that
> > >>>>>>>>>>>>> uninstall & reinstall take a lot longer than just moving a
> > >>>> few
> > >>>>>>>>> files,
> > >>>>>>>>>>> which
> > >>>>>>>>>>>>> is the 99.9% case for most end users who aren't making
> > >>>>>>> modifications
> > >>>>>>>>>> to
> > >>>>>>>>>>>>> plugins.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> This way, we only do the heavy lifting if your plugin
> > >>>>> structure
> > >>>>>>>>>> actually
> > >>>>>>>>>>>>> changed.  Doing it automatically means we no longer have
> > >>> to
> > >>>>>>> advise
> > >>>>>>>>>> users
> > >>>>>>>>>>>>> that making edits inside plugin/ folder is useless.  Now
> > >>> we
> > >>>>> just
> > >>>>>>>>>> advise
> > >>>>>>>>>>>>> them to run "prepare" after making changes to either www/
> > >>> or
> > >>>>>>>>> plugins/.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> This key insight was Braden's idea and I think its just an
> > >>>>>>> awesome
> > >>>>>>>>>>> change
> > >>>>>>>>>>>>> for workflow.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> -Michal
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> On Tue, Sep 24, 2013 at 2:58 PM, Braden Shepherdson <
> > >>>>>>>>>>> braden@chromium.org>wrote:
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>> 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
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>
> > >>>>>
> > >>>>
> > >>>
> >
>

Re: Updating plugin code on prepare

[Andrew Grieve <ag...@chromium.org>]

I think it'd be good to enumerate our options for workflow before we
decided on which to implement (or maybe choose multiple).

Tyler's idea about a sync command seems like it would be handy. Edit your
plugin files within platforms/, and then run `cordova plugin copychanges
org.my.plugin` to do a reverse copy of the source files back to the install
source location of the plugin. Big caveat though is that you run the risk
of prepare clobbering your changes. I think that's too killer a risk.

Another thought is that we could use symlinks when running prepare. Have
files within platforms/ symlink to files within plugins/, then symlink
again back to their original sources. Would this work with editors in
practice? I don't know, but worth exploring. Wikipedia says symlinks work
on NTFS as of Vista.

Braden / Michael - I think yours is a good idea as well. Although, I don't
think we should encourage people to edit files within plugins/. They should
edit their plugins from install point. We should record the install path,
and maybe have prepare have a prepare --update-local-plugins.

Any other ideas?



On Fri, Sep 27, 2013 at 3:13 PM, Michael Sierra <ms...@adobe.com> wrote:

> Can you please file JIRAs on doc problems like this?   Existing overview
> doc says you can use the CLI to bootstrap & hand off to an SDK & supporting
> platform command-line utilities.  I take your comment to mean doc should
> better stress that once you start working with platform tools downstream,
> you can't go back to the CLI. Correct?
>
> --Mike Sierra
>
>
> ________________________________________
> From: Tyler Wilson [twilson@pulse-robotics.com]
> Sent: Thursday, September 26, 2013 8:19 PM
> To: dev@cordova.apache.org
> Subject: Re: Updating plugin code on prepare
>
> Re: IDEs: if it is the case that the CLI should not be used along with an
> IDE, perhaps the documentation - including Getting Started Guides, etc. -
> ought to be much clearer about this. Perhaps a big warning that "Xcode
> project files are created by the CLI, but they should not be opened and
> used by Xcode. And you definitely should not edit code within the IDE".
>
> I just went to the main documentation site here -
> http://cordova.apache.org/docs/en/3.0.0/guide_overview_index.md.html#Overview- and it appears it only mentions the new CLI interface. No mention of the
> old bin/create method. Seems to me there may be communication problem here.
>
> Thanks,
> Tyler
>
> On Sep 26, 2013, at 6:11 PM, Anis KADRI <an...@gmail.com> wrote:
>
> > @purplecabbage: I have the same workflow but I think the proposed
> > solution is a step in the right direction. It would allow us to easily
> > develop platform plugins without having to delete project/create
> > project/install plugin/uninstall plugin constantly. The plugin would
> > be packaged (plugin.xml) from day 1 and one can only focus on
> > development.
> >
> > As far as IDEs, the answer is simple. You should not use IDEs and
> > cordova-cli at the same time. Until IDEs are aware of cordova-cli
> > there is no point in creating projects with cordova-cli because
> > everything gets blown on every build. I am not even sure we can make
> > Xcode aware of cordova-cli. We've already talked about this prior to
> > the 3.0 release and that is why we have the create scripts and plugman
> > approach. You should not be using cordova-cli either if you're doing
> > some custom native dev that can't be pluginized (changing the main
> > Activity.java or AppDelegate.m or whatever). If you're using
> > cordova-cli just to create a project and then open an IDE to develop,
> > you're probably doing it wrong. You should be creating a native
> > project and using plugman instead.
> >
> > On Thu, Sep 26, 2013 at 9:01 PM, Michal Mocny <mm...@chromium.org>
> wrote:
> >> On Thu, Sep 26, 2013 at 1:39 PM, Jesse <pu...@gmail.com> wrote:
> >>
> >>> What does a watch mean?
> >>> - if I reboot, is it still watched?
> >>>
> >>
> >> No, this would start a process that lives until you CTRL+C.  You could
> have
> >> it run it in the background, or set it to start of startup, but that
> would
> >> be using local system tools, not part of the command itself.
> >>
> >> Ideally, "watch" should run "prepare" whenever you would have wanted it
> to.
> >> Though obviously that cannot be perfect, it can be a useful tool when
> >> iterating.
> >>
> >>
> >>>
> >>> I think it would be best to consider separating development from
> packaging
> >>> in your use-case for workflow.
> >>> If I am going to develop featureX as a plugin I would :
> >>>
> >>> 1. create a project for a single cordova platform, and develop the
> feature
> >>> as a native piece, and a js piece.
> >>> 2. test thoroughly
> >>> 3. create a project for a second cordova platform, and develop the
> native
> >>> bit, preserving the js from 1
> >>> 4. test thoroughly
> >>> 5. repeat steps 3+4 for any remaining platforms
> >>> 6. package featureX as a plugin by organizing relevant bits in the
> correct
> >>> folder structure, and adding a plugin.xml
> >>> 7. test each platform by installing with plugman
> >>> 8. publish
> >>>
> >>
> >> As a plugin developer, that is not my workflow.
> >>
> >> Typically for me its:
> >>
> >> Write a sample app/manual test for some new feature that isn't
> implemented
> >> yet.
> >> Create a new plugin Foo for iOS & Android, and stub the implementation.
> >> Implement feature A of plugin Foo for iOS, test, add it for Android,
> test.
> >> Implement feature B of plugin Foo for iOS, test, add it for Android,
> test.
> >> ...
> >>
> >> Usually the js implementation is shared, the auto tests are shared, and
> the
> >> sample test app is shared.
> >>
> >> Sure, I do platform specific stuff for testing and implementation, but I
> >> certainly wouldn't say I do plugin development in platform isolation.
> >>
> >> Also, right now we do not have a "plugin create" command, and so leaving
> >> the "packaging" step for last doesn't add affect total work.  But once
> we
> >> do have such a command, plugins could start packaged, and adding the
> small
> >> changes to plugin.xml as you need them is likely a good way to go.
> >>
> >> Finally, this workflow would get people out of the habit of making
> changes
> >> to the platform artifacts directly.  I'm not sure that can be entirely
> >> avoided in all cases, but why shouldn't we work towards making that
> easier?
> >>
> >>
> >>> We seem to have this notion come up repeatedly that our users + plugin
> >>> developers are working on multiple platforms at the same time, which I
> >>> think is entirely false.
> >>>
> >>
> >> Since we differ in opinion, how can we put this to the test?
> >>
> >> Also, we specifically make sure all our features address the needs of
> those
> >> doing single platform development, so in a world of 3.0+ cli, I really
> >> don't see how we can not do the same to address the needs of those who
> do
> >> do multi-platform development, especially when we have a good proposal
> of
> >> how to do so and someone willing to do it.
> >>
> >>
> >>> I also think we're trying to help the wrong people; If I am a
> developer who
> >>> is working on multiple platforms at once, and I have a bunch of devices
> >>> attached, I probably also have the skills to set up my own grunt
> continuous
> >>> integration system. Setting up tooling for potential plugin developers
> is
> >>> the wrong approach, imho. We should actually just go and implement
> some new
> >>> plugin and evaluate the process instead of creating and imposing a
> specific
> >>> workflow.
> >>>
> >>
> >> The first part of this argument has some merit, I agree.  We the
> >> power-users have found ways to address our problems.  However, I think
> that
> >> with this change it means that even the end user can make changes to
> plugin
> >> folder as they find bugs/etc, and expect to see the change reflected
> after
> >> running prepare.  This is principle of least surprise, and just good
> design.
> >>
> >> I also don't think we are imposing any specific workflow here, just
> >> enabling a new one.  Personally I think that its quite surprising and
> >> embarrassing that we haven't enabled this workflow since 3.0.
> >>
> >>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> @purplecabbage
> >>> risingj.com
> >>>
> >>>
> >>> On Thu, Sep 26, 2013 at 10:09 AM, Brian LeRoux <b...@brian.io> wrote:
> >>>
> >>>> I love the idea of a watch command.
> >>>>
> >>>>
> >>>> On Thu, Sep 26, 2013 at 4:48 PM, Anis KADRI <an...@gmail.com>
> >>> wrote:
> >>>>
> >>>>> Forgot about the existence of --link for a second. I think this is a
> >>>>> good solution (not temporary). watch can be an enhancement to this
> >>>>> solution. This might get people like Joe Bowser and other people who
> >>>>> do native dev to give cordova-cli a try (only maybe though).
> >>>>>
> >>>>> On Thu, Sep 26, 2013 at 4:25 PM, Braden Shepherdson <
> >>> braden@chromium.org
> >>>>>
> >>>>> wrote:
> >>>>>> If the proposal above is temporary, what's permanent? cordova watch?
> >>> I
> >>>>> want
> >>>>>> to make sure we're on the same page.
> >>>>>>
> >>>>>> Braden
> >>>>>>
> >>>>>>
> >>>>>> On Thu, Sep 26, 2013 at 6:08 AM, Anis KADRI <an...@gmail.com>
> >>>>> wrote:
> >>>>>>
> >>>>>>> No I didn't mean implement `plugman --watch`. I don't think plugman
> >>>>>>> needs a `watch` command.
> >>>>>>>
> >>>>>>> I was indeed talking about `cordova watch` which should watch for
> >>>>>>> changes in plugins/ (and maybe in merges/ and www/ as well) and
> >>> update
> >>>>>>> the platform projects (prepare?) on every change.  I am happy to
> >>> know
> >>>>>>> that it's on the wish list.
> >>>>>>>
> >>>>>>> As far as the original proposal, I believe it is a descent
> temporary
> >>>>>>> solution for plugin developers who want to use cordova-cli.
> >>>>>>>
> >>>>>>> On Wed, Sep 25, 2013 at 7:17 PM, Michal Mocny <mmocny@chromium.org
> >
> >>>>> wrote:
> >>>>>>>> Braden, thats has been on the wish list (cordova watch), but I
> >>>> suspect
> >>>>>>> Anis
> >>>>>>>> was suggesting something different with plugman --watch, to do
> >>>>>>> specifically
> >>>>>>>> with plugin development.  Am I right, Anis?  How does your idea
> >>>>> compare
> >>>>>>>> with using --link with cordova watch?  Would plugman --watch be
> >>>> useful
> >>>>>>> for
> >>>>>>>> non cli projects?
> >>>>>>>>
> >>>>>>>> -Michal
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Wed, Sep 25, 2013 at 10:31 AM, Braden Shepherdson <
> >>>>>>> braden@chromium.org>wrote:
> >>>>>>>>
> >>>>>>>>> We've had a vague feature planned for a while now to do a cordova
> >>>>>>> watch. It
> >>>>>>>>> would watch your plugins/, www/, and merges/* for any changes. If
> >>>> any
> >>>>>>>>> changes are detected, it would re-run cordova prepare, so that
> >>> your
> >>>>>>> native
> >>>>>>>>> projects are always up-to-date.
> >>>>>>>>>
> >>>>>>>>> I'm open to checking (hashes?) which files have changed and which
> >>>>> have
> >>>>>>> not,
> >>>>>>>>> but hashing them all is touching them all anyway, and it might be
> >>>>> faster
> >>>>>>>>> for small files to just copy them instead of checking first.
> >>> We'll
> >>>>> have
> >>>>>>> to
> >>>>>>>>> try it and see; for v1 I'm going with the simple option of
> >>> copying
> >>>>>>>>> everything.
> >>>>>>>>>
> >>>>>>>>> Braden
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Wed, Sep 25, 2013 at 9:44 AM, Michal Mocny <
> >>> mmocny@chromium.org
> >>>>>
> >>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> The idea for plugin dev outside of plugins/ folder was to use
> >>>>> "plugin
> >>>>>>> add
> >>>>>>>>>> --link".  Matter of fact, braden suggested that "plugin create"
> >>>>> should
> >>>>>>>>>> default to --link-ing to some external location so that you
> >>> don't
> >>>>> risk
> >>>>>>>>>> deleting your only copy inside plugins/.  (I personally don't
> >>>> think
> >>>>>>>>> thats a
> >>>>>>>>>> necessary concern, but I think its a conversation for later).
> >>>>>>>>>>
> >>>>>>>>>> I'm not even sure what a 'watch' would do, just uninstall &
> >>>> install
> >>>>>>> each
> >>>>>>>>>> time the plugin changes?  I think that ends up being just
> >>>> slightly
> >>>>>>> worse
> >>>>>>>>>> than the current proposal if you factor in that we already do
> >>>>> support
> >>>>>>>>>> --link (except without the above change its been useless).
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> However, we may still want some form of 'watch' command for
> >>> devs
> >>>>> using
> >>>>>>>>>> plugman directly.  I had assumed that those devs just edit in
> >>>>> place,
> >>>>>>>>> since
> >>>>>>>>>> they don't use a prepare step anyway.
> >>>>>>>>>>
> >>>>>>>>>> -Michal
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On Wed, Sep 25, 2013 at 7:50 AM, Anis KADRI <
> >>>> anis.kadri@gmail.com>
> >>>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> If we're talking about developing plugins inside the
> >>>>>>>>>>> plugins/org.myplugin.id folder than I think it's a great
> >>>>> workflow
> >>>>>>> and
> >>>>>>>>>>> I would just hide the cached version of plugin.xml inside
> >>> that
> >>>>>>>>>>> plugins/org.myplugin.id folder.
> >>>>>>>>>>>
> >>>>>>>>>>> However, if you're developing a plugin outside of a cordova
> >>> CLI
> >>>>>>>>>>> project, I think a `watch` (and add --watch) command is more
> >>>>>>>>>>> appropriate. One of the reasons you would develop a plugin
> >>>>> outside
> >>>>>>> of
> >>>>>>>>>>> a cordova CLI project is for easier version control (each
> >>>> plugin
> >>>>>>> would
> >>>>>>>>>>> have its own repository). The other cool thing about `watch`
> >>> is
> >>>>> that
> >>>>>>>>>>> it would copy the files that have actually changed and not
> >>>>>>> everything
> >>>>>>>>>>> (some plugins have a LOT of files [1]).
> >>>>>>>>>>>
> >>>>>>>>>>> [1] https://github.com/phonegap/phonegap-facebook-plugin
> >>>>>>>>>>>
> >>>>>>>>>>> On Wed, Sep 25, 2013 at 3:30 AM, James Jong <
> >>>>> wjamesjong@gmail.com>
> >>>>>>>>>> wrote:
> >>>>>>>>>>>> +1 This is a cleaner workflow and should reduce some
> >>>> confusion.
> >>>>>>>>>>>>
> >>>>>>>>>>>> -James Jong
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Sep 24, 2013, at 3:09 PM, Michal Mocny <
> >>>> mmocny@chromium.org
> >>>>>>
> >>>>>>>>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> Just to add, the reason for the "if" statement in step (2)
> >>>> is
> >>>>>>> that
> >>>>>>>>>>>>> uninstall & reinstall take a lot longer than just moving a
> >>>> few
> >>>>>>>>> files,
> >>>>>>>>>>> which
> >>>>>>>>>>>>> is the 99.9% case for most end users who aren't making
> >>>>>>> modifications
> >>>>>>>>>> to
> >>>>>>>>>>>>> plugins.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> This way, we only do the heavy lifting if your plugin
> >>>>> structure
> >>>>>>>>>> actually
> >>>>>>>>>>>>> changed.  Doing it automatically means we no longer have
> >>> to
> >>>>>>> advise
> >>>>>>>>>> users
> >>>>>>>>>>>>> that making edits inside plugin/ folder is useless.  Now
> >>> we
> >>>>> just
> >>>>>>>>>> advise
> >>>>>>>>>>>>> them to run "prepare" after making changes to either www/
> >>> or
> >>>>>>>>> plugins/.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> This key insight was Braden's idea and I think its just an
> >>>>>>> awesome
> >>>>>>>>>>> change
> >>>>>>>>>>>>> for workflow.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> -Michal
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On Tue, Sep 24, 2013 at 2:58 PM, Braden Shepherdson <
> >>>>>>>>>>> braden@chromium.org>wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> 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
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>
> >>>>
> >>>
>

RE: Updating plugin code on prepare

[Michael Sierra <ms...@adobe.com>]

Can you please file JIRAs on doc problems like this?   Existing overview doc says you can use the CLI to bootstrap & hand off to an SDK & supporting platform command-line utilities.  I take your comment to mean doc should better stress that once you start working with platform tools downstream, you can't go back to the CLI. Correct?

--Mike Sierra


________________________________________
From: Tyler Wilson [twilson@pulse-robotics.com]
Sent: Thursday, September 26, 2013 8:19 PM
To: dev@cordova.apache.org
Subject: Re: Updating plugin code on prepare

Re: IDEs: if it is the case that the CLI should not be used along with an IDE, perhaps the documentation - including Getting Started Guides, etc. - ought to be much clearer about this. Perhaps a big warning that "Xcode project files are created by the CLI, but they should not be opened and used by Xcode. And you definitely should not edit code within the IDE".

I just went to the main documentation site here - http://cordova.apache.org/docs/en/3.0.0/guide_overview_index.md.html#Overview - and it appears it only mentions the new CLI interface. No mention of the old bin/create method. Seems to me there may be communication problem here.

Thanks,
Tyler

On Sep 26, 2013, at 6:11 PM, Anis KADRI <an...@gmail.com> wrote:

> @purplecabbage: I have the same workflow but I think the proposed
> solution is a step in the right direction. It would allow us to easily
> develop platform plugins without having to delete project/create
> project/install plugin/uninstall plugin constantly. The plugin would
> be packaged (plugin.xml) from day 1 and one can only focus on
> development.
>
> As far as IDEs, the answer is simple. You should not use IDEs and
> cordova-cli at the same time. Until IDEs are aware of cordova-cli
> there is no point in creating projects with cordova-cli because
> everything gets blown on every build. I am not even sure we can make
> Xcode aware of cordova-cli. We've already talked about this prior to
> the 3.0 release and that is why we have the create scripts and plugman
> approach. You should not be using cordova-cli either if you're doing
> some custom native dev that can't be pluginized (changing the main
> Activity.java or AppDelegate.m or whatever). If you're using
> cordova-cli just to create a project and then open an IDE to develop,
> you're probably doing it wrong. You should be creating a native
> project and using plugman instead.
>
> On Thu, Sep 26, 2013 at 9:01 PM, Michal Mocny <mm...@chromium.org> wrote:
>> On Thu, Sep 26, 2013 at 1:39 PM, Jesse <pu...@gmail.com> wrote:
>>
>>> What does a watch mean?
>>> - if I reboot, is it still watched?
>>>
>>
>> No, this would start a process that lives until you CTRL+C.  You could have
>> it run it in the background, or set it to start of startup, but that would
>> be using local system tools, not part of the command itself.
>>
>> Ideally, "watch" should run "prepare" whenever you would have wanted it to.
>> Though obviously that cannot be perfect, it can be a useful tool when
>> iterating.
>>
>>
>>>
>>> I think it would be best to consider separating development from packaging
>>> in your use-case for workflow.
>>> If I am going to develop featureX as a plugin I would :
>>>
>>> 1. create a project for a single cordova platform, and develop the feature
>>> as a native piece, and a js piece.
>>> 2. test thoroughly
>>> 3. create a project for a second cordova platform, and develop the native
>>> bit, preserving the js from 1
>>> 4. test thoroughly
>>> 5. repeat steps 3+4 for any remaining platforms
>>> 6. package featureX as a plugin by organizing relevant bits in the correct
>>> folder structure, and adding a plugin.xml
>>> 7. test each platform by installing with plugman
>>> 8. publish
>>>
>>
>> As a plugin developer, that is not my workflow.
>>
>> Typically for me its:
>>
>> Write a sample app/manual test for some new feature that isn't implemented
>> yet.
>> Create a new plugin Foo for iOS & Android, and stub the implementation.
>> Implement feature A of plugin Foo for iOS, test, add it for Android, test.
>> Implement feature B of plugin Foo for iOS, test, add it for Android, test.
>> ...
>>
>> Usually the js implementation is shared, the auto tests are shared, and the
>> sample test app is shared.
>>
>> Sure, I do platform specific stuff for testing and implementation, but I
>> certainly wouldn't say I do plugin development in platform isolation.
>>
>> Also, right now we do not have a "plugin create" command, and so leaving
>> the "packaging" step for last doesn't add affect total work.  But once we
>> do have such a command, plugins could start packaged, and adding the small
>> changes to plugin.xml as you need them is likely a good way to go.
>>
>> Finally, this workflow would get people out of the habit of making changes
>> to the platform artifacts directly.  I'm not sure that can be entirely
>> avoided in all cases, but why shouldn't we work towards making that easier?
>>
>>
>>> We seem to have this notion come up repeatedly that our users + plugin
>>> developers are working on multiple platforms at the same time, which I
>>> think is entirely false.
>>>
>>
>> Since we differ in opinion, how can we put this to the test?
>>
>> Also, we specifically make sure all our features address the needs of those
>> doing single platform development, so in a world of 3.0+ cli, I really
>> don't see how we can not do the same to address the needs of those who do
>> do multi-platform development, especially when we have a good proposal of
>> how to do so and someone willing to do it.
>>
>>
>>> I also think we're trying to help the wrong people; If I am a developer who
>>> is working on multiple platforms at once, and I have a bunch of devices
>>> attached, I probably also have the skills to set up my own grunt continuous
>>> integration system. Setting up tooling for potential plugin developers is
>>> the wrong approach, imho. We should actually just go and implement some new
>>> plugin and evaluate the process instead of creating and imposing a specific
>>> workflow.
>>>
>>
>> The first part of this argument has some merit, I agree.  We the
>> power-users have found ways to address our problems.  However, I think that
>> with this change it means that even the end user can make changes to plugin
>> folder as they find bugs/etc, and expect to see the change reflected after
>> running prepare.  This is principle of least surprise, and just good design.
>>
>> I also don't think we are imposing any specific workflow here, just
>> enabling a new one.  Personally I think that its quite surprising and
>> embarrassing that we haven't enabled this workflow since 3.0.
>>
>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> @purplecabbage
>>> risingj.com
>>>
>>>
>>> On Thu, Sep 26, 2013 at 10:09 AM, Brian LeRoux <b...@brian.io> wrote:
>>>
>>>> I love the idea of a watch command.
>>>>
>>>>
>>>> On Thu, Sep 26, 2013 at 4:48 PM, Anis KADRI <an...@gmail.com>
>>> wrote:
>>>>
>>>>> Forgot about the existence of --link for a second. I think this is a
>>>>> good solution (not temporary). watch can be an enhancement to this
>>>>> solution. This might get people like Joe Bowser and other people who
>>>>> do native dev to give cordova-cli a try (only maybe though).
>>>>>
>>>>> On Thu, Sep 26, 2013 at 4:25 PM, Braden Shepherdson <
>>> braden@chromium.org
>>>>>
>>>>> wrote:
>>>>>> If the proposal above is temporary, what's permanent? cordova watch?
>>> I
>>>>> want
>>>>>> to make sure we're on the same page.
>>>>>>
>>>>>> Braden
>>>>>>
>>>>>>
>>>>>> On Thu, Sep 26, 2013 at 6:08 AM, Anis KADRI <an...@gmail.com>
>>>>> wrote:
>>>>>>
>>>>>>> No I didn't mean implement `plugman --watch`. I don't think plugman
>>>>>>> needs a `watch` command.
>>>>>>>
>>>>>>> I was indeed talking about `cordova watch` which should watch for
>>>>>>> changes in plugins/ (and maybe in merges/ and www/ as well) and
>>> update
>>>>>>> the platform projects (prepare?) on every change.  I am happy to
>>> know
>>>>>>> that it's on the wish list.
>>>>>>>
>>>>>>> As far as the original proposal, I believe it is a descent temporary
>>>>>>> solution for plugin developers who want to use cordova-cli.
>>>>>>>
>>>>>>> On Wed, Sep 25, 2013 at 7:17 PM, Michal Mocny <mm...@chromium.org>
>>>>> wrote:
>>>>>>>> Braden, thats has been on the wish list (cordova watch), but I
>>>> suspect
>>>>>>> Anis
>>>>>>>> was suggesting something different with plugman --watch, to do
>>>>>>> specifically
>>>>>>>> with plugin development.  Am I right, Anis?  How does your idea
>>>>> compare
>>>>>>>> with using --link with cordova watch?  Would plugman --watch be
>>>> useful
>>>>>>> for
>>>>>>>> non cli projects?
>>>>>>>>
>>>>>>>> -Michal
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Sep 25, 2013 at 10:31 AM, Braden Shepherdson <
>>>>>>> braden@chromium.org>wrote:
>>>>>>>>
>>>>>>>>> We've had a vague feature planned for a while now to do a cordova
>>>>>>> watch. It
>>>>>>>>> would watch your plugins/, www/, and merges/* for any changes. If
>>>> any
>>>>>>>>> changes are detected, it would re-run cordova prepare, so that
>>> your
>>>>>>> native
>>>>>>>>> projects are always up-to-date.
>>>>>>>>>
>>>>>>>>> I'm open to checking (hashes?) which files have changed and which
>>>>> have
>>>>>>> not,
>>>>>>>>> but hashing them all is touching them all anyway, and it might be
>>>>> faster
>>>>>>>>> for small files to just copy them instead of checking first.
>>> We'll
>>>>> have
>>>>>>> to
>>>>>>>>> try it and see; for v1 I'm going with the simple option of
>>> copying
>>>>>>>>> everything.
>>>>>>>>>
>>>>>>>>> Braden
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wed, Sep 25, 2013 at 9:44 AM, Michal Mocny <
>>> mmocny@chromium.org
>>>>>
>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> The idea for plugin dev outside of plugins/ folder was to use
>>>>> "plugin
>>>>>>> add
>>>>>>>>>> --link".  Matter of fact, braden suggested that "plugin create"
>>>>> should
>>>>>>>>>> default to --link-ing to some external location so that you
>>> don't
>>>>> risk
>>>>>>>>>> deleting your only copy inside plugins/.  (I personally don't
>>>> think
>>>>>>>>> thats a
>>>>>>>>>> necessary concern, but I think its a conversation for later).
>>>>>>>>>>
>>>>>>>>>> I'm not even sure what a 'watch' would do, just uninstall &
>>>> install
>>>>>>> each
>>>>>>>>>> time the plugin changes?  I think that ends up being just
>>>> slightly
>>>>>>> worse
>>>>>>>>>> than the current proposal if you factor in that we already do
>>>>> support
>>>>>>>>>> --link (except without the above change its been useless).
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> However, we may still want some form of 'watch' command for
>>> devs
>>>>> using
>>>>>>>>>> plugman directly.  I had assumed that those devs just edit in
>>>>> place,
>>>>>>>>> since
>>>>>>>>>> they don't use a prepare step anyway.
>>>>>>>>>>
>>>>>>>>>> -Michal
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Wed, Sep 25, 2013 at 7:50 AM, Anis KADRI <
>>>> anis.kadri@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> If we're talking about developing plugins inside the
>>>>>>>>>>> plugins/org.myplugin.id folder than I think it's a great
>>>>> workflow
>>>>>>> and
>>>>>>>>>>> I would just hide the cached version of plugin.xml inside
>>> that
>>>>>>>>>>> plugins/org.myplugin.id folder.
>>>>>>>>>>>
>>>>>>>>>>> However, if you're developing a plugin outside of a cordova
>>> CLI
>>>>>>>>>>> project, I think a `watch` (and add --watch) command is more
>>>>>>>>>>> appropriate. One of the reasons you would develop a plugin
>>>>> outside
>>>>>>> of
>>>>>>>>>>> a cordova CLI project is for easier version control (each
>>>> plugin
>>>>>>> would
>>>>>>>>>>> have its own repository). The other cool thing about `watch`
>>> is
>>>>> that
>>>>>>>>>>> it would copy the files that have actually changed and not
>>>>>>> everything
>>>>>>>>>>> (some plugins have a LOT of files [1]).
>>>>>>>>>>>
>>>>>>>>>>> [1] https://github.com/phonegap/phonegap-facebook-plugin
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Sep 25, 2013 at 3:30 AM, James Jong <
>>>>> wjamesjong@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>>> +1 This is a cleaner workflow and should reduce some
>>>> confusion.
>>>>>>>>>>>>
>>>>>>>>>>>> -James Jong
>>>>>>>>>>>>
>>>>>>>>>>>> On Sep 24, 2013, at 3:09 PM, Michal Mocny <
>>>> mmocny@chromium.org
>>>>>>
>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Just to add, the reason for the "if" statement in step (2)
>>>> is
>>>>>>> that
>>>>>>>>>>>>> uninstall & reinstall take a lot longer than just moving a
>>>> few
>>>>>>>>> files,
>>>>>>>>>>> which
>>>>>>>>>>>>> is the 99.9% case for most end users who aren't making
>>>>>>> modifications
>>>>>>>>>> to
>>>>>>>>>>>>> plugins.
>>>>>>>>>>>>>
>>>>>>>>>>>>> This way, we only do the heavy lifting if your plugin
>>>>> structure
>>>>>>>>>> actually
>>>>>>>>>>>>> changed.  Doing it automatically means we no longer have
>>> to
>>>>>>> advise
>>>>>>>>>> users
>>>>>>>>>>>>> that making edits inside plugin/ folder is useless.  Now
>>> we
>>>>> just
>>>>>>>>>> advise
>>>>>>>>>>>>> them to run "prepare" after making changes to either www/
>>> or
>>>>>>>>> plugins/.
>>>>>>>>>>>>>
>>>>>>>>>>>>> This key insight was Braden's idea and I think its just an
>>>>>>> awesome
>>>>>>>>>>> change
>>>>>>>>>>>>> for workflow.
>>>>>>>>>>>>>
>>>>>>>>>>>>> -Michal
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Tue, Sep 24, 2013 at 2:58 PM, Braden Shepherdson <
>>>>>>>>>>> braden@chromium.org>wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>

Re: Updating plugin code on prepare

[Tyler Wilson <tw...@pulse-robotics.com>]

And one more data point I think worth mentioning: I just went to the main Cordova site, clicked the top Download button, it took me to the Download & Archive section, and I downloaded the source.zip. I opened it up and it is just a folder full of zip files, including the zips for each plugin.

Now I know how to create a project for each platform the old bin/create way, but then it is unclear how to use the plugins. I looked in the console plugin and the README.md file says to read the "Using Plugman to Manage Plugins" with a URL of "http://cordova.apache.org/docs/en/edge/guide_plugin_ref_plugman.md.html" which does not point to anything.

Perhaps a note in the download that people that want the non-CLI version should download the 2.9.0 version, which as I recall still contains the core plugins people might need/want.

Thanks,
Tyler


On Sep 26, 2013, at 8:19 PM, Tyler Wilson <tw...@pulse-robotics.com> wrote:

> Re: IDEs: if it is the case that the CLI should not be used along with an IDE, perhaps the documentation - including Getting Started Guides, etc. - ought to be much clearer about this. Perhaps a big warning that "Xcode project files are created by the CLI, but they should not be opened and used by Xcode. And you definitely should not edit code within the IDE".
> 
> I just went to the main documentation site here - http://cordova.apache.org/docs/en/3.0.0/guide_overview_index.md.html#Overview - and it appears it only mentions the new CLI interface. No mention of the old bin/create method. Seems to me there may be communication problem here.
> 
> Thanks,
> Tyler
> 
> On Sep 26, 2013, at 6:11 PM, Anis KADRI <an...@gmail.com> wrote:
> 
>> @purplecabbage: I have the same workflow but I think the proposed
>> solution is a step in the right direction. It would allow us to easily
>> develop platform plugins without having to delete project/create
>> project/install plugin/uninstall plugin constantly. The plugin would
>> be packaged (plugin.xml) from day 1 and one can only focus on
>> development.
>> 
>> As far as IDEs, the answer is simple. You should not use IDEs and
>> cordova-cli at the same time. Until IDEs are aware of cordova-cli
>> there is no point in creating projects with cordova-cli because
>> everything gets blown on every build. I am not even sure we can make
>> Xcode aware of cordova-cli. We've already talked about this prior to
>> the 3.0 release and that is why we have the create scripts and plugman
>> approach. You should not be using cordova-cli either if you're doing
>> some custom native dev that can't be pluginized (changing the main
>> Activity.java or AppDelegate.m or whatever). If you're using
>> cordova-cli just to create a project and then open an IDE to develop,
>> you're probably doing it wrong. You should be creating a native
>> project and using plugman instead.
>> 
>> On Thu, Sep 26, 2013 at 9:01 PM, Michal Mocny <mm...@chromium.org> wrote:
>>> On Thu, Sep 26, 2013 at 1:39 PM, Jesse <pu...@gmail.com> wrote:
>>> 
>>>> What does a watch mean?
>>>> - if I reboot, is it still watched?
>>>> 
>>> 
>>> No, this would start a process that lives until you CTRL+C.  You could have
>>> it run it in the background, or set it to start of startup, but that would
>>> be using local system tools, not part of the command itself.
>>> 
>>> Ideally, "watch" should run "prepare" whenever you would have wanted it to.
>>> Though obviously that cannot be perfect, it can be a useful tool when
>>> iterating.
>>> 
>>> 
>>>> 
>>>> I think it would be best to consider separating development from packaging
>>>> in your use-case for workflow.
>>>> If I am going to develop featureX as a plugin I would :
>>>> 
>>>> 1. create a project for a single cordova platform, and develop the feature
>>>> as a native piece, and a js piece.
>>>> 2. test thoroughly
>>>> 3. create a project for a second cordova platform, and develop the native
>>>> bit, preserving the js from 1
>>>> 4. test thoroughly
>>>> 5. repeat steps 3+4 for any remaining platforms
>>>> 6. package featureX as a plugin by organizing relevant bits in the correct
>>>> folder structure, and adding a plugin.xml
>>>> 7. test each platform by installing with plugman
>>>> 8. publish
>>>> 
>>> 
>>> As a plugin developer, that is not my workflow.
>>> 
>>> Typically for me its:
>>> 
>>> Write a sample app/manual test for some new feature that isn't implemented
>>> yet.
>>> Create a new plugin Foo for iOS & Android, and stub the implementation.
>>> Implement feature A of plugin Foo for iOS, test, add it for Android, test.
>>> Implement feature B of plugin Foo for iOS, test, add it for Android, test.
>>> ...
>>> 
>>> Usually the js implementation is shared, the auto tests are shared, and the
>>> sample test app is shared.
>>> 
>>> Sure, I do platform specific stuff for testing and implementation, but I
>>> certainly wouldn't say I do plugin development in platform isolation.
>>> 
>>> Also, right now we do not have a "plugin create" command, and so leaving
>>> the "packaging" step for last doesn't add affect total work.  But once we
>>> do have such a command, plugins could start packaged, and adding the small
>>> changes to plugin.xml as you need them is likely a good way to go.
>>> 
>>> Finally, this workflow would get people out of the habit of making changes
>>> to the platform artifacts directly.  I'm not sure that can be entirely
>>> avoided in all cases, but why shouldn't we work towards making that easier?
>>> 
>>> 
>>>> We seem to have this notion come up repeatedly that our users + plugin
>>>> developers are working on multiple platforms at the same time, which I
>>>> think is entirely false.
>>>> 
>>> 
>>> Since we differ in opinion, how can we put this to the test?
>>> 
>>> Also, we specifically make sure all our features address the needs of those
>>> doing single platform development, so in a world of 3.0+ cli, I really
>>> don't see how we can not do the same to address the needs of those who do
>>> do multi-platform development, especially when we have a good proposal of
>>> how to do so and someone willing to do it.
>>> 
>>> 
>>>> I also think we're trying to help the wrong people; If I am a developer who
>>>> is working on multiple platforms at once, and I have a bunch of devices
>>>> attached, I probably also have the skills to set up my own grunt continuous
>>>> integration system. Setting up tooling for potential plugin developers is
>>>> the wrong approach, imho. We should actually just go and implement some new
>>>> plugin and evaluate the process instead of creating and imposing a specific
>>>> workflow.
>>>> 
>>> 
>>> The first part of this argument has some merit, I agree.  We the
>>> power-users have found ways to address our problems.  However, I think that
>>> with this change it means that even the end user can make changes to plugin
>>> folder as they find bugs/etc, and expect to see the change reflected after
>>> running prepare.  This is principle of least surprise, and just good design.
>>> 
>>> I also don't think we are imposing any specific workflow here, just
>>> enabling a new one.  Personally I think that its quite surprising and
>>> embarrassing that we haven't enabled this workflow since 3.0.
>>> 
>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> @purplecabbage
>>>> risingj.com
>>>> 
>>>> 
>>>> On Thu, Sep 26, 2013 at 10:09 AM, Brian LeRoux <b...@brian.io> wrote:
>>>> 
>>>>> I love the idea of a watch command.
>>>>> 
>>>>> 
>>>>> On Thu, Sep 26, 2013 at 4:48 PM, Anis KADRI <an...@gmail.com>
>>>> wrote:
>>>>> 
>>>>>> Forgot about the existence of --link for a second. I think this is a
>>>>>> good solution (not temporary). watch can be an enhancement to this
>>>>>> solution. This might get people like Joe Bowser and other people who
>>>>>> do native dev to give cordova-cli a try (only maybe though).
>>>>>> 
>>>>>> On Thu, Sep 26, 2013 at 4:25 PM, Braden Shepherdson <
>>>> braden@chromium.org
>>>>>> 
>>>>>> wrote:
>>>>>>> If the proposal above is temporary, what's permanent? cordova watch?
>>>> I
>>>>>> want
>>>>>>> to make sure we're on the same page.
>>>>>>> 
>>>>>>> Braden
>>>>>>> 
>>>>>>> 
>>>>>>> On Thu, Sep 26, 2013 at 6:08 AM, Anis KADRI <an...@gmail.com>
>>>>>> wrote:
>>>>>>> 
>>>>>>>> No I didn't mean implement `plugman --watch`. I don't think plugman
>>>>>>>> needs a `watch` command.
>>>>>>>> 
>>>>>>>> I was indeed talking about `cordova watch` which should watch for
>>>>>>>> changes in plugins/ (and maybe in merges/ and www/ as well) and
>>>> update
>>>>>>>> the platform projects (prepare?) on every change.  I am happy to
>>>> know
>>>>>>>> that it's on the wish list.
>>>>>>>> 
>>>>>>>> As far as the original proposal, I believe it is a descent temporary
>>>>>>>> solution for plugin developers who want to use cordova-cli.
>>>>>>>> 
>>>>>>>> On Wed, Sep 25, 2013 at 7:17 PM, Michal Mocny <mm...@chromium.org>
>>>>>> wrote:
>>>>>>>>> Braden, thats has been on the wish list (cordova watch), but I
>>>>> suspect
>>>>>>>> Anis
>>>>>>>>> was suggesting something different with plugman --watch, to do
>>>>>>>> specifically
>>>>>>>>> with plugin development.  Am I right, Anis?  How does your idea
>>>>>> compare
>>>>>>>>> with using --link with cordova watch?  Would plugman --watch be
>>>>> useful
>>>>>>>> for
>>>>>>>>> non cli projects?
>>>>>>>>> 
>>>>>>>>> -Michal
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On Wed, Sep 25, 2013 at 10:31 AM, Braden Shepherdson <
>>>>>>>> braden@chromium.org>wrote:
>>>>>>>>> 
>>>>>>>>>> We've had a vague feature planned for a while now to do a cordova
>>>>>>>> watch. It
>>>>>>>>>> would watch your plugins/, www/, and merges/* for any changes. If
>>>>> any
>>>>>>>>>> changes are detected, it would re-run cordova prepare, so that
>>>> your
>>>>>>>> native
>>>>>>>>>> projects are always up-to-date.
>>>>>>>>>> 
>>>>>>>>>> I'm open to checking (hashes?) which files have changed and which
>>>>>> have
>>>>>>>> not,
>>>>>>>>>> but hashing them all is touching them all anyway, and it might be
>>>>>> faster
>>>>>>>>>> for small files to just copy them instead of checking first.
>>>> We'll
>>>>>> have
>>>>>>>> to
>>>>>>>>>> try it and see; for v1 I'm going with the simple option of
>>>> copying
>>>>>>>>>> everything.
>>>>>>>>>> 
>>>>>>>>>> Braden
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> On Wed, Sep 25, 2013 at 9:44 AM, Michal Mocny <
>>>> mmocny@chromium.org
>>>>>> 
>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>>> The idea for plugin dev outside of plugins/ folder was to use
>>>>>> "plugin
>>>>>>>> add
>>>>>>>>>>> --link".  Matter of fact, braden suggested that "plugin create"
>>>>>> should
>>>>>>>>>>> default to --link-ing to some external location so that you
>>>> don't
>>>>>> risk
>>>>>>>>>>> deleting your only copy inside plugins/.  (I personally don't
>>>>> think
>>>>>>>>>> thats a
>>>>>>>>>>> necessary concern, but I think its a conversation for later).
>>>>>>>>>>> 
>>>>>>>>>>> I'm not even sure what a 'watch' would do, just uninstall &
>>>>> install
>>>>>>>> each
>>>>>>>>>>> time the plugin changes?  I think that ends up being just
>>>>> slightly
>>>>>>>> worse
>>>>>>>>>>> than the current proposal if you factor in that we already do
>>>>>> support
>>>>>>>>>>> --link (except without the above change its been useless).
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> However, we may still want some form of 'watch' command for
>>>> devs
>>>>>> using
>>>>>>>>>>> plugman directly.  I had assumed that those devs just edit in
>>>>>> place,
>>>>>>>>>> since
>>>>>>>>>>> they don't use a prepare step anyway.
>>>>>>>>>>> 
>>>>>>>>>>> -Michal
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> On Wed, Sep 25, 2013 at 7:50 AM, Anis KADRI <
>>>>> anis.kadri@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>>> If we're talking about developing plugins inside the
>>>>>>>>>>>> plugins/org.myplugin.id folder than I think it's a great
>>>>>> workflow
>>>>>>>> and
>>>>>>>>>>>> I would just hide the cached version of plugin.xml inside
>>>> that
>>>>>>>>>>>> plugins/org.myplugin.id folder.
>>>>>>>>>>>> 
>>>>>>>>>>>> However, if you're developing a plugin outside of a cordova
>>>> CLI
>>>>>>>>>>>> project, I think a `watch` (and add --watch) command is more
>>>>>>>>>>>> appropriate. One of the reasons you would develop a plugin
>>>>>> outside
>>>>>>>> of
>>>>>>>>>>>> a cordova CLI project is for easier version control (each
>>>>> plugin
>>>>>>>> would
>>>>>>>>>>>> have its own repository). The other cool thing about `watch`
>>>> is
>>>>>> that
>>>>>>>>>>>> it would copy the files that have actually changed and not
>>>>>>>> everything
>>>>>>>>>>>> (some plugins have a LOT of files [1]).
>>>>>>>>>>>> 
>>>>>>>>>>>> [1] https://github.com/phonegap/phonegap-facebook-plugin
>>>>>>>>>>>> 
>>>>>>>>>>>> On Wed, Sep 25, 2013 at 3:30 AM, James Jong <
>>>>>> wjamesjong@gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>>> +1 This is a cleaner workflow and should reduce some
>>>>> confusion.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> -James Jong
>>>>>>>>>>>>> 
>>>>>>>>>>>>> On Sep 24, 2013, at 3:09 PM, Michal Mocny <
>>>>> mmocny@chromium.org
>>>>>>> 
>>>>>>>>>> wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Just to add, the reason for the "if" statement in step (2)
>>>>> is
>>>>>>>> that
>>>>>>>>>>>>>> uninstall & reinstall take a lot longer than just moving a
>>>>> few
>>>>>>>>>> files,
>>>>>>>>>>>> which
>>>>>>>>>>>>>> is the 99.9% case for most end users who aren't making
>>>>>>>> modifications
>>>>>>>>>>> to
>>>>>>>>>>>>>> plugins.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> This way, we only do the heavy lifting if your plugin
>>>>>> structure
>>>>>>>>>>> actually
>>>>>>>>>>>>>> changed.  Doing it automatically means we no longer have
>>>> to
>>>>>>>> advise
>>>>>>>>>>> users
>>>>>>>>>>>>>> that making edits inside plugin/ folder is useless.  Now
>>>> we
>>>>>> just
>>>>>>>>>>> advise
>>>>>>>>>>>>>> them to run "prepare" after making changes to either www/
>>>> or
>>>>>>>>>> plugins/.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> This key insight was Braden's idea and I think its just an
>>>>>>>> awesome
>>>>>>>>>>>> change
>>>>>>>>>>>>>> for workflow.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> -Michal
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On Tue, Sep 24, 2013 at 2:58 PM, Braden Shepherdson <
>>>>>>>>>>>> braden@chromium.org>wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
> 

Re: Updating plugin code on prepare

[Tyler Wilson <tw...@pulse-robotics.com>]

Re: IDEs: if it is the case that the CLI should not be used along with an IDE, perhaps the documentation - including Getting Started Guides, etc. - ought to be much clearer about this. Perhaps a big warning that "Xcode project files are created by the CLI, but they should not be opened and used by Xcode. And you definitely should not edit code within the IDE".

I just went to the main documentation site here - http://cordova.apache.org/docs/en/3.0.0/guide_overview_index.md.html#Overview - and it appears it only mentions the new CLI interface. No mention of the old bin/create method. Seems to me there may be communication problem here.

Thanks,
Tyler

On Sep 26, 2013, at 6:11 PM, Anis KADRI <an...@gmail.com> wrote:

> @purplecabbage: I have the same workflow but I think the proposed
> solution is a step in the right direction. It would allow us to easily
> develop platform plugins without having to delete project/create
> project/install plugin/uninstall plugin constantly. The plugin would
> be packaged (plugin.xml) from day 1 and one can only focus on
> development.
> 
> As far as IDEs, the answer is simple. You should not use IDEs and
> cordova-cli at the same time. Until IDEs are aware of cordova-cli
> there is no point in creating projects with cordova-cli because
> everything gets blown on every build. I am not even sure we can make
> Xcode aware of cordova-cli. We've already talked about this prior to
> the 3.0 release and that is why we have the create scripts and plugman
> approach. You should not be using cordova-cli either if you're doing
> some custom native dev that can't be pluginized (changing the main
> Activity.java or AppDelegate.m or whatever). If you're using
> cordova-cli just to create a project and then open an IDE to develop,
> you're probably doing it wrong. You should be creating a native
> project and using plugman instead.
> 
> On Thu, Sep 26, 2013 at 9:01 PM, Michal Mocny <mm...@chromium.org> wrote:
>> On Thu, Sep 26, 2013 at 1:39 PM, Jesse <pu...@gmail.com> wrote:
>> 
>>> What does a watch mean?
>>> - if I reboot, is it still watched?
>>> 
>> 
>> No, this would start a process that lives until you CTRL+C.  You could have
>> it run it in the background, or set it to start of startup, but that would
>> be using local system tools, not part of the command itself.
>> 
>> Ideally, "watch" should run "prepare" whenever you would have wanted it to.
>> Though obviously that cannot be perfect, it can be a useful tool when
>> iterating.
>> 
>> 
>>> 
>>> I think it would be best to consider separating development from packaging
>>> in your use-case for workflow.
>>> If I am going to develop featureX as a plugin I would :
>>> 
>>> 1. create a project for a single cordova platform, and develop the feature
>>> as a native piece, and a js piece.
>>> 2. test thoroughly
>>> 3. create a project for a second cordova platform, and develop the native
>>> bit, preserving the js from 1
>>> 4. test thoroughly
>>> 5. repeat steps 3+4 for any remaining platforms
>>> 6. package featureX as a plugin by organizing relevant bits in the correct
>>> folder structure, and adding a plugin.xml
>>> 7. test each platform by installing with plugman
>>> 8. publish
>>> 
>> 
>> As a plugin developer, that is not my workflow.
>> 
>> Typically for me its:
>> 
>> Write a sample app/manual test for some new feature that isn't implemented
>> yet.
>> Create a new plugin Foo for iOS & Android, and stub the implementation.
>> Implement feature A of plugin Foo for iOS, test, add it for Android, test.
>> Implement feature B of plugin Foo for iOS, test, add it for Android, test.
>> ...
>> 
>> Usually the js implementation is shared, the auto tests are shared, and the
>> sample test app is shared.
>> 
>> Sure, I do platform specific stuff for testing and implementation, but I
>> certainly wouldn't say I do plugin development in platform isolation.
>> 
>> Also, right now we do not have a "plugin create" command, and so leaving
>> the "packaging" step for last doesn't add affect total work.  But once we
>> do have such a command, plugins could start packaged, and adding the small
>> changes to plugin.xml as you need them is likely a good way to go.
>> 
>> Finally, this workflow would get people out of the habit of making changes
>> to the platform artifacts directly.  I'm not sure that can be entirely
>> avoided in all cases, but why shouldn't we work towards making that easier?
>> 
>> 
>>> We seem to have this notion come up repeatedly that our users + plugin
>>> developers are working on multiple platforms at the same time, which I
>>> think is entirely false.
>>> 
>> 
>> Since we differ in opinion, how can we put this to the test?
>> 
>> Also, we specifically make sure all our features address the needs of those
>> doing single platform development, so in a world of 3.0+ cli, I really
>> don't see how we can not do the same to address the needs of those who do
>> do multi-platform development, especially when we have a good proposal of
>> how to do so and someone willing to do it.
>> 
>> 
>>> I also think we're trying to help the wrong people; If I am a developer who
>>> is working on multiple platforms at once, and I have a bunch of devices
>>> attached, I probably also have the skills to set up my own grunt continuous
>>> integration system. Setting up tooling for potential plugin developers is
>>> the wrong approach, imho. We should actually just go and implement some new
>>> plugin and evaluate the process instead of creating and imposing a specific
>>> workflow.
>>> 
>> 
>> The first part of this argument has some merit, I agree.  We the
>> power-users have found ways to address our problems.  However, I think that
>> with this change it means that even the end user can make changes to plugin
>> folder as they find bugs/etc, and expect to see the change reflected after
>> running prepare.  This is principle of least surprise, and just good design.
>> 
>> I also don't think we are imposing any specific workflow here, just
>> enabling a new one.  Personally I think that its quite surprising and
>> embarrassing that we haven't enabled this workflow since 3.0.
>> 
>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> @purplecabbage
>>> risingj.com
>>> 
>>> 
>>> On Thu, Sep 26, 2013 at 10:09 AM, Brian LeRoux <b...@brian.io> wrote:
>>> 
>>>> I love the idea of a watch command.
>>>> 
>>>> 
>>>> On Thu, Sep 26, 2013 at 4:48 PM, Anis KADRI <an...@gmail.com>
>>> wrote:
>>>> 
>>>>> Forgot about the existence of --link for a second. I think this is a
>>>>> good solution (not temporary). watch can be an enhancement to this
>>>>> solution. This might get people like Joe Bowser and other people who
>>>>> do native dev to give cordova-cli a try (only maybe though).
>>>>> 
>>>>> On Thu, Sep 26, 2013 at 4:25 PM, Braden Shepherdson <
>>> braden@chromium.org
>>>>> 
>>>>> wrote:
>>>>>> If the proposal above is temporary, what's permanent? cordova watch?
>>> I
>>>>> want
>>>>>> to make sure we're on the same page.
>>>>>> 
>>>>>> Braden
>>>>>> 
>>>>>> 
>>>>>> On Thu, Sep 26, 2013 at 6:08 AM, Anis KADRI <an...@gmail.com>
>>>>> wrote:
>>>>>> 
>>>>>>> No I didn't mean implement `plugman --watch`. I don't think plugman
>>>>>>> needs a `watch` command.
>>>>>>> 
>>>>>>> I was indeed talking about `cordova watch` which should watch for
>>>>>>> changes in plugins/ (and maybe in merges/ and www/ as well) and
>>> update
>>>>>>> the platform projects (prepare?) on every change.  I am happy to
>>> know
>>>>>>> that it's on the wish list.
>>>>>>> 
>>>>>>> As far as the original proposal, I believe it is a descent temporary
>>>>>>> solution for plugin developers who want to use cordova-cli.
>>>>>>> 
>>>>>>> On Wed, Sep 25, 2013 at 7:17 PM, Michal Mocny <mm...@chromium.org>
>>>>> wrote:
>>>>>>>> Braden, thats has been on the wish list (cordova watch), but I
>>>> suspect
>>>>>>> Anis
>>>>>>>> was suggesting something different with plugman --watch, to do
>>>>>>> specifically
>>>>>>>> with plugin development.  Am I right, Anis?  How does your idea
>>>>> compare
>>>>>>>> with using --link with cordova watch?  Would plugman --watch be
>>>> useful
>>>>>>> for
>>>>>>>> non cli projects?
>>>>>>>> 
>>>>>>>> -Michal
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Wed, Sep 25, 2013 at 10:31 AM, Braden Shepherdson <
>>>>>>> braden@chromium.org>wrote:
>>>>>>>> 
>>>>>>>>> We've had a vague feature planned for a while now to do a cordova
>>>>>>> watch. It
>>>>>>>>> would watch your plugins/, www/, and merges/* for any changes. If
>>>> any
>>>>>>>>> changes are detected, it would re-run cordova prepare, so that
>>> your
>>>>>>> native
>>>>>>>>> projects are always up-to-date.
>>>>>>>>> 
>>>>>>>>> I'm open to checking (hashes?) which files have changed and which
>>>>> have
>>>>>>> not,
>>>>>>>>> but hashing them all is touching them all anyway, and it might be
>>>>> faster
>>>>>>>>> for small files to just copy them instead of checking first.
>>> We'll
>>>>> have
>>>>>>> to
>>>>>>>>> try it and see; for v1 I'm going with the simple option of
>>> copying
>>>>>>>>> everything.
>>>>>>>>> 
>>>>>>>>> Braden
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On Wed, Sep 25, 2013 at 9:44 AM, Michal Mocny <
>>> mmocny@chromium.org
>>>>> 
>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>>> The idea for plugin dev outside of plugins/ folder was to use
>>>>> "plugin
>>>>>>> add
>>>>>>>>>> --link".  Matter of fact, braden suggested that "plugin create"
>>>>> should
>>>>>>>>>> default to --link-ing to some external location so that you
>>> don't
>>>>> risk
>>>>>>>>>> deleting your only copy inside plugins/.  (I personally don't
>>>> think
>>>>>>>>> thats a
>>>>>>>>>> necessary concern, but I think its a conversation for later).
>>>>>>>>>> 
>>>>>>>>>> I'm not even sure what a 'watch' would do, just uninstall &
>>>> install
>>>>>>> each
>>>>>>>>>> time the plugin changes?  I think that ends up being just
>>>> slightly
>>>>>>> worse
>>>>>>>>>> than the current proposal if you factor in that we already do
>>>>> support
>>>>>>>>>> --link (except without the above change its been useless).
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> However, we may still want some form of 'watch' command for
>>> devs
>>>>> using
>>>>>>>>>> plugman directly.  I had assumed that those devs just edit in
>>>>> place,
>>>>>>>>> since
>>>>>>>>>> they don't use a prepare step anyway.
>>>>>>>>>> 
>>>>>>>>>> -Michal
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> On Wed, Sep 25, 2013 at 7:50 AM, Anis KADRI <
>>>> anis.kadri@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>>> If we're talking about developing plugins inside the
>>>>>>>>>>> plugins/org.myplugin.id folder than I think it's a great
>>>>> workflow
>>>>>>> and
>>>>>>>>>>> I would just hide the cached version of plugin.xml inside
>>> that
>>>>>>>>>>> plugins/org.myplugin.id folder.
>>>>>>>>>>> 
>>>>>>>>>>> However, if you're developing a plugin outside of a cordova
>>> CLI
>>>>>>>>>>> project, I think a `watch` (and add --watch) command is more
>>>>>>>>>>> appropriate. One of the reasons you would develop a plugin
>>>>> outside
>>>>>>> of
>>>>>>>>>>> a cordova CLI project is for easier version control (each
>>>> plugin
>>>>>>> would
>>>>>>>>>>> have its own repository). The other cool thing about `watch`
>>> is
>>>>> that
>>>>>>>>>>> it would copy the files that have actually changed and not
>>>>>>> everything
>>>>>>>>>>> (some plugins have a LOT of files [1]).
>>>>>>>>>>> 
>>>>>>>>>>> [1] https://github.com/phonegap/phonegap-facebook-plugin
>>>>>>>>>>> 
>>>>>>>>>>> On Wed, Sep 25, 2013 at 3:30 AM, James Jong <
>>>>> wjamesjong@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>>> +1 This is a cleaner workflow and should reduce some
>>>> confusion.
>>>>>>>>>>>> 
>>>>>>>>>>>> -James Jong
>>>>>>>>>>>> 
>>>>>>>>>>>> On Sep 24, 2013, at 3:09 PM, Michal Mocny <
>>>> mmocny@chromium.org
>>>>>> 
>>>>>>>>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>>> Just to add, the reason for the "if" statement in step (2)
>>>> is
>>>>>>> that
>>>>>>>>>>>>> uninstall & reinstall take a lot longer than just moving a
>>>> few
>>>>>>>>> files,
>>>>>>>>>>> which
>>>>>>>>>>>>> is the 99.9% case for most end users who aren't making
>>>>>>> modifications
>>>>>>>>>> to
>>>>>>>>>>>>> plugins.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> This way, we only do the heavy lifting if your plugin
>>>>> structure
>>>>>>>>>> actually
>>>>>>>>>>>>> changed.  Doing it automatically means we no longer have
>>> to
>>>>>>> advise
>>>>>>>>>> users
>>>>>>>>>>>>> that making edits inside plugin/ folder is useless.  Now
>>> we
>>>>> just
>>>>>>>>>> advise
>>>>>>>>>>>>> them to run "prepare" after making changes to either www/
>>> or
>>>>>>>>> plugins/.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> This key insight was Braden's idea and I think its just an
>>>>>>> awesome
>>>>>>>>>>> change
>>>>>>>>>>>>> for workflow.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> -Michal
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> On Tue, Sep 24, 2013 at 2:58 PM, Braden Shepherdson <
>>>>>>>>>>> braden@chromium.org>wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>> 
>>>>> 
>>>> 
>>> 

Re: Updating plugin code on prepare

[Brian LeRoux <b...@brian.io>]

I'd like to point out we're talking about the future and not the present
too. Yes, its a pain to dev a plugin without an IDE today. That isn't a
reason to sit on our hands. Iain has the right of it: our job is to
implement the future not lament the present.

The future is most certainly not waiting for Eclipse to load or Xcode to
beachball. Our dev community by and large uses lightweight text editors and
the command line. A simple watch command (or link function) would go a long
way to help that workflow AND it could be consumed by the IDEs too.



On Fri, Sep 27, 2013 at 4:31 AM, Ian Clelland <ic...@chromium.org>wrote:

> On Fri, Sep 27, 2013 at 12:11 AM, Anis KADRI <an...@gmail.com> wrote:
>
> > As far as IDEs, the answer is simple. You should not use IDEs and
> > cordova-cli at the same time. Until IDEs are aware of cordova-cli
> > there is no point in creating projects with cordova-cli because
> > everything gets blown on every build. I am not even sure we can make
> > Xcode aware of cordova-cli. We've already talked about this prior to
> > the 3.0 release and that is why we have the create scripts and plugman
> > approach. You should not be using cordova-cli either if you're doing
> > some custom native dev that can't be pluginized (changing the main
> > Activity.java or AppDelegate.m or whatever). If you're using
> > cordova-cli just to create a project and then open an IDE to develop,
> > you're probably doing it wrong. You should be creating a native
> > project and using plugman instead.
> >
> >
> Oh, man, I'm definitely doing it wrong :)
>
> I'm almost always using the CLI to create projects, and then opening the
> platform projects in Eclipse or XCode to run them. When I update code, I
> run prepare, and refresh in the IDE before running again. (In XCode, I
> generally don't even need to refresh; it just knows when the files have
> changed.)
>
> I don't mind using the IDE for debugging if (when) things don't work -- but
> I know that all of the assets are ephemeral, and that I need to make the
> *real* fixes outside of the platforms directory.
>
> I hope that eventually we can have 'cordova prepare' just be part of the
> build step in the IDEs, and let people just edit the master files in www/
> and build from there with the IDE, but I think we're a long way from there.
> Until then, the IDE is occasionally critical for debugging, even on a CLI
> project (wrong as it is ;) )
>
> Ian
>

Re: Updating plugin code on prepare

["Wargo, John" <jo...@sap.com>]

That's the way I do it too.  That shouldn't be problem unless you forget to go back and make Chang in the www folder.  

John M. Wargo

> On Sep 26, 2013, at 10:32 PM, "Ian Clelland" <ic...@chromium.org> wrote:
> 
>> On Fri, Sep 27, 2013 at 12:11 AM, Anis KADRI <an...@gmail.com> wrote:
>> 
>> As far as IDEs, the answer is simple. You should not use IDEs and
>> cordova-cli at the same time. Until IDEs are aware of cordova-cli
>> there is no point in creating projects with cordova-cli because
>> everything gets blown on every build. I am not even sure we can make
>> Xcode aware of cordova-cli. We've already talked about this prior to
>> the 3.0 release and that is why we have the create scripts and plugman
>> approach. You should not be using cordova-cli either if you're doing
>> some custom native dev that can't be pluginized (changing the main
>> Activity.java or AppDelegate.m or whatever). If you're using
>> cordova-cli just to create a project and then open an IDE to develop,
>> you're probably doing it wrong. You should be creating a native
>> project and using plugman instead.
> Oh, man, I'm definitely doing it wrong :)
> 
> I'm almost always using the CLI to create projects, and then opening the
> platform projects in Eclipse or XCode to run them. When I update code, I
> run prepare, and refresh in the IDE before running again. (In XCode, I
> generally don't even need to refresh; it just knows when the files have
> changed.)
> 
> I don't mind using the IDE for debugging if (when) things don't work -- but
> I know that all of the assets are ephemeral, and that I need to make the
> *real* fixes outside of the platforms directory.
> 
> I hope that eventually we can have 'cordova prepare' just be part of the
> build step in the IDEs, and let people just edit the master files in www/
> and build from there with the IDE, but I think we're a long way from there.
> Until then, the IDE is occasionally critical for debugging, even on a CLI
> project (wrong as it is ;) )
> 
> Ian

Re: Updating plugin code on prepare

[Ian Clelland <ic...@chromium.org>]

On Fri, Sep 27, 2013 at 12:11 AM, Anis KADRI <an...@gmail.com> wrote:

> As far as IDEs, the answer is simple. You should not use IDEs and
> cordova-cli at the same time. Until IDEs are aware of cordova-cli
> there is no point in creating projects with cordova-cli because
> everything gets blown on every build. I am not even sure we can make
> Xcode aware of cordova-cli. We've already talked about this prior to
> the 3.0 release and that is why we have the create scripts and plugman
> approach. You should not be using cordova-cli either if you're doing
> some custom native dev that can't be pluginized (changing the main
> Activity.java or AppDelegate.m or whatever). If you're using
> cordova-cli just to create a project and then open an IDE to develop,
> you're probably doing it wrong. You should be creating a native
> project and using plugman instead.
>
>
Oh, man, I'm definitely doing it wrong :)

I'm almost always using the CLI to create projects, and then opening the
platform projects in Eclipse or XCode to run them. When I update code, I
run prepare, and refresh in the IDE before running again. (In XCode, I
generally don't even need to refresh; it just knows when the files have
changed.)

I don't mind using the IDE for debugging if (when) things don't work -- but
I know that all of the assets are ephemeral, and that I need to make the
*real* fixes outside of the platforms directory.

I hope that eventually we can have 'cordova prepare' just be part of the
build step in the IDEs, and let people just edit the master files in www/
and build from there with the IDE, but I think we're a long way from there.
Until then, the IDE is occasionally critical for debugging, even on a CLI
project (wrong as it is ;) )

Ian

Re: Cordova non-CLI development (was: Re: Updating plugin code on prepare)

[Brian LeRoux <b...@brian.io>]

Plugman is intended to work directly on native projects (and Cordova CLI
should delegate all plugin related things to it). If this is not the case
you have found a bug!


On Tue, Oct 8, 2013 at 9:12 AM, Tyler Wilson <tw...@symbeeco.com> wrote:

> So, I was trying to use the Cordova CLI for a real project, using Xcode.
> As Anis says below, this should not be done. I tried to adjust things to
> make it more palatable, but having to go back to a console window to
> 'cordova prepare iOS' every time to copy the files and have it reset my
> project view got old real fast.
>
> So today I thought I would go back to the 'old' way of things - bin/create
> (--shared and --arc in my case). I cloned the latest Cordova iOS, cd to bin
> and do a create command of a test project. Load up the Xcode project file
> and runs fine. Now the issue: as Anis says below: "You should be creating a
> native project and using plugman instead". So I cd to my project and try to
> 'plugman install org.apache.cordova.console' so I can get my console.log
> working. Problem is that it appears to be designed for the new platform
> layout, and the bin/create script does not create it that way.
>
> So, what is the currently recommended method to add plugins to a
> bin/create-d native project? It would be great if it worked, but I have a
> bad feeling...
>
> Thank you,
> Tyler
>
> >>
> >>
> >> On Sep 26, 2013, at 6:11 PM, Anis KADRI <an...@gmail.com> wrote:
> >>
> >>> @purplecabbage: I have the same workflow but I think the proposed
> >>> solution is a step in the right direction. It would allow us to easily
> >>> develop platform plugins without having to delete project/create
> >>> project/install plugin/uninstall plugin constantly. The plugin would
> >>> be packaged (plugin.xml) from day 1 and one can only focus on
> >>> development.
> >>>
> >>> As far as IDEs, the answer is simple. You should not use IDEs and
> >>> cordova-cli at the same time. Until IDEs are aware of cordova-cli
> >>> there is no point in creating projects with cordova-cli because
> >>> everything gets blown on every build. I am not even sure we can make
> >>> Xcode aware of cordova-cli. We've already talked about this prior to
> >>> the 3.0 release and that is why we have the create scripts and plugman
> >>> approach. You should not be using cordova-cli either if you're doing
> >>> some custom native dev that can't be pluginized (changing the main
> >>> Activity.java or AppDelegate.m or whatever). If you're using
> >>> cordova-cli just to create a project and then open an IDE to develop,
> >>> you're probably doing it wrong. You should be creating a native
> >>> project and using plugman instead.
>
>

Re: Cordova non-CLI development (was: Re: Updating plugin code on prepare)

[Brian LeRoux <b...@brian.io>]

/me highfives


On Tue, Oct 8, 2013 at 9:20 AM, Tyler Wilson <tw...@symbeeco.com> wrote:

> Sorry, I sent too soon. I had not put the right params to the command. It
> appears to be working fine. Nothing to see here..
>
> - Tyler
>
> On Oct 8, 2013, at 12:12 PM, Tyler Wilson <tw...@pulse-robotics.com>
> wrote:
>
> > So, I was trying to use the Cordova CLI for a real project, using Xcode.
> As Anis says below, this should not be done. I tried to adjust things to
> make it more palatable, but having to go back to a console window to
> 'cordova prepare iOS' every time to copy the files and have it reset my
> project view got old real fast.
> >
> > So today I thought I would go back to the 'old' way of things -
> bin/create (--shared and --arc in my case). I cloned the latest Cordova
> iOS, cd to bin and do a create command of a test project. Load up the Xcode
> project file and runs fine. Now the issue: as Anis says below: "You should
> be creating a native project and using plugman instead". So I cd to my
> project and try to 'plugman install org.apache.cordova.console' so I can
> get my console.log working. Problem is that it appears to be designed for
> the new platform layout, and the bin/create script does not create it that
> way.
> >
> > So, what is the currently recommended method to add plugins to a
> bin/create-d native project? It would be great if it worked, but I have a
> bad feeling...
> >
> > Thank you,
> > Tyler
> >
> >>>
> >>>
> >>> On Sep 26, 2013, at 6:11 PM, Anis KADRI <an...@gmail.com> wrote:
> >>>
> >>>> @purplecabbage: I have the same workflow but I think the proposed
> >>>> solution is a step in the right direction. It would allow us to easily
> >>>> develop platform plugins without having to delete project/create
> >>>> project/install plugin/uninstall plugin constantly. The plugin would
> >>>> be packaged (plugin.xml) from day 1 and one can only focus on
> >>>> development.
> >>>>
> >>>> As far as IDEs, the answer is simple. You should not use IDEs and
> >>>> cordova-cli at the same time. Until IDEs are aware of cordova-cli
> >>>> there is no point in creating projects with cordova-cli because
> >>>> everything gets blown on every build. I am not even sure we can make
> >>>> Xcode aware of cordova-cli. We've already talked about this prior to
> >>>> the 3.0 release and that is why we have the create scripts and plugman
> >>>> approach. You should not be using cordova-cli either if you're doing
> >>>> some custom native dev that can't be pluginized (changing the main
> >>>> Activity.java or AppDelegate.m or whatever). If you're using
> >>>> cordova-cli just to create a project and then open an IDE to develop,
> >>>> you're probably doing it wrong. You should be creating a native
> >>>> project and using plugman instead.
> >
>
>

Re: Cordova non-CLI development (was: Re: Updating plugin code on prepare)

[Tyler Wilson <tw...@symbeeco.com>]

Sorry, I sent too soon. I had not put the right params to the command. It appears to be working fine. Nothing to see here..

- Tyler

On Oct 8, 2013, at 12:12 PM, Tyler Wilson <tw...@pulse-robotics.com> wrote:

> So, I was trying to use the Cordova CLI for a real project, using Xcode. As Anis says below, this should not be done. I tried to adjust things to make it more palatable, but having to go back to a console window to 'cordova prepare iOS' every time to copy the files and have it reset my project view got old real fast.
> 
> So today I thought I would go back to the 'old' way of things - bin/create (--shared and --arc in my case). I cloned the latest Cordova iOS, cd to bin and do a create command of a test project. Load up the Xcode project file and runs fine. Now the issue: as Anis says below: "You should be creating a native project and using plugman instead". So I cd to my project and try to 'plugman install org.apache.cordova.console' so I can get my console.log working. Problem is that it appears to be designed for the new platform layout, and the bin/create script does not create it that way.
> 
> So, what is the currently recommended method to add plugins to a bin/create-d native project? It would be great if it worked, but I have a bad feeling...
> 
> Thank you,
> Tyler
> 
>>> 
>>> 
>>> On Sep 26, 2013, at 6:11 PM, Anis KADRI <an...@gmail.com> wrote:
>>> 
>>>> @purplecabbage: I have the same workflow but I think the proposed
>>>> solution is a step in the right direction. It would allow us to easily
>>>> develop platform plugins without having to delete project/create
>>>> project/install plugin/uninstall plugin constantly. The plugin would
>>>> be packaged (plugin.xml) from day 1 and one can only focus on
>>>> development.
>>>> 
>>>> As far as IDEs, the answer is simple. You should not use IDEs and
>>>> cordova-cli at the same time. Until IDEs are aware of cordova-cli
>>>> there is no point in creating projects with cordova-cli because
>>>> everything gets blown on every build. I am not even sure we can make
>>>> Xcode aware of cordova-cli. We've already talked about this prior to
>>>> the 3.0 release and that is why we have the create scripts and plugman
>>>> approach. You should not be using cordova-cli either if you're doing
>>>> some custom native dev that can't be pluginized (changing the main
>>>> Activity.java or AppDelegate.m or whatever). If you're using
>>>> cordova-cli just to create a project and then open an IDE to develop,
>>>> you're probably doing it wrong. You should be creating a native
>>>> project and using plugman instead.
> 

Cordova non-CLI development (was: Re: Updating plugin code on prepare)

[Tyler Wilson <tw...@symbeeco.com>]

So, I was trying to use the Cordova CLI for a real project, using Xcode. As Anis says below, this should not be done. I tried to adjust things to make it more palatable, but having to go back to a console window to 'cordova prepare iOS' every time to copy the files and have it reset my project view got old real fast.

So today I thought I would go back to the 'old' way of things - bin/create (--shared and --arc in my case). I cloned the latest Cordova iOS, cd to bin and do a create command of a test project. Load up the Xcode project file and runs fine. Now the issue: as Anis says below: "You should be creating a native project and using plugman instead". So I cd to my project and try to 'plugman install org.apache.cordova.console' so I can get my console.log working. Problem is that it appears to be designed for the new platform layout, and the bin/create script does not create it that way.

So, what is the currently recommended method to add plugins to a bin/create-d native project? It would be great if it worked, but I have a bad feeling...

Thank you,
Tyler

>> 
>> 
>> On Sep 26, 2013, at 6:11 PM, Anis KADRI <an...@gmail.com> wrote:
>> 
>>> @purplecabbage: I have the same workflow but I think the proposed
>>> solution is a step in the right direction. It would allow us to easily
>>> develop platform plugins without having to delete project/create
>>> project/install plugin/uninstall plugin constantly. The plugin would
>>> be packaged (plugin.xml) from day 1 and one can only focus on
>>> development.
>>> 
>>> As far as IDEs, the answer is simple. You should not use IDEs and
>>> cordova-cli at the same time. Until IDEs are aware of cordova-cli
>>> there is no point in creating projects with cordova-cli because
>>> everything gets blown on every build. I am not even sure we can make
>>> Xcode aware of cordova-cli. We've already talked about this prior to
>>> the 3.0 release and that is why we have the create scripts and plugman
>>> approach. You should not be using cordova-cli either if you're doing
>>> some custom native dev that can't be pluginized (changing the main
>>> Activity.java or AppDelegate.m or whatever). If you're using
>>> cordova-cli just to create a project and then open an IDE to develop,
>>> you're probably doing it wrong. You should be creating a native
>>> project and using plugman instead.

Re: Updating plugin code on prepare

[Anis KADRI <an...@gmail.com>]

@purplecabbage: I have the same workflow but I think the proposed
solution is a step in the right direction. It would allow us to easily
develop platform plugins without having to delete project/create
project/install plugin/uninstall plugin constantly. The plugin would
be packaged (plugin.xml) from day 1 and one can only focus on
development.

As far as IDEs, the answer is simple. You should not use IDEs and
cordova-cli at the same time. Until IDEs are aware of cordova-cli
there is no point in creating projects with cordova-cli because
everything gets blown on every build. I am not even sure we can make
Xcode aware of cordova-cli. We've already talked about this prior to
the 3.0 release and that is why we have the create scripts and plugman
approach. You should not be using cordova-cli either if you're doing
some custom native dev that can't be pluginized (changing the main
Activity.java or AppDelegate.m or whatever). If you're using
cordova-cli just to create a project and then open an IDE to develop,
you're probably doing it wrong. You should be creating a native
project and using plugman instead.

On Thu, Sep 26, 2013 at 9:01 PM, Michal Mocny <mm...@chromium.org> wrote:
> On Thu, Sep 26, 2013 at 1:39 PM, Jesse <pu...@gmail.com> wrote:
>
>> What does a watch mean?
>> - if I reboot, is it still watched?
>>
>
> No, this would start a process that lives until you CTRL+C.  You could have
> it run it in the background, or set it to start of startup, but that would
> be using local system tools, not part of the command itself.
>
> Ideally, "watch" should run "prepare" whenever you would have wanted it to.
>  Though obviously that cannot be perfect, it can be a useful tool when
> iterating.
>
>
>>
>> I think it would be best to consider separating development from packaging
>> in your use-case for workflow.
>> If I am going to develop featureX as a plugin I would :
>>
>> 1. create a project for a single cordova platform, and develop the feature
>> as a native piece, and a js piece.
>> 2. test thoroughly
>> 3. create a project for a second cordova platform, and develop the native
>> bit, preserving the js from 1
>> 4. test thoroughly
>> 5. repeat steps 3+4 for any remaining platforms
>> 6. package featureX as a plugin by organizing relevant bits in the correct
>> folder structure, and adding a plugin.xml
>> 7. test each platform by installing with plugman
>> 8. publish
>>
>
> As a plugin developer, that is not my workflow.
>
> Typically for me its:
>
> Write a sample app/manual test for some new feature that isn't implemented
> yet.
> Create a new plugin Foo for iOS & Android, and stub the implementation.
> Implement feature A of plugin Foo for iOS, test, add it for Android, test.
> Implement feature B of plugin Foo for iOS, test, add it for Android, test.
> ...
>
> Usually the js implementation is shared, the auto tests are shared, and the
> sample test app is shared.
>
> Sure, I do platform specific stuff for testing and implementation, but I
> certainly wouldn't say I do plugin development in platform isolation.
>
> Also, right now we do not have a "plugin create" command, and so leaving
> the "packaging" step for last doesn't add affect total work.  But once we
> do have such a command, plugins could start packaged, and adding the small
> changes to plugin.xml as you need them is likely a good way to go.
>
> Finally, this workflow would get people out of the habit of making changes
> to the platform artifacts directly.  I'm not sure that can be entirely
> avoided in all cases, but why shouldn't we work towards making that easier?
>
>
>> We seem to have this notion come up repeatedly that our users + plugin
>> developers are working on multiple platforms at the same time, which I
>> think is entirely false.
>>
>
> Since we differ in opinion, how can we put this to the test?
>
> Also, we specifically make sure all our features address the needs of those
> doing single platform development, so in a world of 3.0+ cli, I really
> don't see how we can not do the same to address the needs of those who do
> do multi-platform development, especially when we have a good proposal of
> how to do so and someone willing to do it.
>
>
>> I also think we're trying to help the wrong people; If I am a developer who
>> is working on multiple platforms at once, and I have a bunch of devices
>> attached, I probably also have the skills to set up my own grunt continuous
>> integration system. Setting up tooling for potential plugin developers is
>> the wrong approach, imho. We should actually just go and implement some new
>> plugin and evaluate the process instead of creating and imposing a specific
>> workflow.
>>
>
> The first part of this argument has some merit, I agree.  We the
> power-users have found ways to address our problems.  However, I think that
> with this change it means that even the end user can make changes to plugin
> folder as they find bugs/etc, and expect to see the change reflected after
> running prepare.  This is principle of least surprise, and just good design.
>
> I also don't think we are imposing any specific workflow here, just
> enabling a new one.  Personally I think that its quite surprising and
> embarrassing that we haven't enabled this workflow since 3.0.
>
>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> @purplecabbage
>> risingj.com
>>
>>
>> On Thu, Sep 26, 2013 at 10:09 AM, Brian LeRoux <b...@brian.io> wrote:
>>
>> > I love the idea of a watch command.
>> >
>> >
>> > On Thu, Sep 26, 2013 at 4:48 PM, Anis KADRI <an...@gmail.com>
>> wrote:
>> >
>> > > Forgot about the existence of --link for a second. I think this is a
>> > > good solution (not temporary). watch can be an enhancement to this
>> > > solution. This might get people like Joe Bowser and other people who
>> > > do native dev to give cordova-cli a try (only maybe though).
>> > >
>> > > On Thu, Sep 26, 2013 at 4:25 PM, Braden Shepherdson <
>> braden@chromium.org
>> > >
>> > > wrote:
>> > > > If the proposal above is temporary, what's permanent? cordova watch?
>> I
>> > > want
>> > > > to make sure we're on the same page.
>> > > >
>> > > > Braden
>> > > >
>> > > >
>> > > > On Thu, Sep 26, 2013 at 6:08 AM, Anis KADRI <an...@gmail.com>
>> > > wrote:
>> > > >
>> > > >> No I didn't mean implement `plugman --watch`. I don't think plugman
>> > > >> needs a `watch` command.
>> > > >>
>> > > >> I was indeed talking about `cordova watch` which should watch for
>> > > >> changes in plugins/ (and maybe in merges/ and www/ as well) and
>> update
>> > > >> the platform projects (prepare?) on every change.  I am happy to
>> know
>> > > >> that it's on the wish list.
>> > > >>
>> > > >> As far as the original proposal, I believe it is a descent temporary
>> > > >> solution for plugin developers who want to use cordova-cli.
>> > > >>
>> > > >> On Wed, Sep 25, 2013 at 7:17 PM, Michal Mocny <mm...@chromium.org>
>> > > wrote:
>> > > >> > Braden, thats has been on the wish list (cordova watch), but I
>> > suspect
>> > > >> Anis
>> > > >> > was suggesting something different with plugman --watch, to do
>> > > >> specifically
>> > > >> > with plugin development.  Am I right, Anis?  How does your idea
>> > > compare
>> > > >> > with using --link with cordova watch?  Would plugman --watch be
>> > useful
>> > > >> for
>> > > >> > non cli projects?
>> > > >> >
>> > > >> > -Michal
>> > > >> >
>> > > >> >
>> > > >> > On Wed, Sep 25, 2013 at 10:31 AM, Braden Shepherdson <
>> > > >> braden@chromium.org>wrote:
>> > > >> >
>> > > >> >> We've had a vague feature planned for a while now to do a cordova
>> > > >> watch. It
>> > > >> >> would watch your plugins/, www/, and merges/* for any changes. If
>> > any
>> > > >> >> changes are detected, it would re-run cordova prepare, so that
>> your
>> > > >> native
>> > > >> >> projects are always up-to-date.
>> > > >> >>
>> > > >> >> I'm open to checking (hashes?) which files have changed and which
>> > > have
>> > > >> not,
>> > > >> >> but hashing them all is touching them all anyway, and it might be
>> > > faster
>> > > >> >> for small files to just copy them instead of checking first.
>> We'll
>> > > have
>> > > >> to
>> > > >> >> try it and see; for v1 I'm going with the simple option of
>> copying
>> > > >> >> everything.
>> > > >> >>
>> > > >> >> Braden
>> > > >> >>
>> > > >> >>
>> > > >> >> On Wed, Sep 25, 2013 at 9:44 AM, Michal Mocny <
>> mmocny@chromium.org
>> > >
>> > > >> wrote:
>> > > >> >>
>> > > >> >> > The idea for plugin dev outside of plugins/ folder was to use
>> > > "plugin
>> > > >> add
>> > > >> >> > --link".  Matter of fact, braden suggested that "plugin create"
>> > > should
>> > > >> >> > default to --link-ing to some external location so that you
>> don't
>> > > risk
>> > > >> >> > deleting your only copy inside plugins/.  (I personally don't
>> > think
>> > > >> >> thats a
>> > > >> >> > necessary concern, but I think its a conversation for later).
>> > > >> >> >
>> > > >> >> > I'm not even sure what a 'watch' would do, just uninstall &
>> > install
>> > > >> each
>> > > >> >> > time the plugin changes?  I think that ends up being just
>> > slightly
>> > > >> worse
>> > > >> >> > than the current proposal if you factor in that we already do
>> > > support
>> > > >> >> > --link (except without the above change its been useless).
>> > > >> >> >
>> > > >> >> >
>> > > >> >> > However, we may still want some form of 'watch' command for
>> devs
>> > > using
>> > > >> >> > plugman directly.  I had assumed that those devs just edit in
>> > > place,
>> > > >> >> since
>> > > >> >> > they don't use a prepare step anyway.
>> > > >> >> >
>> > > >> >> > -Michal
>> > > >> >> >
>> > > >> >> >
>> > > >> >> >
>> > > >> >> > On Wed, Sep 25, 2013 at 7:50 AM, Anis KADRI <
>> > anis.kadri@gmail.com>
>> > > >> >> wrote:
>> > > >> >> >
>> > > >> >> > > If we're talking about developing plugins inside the
>> > > >> >> > > plugins/org.myplugin.id folder than I think it's a great
>> > > workflow
>> > > >> and
>> > > >> >> > > I would just hide the cached version of plugin.xml inside
>> that
>> > > >> >> > > plugins/org.myplugin.id folder.
>> > > >> >> > >
>> > > >> >> > > However, if you're developing a plugin outside of a cordova
>> CLI
>> > > >> >> > > project, I think a `watch` (and add --watch) command is more
>> > > >> >> > > appropriate. One of the reasons you would develop a plugin
>> > > outside
>> > > >> of
>> > > >> >> > > a cordova CLI project is for easier version control (each
>> > plugin
>> > > >> would
>> > > >> >> > > have its own repository). The other cool thing about `watch`
>> is
>> > > that
>> > > >> >> > > it would copy the files that have actually changed and not
>> > > >> everything
>> > > >> >> > > (some plugins have a LOT of files [1]).
>> > > >> >> > >
>> > > >> >> > > [1] https://github.com/phonegap/phonegap-facebook-plugin
>> > > >> >> > >
>> > > >> >> > > On Wed, Sep 25, 2013 at 3:30 AM, James Jong <
>> > > wjamesjong@gmail.com>
>> > > >> >> > wrote:
>> > > >> >> > > > +1 This is a cleaner workflow and should reduce some
>> > confusion.
>> > > >> >> > > >
>> > > >> >> > > > -James Jong
>> > > >> >> > > >
>> > > >> >> > > > On Sep 24, 2013, at 3:09 PM, Michal Mocny <
>> > mmocny@chromium.org
>> > > >
>> > > >> >> wrote:
>> > > >> >> > > >
>> > > >> >> > > >> Just to add, the reason for the "if" statement in step (2)
>> > is
>> > > >> that
>> > > >> >> > > >> uninstall & reinstall take a lot longer than just moving a
>> > few
>> > > >> >> files,
>> > > >> >> > > which
>> > > >> >> > > >> is the 99.9% case for most end users who aren't making
>> > > >> modifications
>> > > >> >> > to
>> > > >> >> > > >> plugins.
>> > > >> >> > > >>
>> > > >> >> > > >> This way, we only do the heavy lifting if your plugin
>> > > structure
>> > > >> >> > actually
>> > > >> >> > > >> changed.  Doing it automatically means we no longer have
>> to
>> > > >> advise
>> > > >> >> > users
>> > > >> >> > > >> that making edits inside plugin/ folder is useless.  Now
>> we
>> > > just
>> > > >> >> > advise
>> > > >> >> > > >> them to run "prepare" after making changes to either www/
>> or
>> > > >> >> plugins/.
>> > > >> >> > > >>
>> > > >> >> > > >> This key insight was Braden's idea and I think its just an
>> > > >> awesome
>> > > >> >> > > change
>> > > >> >> > > >> for workflow.
>> > > >> >> > > >>
>> > > >> >> > > >> -Michal
>> > > >> >> > > >>
>> > > >> >> > > >>
>> > > >> >> > > >> On Tue, Sep 24, 2013 at 2:58 PM, Braden Shepherdson <
>> > > >> >> > > braden@chromium.org>wrote:
>> > > >> >> > > >>
>> > > >> >> > > >>> 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
>> > > >> >> > > >>>
>> > > >> >> > > >
>> > > >> >> > >
>> > > >> >> >
>> > > >> >>
>> > > >>
>> > >
>> >
>>

Re: Updating plugin code on prepare

[Michal Mocny <mm...@chromium.org>]

On Thu, Sep 26, 2013 at 1:39 PM, Jesse <pu...@gmail.com> wrote:

> What does a watch mean?
> - if I reboot, is it still watched?
>

No, this would start a process that lives until you CTRL+C.  You could have
it run it in the background, or set it to start of startup, but that would
be using local system tools, not part of the command itself.

Ideally, "watch" should run "prepare" whenever you would have wanted it to.
 Though obviously that cannot be perfect, it can be a useful tool when
iterating.


>
> I think it would be best to consider separating development from packaging
> in your use-case for workflow.
> If I am going to develop featureX as a plugin I would :
>
> 1. create a project for a single cordova platform, and develop the feature
> as a native piece, and a js piece.
> 2. test thoroughly
> 3. create a project for a second cordova platform, and develop the native
> bit, preserving the js from 1
> 4. test thoroughly
> 5. repeat steps 3+4 for any remaining platforms
> 6. package featureX as a plugin by organizing relevant bits in the correct
> folder structure, and adding a plugin.xml
> 7. test each platform by installing with plugman
> 8. publish
>

As a plugin developer, that is not my workflow.

Typically for me its:

Write a sample app/manual test for some new feature that isn't implemented
yet.
Create a new plugin Foo for iOS & Android, and stub the implementation.
Implement feature A of plugin Foo for iOS, test, add it for Android, test.
Implement feature B of plugin Foo for iOS, test, add it for Android, test.
...

Usually the js implementation is shared, the auto tests are shared, and the
sample test app is shared.

Sure, I do platform specific stuff for testing and implementation, but I
certainly wouldn't say I do plugin development in platform isolation.

Also, right now we do not have a "plugin create" command, and so leaving
the "packaging" step for last doesn't add affect total work.  But once we
do have such a command, plugins could start packaged, and adding the small
changes to plugin.xml as you need them is likely a good way to go.

Finally, this workflow would get people out of the habit of making changes
to the platform artifacts directly.  I'm not sure that can be entirely
avoided in all cases, but why shouldn't we work towards making that easier?


> We seem to have this notion come up repeatedly that our users + plugin
> developers are working on multiple platforms at the same time, which I
> think is entirely false.
>

Since we differ in opinion, how can we put this to the test?

Also, we specifically make sure all our features address the needs of those
doing single platform development, so in a world of 3.0+ cli, I really
don't see how we can not do the same to address the needs of those who do
do multi-platform development, especially when we have a good proposal of
how to do so and someone willing to do it.


> I also think we're trying to help the wrong people; If I am a developer who
> is working on multiple platforms at once, and I have a bunch of devices
> attached, I probably also have the skills to set up my own grunt continuous
> integration system. Setting up tooling for potential plugin developers is
> the wrong approach, imho. We should actually just go and implement some new
> plugin and evaluate the process instead of creating and imposing a specific
> workflow.
>

The first part of this argument has some merit, I agree.  We the
power-users have found ways to address our problems.  However, I think that
with this change it means that even the end user can make changes to plugin
folder as they find bugs/etc, and expect to see the change reflected after
running prepare.  This is principle of least surprise, and just good design.

I also don't think we are imposing any specific workflow here, just
enabling a new one.  Personally I think that its quite surprising and
embarrassing that we haven't enabled this workflow since 3.0.


>
>
>
>
>
>
>
>
>
> @purplecabbage
> risingj.com
>
>
> On Thu, Sep 26, 2013 at 10:09 AM, Brian LeRoux <b...@brian.io> wrote:
>
> > I love the idea of a watch command.
> >
> >
> > On Thu, Sep 26, 2013 at 4:48 PM, Anis KADRI <an...@gmail.com>
> wrote:
> >
> > > Forgot about the existence of --link for a second. I think this is a
> > > good solution (not temporary). watch can be an enhancement to this
> > > solution. This might get people like Joe Bowser and other people who
> > > do native dev to give cordova-cli a try (only maybe though).
> > >
> > > On Thu, Sep 26, 2013 at 4:25 PM, Braden Shepherdson <
> braden@chromium.org
> > >
> > > wrote:
> > > > If the proposal above is temporary, what's permanent? cordova watch?
> I
> > > want
> > > > to make sure we're on the same page.
> > > >
> > > > Braden
> > > >
> > > >
> > > > On Thu, Sep 26, 2013 at 6:08 AM, Anis KADRI <an...@gmail.com>
> > > wrote:
> > > >
> > > >> No I didn't mean implement `plugman --watch`. I don't think plugman
> > > >> needs a `watch` command.
> > > >>
> > > >> I was indeed talking about `cordova watch` which should watch for
> > > >> changes in plugins/ (and maybe in merges/ and www/ as well) and
> update
> > > >> the platform projects (prepare?) on every change.  I am happy to
> know
> > > >> that it's on the wish list.
> > > >>
> > > >> As far as the original proposal, I believe it is a descent temporary
> > > >> solution for plugin developers who want to use cordova-cli.
> > > >>
> > > >> On Wed, Sep 25, 2013 at 7:17 PM, Michal Mocny <mm...@chromium.org>
> > > wrote:
> > > >> > Braden, thats has been on the wish list (cordova watch), but I
> > suspect
> > > >> Anis
> > > >> > was suggesting something different with plugman --watch, to do
> > > >> specifically
> > > >> > with plugin development.  Am I right, Anis?  How does your idea
> > > compare
> > > >> > with using --link with cordova watch?  Would plugman --watch be
> > useful
> > > >> for
> > > >> > non cli projects?
> > > >> >
> > > >> > -Michal
> > > >> >
> > > >> >
> > > >> > On Wed, Sep 25, 2013 at 10:31 AM, Braden Shepherdson <
> > > >> braden@chromium.org>wrote:
> > > >> >
> > > >> >> We've had a vague feature planned for a while now to do a cordova
> > > >> watch. It
> > > >> >> would watch your plugins/, www/, and merges/* for any changes. If
> > any
> > > >> >> changes are detected, it would re-run cordova prepare, so that
> your
> > > >> native
> > > >> >> projects are always up-to-date.
> > > >> >>
> > > >> >> I'm open to checking (hashes?) which files have changed and which
> > > have
> > > >> not,
> > > >> >> but hashing them all is touching them all anyway, and it might be
> > > faster
> > > >> >> for small files to just copy them instead of checking first.
> We'll
> > > have
> > > >> to
> > > >> >> try it and see; for v1 I'm going with the simple option of
> copying
> > > >> >> everything.
> > > >> >>
> > > >> >> Braden
> > > >> >>
> > > >> >>
> > > >> >> On Wed, Sep 25, 2013 at 9:44 AM, Michal Mocny <
> mmocny@chromium.org
> > >
> > > >> wrote:
> > > >> >>
> > > >> >> > The idea for plugin dev outside of plugins/ folder was to use
> > > "plugin
> > > >> add
> > > >> >> > --link".  Matter of fact, braden suggested that "plugin create"
> > > should
> > > >> >> > default to --link-ing to some external location so that you
> don't
> > > risk
> > > >> >> > deleting your only copy inside plugins/.  (I personally don't
> > think
> > > >> >> thats a
> > > >> >> > necessary concern, but I think its a conversation for later).
> > > >> >> >
> > > >> >> > I'm not even sure what a 'watch' would do, just uninstall &
> > install
> > > >> each
> > > >> >> > time the plugin changes?  I think that ends up being just
> > slightly
> > > >> worse
> > > >> >> > than the current proposal if you factor in that we already do
> > > support
> > > >> >> > --link (except without the above change its been useless).
> > > >> >> >
> > > >> >> >
> > > >> >> > However, we may still want some form of 'watch' command for
> devs
> > > using
> > > >> >> > plugman directly.  I had assumed that those devs just edit in
> > > place,
> > > >> >> since
> > > >> >> > they don't use a prepare step anyway.
> > > >> >> >
> > > >> >> > -Michal
> > > >> >> >
> > > >> >> >
> > > >> >> >
> > > >> >> > On Wed, Sep 25, 2013 at 7:50 AM, Anis KADRI <
> > anis.kadri@gmail.com>
> > > >> >> wrote:
> > > >> >> >
> > > >> >> > > If we're talking about developing plugins inside the
> > > >> >> > > plugins/org.myplugin.id folder than I think it's a great
> > > workflow
> > > >> and
> > > >> >> > > I would just hide the cached version of plugin.xml inside
> that
> > > >> >> > > plugins/org.myplugin.id folder.
> > > >> >> > >
> > > >> >> > > However, if you're developing a plugin outside of a cordova
> CLI
> > > >> >> > > project, I think a `watch` (and add --watch) command is more
> > > >> >> > > appropriate. One of the reasons you would develop a plugin
> > > outside
> > > >> of
> > > >> >> > > a cordova CLI project is for easier version control (each
> > plugin
> > > >> would
> > > >> >> > > have its own repository). The other cool thing about `watch`
> is
> > > that
> > > >> >> > > it would copy the files that have actually changed and not
> > > >> everything
> > > >> >> > > (some plugins have a LOT of files [1]).
> > > >> >> > >
> > > >> >> > > [1] https://github.com/phonegap/phonegap-facebook-plugin
> > > >> >> > >
> > > >> >> > > On Wed, Sep 25, 2013 at 3:30 AM, James Jong <
> > > wjamesjong@gmail.com>
> > > >> >> > wrote:
> > > >> >> > > > +1 This is a cleaner workflow and should reduce some
> > confusion.
> > > >> >> > > >
> > > >> >> > > > -James Jong
> > > >> >> > > >
> > > >> >> > > > On Sep 24, 2013, at 3:09 PM, Michal Mocny <
> > mmocny@chromium.org
> > > >
> > > >> >> wrote:
> > > >> >> > > >
> > > >> >> > > >> Just to add, the reason for the "if" statement in step (2)
> > is
> > > >> that
> > > >> >> > > >> uninstall & reinstall take a lot longer than just moving a
> > few
> > > >> >> files,
> > > >> >> > > which
> > > >> >> > > >> is the 99.9% case for most end users who aren't making
> > > >> modifications
> > > >> >> > to
> > > >> >> > > >> plugins.
> > > >> >> > > >>
> > > >> >> > > >> This way, we only do the heavy lifting if your plugin
> > > structure
> > > >> >> > actually
> > > >> >> > > >> changed.  Doing it automatically means we no longer have
> to
> > > >> advise
> > > >> >> > users
> > > >> >> > > >> that making edits inside plugin/ folder is useless.  Now
> we
> > > just
> > > >> >> > advise
> > > >> >> > > >> them to run "prepare" after making changes to either www/
> or
> > > >> >> plugins/.
> > > >> >> > > >>
> > > >> >> > > >> This key insight was Braden's idea and I think its just an
> > > >> awesome
> > > >> >> > > change
> > > >> >> > > >> for workflow.
> > > >> >> > > >>
> > > >> >> > > >> -Michal
> > > >> >> > > >>
> > > >> >> > > >>
> > > >> >> > > >> On Tue, Sep 24, 2013 at 2:58 PM, Braden Shepherdson <
> > > >> >> > > braden@chromium.org>wrote:
> > > >> >> > > >>
> > > >> >> > > >>> 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
> > > >> >> > > >>>
> > > >> >> > > >
> > > >> >> > >
> > > >> >> >
> > > >> >>
> > > >>
> > >
> >
>

Re: Updating plugin code on prepare

[Jesse <pu...@gmail.com>]

What does a watch mean?
- if I reboot, is it still watched?

I think it would be best to consider separating development from packaging
in your use-case for workflow.
If I am going to develop featureX as a plugin I would :

1. create a project for a single cordova platform, and develop the feature
as a native piece, and a js piece.
2. test thoroughly
3. create a project for a second cordova platform, and develop the native
bit, preserving the js from 1
4. test thoroughly
5. repeat steps 3+4 for any remaining platforms
6. package featureX as a plugin by organizing relevant bits in the correct
folder structure, and adding a plugin.xml
7. test each platform by installing with plugman
8. publish

We seem to have this notion come up repeatedly that our users + plugin
developers are working on multiple platforms at the same time, which I
think is entirely false.
I also think we're trying to help the wrong people; If I am a developer who
is working on multiple platforms at once, and I have a bunch of devices
attached, I probably also have the skills to set up my own grunt continuous
integration system. Setting up tooling for potential plugin developers is
the wrong approach, imho. We should actually just go and implement some new
plugin and evaluate the process instead of creating and imposing a specific
workflow.









@purplecabbage
risingj.com


On Thu, Sep 26, 2013 at 10:09 AM, Brian LeRoux <b...@brian.io> wrote:

> I love the idea of a watch command.
>
>
> On Thu, Sep 26, 2013 at 4:48 PM, Anis KADRI <an...@gmail.com> wrote:
>
> > Forgot about the existence of --link for a second. I think this is a
> > good solution (not temporary). watch can be an enhancement to this
> > solution. This might get people like Joe Bowser and other people who
> > do native dev to give cordova-cli a try (only maybe though).
> >
> > On Thu, Sep 26, 2013 at 4:25 PM, Braden Shepherdson <braden@chromium.org
> >
> > wrote:
> > > If the proposal above is temporary, what's permanent? cordova watch? I
> > want
> > > to make sure we're on the same page.
> > >
> > > Braden
> > >
> > >
> > > On Thu, Sep 26, 2013 at 6:08 AM, Anis KADRI <an...@gmail.com>
> > wrote:
> > >
> > >> No I didn't mean implement `plugman --watch`. I don't think plugman
> > >> needs a `watch` command.
> > >>
> > >> I was indeed talking about `cordova watch` which should watch for
> > >> changes in plugins/ (and maybe in merges/ and www/ as well) and update
> > >> the platform projects (prepare?) on every change.  I am happy to know
> > >> that it's on the wish list.
> > >>
> > >> As far as the original proposal, I believe it is a descent temporary
> > >> solution for plugin developers who want to use cordova-cli.
> > >>
> > >> On Wed, Sep 25, 2013 at 7:17 PM, Michal Mocny <mm...@chromium.org>
> > wrote:
> > >> > Braden, thats has been on the wish list (cordova watch), but I
> suspect
> > >> Anis
> > >> > was suggesting something different with plugman --watch, to do
> > >> specifically
> > >> > with plugin development.  Am I right, Anis?  How does your idea
> > compare
> > >> > with using --link with cordova watch?  Would plugman --watch be
> useful
> > >> for
> > >> > non cli projects?
> > >> >
> > >> > -Michal
> > >> >
> > >> >
> > >> > On Wed, Sep 25, 2013 at 10:31 AM, Braden Shepherdson <
> > >> braden@chromium.org>wrote:
> > >> >
> > >> >> We've had a vague feature planned for a while now to do a cordova
> > >> watch. It
> > >> >> would watch your plugins/, www/, and merges/* for any changes. If
> any
> > >> >> changes are detected, it would re-run cordova prepare, so that your
> > >> native
> > >> >> projects are always up-to-date.
> > >> >>
> > >> >> I'm open to checking (hashes?) which files have changed and which
> > have
> > >> not,
> > >> >> but hashing them all is touching them all anyway, and it might be
> > faster
> > >> >> for small files to just copy them instead of checking first. We'll
> > have
> > >> to
> > >> >> try it and see; for v1 I'm going with the simple option of copying
> > >> >> everything.
> > >> >>
> > >> >> Braden
> > >> >>
> > >> >>
> > >> >> On Wed, Sep 25, 2013 at 9:44 AM, Michal Mocny <mmocny@chromium.org
> >
> > >> wrote:
> > >> >>
> > >> >> > The idea for plugin dev outside of plugins/ folder was to use
> > "plugin
> > >> add
> > >> >> > --link".  Matter of fact, braden suggested that "plugin create"
> > should
> > >> >> > default to --link-ing to some external location so that you don't
> > risk
> > >> >> > deleting your only copy inside plugins/.  (I personally don't
> think
> > >> >> thats a
> > >> >> > necessary concern, but I think its a conversation for later).
> > >> >> >
> > >> >> > I'm not even sure what a 'watch' would do, just uninstall &
> install
> > >> each
> > >> >> > time the plugin changes?  I think that ends up being just
> slightly
> > >> worse
> > >> >> > than the current proposal if you factor in that we already do
> > support
> > >> >> > --link (except without the above change its been useless).
> > >> >> >
> > >> >> >
> > >> >> > However, we may still want some form of 'watch' command for devs
> > using
> > >> >> > plugman directly.  I had assumed that those devs just edit in
> > place,
> > >> >> since
> > >> >> > they don't use a prepare step anyway.
> > >> >> >
> > >> >> > -Michal
> > >> >> >
> > >> >> >
> > >> >> >
> > >> >> > On Wed, Sep 25, 2013 at 7:50 AM, Anis KADRI <
> anis.kadri@gmail.com>
> > >> >> wrote:
> > >> >> >
> > >> >> > > If we're talking about developing plugins inside the
> > >> >> > > plugins/org.myplugin.id folder than I think it's a great
> > workflow
> > >> and
> > >> >> > > I would just hide the cached version of plugin.xml inside that
> > >> >> > > plugins/org.myplugin.id folder.
> > >> >> > >
> > >> >> > > However, if you're developing a plugin outside of a cordova CLI
> > >> >> > > project, I think a `watch` (and add --watch) command is more
> > >> >> > > appropriate. One of the reasons you would develop a plugin
> > outside
> > >> of
> > >> >> > > a cordova CLI project is for easier version control (each
> plugin
> > >> would
> > >> >> > > have its own repository). The other cool thing about `watch` is
> > that
> > >> >> > > it would copy the files that have actually changed and not
> > >> everything
> > >> >> > > (some plugins have a LOT of files [1]).
> > >> >> > >
> > >> >> > > [1] https://github.com/phonegap/phonegap-facebook-plugin
> > >> >> > >
> > >> >> > > On Wed, Sep 25, 2013 at 3:30 AM, James Jong <
> > wjamesjong@gmail.com>
> > >> >> > wrote:
> > >> >> > > > +1 This is a cleaner workflow and should reduce some
> confusion.
> > >> >> > > >
> > >> >> > > > -James Jong
> > >> >> > > >
> > >> >> > > > On Sep 24, 2013, at 3:09 PM, Michal Mocny <
> mmocny@chromium.org
> > >
> > >> >> wrote:
> > >> >> > > >
> > >> >> > > >> Just to add, the reason for the "if" statement in step (2)
> is
> > >> that
> > >> >> > > >> uninstall & reinstall take a lot longer than just moving a
> few
> > >> >> files,
> > >> >> > > which
> > >> >> > > >> is the 99.9% case for most end users who aren't making
> > >> modifications
> > >> >> > to
> > >> >> > > >> plugins.
> > >> >> > > >>
> > >> >> > > >> This way, we only do the heavy lifting if your plugin
> > structure
> > >> >> > actually
> > >> >> > > >> changed.  Doing it automatically means we no longer have to
> > >> advise
> > >> >> > users
> > >> >> > > >> that making edits inside plugin/ folder is useless.  Now we
> > just
> > >> >> > advise
> > >> >> > > >> them to run "prepare" after making changes to either www/ or
> > >> >> plugins/.
> > >> >> > > >>
> > >> >> > > >> This key insight was Braden's idea and I think its just an
> > >> awesome
> > >> >> > > change
> > >> >> > > >> for workflow.
> > >> >> > > >>
> > >> >> > > >> -Michal
> > >> >> > > >>
> > >> >> > > >>
> > >> >> > > >> On Tue, Sep 24, 2013 at 2:58 PM, Braden Shepherdson <
> > >> >> > > braden@chromium.org>wrote:
> > >> >> > > >>
> > >> >> > > >>> 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
> > >> >> > > >>>
> > >> >> > > >
> > >> >> > >
> > >> >> >
> > >> >>
> > >>
> >
>

Re: Updating plugin code on prepare

[Michal Mocny <mm...@chromium.org>]

On Thu, Sep 26, 2013 at 2:03 PM, Carlos Santana <cs...@gmail.com>wrote:

> I think we can do something outside cordova in grunt using the
> grunt-contrib-watch plugin in user land.
>
Agreed.  I think watch command should leverage grunt, and is just a future
value-add on top of cordova-cli base functionality.  This proposal is
entirely orthogonal, thought a watch feature will certainly be very useful.


> If after a while there is a compelling reason to add some portion or
> lessons learned to cordova  then it can be expose to users.
>
> Also there is the possibility of star experimenting just for cordova usage
> for cordova contributors workflows like we have today in
> cordova-js\Gruntfile
>
> TLDR: lets eat our own dog food before we adopted as something to support
> in apache cordova for consumer of the project.
>
>
>
>
> On Thu, Sep 26, 2013 at 1:42 PM, Tyler Wilson <twilson@pulse-robotics.com
> >wrote:
>
> > Just one comment: if I understand this feature correctly, it watches the
> > top-level www folder and will copy any updated files into the platform
> > files.
> >
> > My issue with this is that I typically create the project, add the
> > platform (iOS in my case) and then load the Xcode project. And what is
> > shown in the iOS project is the platform www folder. And since we
> naturally
> > edit the code directly in Xcode, this watch command would never really do
> > anything for me.
>

This, I consider a major UX bug on our part.  That xcode www/ folder should
just point directly to your top level www/.  Otherwise, you will blow away
your work with each prepare, as you notice.  The solution is not to ignore
the prepare command, indeed that is defeating the point, if not impossible,
when using the CLI.  The solution is not to edit the platform copy of www/.

However, I completely agree that it is more comfortable to edit directly
inside xcode if that is your prefered workflow.  I am not advising against
that.  The answer is perhaps to have a "prepare" hook tred to the xcode
build command, so that your www/ assets are edited directly in, and updated
from, the top level www/ folder automatically whenever you build.

The specifics here are likely topic for another thread since different
parties have different opinions about the idea IDE workflow, but it seems
very clear that what we have right now is confusing to every single user,
like yourself.


> >
> > What I would like a reverse watch, which will detect changes in the
> > platform www and copy them up to the top-level shared www folder. Perhaps
> > this is part of the feature set - more like a 'sync' than a watch.
> >
> > Thanks,
> > Tyler
> >
> > On Sep 26, 2013, at 1:09 PM, Brian LeRoux <b...@brian.io> wrote:
> >
> > > I love the idea of a watch command.
> > >
> > >
> > > On Thu, Sep 26, 2013 at 4:48 PM, Anis KADRI <an...@gmail.com>
> > wrote:
> > >
> > >> Forgot about the existence of --link for a second. I think this is a
> > >> good solution (not temporary). watch can be an enhancement to this
> > >> solution. This might get people like Joe Bowser and other people who
> > >> do native dev to give cordova-cli a try (only maybe though).
> > >>
> > >> On Thu, Sep 26, 2013 at 4:25 PM, Braden Shepherdson <
> > braden@chromium.org>
> > >> wrote:
> > >>> If the proposal above is temporary, what's permanent? cordova watch?
> I
> > >> want
> > >>> to make sure we're on the same page.
> > >>>
> > >>> Braden
> > >>>
> > >>>
> > >>> On Thu, Sep 26, 2013 at 6:08 AM, Anis KADRI <an...@gmail.com>
> > >> wrote:
> > >>>
> > >>>> No I didn't mean implement `plugman --watch`. I don't think plugman
> > >>>> needs a `watch` command.
> > >>>>
> > >>>> I was indeed talking about `cordova watch` which should watch for
> > >>>> changes in plugins/ (and maybe in merges/ and www/ as well) and
> update
> > >>>> the platform projects (prepare?) on every change.  I am happy to
> know
> > >>>> that it's on the wish list.
> > >>>>
> > >>>> As far as the original proposal, I believe it is a descent temporary
> > >>>> solution for plugin developers who want to use cordova-cli.
> > >>>>
> > >>>> On Wed, Sep 25, 2013 at 7:17 PM, Michal Mocny <mm...@chromium.org>
> > >> wrote:
> > >>>>> Braden, thats has been on the wish list (cordova watch), but I
> > suspect
> > >>>> Anis
> > >>>>> was suggesting something different with plugman --watch, to do
> > >>>> specifically
> > >>>>> with plugin development.  Am I right, Anis?  How does your idea
> > >> compare
> > >>>>> with using --link with cordova watch?  Would plugman --watch be
> > useful
> > >>>> for
> > >>>>> non cli projects?
> > >>>>>
> > >>>>> -Michal
> > >>>>>
> > >>>>>
> > >>>>> On Wed, Sep 25, 2013 at 10:31 AM, Braden Shepherdson <
> > >>>> braden@chromium.org>wrote:
> > >>>>>
> > >>>>>> We've had a vague feature planned for a while now to do a cordova
> > >>>> watch. It
> > >>>>>> would watch your plugins/, www/, and merges/* for any changes. If
> > any
> > >>>>>> changes are detected, it would re-run cordova prepare, so that
> your
> > >>>> native
> > >>>>>> projects are always up-to-date.
> > >>>>>>
> > >>>>>> I'm open to checking (hashes?) which files have changed and which
> > >> have
> > >>>> not,
> > >>>>>> but hashing them all is touching them all anyway, and it might be
> > >> faster
> > >>>>>> for small files to just copy them instead of checking first. We'll
> > >> have
> > >>>> to
> > >>>>>> try it and see; for v1 I'm going with the simple option of copying
> > >>>>>> everything.
> > >>>>>>
> > >>>>>> Braden
> > >>>>>>
> > >>>>>>
> > >>>>>> On Wed, Sep 25, 2013 at 9:44 AM, Michal Mocny <
> mmocny@chromium.org>
> > >>>> wrote:
> > >>>>>>
> > >>>>>>> The idea for plugin dev outside of plugins/ folder was to use
> > >> "plugin
> > >>>> add
> > >>>>>>> --link".  Matter of fact, braden suggested that "plugin create"
> > >> should
> > >>>>>>> default to --link-ing to some external location so that you don't
> > >> risk
> > >>>>>>> deleting your only copy inside plugins/.  (I personally don't
> think
> > >>>>>> thats a
> > >>>>>>> necessary concern, but I think its a conversation for later).
> > >>>>>>>
> > >>>>>>> I'm not even sure what a 'watch' would do, just uninstall &
> install
> > >>>> each
> > >>>>>>> time the plugin changes?  I think that ends up being just
> slightly
> > >>>> worse
> > >>>>>>> than the current proposal if you factor in that we already do
> > >> support
> > >>>>>>> --link (except without the above change its been useless).
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> However, we may still want some form of 'watch' command for devs
> > >> using
> > >>>>>>> plugman directly.  I had assumed that those devs just edit in
> > >> place,
> > >>>>>> since
> > >>>>>>> they don't use a prepare step anyway.
> > >>>>>>>
> > >>>>>>> -Michal
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> On Wed, Sep 25, 2013 at 7:50 AM, Anis KADRI <
> anis.kadri@gmail.com>
> > >>>>>> wrote:
> > >>>>>>>
> > >>>>>>>> If we're talking about developing plugins inside the
> > >>>>>>>> plugins/org.myplugin.id folder than I think it's a great
> > >> workflow
> > >>>> and
> > >>>>>>>> I would just hide the cached version of plugin.xml inside that
> > >>>>>>>> plugins/org.myplugin.id folder.
> > >>>>>>>>
> > >>>>>>>> However, if you're developing a plugin outside of a cordova CLI
> > >>>>>>>> project, I think a `watch` (and add --watch) command is more
> > >>>>>>>> appropriate. One of the reasons you would develop a plugin
> > >> outside
> > >>>> of
> > >>>>>>>> a cordova CLI project is for easier version control (each plugin
> > >>>> would
> > >>>>>>>> have its own repository). The other cool thing about `watch` is
> > >> that
> > >>>>>>>> it would copy the files that have actually changed and not
> > >>>> everything
> > >>>>>>>> (some plugins have a LOT of files [1]).
> > >>>>>>>>
> > >>>>>>>> [1] https://github.com/phonegap/phonegap-facebook-plugin
> > >>>>>>>>
> > >>>>>>>> On Wed, Sep 25, 2013 at 3:30 AM, James Jong <
> > >> wjamesjong@gmail.com>
> > >>>>>>> wrote:
> > >>>>>>>>> +1 This is a cleaner workflow and should reduce some confusion.
> > >>>>>>>>>
> > >>>>>>>>> -James Jong
> > >>>>>>>>>
> > >>>>>>>>> On Sep 24, 2013, at 3:09 PM, Michal Mocny <mmocny@chromium.org
> > >>>
> > >>>>>> wrote:
> > >>>>>>>>>
> > >>>>>>>>>> Just to add, the reason for the "if" statement in step (2) is
> > >>>> that
> > >>>>>>>>>> uninstall & reinstall take a lot longer than just moving a few
> > >>>>>> files,
> > >>>>>>>> which
> > >>>>>>>>>> is the 99.9% case for most end users who aren't making
> > >>>> modifications
> > >>>>>>> to
> > >>>>>>>>>> plugins.
> > >>>>>>>>>>
> > >>>>>>>>>> This way, we only do the heavy lifting if your plugin
> > >> structure
> > >>>>>>> actually
> > >>>>>>>>>> changed.  Doing it automatically means we no longer have to
> > >>>> advise
> > >>>>>>> users
> > >>>>>>>>>> that making edits inside plugin/ folder is useless.  Now we
> > >> just
> > >>>>>>> advise
> > >>>>>>>>>> them to run "prepare" after making changes to either www/ or
> > >>>>>> plugins/.
> > >>>>>>>>>>
> > >>>>>>>>>> This key insight was Braden's idea and I think its just an
> > >>>> awesome
> > >>>>>>>> change
> > >>>>>>>>>> for workflow.
> > >>>>>>>>>>
> > >>>>>>>>>> -Michal
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>> On Tue, Sep 24, 2013 at 2:58 PM, Braden Shepherdson <
> > >>>>>>>> braden@chromium.org>wrote:
> > >>>>>>>>>>
> > >>>>>>>>>>> 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
> > >>>>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>
> > >>>>
> > >>
> >
> >
>
>
> --
> Carlos Santana
> <cs...@gmail.com>
>

Re: Updating plugin code on prepare

[Carlos Santana <cs...@gmail.com>]

I think we can do something outside cordova in grunt using the
grunt-contrib-watch plugin in user land.

If after a while there is a compelling reason to add some portion or
lessons learned to cordova  then it can be expose to users.

Also there is the possibility of star experimenting just for cordova usage
for cordova contributors workflows like we have today in
cordova-js\Gruntfile

TLDR: lets eat our own dog food before we adopted as something to support
in apache cordova for consumer of the project.




On Thu, Sep 26, 2013 at 1:42 PM, Tyler Wilson <tw...@pulse-robotics.com>wrote:

> Just one comment: if I understand this feature correctly, it watches the
> top-level www folder and will copy any updated files into the platform
> files.
>
> My issue with this is that I typically create the project, add the
> platform (iOS in my case) and then load the Xcode project. And what is
> shown in the iOS project is the platform www folder. And since we naturally
> edit the code directly in Xcode, this watch command would never really do
> anything for me.
>
> What I would like a reverse watch, which will detect changes in the
> platform www and copy them up to the top-level shared www folder. Perhaps
> this is part of the feature set - more like a 'sync' than a watch.
>
> Thanks,
> Tyler
>
> On Sep 26, 2013, at 1:09 PM, Brian LeRoux <b...@brian.io> wrote:
>
> > I love the idea of a watch command.
> >
> >
> > On Thu, Sep 26, 2013 at 4:48 PM, Anis KADRI <an...@gmail.com>
> wrote:
> >
> >> Forgot about the existence of --link for a second. I think this is a
> >> good solution (not temporary). watch can be an enhancement to this
> >> solution. This might get people like Joe Bowser and other people who
> >> do native dev to give cordova-cli a try (only maybe though).
> >>
> >> On Thu, Sep 26, 2013 at 4:25 PM, Braden Shepherdson <
> braden@chromium.org>
> >> wrote:
> >>> If the proposal above is temporary, what's permanent? cordova watch? I
> >> want
> >>> to make sure we're on the same page.
> >>>
> >>> Braden
> >>>
> >>>
> >>> On Thu, Sep 26, 2013 at 6:08 AM, Anis KADRI <an...@gmail.com>
> >> wrote:
> >>>
> >>>> No I didn't mean implement `plugman --watch`. I don't think plugman
> >>>> needs a `watch` command.
> >>>>
> >>>> I was indeed talking about `cordova watch` which should watch for
> >>>> changes in plugins/ (and maybe in merges/ and www/ as well) and update
> >>>> the platform projects (prepare?) on every change.  I am happy to know
> >>>> that it's on the wish list.
> >>>>
> >>>> As far as the original proposal, I believe it is a descent temporary
> >>>> solution for plugin developers who want to use cordova-cli.
> >>>>
> >>>> On Wed, Sep 25, 2013 at 7:17 PM, Michal Mocny <mm...@chromium.org>
> >> wrote:
> >>>>> Braden, thats has been on the wish list (cordova watch), but I
> suspect
> >>>> Anis
> >>>>> was suggesting something different with plugman --watch, to do
> >>>> specifically
> >>>>> with plugin development.  Am I right, Anis?  How does your idea
> >> compare
> >>>>> with using --link with cordova watch?  Would plugman --watch be
> useful
> >>>> for
> >>>>> non cli projects?
> >>>>>
> >>>>> -Michal
> >>>>>
> >>>>>
> >>>>> On Wed, Sep 25, 2013 at 10:31 AM, Braden Shepherdson <
> >>>> braden@chromium.org>wrote:
> >>>>>
> >>>>>> We've had a vague feature planned for a while now to do a cordova
> >>>> watch. It
> >>>>>> would watch your plugins/, www/, and merges/* for any changes. If
> any
> >>>>>> changes are detected, it would re-run cordova prepare, so that your
> >>>> native
> >>>>>> projects are always up-to-date.
> >>>>>>
> >>>>>> I'm open to checking (hashes?) which files have changed and which
> >> have
> >>>> not,
> >>>>>> but hashing them all is touching them all anyway, and it might be
> >> faster
> >>>>>> for small files to just copy them instead of checking first. We'll
> >> have
> >>>> to
> >>>>>> try it and see; for v1 I'm going with the simple option of copying
> >>>>>> everything.
> >>>>>>
> >>>>>> Braden
> >>>>>>
> >>>>>>
> >>>>>> On Wed, Sep 25, 2013 at 9:44 AM, Michal Mocny <mm...@chromium.org>
> >>>> wrote:
> >>>>>>
> >>>>>>> The idea for plugin dev outside of plugins/ folder was to use
> >> "plugin
> >>>> add
> >>>>>>> --link".  Matter of fact, braden suggested that "plugin create"
> >> should
> >>>>>>> default to --link-ing to some external location so that you don't
> >> risk
> >>>>>>> deleting your only copy inside plugins/.  (I personally don't think
> >>>>>> thats a
> >>>>>>> necessary concern, but I think its a conversation for later).
> >>>>>>>
> >>>>>>> I'm not even sure what a 'watch' would do, just uninstall & install
> >>>> each
> >>>>>>> time the plugin changes?  I think that ends up being just slightly
> >>>> worse
> >>>>>>> than the current proposal if you factor in that we already do
> >> support
> >>>>>>> --link (except without the above change its been useless).
> >>>>>>>
> >>>>>>>
> >>>>>>> However, we may still want some form of 'watch' command for devs
> >> using
> >>>>>>> plugman directly.  I had assumed that those devs just edit in
> >> place,
> >>>>>> since
> >>>>>>> they don't use a prepare step anyway.
> >>>>>>>
> >>>>>>> -Michal
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> On Wed, Sep 25, 2013 at 7:50 AM, Anis KADRI <an...@gmail.com>
> >>>>>> wrote:
> >>>>>>>
> >>>>>>>> If we're talking about developing plugins inside the
> >>>>>>>> plugins/org.myplugin.id folder than I think it's a great
> >> workflow
> >>>> and
> >>>>>>>> I would just hide the cached version of plugin.xml inside that
> >>>>>>>> plugins/org.myplugin.id folder.
> >>>>>>>>
> >>>>>>>> However, if you're developing a plugin outside of a cordova CLI
> >>>>>>>> project, I think a `watch` (and add --watch) command is more
> >>>>>>>> appropriate. One of the reasons you would develop a plugin
> >> outside
> >>>> of
> >>>>>>>> a cordova CLI project is for easier version control (each plugin
> >>>> would
> >>>>>>>> have its own repository). The other cool thing about `watch` is
> >> that
> >>>>>>>> it would copy the files that have actually changed and not
> >>>> everything
> >>>>>>>> (some plugins have a LOT of files [1]).
> >>>>>>>>
> >>>>>>>> [1] https://github.com/phonegap/phonegap-facebook-plugin
> >>>>>>>>
> >>>>>>>> On Wed, Sep 25, 2013 at 3:30 AM, James Jong <
> >> wjamesjong@gmail.com>
> >>>>>>> wrote:
> >>>>>>>>> +1 This is a cleaner workflow and should reduce some confusion.
> >>>>>>>>>
> >>>>>>>>> -James Jong
> >>>>>>>>>
> >>>>>>>>> On Sep 24, 2013, at 3:09 PM, Michal Mocny <mmocny@chromium.org
> >>>
> >>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> Just to add, the reason for the "if" statement in step (2) is
> >>>> that
> >>>>>>>>>> uninstall & reinstall take a lot longer than just moving a few
> >>>>>> files,
> >>>>>>>> which
> >>>>>>>>>> is the 99.9% case for most end users who aren't making
> >>>> modifications
> >>>>>>> to
> >>>>>>>>>> plugins.
> >>>>>>>>>>
> >>>>>>>>>> This way, we only do the heavy lifting if your plugin
> >> structure
> >>>>>>> actually
> >>>>>>>>>> changed.  Doing it automatically means we no longer have to
> >>>> advise
> >>>>>>> users
> >>>>>>>>>> that making edits inside plugin/ folder is useless.  Now we
> >> just
> >>>>>>> advise
> >>>>>>>>>> them to run "prepare" after making changes to either www/ or
> >>>>>> plugins/.
> >>>>>>>>>>
> >>>>>>>>>> This key insight was Braden's idea and I think its just an
> >>>> awesome
> >>>>>>>> change
> >>>>>>>>>> for workflow.
> >>>>>>>>>>
> >>>>>>>>>> -Michal
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On Tue, Sep 24, 2013 at 2:58 PM, Braden Shepherdson <
> >>>>>>>> braden@chromium.org>wrote:
> >>>>>>>>>>
> >>>>>>>>>>> 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
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
>
>


-- 
Carlos Santana
<cs...@gmail.com>

Re: Updating plugin code on prepare

[Tyler Wilson <tw...@pulse-robotics.com>]

Just one comment: if I understand this feature correctly, it watches the top-level www folder and will copy any updated files into the platform files. 

My issue with this is that I typically create the project, add the platform (iOS in my case) and then load the Xcode project. And what is shown in the iOS project is the platform www folder. And since we naturally edit the code directly in Xcode, this watch command would never really do anything for me.

What I would like a reverse watch, which will detect changes in the platform www and copy them up to the top-level shared www folder. Perhaps this is part of the feature set - more like a 'sync' than a watch.

Thanks,
Tyler
 
On Sep 26, 2013, at 1:09 PM, Brian LeRoux <b...@brian.io> wrote:

> I love the idea of a watch command.
> 
> 
> On Thu, Sep 26, 2013 at 4:48 PM, Anis KADRI <an...@gmail.com> wrote:
> 
>> Forgot about the existence of --link for a second. I think this is a
>> good solution (not temporary). watch can be an enhancement to this
>> solution. This might get people like Joe Bowser and other people who
>> do native dev to give cordova-cli a try (only maybe though).
>> 
>> On Thu, Sep 26, 2013 at 4:25 PM, Braden Shepherdson <br...@chromium.org>
>> wrote:
>>> If the proposal above is temporary, what's permanent? cordova watch? I
>> want
>>> to make sure we're on the same page.
>>> 
>>> Braden
>>> 
>>> 
>>> On Thu, Sep 26, 2013 at 6:08 AM, Anis KADRI <an...@gmail.com>
>> wrote:
>>> 
>>>> No I didn't mean implement `plugman --watch`. I don't think plugman
>>>> needs a `watch` command.
>>>> 
>>>> I was indeed talking about `cordova watch` which should watch for
>>>> changes in plugins/ (and maybe in merges/ and www/ as well) and update
>>>> the platform projects (prepare?) on every change.  I am happy to know
>>>> that it's on the wish list.
>>>> 
>>>> As far as the original proposal, I believe it is a descent temporary
>>>> solution for plugin developers who want to use cordova-cli.
>>>> 
>>>> On Wed, Sep 25, 2013 at 7:17 PM, Michal Mocny <mm...@chromium.org>
>> wrote:
>>>>> Braden, thats has been on the wish list (cordova watch), but I suspect
>>>> Anis
>>>>> was suggesting something different with plugman --watch, to do
>>>> specifically
>>>>> with plugin development.  Am I right, Anis?  How does your idea
>> compare
>>>>> with using --link with cordova watch?  Would plugman --watch be useful
>>>> for
>>>>> non cli projects?
>>>>> 
>>>>> -Michal
>>>>> 
>>>>> 
>>>>> On Wed, Sep 25, 2013 at 10:31 AM, Braden Shepherdson <
>>>> braden@chromium.org>wrote:
>>>>> 
>>>>>> We've had a vague feature planned for a while now to do a cordova
>>>> watch. It
>>>>>> would watch your plugins/, www/, and merges/* for any changes. If any
>>>>>> changes are detected, it would re-run cordova prepare, so that your
>>>> native
>>>>>> projects are always up-to-date.
>>>>>> 
>>>>>> I'm open to checking (hashes?) which files have changed and which
>> have
>>>> not,
>>>>>> but hashing them all is touching them all anyway, and it might be
>> faster
>>>>>> for small files to just copy them instead of checking first. We'll
>> have
>>>> to
>>>>>> try it and see; for v1 I'm going with the simple option of copying
>>>>>> everything.
>>>>>> 
>>>>>> Braden
>>>>>> 
>>>>>> 
>>>>>> On Wed, Sep 25, 2013 at 9:44 AM, Michal Mocny <mm...@chromium.org>
>>>> wrote:
>>>>>> 
>>>>>>> The idea for plugin dev outside of plugins/ folder was to use
>> "plugin
>>>> add
>>>>>>> --link".  Matter of fact, braden suggested that "plugin create"
>> should
>>>>>>> default to --link-ing to some external location so that you don't
>> risk
>>>>>>> deleting your only copy inside plugins/.  (I personally don't think
>>>>>> thats a
>>>>>>> necessary concern, but I think its a conversation for later).
>>>>>>> 
>>>>>>> I'm not even sure what a 'watch' would do, just uninstall & install
>>>> each
>>>>>>> time the plugin changes?  I think that ends up being just slightly
>>>> worse
>>>>>>> than the current proposal if you factor in that we already do
>> support
>>>>>>> --link (except without the above change its been useless).
>>>>>>> 
>>>>>>> 
>>>>>>> However, we may still want some form of 'watch' command for devs
>> using
>>>>>>> plugman directly.  I had assumed that those devs just edit in
>> place,
>>>>>> since
>>>>>>> they don't use a prepare step anyway.
>>>>>>> 
>>>>>>> -Michal
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> On Wed, Sep 25, 2013 at 7:50 AM, Anis KADRI <an...@gmail.com>
>>>>>> wrote:
>>>>>>> 
>>>>>>>> If we're talking about developing plugins inside the
>>>>>>>> plugins/org.myplugin.id folder than I think it's a great
>> workflow
>>>> and
>>>>>>>> I would just hide the cached version of plugin.xml inside that
>>>>>>>> plugins/org.myplugin.id folder.
>>>>>>>> 
>>>>>>>> However, if you're developing a plugin outside of a cordova CLI
>>>>>>>> project, I think a `watch` (and add --watch) command is more
>>>>>>>> appropriate. One of the reasons you would develop a plugin
>> outside
>>>> of
>>>>>>>> a cordova CLI project is for easier version control (each plugin
>>>> would
>>>>>>>> have its own repository). The other cool thing about `watch` is
>> that
>>>>>>>> it would copy the files that have actually changed and not
>>>> everything
>>>>>>>> (some plugins have a LOT of files [1]).
>>>>>>>> 
>>>>>>>> [1] https://github.com/phonegap/phonegap-facebook-plugin
>>>>>>>> 
>>>>>>>> On Wed, Sep 25, 2013 at 3:30 AM, James Jong <
>> wjamesjong@gmail.com>
>>>>>>> wrote:
>>>>>>>>> +1 This is a cleaner workflow and should reduce some confusion.
>>>>>>>>> 
>>>>>>>>> -James Jong
>>>>>>>>> 
>>>>>>>>> On Sep 24, 2013, at 3:09 PM, Michal Mocny <mmocny@chromium.org
>>> 
>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>>> Just to add, the reason for the "if" statement in step (2) is
>>>> that
>>>>>>>>>> uninstall & reinstall take a lot longer than just moving a few
>>>>>> files,
>>>>>>>> which
>>>>>>>>>> is the 99.9% case for most end users who aren't making
>>>> modifications
>>>>>>> to
>>>>>>>>>> plugins.
>>>>>>>>>> 
>>>>>>>>>> This way, we only do the heavy lifting if your plugin
>> structure
>>>>>>> actually
>>>>>>>>>> changed.  Doing it automatically means we no longer have to
>>>> advise
>>>>>>> users
>>>>>>>>>> that making edits inside plugin/ folder is useless.  Now we
>> just
>>>>>>> advise
>>>>>>>>>> them to run "prepare" after making changes to either www/ or
>>>>>> plugins/.
>>>>>>>>>> 
>>>>>>>>>> This key insight was Braden's idea and I think its just an
>>>> awesome
>>>>>>>> change
>>>>>>>>>> for workflow.
>>>>>>>>>> 
>>>>>>>>>> -Michal
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> On Tue, Sep 24, 2013 at 2:58 PM, Braden Shepherdson <
>>>>>>>> braden@chromium.org>wrote:
>>>>>>>>>> 
>>>>>>>>>>> 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
>>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> 

Re: Updating plugin code on prepare

[Brian LeRoux <b...@brian.io>]

I love the idea of a watch command.


On Thu, Sep 26, 2013 at 4:48 PM, Anis KADRI <an...@gmail.com> wrote:

> Forgot about the existence of --link for a second. I think this is a
> good solution (not temporary). watch can be an enhancement to this
> solution. This might get people like Joe Bowser and other people who
> do native dev to give cordova-cli a try (only maybe though).
>
> On Thu, Sep 26, 2013 at 4:25 PM, Braden Shepherdson <br...@chromium.org>
> wrote:
> > If the proposal above is temporary, what's permanent? cordova watch? I
> want
> > to make sure we're on the same page.
> >
> > Braden
> >
> >
> > On Thu, Sep 26, 2013 at 6:08 AM, Anis KADRI <an...@gmail.com>
> wrote:
> >
> >> No I didn't mean implement `plugman --watch`. I don't think plugman
> >> needs a `watch` command.
> >>
> >> I was indeed talking about `cordova watch` which should watch for
> >> changes in plugins/ (and maybe in merges/ and www/ as well) and update
> >> the platform projects (prepare?) on every change.  I am happy to know
> >> that it's on the wish list.
> >>
> >> As far as the original proposal, I believe it is a descent temporary
> >> solution for plugin developers who want to use cordova-cli.
> >>
> >> On Wed, Sep 25, 2013 at 7:17 PM, Michal Mocny <mm...@chromium.org>
> wrote:
> >> > Braden, thats has been on the wish list (cordova watch), but I suspect
> >> Anis
> >> > was suggesting something different with plugman --watch, to do
> >> specifically
> >> > with plugin development.  Am I right, Anis?  How does your idea
> compare
> >> > with using --link with cordova watch?  Would plugman --watch be useful
> >> for
> >> > non cli projects?
> >> >
> >> > -Michal
> >> >
> >> >
> >> > On Wed, Sep 25, 2013 at 10:31 AM, Braden Shepherdson <
> >> braden@chromium.org>wrote:
> >> >
> >> >> We've had a vague feature planned for a while now to do a cordova
> >> watch. It
> >> >> would watch your plugins/, www/, and merges/* for any changes. If any
> >> >> changes are detected, it would re-run cordova prepare, so that your
> >> native
> >> >> projects are always up-to-date.
> >> >>
> >> >> I'm open to checking (hashes?) which files have changed and which
> have
> >> not,
> >> >> but hashing them all is touching them all anyway, and it might be
> faster
> >> >> for small files to just copy them instead of checking first. We'll
> have
> >> to
> >> >> try it and see; for v1 I'm going with the simple option of copying
> >> >> everything.
> >> >>
> >> >> Braden
> >> >>
> >> >>
> >> >> On Wed, Sep 25, 2013 at 9:44 AM, Michal Mocny <mm...@chromium.org>
> >> wrote:
> >> >>
> >> >> > The idea for plugin dev outside of plugins/ folder was to use
> "plugin
> >> add
> >> >> > --link".  Matter of fact, braden suggested that "plugin create"
> should
> >> >> > default to --link-ing to some external location so that you don't
> risk
> >> >> > deleting your only copy inside plugins/.  (I personally don't think
> >> >> thats a
> >> >> > necessary concern, but I think its a conversation for later).
> >> >> >
> >> >> > I'm not even sure what a 'watch' would do, just uninstall & install
> >> each
> >> >> > time the plugin changes?  I think that ends up being just slightly
> >> worse
> >> >> > than the current proposal if you factor in that we already do
> support
> >> >> > --link (except without the above change its been useless).
> >> >> >
> >> >> >
> >> >> > However, we may still want some form of 'watch' command for devs
> using
> >> >> > plugman directly.  I had assumed that those devs just edit in
> place,
> >> >> since
> >> >> > they don't use a prepare step anyway.
> >> >> >
> >> >> > -Michal
> >> >> >
> >> >> >
> >> >> >
> >> >> > On Wed, Sep 25, 2013 at 7:50 AM, Anis KADRI <an...@gmail.com>
> >> >> wrote:
> >> >> >
> >> >> > > If we're talking about developing plugins inside the
> >> >> > > plugins/org.myplugin.id folder than I think it's a great
> workflow
> >> and
> >> >> > > I would just hide the cached version of plugin.xml inside that
> >> >> > > plugins/org.myplugin.id folder.
> >> >> > >
> >> >> > > However, if you're developing a plugin outside of a cordova CLI
> >> >> > > project, I think a `watch` (and add --watch) command is more
> >> >> > > appropriate. One of the reasons you would develop a plugin
> outside
> >> of
> >> >> > > a cordova CLI project is for easier version control (each plugin
> >> would
> >> >> > > have its own repository). The other cool thing about `watch` is
> that
> >> >> > > it would copy the files that have actually changed and not
> >> everything
> >> >> > > (some plugins have a LOT of files [1]).
> >> >> > >
> >> >> > > [1] https://github.com/phonegap/phonegap-facebook-plugin
> >> >> > >
> >> >> > > On Wed, Sep 25, 2013 at 3:30 AM, James Jong <
> wjamesjong@gmail.com>
> >> >> > wrote:
> >> >> > > > +1 This is a cleaner workflow and should reduce some confusion.
> >> >> > > >
> >> >> > > > -James Jong
> >> >> > > >
> >> >> > > > On Sep 24, 2013, at 3:09 PM, Michal Mocny <mmocny@chromium.org
> >
> >> >> wrote:
> >> >> > > >
> >> >> > > >> Just to add, the reason for the "if" statement in step (2) is
> >> that
> >> >> > > >> uninstall & reinstall take a lot longer than just moving a few
> >> >> files,
> >> >> > > which
> >> >> > > >> is the 99.9% case for most end users who aren't making
> >> modifications
> >> >> > to
> >> >> > > >> plugins.
> >> >> > > >>
> >> >> > > >> This way, we only do the heavy lifting if your plugin
> structure
> >> >> > actually
> >> >> > > >> changed.  Doing it automatically means we no longer have to
> >> advise
> >> >> > users
> >> >> > > >> that making edits inside plugin/ folder is useless.  Now we
> just
> >> >> > advise
> >> >> > > >> them to run "prepare" after making changes to either www/ or
> >> >> plugins/.
> >> >> > > >>
> >> >> > > >> This key insight was Braden's idea and I think its just an
> >> awesome
> >> >> > > change
> >> >> > > >> for workflow.
> >> >> > > >>
> >> >> > > >> -Michal
> >> >> > > >>
> >> >> > > >>
> >> >> > > >> On Tue, Sep 24, 2013 at 2:58 PM, Braden Shepherdson <
> >> >> > > braden@chromium.org>wrote:
> >> >> > > >>
> >> >> > > >>> 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
> >> >> > > >>>
> >> >> > > >
> >> >> > >
> >> >> >
> >> >>
> >>
>

Re: Updating plugin code on prepare

[Anis KADRI <an...@gmail.com>]

Forgot about the existence of --link for a second. I think this is a
good solution (not temporary). watch can be an enhancement to this
solution. This might get people like Joe Bowser and other people who
do native dev to give cordova-cli a try (only maybe though).

On Thu, Sep 26, 2013 at 4:25 PM, Braden Shepherdson <br...@chromium.org> wrote:
> If the proposal above is temporary, what's permanent? cordova watch? I want
> to make sure we're on the same page.
>
> Braden
>
>
> On Thu, Sep 26, 2013 at 6:08 AM, Anis KADRI <an...@gmail.com> wrote:
>
>> No I didn't mean implement `plugman --watch`. I don't think plugman
>> needs a `watch` command.
>>
>> I was indeed talking about `cordova watch` which should watch for
>> changes in plugins/ (and maybe in merges/ and www/ as well) and update
>> the platform projects (prepare?) on every change.  I am happy to know
>> that it's on the wish list.
>>
>> As far as the original proposal, I believe it is a descent temporary
>> solution for plugin developers who want to use cordova-cli.
>>
>> On Wed, Sep 25, 2013 at 7:17 PM, Michal Mocny <mm...@chromium.org> wrote:
>> > Braden, thats has been on the wish list (cordova watch), but I suspect
>> Anis
>> > was suggesting something different with plugman --watch, to do
>> specifically
>> > with plugin development.  Am I right, Anis?  How does your idea compare
>> > with using --link with cordova watch?  Would plugman --watch be useful
>> for
>> > non cli projects?
>> >
>> > -Michal
>> >
>> >
>> > On Wed, Sep 25, 2013 at 10:31 AM, Braden Shepherdson <
>> braden@chromium.org>wrote:
>> >
>> >> We've had a vague feature planned for a while now to do a cordova
>> watch. It
>> >> would watch your plugins/, www/, and merges/* for any changes. If any
>> >> changes are detected, it would re-run cordova prepare, so that your
>> native
>> >> projects are always up-to-date.
>> >>
>> >> I'm open to checking (hashes?) which files have changed and which have
>> not,
>> >> but hashing them all is touching them all anyway, and it might be faster
>> >> for small files to just copy them instead of checking first. We'll have
>> to
>> >> try it and see; for v1 I'm going with the simple option of copying
>> >> everything.
>> >>
>> >> Braden
>> >>
>> >>
>> >> On Wed, Sep 25, 2013 at 9:44 AM, Michal Mocny <mm...@chromium.org>
>> wrote:
>> >>
>> >> > The idea for plugin dev outside of plugins/ folder was to use "plugin
>> add
>> >> > --link".  Matter of fact, braden suggested that "plugin create" should
>> >> > default to --link-ing to some external location so that you don't risk
>> >> > deleting your only copy inside plugins/.  (I personally don't think
>> >> thats a
>> >> > necessary concern, but I think its a conversation for later).
>> >> >
>> >> > I'm not even sure what a 'watch' would do, just uninstall & install
>> each
>> >> > time the plugin changes?  I think that ends up being just slightly
>> worse
>> >> > than the current proposal if you factor in that we already do support
>> >> > --link (except without the above change its been useless).
>> >> >
>> >> >
>> >> > However, we may still want some form of 'watch' command for devs using
>> >> > plugman directly.  I had assumed that those devs just edit in place,
>> >> since
>> >> > they don't use a prepare step anyway.
>> >> >
>> >> > -Michal
>> >> >
>> >> >
>> >> >
>> >> > On Wed, Sep 25, 2013 at 7:50 AM, Anis KADRI <an...@gmail.com>
>> >> wrote:
>> >> >
>> >> > > If we're talking about developing plugins inside the
>> >> > > plugins/org.myplugin.id folder than I think it's a great workflow
>> and
>> >> > > I would just hide the cached version of plugin.xml inside that
>> >> > > plugins/org.myplugin.id folder.
>> >> > >
>> >> > > However, if you're developing a plugin outside of a cordova CLI
>> >> > > project, I think a `watch` (and add --watch) command is more
>> >> > > appropriate. One of the reasons you would develop a plugin outside
>> of
>> >> > > a cordova CLI project is for easier version control (each plugin
>> would
>> >> > > have its own repository). The other cool thing about `watch` is that
>> >> > > it would copy the files that have actually changed and not
>> everything
>> >> > > (some plugins have a LOT of files [1]).
>> >> > >
>> >> > > [1] https://github.com/phonegap/phonegap-facebook-plugin
>> >> > >
>> >> > > On Wed, Sep 25, 2013 at 3:30 AM, James Jong <wj...@gmail.com>
>> >> > wrote:
>> >> > > > +1 This is a cleaner workflow and should reduce some confusion.
>> >> > > >
>> >> > > > -James Jong
>> >> > > >
>> >> > > > On Sep 24, 2013, at 3:09 PM, Michal Mocny <mm...@chromium.org>
>> >> wrote:
>> >> > > >
>> >> > > >> Just to add, the reason for the "if" statement in step (2) is
>> that
>> >> > > >> uninstall & reinstall take a lot longer than just moving a few
>> >> files,
>> >> > > which
>> >> > > >> is the 99.9% case for most end users who aren't making
>> modifications
>> >> > to
>> >> > > >> plugins.
>> >> > > >>
>> >> > > >> This way, we only do the heavy lifting if your plugin structure
>> >> > actually
>> >> > > >> changed.  Doing it automatically means we no longer have to
>> advise
>> >> > users
>> >> > > >> that making edits inside plugin/ folder is useless.  Now we just
>> >> > advise
>> >> > > >> them to run "prepare" after making changes to either www/ or
>> >> plugins/.
>> >> > > >>
>> >> > > >> This key insight was Braden's idea and I think its just an
>> awesome
>> >> > > change
>> >> > > >> for workflow.
>> >> > > >>
>> >> > > >> -Michal
>> >> > > >>
>> >> > > >>
>> >> > > >> On Tue, Sep 24, 2013 at 2:58 PM, Braden Shepherdson <
>> >> > > braden@chromium.org>wrote:
>> >> > > >>
>> >> > > >>> 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
>> >> > > >>>
>> >> > > >
>> >> > >
>> >> >
>> >>
>>

Re: Updating plugin code on prepare

[Braden Shepherdson <br...@chromium.org>]

If the proposal above is temporary, what's permanent? cordova watch? I want
to make sure we're on the same page.

Braden


On Thu, Sep 26, 2013 at 6:08 AM, Anis KADRI <an...@gmail.com> wrote:

> No I didn't mean implement `plugman --watch`. I don't think plugman
> needs a `watch` command.
>
> I was indeed talking about `cordova watch` which should watch for
> changes in plugins/ (and maybe in merges/ and www/ as well) and update
> the platform projects (prepare?) on every change.  I am happy to know
> that it's on the wish list.
>
> As far as the original proposal, I believe it is a descent temporary
> solution for plugin developers who want to use cordova-cli.
>
> On Wed, Sep 25, 2013 at 7:17 PM, Michal Mocny <mm...@chromium.org> wrote:
> > Braden, thats has been on the wish list (cordova watch), but I suspect
> Anis
> > was suggesting something different with plugman --watch, to do
> specifically
> > with plugin development.  Am I right, Anis?  How does your idea compare
> > with using --link with cordova watch?  Would plugman --watch be useful
> for
> > non cli projects?
> >
> > -Michal
> >
> >
> > On Wed, Sep 25, 2013 at 10:31 AM, Braden Shepherdson <
> braden@chromium.org>wrote:
> >
> >> We've had a vague feature planned for a while now to do a cordova
> watch. It
> >> would watch your plugins/, www/, and merges/* for any changes. If any
> >> changes are detected, it would re-run cordova prepare, so that your
> native
> >> projects are always up-to-date.
> >>
> >> I'm open to checking (hashes?) which files have changed and which have
> not,
> >> but hashing them all is touching them all anyway, and it might be faster
> >> for small files to just copy them instead of checking first. We'll have
> to
> >> try it and see; for v1 I'm going with the simple option of copying
> >> everything.
> >>
> >> Braden
> >>
> >>
> >> On Wed, Sep 25, 2013 at 9:44 AM, Michal Mocny <mm...@chromium.org>
> wrote:
> >>
> >> > The idea for plugin dev outside of plugins/ folder was to use "plugin
> add
> >> > --link".  Matter of fact, braden suggested that "plugin create" should
> >> > default to --link-ing to some external location so that you don't risk
> >> > deleting your only copy inside plugins/.  (I personally don't think
> >> thats a
> >> > necessary concern, but I think its a conversation for later).
> >> >
> >> > I'm not even sure what a 'watch' would do, just uninstall & install
> each
> >> > time the plugin changes?  I think that ends up being just slightly
> worse
> >> > than the current proposal if you factor in that we already do support
> >> > --link (except without the above change its been useless).
> >> >
> >> >
> >> > However, we may still want some form of 'watch' command for devs using
> >> > plugman directly.  I had assumed that those devs just edit in place,
> >> since
> >> > they don't use a prepare step anyway.
> >> >
> >> > -Michal
> >> >
> >> >
> >> >
> >> > On Wed, Sep 25, 2013 at 7:50 AM, Anis KADRI <an...@gmail.com>
> >> wrote:
> >> >
> >> > > If we're talking about developing plugins inside the
> >> > > plugins/org.myplugin.id folder than I think it's a great workflow
> and
> >> > > I would just hide the cached version of plugin.xml inside that
> >> > > plugins/org.myplugin.id folder.
> >> > >
> >> > > However, if you're developing a plugin outside of a cordova CLI
> >> > > project, I think a `watch` (and add --watch) command is more
> >> > > appropriate. One of the reasons you would develop a plugin outside
> of
> >> > > a cordova CLI project is for easier version control (each plugin
> would
> >> > > have its own repository). The other cool thing about `watch` is that
> >> > > it would copy the files that have actually changed and not
> everything
> >> > > (some plugins have a LOT of files [1]).
> >> > >
> >> > > [1] https://github.com/phonegap/phonegap-facebook-plugin
> >> > >
> >> > > On Wed, Sep 25, 2013 at 3:30 AM, James Jong <wj...@gmail.com>
> >> > wrote:
> >> > > > +1 This is a cleaner workflow and should reduce some confusion.
> >> > > >
> >> > > > -James Jong
> >> > > >
> >> > > > On Sep 24, 2013, at 3:09 PM, Michal Mocny <mm...@chromium.org>
> >> wrote:
> >> > > >
> >> > > >> Just to add, the reason for the "if" statement in step (2) is
> that
> >> > > >> uninstall & reinstall take a lot longer than just moving a few
> >> files,
> >> > > which
> >> > > >> is the 99.9% case for most end users who aren't making
> modifications
> >> > to
> >> > > >> plugins.
> >> > > >>
> >> > > >> This way, we only do the heavy lifting if your plugin structure
> >> > actually
> >> > > >> changed.  Doing it automatically means we no longer have to
> advise
> >> > users
> >> > > >> that making edits inside plugin/ folder is useless.  Now we just
> >> > advise
> >> > > >> them to run "prepare" after making changes to either www/ or
> >> plugins/.
> >> > > >>
> >> > > >> This key insight was Braden's idea and I think its just an
> awesome
> >> > > change
> >> > > >> for workflow.
> >> > > >>
> >> > > >> -Michal
> >> > > >>
> >> > > >>
> >> > > >> On Tue, Sep 24, 2013 at 2:58 PM, Braden Shepherdson <
> >> > > braden@chromium.org>wrote:
> >> > > >>
> >> > > >>> 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
> >> > > >>>
> >> > > >
> >> > >
> >> >
> >>
>

Re: Updating plugin code on prepare

[Anis KADRI <an...@gmail.com>]

No I didn't mean implement `plugman --watch`. I don't think plugman
needs a `watch` command.

I was indeed talking about `cordova watch` which should watch for
changes in plugins/ (and maybe in merges/ and www/ as well) and update
the platform projects (prepare?) on every change.  I am happy to know
that it's on the wish list.

As far as the original proposal, I believe it is a descent temporary
solution for plugin developers who want to use cordova-cli.

On Wed, Sep 25, 2013 at 7:17 PM, Michal Mocny <mm...@chromium.org> wrote:
> Braden, thats has been on the wish list (cordova watch), but I suspect Anis
> was suggesting something different with plugman --watch, to do specifically
> with plugin development.  Am I right, Anis?  How does your idea compare
> with using --link with cordova watch?  Would plugman --watch be useful for
> non cli projects?
>
> -Michal
>
>
> On Wed, Sep 25, 2013 at 10:31 AM, Braden Shepherdson <br...@chromium.org>wrote:
>
>> We've had a vague feature planned for a while now to do a cordova watch. It
>> would watch your plugins/, www/, and merges/* for any changes. If any
>> changes are detected, it would re-run cordova prepare, so that your native
>> projects are always up-to-date.
>>
>> I'm open to checking (hashes?) which files have changed and which have not,
>> but hashing them all is touching them all anyway, and it might be faster
>> for small files to just copy them instead of checking first. We'll have to
>> try it and see; for v1 I'm going with the simple option of copying
>> everything.
>>
>> Braden
>>
>>
>> On Wed, Sep 25, 2013 at 9:44 AM, Michal Mocny <mm...@chromium.org> wrote:
>>
>> > The idea for plugin dev outside of plugins/ folder was to use "plugin add
>> > --link".  Matter of fact, braden suggested that "plugin create" should
>> > default to --link-ing to some external location so that you don't risk
>> > deleting your only copy inside plugins/.  (I personally don't think
>> thats a
>> > necessary concern, but I think its a conversation for later).
>> >
>> > I'm not even sure what a 'watch' would do, just uninstall & install each
>> > time the plugin changes?  I think that ends up being just slightly worse
>> > than the current proposal if you factor in that we already do support
>> > --link (except without the above change its been useless).
>> >
>> >
>> > However, we may still want some form of 'watch' command for devs using
>> > plugman directly.  I had assumed that those devs just edit in place,
>> since
>> > they don't use a prepare step anyway.
>> >
>> > -Michal
>> >
>> >
>> >
>> > On Wed, Sep 25, 2013 at 7:50 AM, Anis KADRI <an...@gmail.com>
>> wrote:
>> >
>> > > If we're talking about developing plugins inside the
>> > > plugins/org.myplugin.id folder than I think it's a great workflow and
>> > > I would just hide the cached version of plugin.xml inside that
>> > > plugins/org.myplugin.id folder.
>> > >
>> > > However, if you're developing a plugin outside of a cordova CLI
>> > > project, I think a `watch` (and add --watch) command is more
>> > > appropriate. One of the reasons you would develop a plugin outside of
>> > > a cordova CLI project is for easier version control (each plugin would
>> > > have its own repository). The other cool thing about `watch` is that
>> > > it would copy the files that have actually changed and not everything
>> > > (some plugins have a LOT of files [1]).
>> > >
>> > > [1] https://github.com/phonegap/phonegap-facebook-plugin
>> > >
>> > > On Wed, Sep 25, 2013 at 3:30 AM, James Jong <wj...@gmail.com>
>> > wrote:
>> > > > +1 This is a cleaner workflow and should reduce some confusion.
>> > > >
>> > > > -James Jong
>> > > >
>> > > > On Sep 24, 2013, at 3:09 PM, Michal Mocny <mm...@chromium.org>
>> wrote:
>> > > >
>> > > >> Just to add, the reason for the "if" statement in step (2) is that
>> > > >> uninstall & reinstall take a lot longer than just moving a few
>> files,
>> > > which
>> > > >> is the 99.9% case for most end users who aren't making modifications
>> > to
>> > > >> plugins.
>> > > >>
>> > > >> This way, we only do the heavy lifting if your plugin structure
>> > actually
>> > > >> changed.  Doing it automatically means we no longer have to advise
>> > users
>> > > >> that making edits inside plugin/ folder is useless.  Now we just
>> > advise
>> > > >> them to run "prepare" after making changes to either www/ or
>> plugins/.
>> > > >>
>> > > >> This key insight was Braden's idea and I think its just an awesome
>> > > change
>> > > >> for workflow.
>> > > >>
>> > > >> -Michal
>> > > >>
>> > > >>
>> > > >> On Tue, Sep 24, 2013 at 2:58 PM, Braden Shepherdson <
>> > > braden@chromium.org>wrote:
>> > > >>
>> > > >>> 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
>> > > >>>
>> > > >
>> > >
>> >
>>

Re: Updating plugin code on prepare

[Michal Mocny <mm...@chromium.org>]

Braden, thats has been on the wish list (cordova watch), but I suspect Anis
was suggesting something different with plugman --watch, to do specifically
with plugin development.  Am I right, Anis?  How does your idea compare
with using --link with cordova watch?  Would plugman --watch be useful for
non cli projects?

-Michal


On Wed, Sep 25, 2013 at 10:31 AM, Braden Shepherdson <br...@chromium.org>wrote:

> We've had a vague feature planned for a while now to do a cordova watch. It
> would watch your plugins/, www/, and merges/* for any changes. If any
> changes are detected, it would re-run cordova prepare, so that your native
> projects are always up-to-date.
>
> I'm open to checking (hashes?) which files have changed and which have not,
> but hashing them all is touching them all anyway, and it might be faster
> for small files to just copy them instead of checking first. We'll have to
> try it and see; for v1 I'm going with the simple option of copying
> everything.
>
> Braden
>
>
> On Wed, Sep 25, 2013 at 9:44 AM, Michal Mocny <mm...@chromium.org> wrote:
>
> > The idea for plugin dev outside of plugins/ folder was to use "plugin add
> > --link".  Matter of fact, braden suggested that "plugin create" should
> > default to --link-ing to some external location so that you don't risk
> > deleting your only copy inside plugins/.  (I personally don't think
> thats a
> > necessary concern, but I think its a conversation for later).
> >
> > I'm not even sure what a 'watch' would do, just uninstall & install each
> > time the plugin changes?  I think that ends up being just slightly worse
> > than the current proposal if you factor in that we already do support
> > --link (except without the above change its been useless).
> >
> >
> > However, we may still want some form of 'watch' command for devs using
> > plugman directly.  I had assumed that those devs just edit in place,
> since
> > they don't use a prepare step anyway.
> >
> > -Michal
> >
> >
> >
> > On Wed, Sep 25, 2013 at 7:50 AM, Anis KADRI <an...@gmail.com>
> wrote:
> >
> > > If we're talking about developing plugins inside the
> > > plugins/org.myplugin.id folder than I think it's a great workflow and
> > > I would just hide the cached version of plugin.xml inside that
> > > plugins/org.myplugin.id folder.
> > >
> > > However, if you're developing a plugin outside of a cordova CLI
> > > project, I think a `watch` (and add --watch) command is more
> > > appropriate. One of the reasons you would develop a plugin outside of
> > > a cordova CLI project is for easier version control (each plugin would
> > > have its own repository). The other cool thing about `watch` is that
> > > it would copy the files that have actually changed and not everything
> > > (some plugins have a LOT of files [1]).
> > >
> > > [1] https://github.com/phonegap/phonegap-facebook-plugin
> > >
> > > On Wed, Sep 25, 2013 at 3:30 AM, James Jong <wj...@gmail.com>
> > wrote:
> > > > +1 This is a cleaner workflow and should reduce some confusion.
> > > >
> > > > -James Jong
> > > >
> > > > On Sep 24, 2013, at 3:09 PM, Michal Mocny <mm...@chromium.org>
> wrote:
> > > >
> > > >> Just to add, the reason for the "if" statement in step (2) is that
> > > >> uninstall & reinstall take a lot longer than just moving a few
> files,
> > > which
> > > >> is the 99.9% case for most end users who aren't making modifications
> > to
> > > >> plugins.
> > > >>
> > > >> This way, we only do the heavy lifting if your plugin structure
> > actually
> > > >> changed.  Doing it automatically means we no longer have to advise
> > users
> > > >> that making edits inside plugin/ folder is useless.  Now we just
> > advise
> > > >> them to run "prepare" after making changes to either www/ or
> plugins/.
> > > >>
> > > >> This key insight was Braden's idea and I think its just an awesome
> > > change
> > > >> for workflow.
> > > >>
> > > >> -Michal
> > > >>
> > > >>
> > > >> On Tue, Sep 24, 2013 at 2:58 PM, Braden Shepherdson <
> > > braden@chromium.org>wrote:
> > > >>
> > > >>> 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
> > > >>>
> > > >
> > >
> >
>

Re: Updating plugin code on prepare

[Braden Shepherdson <br...@chromium.org>]

We've had a vague feature planned for a while now to do a cordova watch. It
would watch your plugins/, www/, and merges/* for any changes. If any
changes are detected, it would re-run cordova prepare, so that your native
projects are always up-to-date.

I'm open to checking (hashes?) which files have changed and which have not,
but hashing them all is touching them all anyway, and it might be faster
for small files to just copy them instead of checking first. We'll have to
try it and see; for v1 I'm going with the simple option of copying
everything.

Braden


On Wed, Sep 25, 2013 at 9:44 AM, Michal Mocny <mm...@chromium.org> wrote:

> The idea for plugin dev outside of plugins/ folder was to use "plugin add
> --link".  Matter of fact, braden suggested that "plugin create" should
> default to --link-ing to some external location so that you don't risk
> deleting your only copy inside plugins/.  (I personally don't think thats a
> necessary concern, but I think its a conversation for later).
>
> I'm not even sure what a 'watch' would do, just uninstall & install each
> time the plugin changes?  I think that ends up being just slightly worse
> than the current proposal if you factor in that we already do support
> --link (except without the above change its been useless).
>
>
> However, we may still want some form of 'watch' command for devs using
> plugman directly.  I had assumed that those devs just edit in place, since
> they don't use a prepare step anyway.
>
> -Michal
>
>
>
> On Wed, Sep 25, 2013 at 7:50 AM, Anis KADRI <an...@gmail.com> wrote:
>
> > If we're talking about developing plugins inside the
> > plugins/org.myplugin.id folder than I think it's a great workflow and
> > I would just hide the cached version of plugin.xml inside that
> > plugins/org.myplugin.id folder.
> >
> > However, if you're developing a plugin outside of a cordova CLI
> > project, I think a `watch` (and add --watch) command is more
> > appropriate. One of the reasons you would develop a plugin outside of
> > a cordova CLI project is for easier version control (each plugin would
> > have its own repository). The other cool thing about `watch` is that
> > it would copy the files that have actually changed and not everything
> > (some plugins have a LOT of files [1]).
> >
> > [1] https://github.com/phonegap/phonegap-facebook-plugin
> >
> > On Wed, Sep 25, 2013 at 3:30 AM, James Jong <wj...@gmail.com>
> wrote:
> > > +1 This is a cleaner workflow and should reduce some confusion.
> > >
> > > -James Jong
> > >
> > > On Sep 24, 2013, at 3:09 PM, Michal Mocny <mm...@chromium.org> wrote:
> > >
> > >> Just to add, the reason for the "if" statement in step (2) is that
> > >> uninstall & reinstall take a lot longer than just moving a few files,
> > which
> > >> is the 99.9% case for most end users who aren't making modifications
> to
> > >> plugins.
> > >>
> > >> This way, we only do the heavy lifting if your plugin structure
> actually
> > >> changed.  Doing it automatically means we no longer have to advise
> users
> > >> that making edits inside plugin/ folder is useless.  Now we just
> advise
> > >> them to run "prepare" after making changes to either www/ or plugins/.
> > >>
> > >> This key insight was Braden's idea and I think its just an awesome
> > change
> > >> for workflow.
> > >>
> > >> -Michal
> > >>
> > >>
> > >> On Tue, Sep 24, 2013 at 2:58 PM, Braden Shepherdson <
> > braden@chromium.org>wrote:
> > >>
> > >>> 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
> > >>>
> > >
> >
>

Re: Updating plugin code on prepare

[Michal Mocny <mm...@chromium.org>]

The idea for plugin dev outside of plugins/ folder was to use "plugin add
--link".  Matter of fact, braden suggested that "plugin create" should
default to --link-ing to some external location so that you don't risk
deleting your only copy inside plugins/.  (I personally don't think thats a
necessary concern, but I think its a conversation for later).

I'm not even sure what a 'watch' would do, just uninstall & install each
time the plugin changes?  I think that ends up being just slightly worse
than the current proposal if you factor in that we already do support
--link (except without the above change its been useless).


However, we may still want some form of 'watch' command for devs using
plugman directly.  I had assumed that those devs just edit in place, since
they don't use a prepare step anyway.

-Michal



On Wed, Sep 25, 2013 at 7:50 AM, Anis KADRI <an...@gmail.com> wrote:

> If we're talking about developing plugins inside the
> plugins/org.myplugin.id folder than I think it's a great workflow and
> I would just hide the cached version of plugin.xml inside that
> plugins/org.myplugin.id folder.
>
> However, if you're developing a plugin outside of a cordova CLI
> project, I think a `watch` (and add --watch) command is more
> appropriate. One of the reasons you would develop a plugin outside of
> a cordova CLI project is for easier version control (each plugin would
> have its own repository). The other cool thing about `watch` is that
> it would copy the files that have actually changed and not everything
> (some plugins have a LOT of files [1]).
>
> [1] https://github.com/phonegap/phonegap-facebook-plugin
>
> On Wed, Sep 25, 2013 at 3:30 AM, James Jong <wj...@gmail.com> wrote:
> > +1 This is a cleaner workflow and should reduce some confusion.
> >
> > -James Jong
> >
> > On Sep 24, 2013, at 3:09 PM, Michal Mocny <mm...@chromium.org> wrote:
> >
> >> Just to add, the reason for the "if" statement in step (2) is that
> >> uninstall & reinstall take a lot longer than just moving a few files,
> which
> >> is the 99.9% case for most end users who aren't making modifications to
> >> plugins.
> >>
> >> This way, we only do the heavy lifting if your plugin structure actually
> >> changed.  Doing it automatically means we no longer have to advise users
> >> that making edits inside plugin/ folder is useless.  Now we just advise
> >> them to run "prepare" after making changes to either www/ or plugins/.
> >>
> >> This key insight was Braden's idea and I think its just an awesome
> change
> >> for workflow.
> >>
> >> -Michal
> >>
> >>
> >> On Tue, Sep 24, 2013 at 2:58 PM, Braden Shepherdson <
> braden@chromium.org>wrote:
> >>
> >>> 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
> >>>
> >
>

Re: Updating plugin code on prepare

[Anis KADRI <an...@gmail.com>]

If we're talking about developing plugins inside the
plugins/org.myplugin.id folder than I think it's a great workflow and
I would just hide the cached version of plugin.xml inside that
plugins/org.myplugin.id folder.

However, if you're developing a plugin outside of a cordova CLI
project, I think a `watch` (and add --watch) command is more
appropriate. One of the reasons you would develop a plugin outside of
a cordova CLI project is for easier version control (each plugin would
have its own repository). The other cool thing about `watch` is that
it would copy the files that have actually changed and not everything
(some plugins have a LOT of files [1]).

[1] https://github.com/phonegap/phonegap-facebook-plugin

On Wed, Sep 25, 2013 at 3:30 AM, James Jong <wj...@gmail.com> wrote:
> +1 This is a cleaner workflow and should reduce some confusion.
>
> -James Jong
>
> On Sep 24, 2013, at 3:09 PM, Michal Mocny <mm...@chromium.org> wrote:
>
>> Just to add, the reason for the "if" statement in step (2) is that
>> uninstall & reinstall take a lot longer than just moving a few files, which
>> is the 99.9% case for most end users who aren't making modifications to
>> plugins.
>>
>> This way, we only do the heavy lifting if your plugin structure actually
>> changed.  Doing it automatically means we no longer have to advise users
>> that making edits inside plugin/ folder is useless.  Now we just advise
>> them to run "prepare" after making changes to either www/ or plugins/.
>>
>> This key insight was Braden's idea and I think its just an awesome change
>> for workflow.
>>
>> -Michal
>>
>>
>> On Tue, Sep 24, 2013 at 2:58 PM, Braden Shepherdson <br...@chromium.org>wrote:
>>
>>> 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
>>>
>

Re: Updating plugin code on prepare

[James Jong <wj...@gmail.com>]

+1 This is a cleaner workflow and should reduce some confusion.

-James Jong

On Sep 24, 2013, at 3:09 PM, Michal Mocny <mm...@chromium.org> wrote:

> Just to add, the reason for the "if" statement in step (2) is that
> uninstall & reinstall take a lot longer than just moving a few files, which
> is the 99.9% case for most end users who aren't making modifications to
> plugins.
> 
> This way, we only do the heavy lifting if your plugin structure actually
> changed.  Doing it automatically means we no longer have to advise users
> that making edits inside plugin/ folder is useless.  Now we just advise
> them to run "prepare" after making changes to either www/ or plugins/.
> 
> This key insight was Braden's idea and I think its just an awesome change
> for workflow.
> 
> -Michal
> 
> 
> On Tue, Sep 24, 2013 at 2:58 PM, Braden Shepherdson <br...@chromium.org>wrote:
> 
>> 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
>> 

Re: Updating plugin code on prepare

[Michal Mocny <mm...@chromium.org>]

Just to add, the reason for the "if" statement in step (2) is that
uninstall & reinstall take a lot longer than just moving a few files, which
is the 99.9% case for most end users who aren't making modifications to
plugins.

This way, we only do the heavy lifting if your plugin structure actually
changed.  Doing it automatically means we no longer have to advise users
that making edits inside plugin/ folder is useless.  Now we just advise
them to run "prepare" after making changes to either www/ or plugins/.

This key insight was Braden's idea and I think its just an awesome change
for workflow.

-Michal


On Tue, Sep 24, 2013 at 2:58 PM, Braden Shepherdson <br...@chromium.org>wrote:

> 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
>