This feature has not received any work yet, largely because I was away most of last week. It will land in 3.2, or possibly earlier - CLI releases are not tied to Cordova releases.
Braden On Mon, Oct 7, 2013 at 10:57 AM, Michael Gauthier <m...@silverorange.com>wrote: > Did this feature land in 3.1.0 or is it targeted for 3.2.0? > > On 2013-10-03 11:30, Michal Mocny 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<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 >>>> >>>>
