And one more data point I think worth mentioning: I just went to the main Cordova site, clicked the top Download button, it took me to the Download & Archive section, and I downloaded the source.zip. I opened it up and it is just a folder full of zip files, including the zips for each plugin.
Now I know how to create a project for each platform the old bin/create way, but then it is unclear how to use the plugins. I looked in the console plugin and the README.md file says to read the "Using Plugman to Manage Plugins" with a URL of "http://cordova.apache.org/docs/en/edge/guide_plugin_ref_plugman.md.html"; which does not point to anything. Perhaps a note in the download that people that want the non-CLI version should download the 2.9.0 version, which as I recall still contains the core plugins people might need/want. Thanks, Tyler On Sep 26, 2013, at 8:19 PM, Tyler Wilson <twil...@pulse-robotics.com> wrote: > 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 > - and it appears it only mentions the new CLI interface. No mention of the > old bin/create method. Seems to me there may be communication problem here. > > Thanks, > Tyler > > On Sep 26, 2013, at 6:11 PM, Anis KADRI <anis.ka...@gmail.com> wrote: > >> @purplecabbage: I have the same workflow but I think the proposed >> solution is a step in the right direction. It would allow us to easily >> develop platform plugins without having to delete project/create >> project/install plugin/uninstall plugin constantly. The plugin would >> be packaged (plugin.xml) from day 1 and one can only focus on >> development. >> >> As far as IDEs, the answer is simple. You should not use IDEs and >> cordova-cli at the same time. Until IDEs are aware of cordova-cli >> there is no point in creating projects with cordova-cli because >> everything gets blown on every build. I am not even sure we can make >> Xcode aware of cordova-cli. We've already talked about this prior to >> the 3.0 release and that is why we have the create scripts and plugman >> approach. You should not be using cordova-cli either if you're doing >> some custom native dev that can't be pluginized (changing the main >> Activity.java or AppDelegate.m or whatever). If you're using >> cordova-cli just to create a project and then open an IDE to develop, >> you're probably doing it wrong. You should be creating a native >> project and using plugman instead. >> >> On Thu, Sep 26, 2013 at 9:01 PM, Michal Mocny <mmo...@chromium.org> wrote: >>> On Thu, Sep 26, 2013 at 1:39 PM, Jesse <purplecabb...@gmail.com> wrote: >>> >>>> What does a watch mean? >>>> - if I reboot, is it still watched? >>>> >>> >>> No, this would start a process that lives until you CTRL+C. You could have >>> it run it in the background, or set it to start of startup, but that would >>> be using local system tools, not part of the command itself. >>> >>> Ideally, "watch" should run "prepare" whenever you would have wanted it to. >>> Though obviously that cannot be perfect, it can be a useful tool when >>> iterating. >>> >>> >>>> >>>> I think it would be best to consider separating development from packaging >>>> in your use-case for workflow. >>>> If I am going to develop featureX as a plugin I would : >>>> >>>> 1. create a project for a single cordova platform, and develop the feature >>>> as a native piece, and a js piece. >>>> 2. test thoroughly >>>> 3. create a project for a second cordova platform, and develop the native >>>> bit, preserving the js from 1 >>>> 4. test thoroughly >>>> 5. repeat steps 3+4 for any remaining platforms >>>> 6. package featureX as a plugin by organizing relevant bits in the correct >>>> folder structure, and adding a plugin.xml >>>> 7. test each platform by installing with plugman >>>> 8. publish >>>> >>> >>> As a plugin developer, that is not my workflow. >>> >>> Typically for me its: >>> >>> Write a sample app/manual test for some new feature that isn't implemented >>> yet. >>> Create a new plugin Foo for iOS & Android, and stub the implementation. >>> Implement feature A of plugin Foo for iOS, test, add it for Android, test. >>> Implement feature B of plugin Foo for iOS, test, add it for Android, test. >>> ... >>> >>> Usually the js implementation is shared, the auto tests are shared, and the >>> sample test app is shared. >>> >>> Sure, I do platform specific stuff for testing and implementation, but I >>> certainly wouldn't say I do plugin development in platform isolation. >>> >>> Also, right now we do not have a "plugin create" command, and so leaving >>> the "packaging" step for last doesn't add affect total work. But once we >>> do have such a command, plugins could start packaged, and adding the small >>> changes to plugin.xml as you need them is likely a good way to go. >>> >>> Finally, this workflow would get people out of the habit of making changes >>> to the platform artifacts directly. I'm not sure that can be entirely >>> avoided in all cases, but why shouldn't we work towards making that easier? >>> >>> >>>> We seem to have this notion come up repeatedly that our users + plugin >>>> developers are working on multiple platforms at the same time, which I >>>> think is entirely false. >>>> >>> >>> Since we differ in opinion, how can we put this to the test? >>> >>> Also, we specifically make sure all our features address the needs of those >>> doing single platform development, so in a world of 3.0+ cli, I really >>> don't see how we can not do the same to address the needs of those who do >>> do multi-platform development, especially when we have a good proposal of >>> how to do so and someone willing to do it. >>> >>> >>>> I also think we're trying to help the wrong people; If I am a developer who >>>> is working on multiple platforms at once, and I have a bunch of devices >>>> attached, I probably also have the skills to set up my own grunt continuous >>>> integration system. Setting up tooling for potential plugin developers is >>>> the wrong approach, imho. We should actually just go and implement some new >>>> plugin and evaluate the process instead of creating and imposing a specific >>>> workflow. >>>> >>> >>> The first part of this argument has some merit, I agree. We the >>> power-users have found ways to address our problems. However, I think that >>> with this change it means that even the end user can make changes to plugin >>> folder as they find bugs/etc, and expect to see the change reflected after >>> running prepare. This is principle of least surprise, and just good design. >>> >>> I also don't think we are imposing any specific workflow here, just >>> enabling a new one. Personally I think that its quite surprising and >>> embarrassing that we haven't enabled this workflow since 3.0. >>> >>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> @purplecabbage >>>> risingj.com >>>> >>>> >>>> On Thu, Sep 26, 2013 at 10:09 AM, Brian LeRoux <b...@brian.io> wrote: >>>> >>>>> I love the idea of a watch command. >>>>> >>>>> >>>>> On Thu, Sep 26, 2013 at 4:48 PM, Anis KADRI <anis.ka...@gmail.com> >>>> wrote: >>>>> >>>>>> Forgot about the existence of --link for a second. I think this is a >>>>>> good solution (not temporary). watch can be an enhancement to this >>>>>> solution. This might get people like Joe Bowser and other people who >>>>>> do native dev to give cordova-cli a try (only maybe though). >>>>>> >>>>>> On Thu, Sep 26, 2013 at 4:25 PM, Braden Shepherdson < >>>> bra...@chromium.org >>>>>> >>>>>> wrote: >>>>>>> If the proposal above is temporary, what's permanent? cordova watch? >>>> I >>>>>> want >>>>>>> to make sure we're on the same page. >>>>>>> >>>>>>> Braden >>>>>>> >>>>>>> >>>>>>> On Thu, Sep 26, 2013 at 6:08 AM, Anis KADRI <anis.ka...@gmail.com> >>>>>> wrote: >>>>>>> >>>>>>>> No I didn't mean implement `plugman --watch`. I don't think plugman >>>>>>>> needs a `watch` command. >>>>>>>> >>>>>>>> I was indeed talking about `cordova watch` which should watch for >>>>>>>> changes in plugins/ (and maybe in merges/ and www/ as well) and >>>> update >>>>>>>> the platform projects (prepare?) on every change. I am happy to >>>> know >>>>>>>> that it's on the wish list. >>>>>>>> >>>>>>>> As far as the original proposal, I believe it is a descent temporary >>>>>>>> solution for plugin developers who want to use cordova-cli. >>>>>>>> >>>>>>>> On Wed, Sep 25, 2013 at 7:17 PM, Michal Mocny <mmo...@chromium.org> >>>>>> wrote: >>>>>>>>> Braden, thats has been on the wish list (cordova watch), but I >>>>> suspect >>>>>>>> Anis >>>>>>>>> was suggesting something different with plugman --watch, to do >>>>>>>> specifically >>>>>>>>> with plugin development. Am I right, Anis? How does your idea >>>>>> compare >>>>>>>>> with using --link with cordova watch? Would plugman --watch be >>>>> useful >>>>>>>> for >>>>>>>>> non cli projects? >>>>>>>>> >>>>>>>>> -Michal >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Sep 25, 2013 at 10:31 AM, Braden Shepherdson < >>>>>>>> bra...@chromium.org>wrote: >>>>>>>>> >>>>>>>>>> We've had a vague feature planned for a while now to do a cordova >>>>>>>> watch. It >>>>>>>>>> would watch your plugins/, www/, and merges/* for any changes. If >>>>> any >>>>>>>>>> changes are detected, it would re-run cordova prepare, so that >>>> your >>>>>>>> native >>>>>>>>>> projects are always up-to-date. >>>>>>>>>> >>>>>>>>>> I'm open to checking (hashes?) which files have changed and which >>>>>> have >>>>>>>> not, >>>>>>>>>> but hashing them all is touching them all anyway, and it might be >>>>>> faster >>>>>>>>>> for small files to just copy them instead of checking first. >>>> We'll >>>>>> have >>>>>>>> to >>>>>>>>>> try it and see; for v1 I'm going with the simple option of >>>> copying >>>>>>>>>> everything. >>>>>>>>>> >>>>>>>>>> Braden >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Wed, Sep 25, 2013 at 9:44 AM, Michal Mocny < >>>> mmo...@chromium.org >>>>>> >>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> The idea for plugin dev outside of plugins/ folder was to use >>>>>> "plugin >>>>>>>> add >>>>>>>>>>> --link". Matter of fact, braden suggested that "plugin create" >>>>>> should >>>>>>>>>>> default to --link-ing to some external location so that you >>>> don't >>>>>> risk >>>>>>>>>>> deleting your only copy inside plugins/. (I personally don't >>>>> think >>>>>>>>>> thats a >>>>>>>>>>> necessary concern, but I think its a conversation for later). >>>>>>>>>>> >>>>>>>>>>> I'm not even sure what a 'watch' would do, just uninstall & >>>>> install >>>>>>>> each >>>>>>>>>>> time the plugin changes? I think that ends up being just >>>>> slightly >>>>>>>> worse >>>>>>>>>>> than the current proposal if you factor in that we already do >>>>>> support >>>>>>>>>>> --link (except without the above change its been useless). >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> However, we may still want some form of 'watch' command for >>>> devs >>>>>> using >>>>>>>>>>> plugman directly. I had assumed that those devs just edit in >>>>>> place, >>>>>>>>>> since >>>>>>>>>>> they don't use a prepare step anyway. >>>>>>>>>>> >>>>>>>>>>> -Michal >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Wed, Sep 25, 2013 at 7:50 AM, Anis KADRI < >>>>> anis.ka...@gmail.com> >>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> If we're talking about developing plugins inside the >>>>>>>>>>>> plugins/org.myplugin.id folder than I think it's a great >>>>>> workflow >>>>>>>> and >>>>>>>>>>>> I would just hide the cached version of plugin.xml inside >>>> that >>>>>>>>>>>> plugins/org.myplugin.id folder. >>>>>>>>>>>> >>>>>>>>>>>> However, if you're developing a plugin outside of a cordova >>>> CLI >>>>>>>>>>>> project, I think a `watch` (and add --watch) command is more >>>>>>>>>>>> appropriate. One of the reasons you would develop a plugin >>>>>> outside >>>>>>>> of >>>>>>>>>>>> a cordova CLI project is for easier version control (each >>>>> plugin >>>>>>>> would >>>>>>>>>>>> have its own repository). The other cool thing about `watch` >>>> is >>>>>> that >>>>>>>>>>>> it would copy the files that have actually changed and not >>>>>>>> everything >>>>>>>>>>>> (some plugins have a LOT of files [1]). >>>>>>>>>>>> >>>>>>>>>>>> [1] https://github.com/phonegap/phonegap-facebook-plugin >>>>>>>>>>>> >>>>>>>>>>>> On Wed, Sep 25, 2013 at 3:30 AM, James Jong < >>>>>> wjamesj...@gmail.com> >>>>>>>>>>> wrote: >>>>>>>>>>>>> +1 This is a cleaner workflow and should reduce some >>>>> confusion. >>>>>>>>>>>>> >>>>>>>>>>>>> -James Jong >>>>>>>>>>>>> >>>>>>>>>>>>> On Sep 24, 2013, at 3:09 PM, Michal Mocny < >>>>> mmo...@chromium.org >>>>>>> >>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Just to add, the reason for the "if" statement in step (2) >>>>> is >>>>>>>> that >>>>>>>>>>>>>> uninstall & reinstall take a lot longer than just moving a >>>>> few >>>>>>>>>> files, >>>>>>>>>>>> which >>>>>>>>>>>>>> is the 99.9% case for most end users who aren't making >>>>>>>> modifications >>>>>>>>>>> to >>>>>>>>>>>>>> plugins. >>>>>>>>>>>>>> >>>>>>>>>>>>>> This way, we only do the heavy lifting if your plugin >>>>>> structure >>>>>>>>>>> actually >>>>>>>>>>>>>> changed. Doing it automatically means we no longer have >>>> to >>>>>>>> advise >>>>>>>>>>> users >>>>>>>>>>>>>> that making edits inside plugin/ folder is useless. Now >>>> we >>>>>> just >>>>>>>>>>> advise >>>>>>>>>>>>>> them to run "prepare" after making changes to either www/ >>>> or >>>>>>>>>> plugins/. >>>>>>>>>>>>>> >>>>>>>>>>>>>> This key insight was Braden's idea and I think its just an >>>>>>>> awesome >>>>>>>>>>>> change >>>>>>>>>>>>>> for workflow. >>>>>>>>>>>>>> >>>>>>>>>>>>>> -Michal >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Tue, Sep 24, 2013 at 2:58 PM, Braden Shepherdson < >>>>>>>>>>>> bra...@chromium.org>wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Michal and I were discussing how to make the plugin >>>>> developer >>>>>>>>>>>> experience >>>>>>>>>>>>>>> better, by having `cordova prepare` update the platform >>>>>> projects >>>>>>>>>>>> properly >>>>>>>>>>>>>>> when you change a plugin in place. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I propose the following changes: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 1. On plugin install, we cache the plugin.xml in >>>>>>>> $PROJECT/.cordova >>>>>>>>>>>>>>> somewhere. >>>>>>>>>>>>>>> 2. On 'cordova prepare', compare each plugin's plugin.xml >>>>>>>> against >>>>>>>>>> the >>>>>>>>>>>>>>> cached one. >>>>>>>>>>>>>>> a. If they have changed, uninstall the plugin using >>>> the >>>>>> old >>>>>>>>>>>> plugin.xml, >>>>>>>>>>>>>>> then reinstall using the new one (and update the cached >>>>>>>>>> plugin.xml). >>>>>>>>>>>>>>> b. If they are identical, copy all the native code >>>> files >>>>>> from >>>>>>>>>> the >>>>>>>>>>>>>>> plugin into the project again. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The idea is that you can change your plugin's native >>>> code, >>>>> JS >>>>>>>>>>> modules, >>>>>>>>>>>> or >>>>>>>>>>>>>>> assets, and after a prepare you'll be running the latest. >>>>> We >>>>>>>>>> already >>>>>>>>>>>> have >>>>>>>>>>>>>>> cordova plugin add foo --link, but it wasn't very useful. >>>>>> This >>>>>>>> will >>>>>>>>>>>> make >>>>>>>>>>>>>>> plugin development a much smoother flow, without too much >>>>>>>>>>>> implementation >>>>>>>>>>>>>>> effort. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Checking for changes to plugin.xml lets us know that no >>>>> files >>>>>>>> have >>>>>>>>>>> been >>>>>>>>>>>>>>> added or removed, that <config-file> edits haven't >>>> changed, >>>>>> and >>>>>>>> so >>>>>>>>>>> on, >>>>>>>>>>>>>>> meaning that simply copying the native code again will be >>>>>>>>>> sufficient. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> What do people think? Any gotchas that I overlooked? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Braden >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>> >>>>> >>>> >
