cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tommy-Carlos Williams <to...@devgeeks.org>
Subject Re: What's your daily workflow for cordova development?
Date Mon, 02 Sep 2013 23:51:33 GMT
+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.kadri@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.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