Hi, Thanks for all your detailed explanations.
I tend to agree with @Anis KADRI, CLI is amazing, but it's a little low-productive to iterate "add/remove". However, I think I can accept a compromise: add a "plugin upgrade" command, as @Michal Mocny has mentioned. Best Regards! On 2013-8-31, at 上午5:03, 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! >>>>> >>>>> >>>>> >>>>> >>>