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 <msie...@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 [twil...@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 <anis.ka...@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 <mmo...@chromium.org> > wrote: > >> On Thu, Sep 26, 2013 at 1:39 PM, Jesse <purplecabb...@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.ka...@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 < > >>> bra...@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.ka...@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 <mmo...@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 < > >>>>>>> bra...@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 < > >>> mmo...@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.ka...@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 < > >>>>> wjamesj...@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 < > >>>> mmo...@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 < > >>>>>>>>>>> bra...@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 > >>>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>> > >>>>> > >>>> > >>> >
