cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian LeRoux...@brian.io>
Subject Re: What's your daily workflow for cordova development?
Date Fri, 20 Sep 2013 16:38:42 GMT
Agree you will certainly arrive at the ideal solution by iterating from the
less-than-ideal solution. That is not a reason to not start breaking stuff
though.


On Fri, Sep 20, 2013 at 5:31 PM, Michal Mocny <mmocny@chromium.org> wrote:

> Ugh, unfortunately Braden is right.  Still, I think that means we can move
> forward with the plan to make "plugman create" work anywhere and "cordova
> plugin create" only work inside of a workspace, but don't implement the
> latter until its actually feasible to make edits to plugins inside a
> workspace in some sane fashion.
>
> Not supporting cordova plugin create from a global context leaves us open
> to doing the right thing in the future, I think.
>
> -Michal
>
>
> On Fri, Sep 20, 2013 at 7:53 AM, Braden Shepherdson <braden@chromium.org
> >wrote:
>
> > I would caution against developing a plugin inside a cordova-cli
> workspace.
> > The nature of the install vs. prepare divide is that any changes to
> native
> > code require reinstalling. That's confusing for developers, so I would
> > recommend that the best way to develop a plugin using CLI is to plugman
> > create elsewhere, and then install that plugin into a CLI workspace for
> > testing. Then when you make a change to the plugin at its top-level
> > location, you uninstall and reinstall it.
> >
> > I recognize that this flow is less than ideal, and I'd like to improve it
> > in the long term, but in the meantime it would be a bad idea to keep a
> > plugin's canonical location inside plugins/.
> >
> > Braden
> >
> >
> > On Fri, Sep 20, 2013 at 10:16 AM, Lucas Holmquist <lholmqui@redhat.com
> > >wrote:
> >
> > > i always forget about plugman
> > > On Sep 20, 2013, at 9:57 AM, Michal Mocny <mmocny@chromium.org> wrote:
> > >
> > > > plugman create could be used outside of a project, and cordova plugin
> > > > create should be used only inside of a project?
> > > >
> > > > All other cordova commands must be used inside a project (except the
> > > > "create" entry point), and if we decide to ship the plugin templates
> > with
> > > > platforms, and/or decide to make the global cordova command just a
> > > > grunt-cli like thing, etc etc, then I would worry about adding uses
> for
> > > > cordova command in some global context.
> > > >
> > > >
> > > > On Fri, Sep 20, 2013 at 6:42 AM, Lucas Holmquist <
> lholmqui@redhat.com
> > > >wrote:
> > > >
> > > >> So currently when doing
> > > >>
> > > >> $ cordova plugin ….
> > > >>
> > > >> it fails if you are not in a cordova project.
> > > >>
> > > >> but
> > > >>
> > > >> $ cordova plugin create
> > > >>
> > > >> might not be used inside a project( i think it shouldn't be used
> > inside
> > > a
> > > >> project at all,  but i can be convinced otherwise )
> > > >>
> > > >>
> > > >> On Sep 4, 2013, at 10:46 PM, lmnbeyond <lmnbeyond@gmail.com>
wrote:
> > > >>
> > > >>>
> > > >>>
> > > >>>> I also think it should sub-shell to a platform script. We
already
> > have
> > > >>>> a `project template` folder in each platform. We can easily
add a
> > > >>>> `plugin template` as well and write a quick create_plugin
script.
> > > >>>>
> > > >>>> What do you guys think of the workflow I described above ?
Any
> > > >>>> comments ? I can create jira issues for it and tackle it.
> > > >>>>
> > > >>>> -a
> > > >>>>
> > > >>>
> > > >>> Hi Anis,
> > > >>>
> > > >>> I just want to confirm whether or not this is the workflow we
are
> > > >> talking about :
> > > >>>
> > > >>> For a brand new plugin:
> > > >>>
> > > >>> $ cordova plugin create /path/to/myPlugin
> > > >>> $ cordova plugin add /path/to/myPlugin --watch
> > > >>>
> > > >>>
> > > >>> For an existing plugin:
> > > >>>
> > > >>> $ cordova plugin add /path/to/corePlugin --watch
> > > >>>
> > > >>>
> > > >>> Although, I'm not quite clear about the complexity behind this,
 I
> > > think
> > > >> the above workflow is great for me!
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>
> > > >>
> > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message