+1!
On Thu, Oct 3, 2013 at 4:30 PM, Michal Mocny <mmo...@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 > <bra...@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 <csantan...@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 <anis.ka...@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 <mmo...@chromium.org> >> > wrote: >> > > > On Fri, Sep 27, 2013 at 2:10 PM, Andrew Grieve <agri...@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 <mmo...@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 < >> > > 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-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.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 >> > > >> > > > > >>>>>>>>>>>>>> >> > > >> > > > > >>>>>>>>>>>> >> > > >> > > > > >>>>>>>>>>> >> > > >> > > > > >>>>>>>>>> >> > > >> > > > > >>>>>>>>> >> > > >> > > > > >>>>>>> >> > > >> > > > > >>>>> >> > > >> > > > > >>>> >> > > >> > > > > >>> >> > > >> > > > > >> > > >> > > > >> > > >> > > >> > > >> > >> > > >> >> > > >> > >> > >> > >> > -- >> > Carlos Santana >> > <csantan...@gmail.com> >> > >>
