Return-Path: X-Original-To: apmail-cordova-dev-archive@www.apache.org Delivered-To: apmail-cordova-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 3985C10B29 for ; Sun, 29 Sep 2013 17:44:02 +0000 (UTC) Received: (qmail 61958 invoked by uid 500); 29 Sep 2013 17:44:01 -0000 Delivered-To: apmail-cordova-dev-archive@cordova.apache.org Received: (qmail 61911 invoked by uid 500); 29 Sep 2013 17:43:56 -0000 Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cordova.apache.org Delivered-To: mailing list dev@cordova.apache.org Received: (qmail 61903 invoked by uid 99); 29 Sep 2013 17:43:55 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 29 Sep 2013 17:43:55 +0000 X-ASF-Spam-Status: No, hits=1.7 required=5.0 tests=FREEMAIL_ENVFROM_END_DIGIT,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of csantana23@gmail.com designates 74.125.82.182 as permitted sender) Received: from [74.125.82.182] (HELO mail-we0-f182.google.com) (74.125.82.182) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 29 Sep 2013 17:43:45 +0000 Received: by mail-we0-f182.google.com with SMTP id q59so4573186wes.41 for ; Sun, 29 Sep 2013 10:43:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=EVoNAPLCCf/ifqvCV5vaifc7LCv4pXuAKYlbIzjkLps=; b=PRZPG4pYvDiu4SrmzE3B49GyCe4GY1yW20FG/RuJpe4/wZqILaFDtOh9BjGuLabGYp +Ndpw4GSQxCks2wokb7HwRn1P/UEGhaEnfE34VS7hQPq49S6LrVQnXj/ON8eh8f9Fgdp D+PbYa+etA4nBaSKroI6YElrDLQQ5w24fCC+lxqo6K656zEcn6dQkppsdKdJqoNwluqG H5ps8sB3AVq5D43Fz6uJ/5NJxnmLIM0L8lEcVOYUaLLYJH1K1TcXXTU+u8kRMenm2LU5 SdQ1FDGuQ+wMBrC+FYE9PYJRlDsSn9lSlvrVuvZhJVBjSlKxvWYdR+aPq6XhGXjdjH31 yP/Q== MIME-Version: 1.0 X-Received: by 10.180.73.134 with SMTP id l6mr10544495wiv.16.1380476604942; Sun, 29 Sep 2013 10:43:24 -0700 (PDT) Received: by 10.194.39.36 with HTTP; Sun, 29 Sep 2013 10:43:24 -0700 (PDT) In-Reply-To: References: <65F0E694-2BAD-430D-AD36-884087C520AC@gmail.com> <35C02676BF7FD84F92417E42E09DD8DCBD0134D34B@nambx08.corp.adobe.com> Date: Sun, 29 Sep 2013 13:43:24 -0400 Message-ID: Subject: Re: Updating plugin code on prepare From: Carlos Santana To: "dev@cordova.apache.org" Content-Type: multipart/alternative; boundary=f46d043d673fa890fe04e789415c X-Virus-Checked: Checked by ClamAV on apache.org --f46d043d673fa890fe04e789415c Content-Type: text/plain; charset=ISO-8859-1 +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 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 wrote: > > On Fri, Sep 27, 2013 at 2:10 PM, Andrew Grieve > 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 > 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 < > braden@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 < > agrieve@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 < > msierra@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 [twilson@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-anditappearsitonly 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 > >> > 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 < > >> mmocny@chromium.org > >> > > > >> > > > > wrote: > >> > > > > >> On Thu, Sep 26, 2013 at 1:39 PM, Jesse < > purplecabbage@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 > >> > wrote: > >> > > > > >>> > >> > > > > >>>> I love the idea of a watch command. > >> > > > > >>>> > >> > > > > >>>> > >> > > > > >>>> On Thu, Sep 26, 2013 at 4:48 PM, Anis KADRI < > >> > anis.kadri@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 < > >> > > > > >>> braden@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.kadri@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 < > >> > > > mmocny@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 < > >> > > > > >>>>>>> braden@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 < > >> > > > > >>> mmocny@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.kadri@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 < > >> > > > > >>>>> wjamesjong@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 < > >> > > > > >>>> mmocny@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 < > >> > > > > >>>>>>>>>>> braden@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 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 --f46d043d673fa890fe04e789415c--