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 <bra...@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 <agri...@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 <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-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 <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 > > > >>>>>>>>>>>>>> > > > >>>>>>>>>>>> > > > >>>>>>>>>>> > > > >>>>>>>>>> > > > >>>>>>>>> > > > >>>>>>> > > > >>>>> > > > >>>> > > > >>> > > > > > >
