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