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! >> >> >> >> >> >> >> >> >>
