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