cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anis KADRI <anis.ka...@gmail.com>
Subject Re: What's your daily workflow for cordova development?
Date Fri, 30 Aug 2013 21:03:38 GMT
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.kadri@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 <mmocny@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 <lmnbeyond@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!
>> >>
>> >>
>> >>
>> >>
>>

Mime
View raw message