cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Braden Shepherdson <bra...@chromium.org>
Subject Re: What's your daily workflow for cordova development?
Date Mon, 23 Sep 2013 14:51:43 GMT
It could be, and there's even a plugin add --link option.

BUT, there's a major caveat here: Changes to plugin.xml, native code, and
possibly other parts, won't be updated on cordova prepare, but only on
cordova plugin add. So you'd have to plugin rm+add on most changes anyway,
so there's little advantage to linking.

Braden


On Mon, Sep 23, 2013 at 10:33 AM, Jamie Munro <jamie@whiteoctober.co.uk>wrote:

> Could a plugin that is in development be symlinked into the plugins folder
> of the project it is being developed for?
>
> Robert (Jamie) Munro
>
>
> On 20 September 2013 17:38, Brian LeRoux <b@brian.io> wrote:
>
> > 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