+1 I am surprised that once a plugin has been added to ./platforms/**/* it is never refreshed from the version in ./plugins/**/*
It means that plugin dev has to happen in ./platforms instead of in ./plugins at the very least. If I could create a plugin or even add a scaffold of a plugin to ./plugins and then edit it there and have it get refreshed into my platform when I build that would be a great start. Having said all that, I personally love the cli with all my heart because it means I almost never have to open Xcode or Eclipse… but when working on a plugin, native debugging tools can be a must, so I need to open them anyway… so maybe having to work within ./platforms isn't as bad as it sounds… :| On 03/09/2013, at 9:34 AM, Brian LeRoux <b...@brian.io> wrote: > So, first of all I agree, this is probably the ideal flow today. A good > reason for this list is to figure out how we can make the best possible > developer experience going forward. With the Discovery side of things all > but deployed I'd love for us to look at making this part a little more sane > for our dev community. > > Here's a shot. Ideal flow tomorrow might be to generate a plugin called, > lets say, "Echo" that matches something we'd find in our docs, automate > add/remove with some sort of watch command. That way ppl are writing to the > plugin spec from the beginning instead of refactoring a plugin out of a > native project. > > Thoughts? > > > > On Fri, Aug 30, 2013 at 2:03 PM, Anis KADRI <anis.ka...@gmail.com> wrote: > >> Neither CLI nor plugman (at least while developing). >> >> I would create a project using our platform scripts and develop my >> plugin in that project workspace and when I feel that my plugin is >> ready that I will create a plugin.xml and test it out with plugman and >> CLI and then publish it. >> >> plugman automates plugin installation but I don't think it adds any >> real benefits to plugin authors. >> CLI automates cross-platform project management but I don't think it >> adds any real benefits for plugin authors either. Unless we're talking >> about javascript only plugins, in which case you just work on your >> www/ folder and test out things with CLI commands. For plugins that >> require native bits you have to re-add it every time since your >> platforms/ folder gets blown away on every build. That is why I said >> it's not ideal. >> >> That is how I roll but I don't expect or advise anybody to do the same. >> >> On Fri, Aug 30, 2013 at 1:16 PM, Brian LeRoux <b...@brian.io> wrote: >>> Pls explain. >>> On Aug 30, 2013 12:45 PM, "Anis KADRI" <anis.ka...@gmail.com> wrote: >>> >>>> I wouldn't use cordova-cli if I were to develop a plugin. I don't >>>> think the workflow is ideal. >>>> >>>> On Fri, Aug 30, 2013 at 6:47 AM, Michal Mocny <mmo...@chromium.org> >> wrote: >>>>> I am interpreting your concern in two different ways, so I'll clarify >> my >>>>> assumption and answer both: >>>>> >>>>> ------------------ >>>>> >>>>> Interpretation (1): You want to develop a new plugin, and find it >> hard to >>>>> find the right files to track inside a cli created workspace. >>>>> >>>>> If you want to "develop some feature or plugin", I suggest you do not >>>> first >>>>> create a project in the cli and try to write your plugin directly >> inside >>>>> there manually. >>>>> >>>>> Instead, create a new plugin using the plugin dev guide[1] and >> spec[2], >>>>> creating it in a separate folder/repo. It seems we don't have a great >>>>> "overview" page about how to create a plugin directory structure. >> I'll >>>> see >>>>> about adding that, but for now, just consult another plugin structure, >>>> such >>>>> as cordova-plugin-device[3]. >>>>> >>>>> Once you've started writing your plugin, and have at least the bare >> bones >>>>> structure, create a cli project to consume it: >>>>> >>>>> cordova create App ... && cd App >>>>> cordova platform add ... >>>>> cordova plugin add PATH_TO_YOUR_LOCAL_PLUGIN >>>>> cordova prepare >>>>> ... >>>>> >>>>> Now, every time you make changes to *the original* plugin, you'll >> need to >>>>> re-add it from source: >>>>> >>>>> cordova plugin add PATH_TO_YOUR_LOCAL_PLUGIN // Doing this should >>>>> overwrite the old version >>>>> cordova prepare >>>>> ... >>>>> >>>>> Then, Iterate! >>>>> >>>>> (We may simplify that step with a "plugin upgrade" command one day) >>>>> >>>>> Note: If you make mistakes in your plugin.xml specifications, the >> install >>>>> may fail and you may end up with a slightly awkward workspace, and >> will >>>>> need to manually delete some files, or just re-create a new workspace >> for >>>>> testing. >>>>> >>>>> ------------------ >>>>> >>>>> Interpretation (2): You want to version an entire workspace you've >>>> created >>>>> with cordova-cli. >>>>> >>>>> You can do this, but, cli created workspaces have a bunch of "build >>>>> artifacts" and it serves little purpose to actually track changes to >> them >>>>> (in my opinion). >>>>> >>>>> The pieces that are actually worth tracking are the original sources: >>>>> platforms, plugins, and your app(s). >>>>> >>>>> If you would like to manually track versions of platforms or the core >>>>> plugins, you are free to clone the git repos manually, and use >>>> cordova-cli >>>>> to add them from local paths. This way, you can also make downstream >>>>> changes inside feature branches etc. >>>>> >>>>> If you do not actually need to make changes to platforms/plugins, it >> is >>>>> easier to let CLI automatically fetch the latest stable versions for >> you, >>>>> or fetch specific version you request for you, and trust that we will >>>> serve >>>>> good working versions. You can always revert to older versions if >> issues >>>>> come up. >>>>> >>>>> Again, you can of course add the whole workspace into a repo and share >>>> that >>>>> across a team, but much of those files are created as a result of file >>>>> munging and will change in odd ways over time. >>>>> >>>>> ------------------ >>>>> >>>>> >>>>> [1]: >>>>> >>>> >> http://cordova.apache.org/docs/en/3.0.0/guide_hybrid_plugins_index.md.html#Plugin%20Development%20Guide >>>>> [2]: >>>>> >>>> >> http://cordova.apache.org/docs/en/3.0.0/plugin_ref_spec.md.html#Plugin%20Specification >>>>> [3]: https://github.com/apache/cordova-plugin-device >>>>> >>>>> -Michal >>>>> >>>>> >>>>> >>>>> On Fri, Aug 30, 2013 at 5:51 AM, lmnbeyond <lmnbey...@gmail.com> >> wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> Cordova was separated into tens of individual repos ever >> since >>>> 3.0 >>>>>> and we're benefit from this change and can quickly build/test apps. >>>>>> >>>>>> For now, if I want to develop some feature or plugin, I can >>>> first >>>>>> create a project by cli, then did some changes, but meanwhile it's >>>>>> difficult to track which files got changed/added/removed, since all >>>> source >>>>>> was not under source control. And it's also error prone to manually >> do >>>> the >>>>>> tracking. The structure of cordova-x repos is different from the >>>> structure >>>>>> in a development project. >>>>>> >>>>>> It was easier if there was an all-in-one project, I mean all >>>>>> native sources in a single project, before 3.0. >>>>>> >>>>>> >>>>>> Best Regards! >>>>>> >>>>>> >>>>>> >>>>>> >>>> >>
