cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Mocny <mmo...@chromium.org>
Subject Re: Updating plugin code on prepare
Date Thu, 26 Sep 2013 19:01:14 GMT
On Thu, Sep 26, 2013 at 1:39 PM, Jesse <purplecabbage@gmail.com> wrote:

> What does a watch mean?
> - if I reboot, is it still watched?
>

No, this would start a process that lives until you CTRL+C.  You could have
it run it in the background, or set it to start of startup, but that would
be using local system tools, not part of the command itself.

Ideally, "watch" should run "prepare" whenever you would have wanted it to.
 Though obviously that cannot be perfect, it can be a useful tool when
iterating.


>
> I think it would be best to consider separating development from packaging
> in your use-case for workflow.
> If I am going to develop featureX as a plugin I would :
>
> 1. create a project for a single cordova platform, and develop the feature
> as a native piece, and a js piece.
> 2. test thoroughly
> 3. create a project for a second cordova platform, and develop the native
> bit, preserving the js from 1
> 4. test thoroughly
> 5. repeat steps 3+4 for any remaining platforms
> 6. package featureX as a plugin by organizing relevant bits in the correct
> folder structure, and adding a plugin.xml
> 7. test each platform by installing with plugman
> 8. publish
>

As a plugin developer, that is not my workflow.

Typically for me its:

Write a sample app/manual test for some new feature that isn't implemented
yet.
Create a new plugin Foo for iOS & Android, and stub the implementation.
Implement feature A of plugin Foo for iOS, test, add it for Android, test.
Implement feature B of plugin Foo for iOS, test, add it for Android, test.
...

Usually the js implementation is shared, the auto tests are shared, and the
sample test app is shared.

Sure, I do platform specific stuff for testing and implementation, but I
certainly wouldn't say I do plugin development in platform isolation.

Also, right now we do not have a "plugin create" command, and so leaving
the "packaging" step for last doesn't add affect total work.  But once we
do have such a command, plugins could start packaged, and adding the small
changes to plugin.xml as you need them is likely a good way to go.

Finally, this workflow would get people out of the habit of making changes
to the platform artifacts directly.  I'm not sure that can be entirely
avoided in all cases, but why shouldn't we work towards making that easier?


> We seem to have this notion come up repeatedly that our users + plugin
> developers are working on multiple platforms at the same time, which I
> think is entirely false.
>

Since we differ in opinion, how can we put this to the test?

Also, we specifically make sure all our features address the needs of those
doing single platform development, so in a world of 3.0+ cli, I really
don't see how we can not do the same to address the needs of those who do
do multi-platform development, especially when we have a good proposal of
how to do so and someone willing to do it.


> I also think we're trying to help the wrong people; If I am a developer who
> is working on multiple platforms at once, and I have a bunch of devices
> attached, I probably also have the skills to set up my own grunt continuous
> integration system. Setting up tooling for potential plugin developers is
> the wrong approach, imho. We should actually just go and implement some new
> plugin and evaluate the process instead of creating and imposing a specific
> workflow.
>

The first part of this argument has some merit, I agree.  We the
power-users have found ways to address our problems.  However, I think that
with this change it means that even the end user can make changes to plugin
folder as they find bugs/etc, and expect to see the change reflected after
running prepare.  This is principle of least surprise, and just good design.

I also don't think we are imposing any specific workflow here, just
enabling a new one.  Personally I think that its quite surprising and
embarrassing that we haven't enabled this workflow since 3.0.


>
>
>
>
>
>
>
>
>
> @purplecabbage
> risingj.com
>
>
> On Thu, Sep 26, 2013 at 10:09 AM, Brian LeRoux <b@brian.io> wrote:
>
> > I love the idea of a watch command.
> >
> >
> > On Thu, Sep 26, 2013 at 4:48 PM, Anis KADRI <anis.kadri@gmail.com>
> wrote:
> >
> > > Forgot about the existence of --link for a second. I think this is a
> > > good solution (not temporary). watch can be an enhancement to this
> > > solution. This might get people like Joe Bowser and other people who
> > > do native dev to give cordova-cli a try (only maybe though).
> > >
> > > On Thu, Sep 26, 2013 at 4:25 PM, Braden Shepherdson <
> braden@chromium.org
> > >
> > > wrote:
> > > > If the proposal above is temporary, what's permanent? cordova watch?
> I
> > > want
> > > > to make sure we're on the same page.
> > > >
> > > > Braden
> > > >
> > > >
> > > > On Thu, Sep 26, 2013 at 6:08 AM, Anis KADRI <anis.kadri@gmail.com>
> > > wrote:
> > > >
> > > >> No I didn't mean implement `plugman --watch`. I don't think plugman
> > > >> needs a `watch` command.
> > > >>
> > > >> I was indeed talking about `cordova watch` which should watch for
> > > >> changes in plugins/ (and maybe in merges/ and www/ as well) and
> update
> > > >> the platform projects (prepare?) on every change.  I am happy to
> know
> > > >> that it's on the wish list.
> > > >>
> > > >> As far as the original proposal, I believe it is a descent temporary
> > > >> solution for plugin developers who want to use cordova-cli.
> > > >>
> > > >> On Wed, Sep 25, 2013 at 7:17 PM, Michal Mocny <mmocny@chromium.org>
> > > wrote:
> > > >> > Braden, thats has been on the wish list (cordova watch), but
I
> > suspect
> > > >> Anis
> > > >> > was suggesting something different with plugman --watch, to do
> > > >> specifically
> > > >> > with plugin development.  Am I right, Anis?  How does your idea
> > > compare
> > > >> > with using --link with cordova watch?  Would plugman --watch
be
> > useful
> > > >> for
> > > >> > non cli projects?
> > > >> >
> > > >> > -Michal
> > > >> >
> > > >> >
> > > >> > On Wed, Sep 25, 2013 at 10:31 AM, Braden Shepherdson <
> > > >> braden@chromium.org>wrote:
> > > >> >
> > > >> >> We've had a vague feature planned for a while now to do a
cordova
> > > >> watch. It
> > > >> >> would watch your plugins/, www/, and merges/* for any changes.
If
> > any
> > > >> >> changes are detected, it would re-run cordova prepare, so
that
> your
> > > >> native
> > > >> >> projects are always up-to-date.
> > > >> >>
> > > >> >> I'm open to checking (hashes?) which files have changed and
which
> > > have
> > > >> not,
> > > >> >> but hashing them all is touching them all anyway, and it
might be
> > > faster
> > > >> >> for small files to just copy them instead of checking first.
> We'll
> > > have
> > > >> to
> > > >> >> try it and see; for v1 I'm going with the simple option of
> copying
> > > >> >> everything.
> > > >> >>
> > > >> >> Braden
> > > >> >>
> > > >> >>
> > > >> >> On Wed, Sep 25, 2013 at 9:44 AM, Michal Mocny <
> mmocny@chromium.org
> > >
> > > >> wrote:
> > > >> >>
> > > >> >> > The idea for plugin dev outside of plugins/ folder was
to use
> > > "plugin
> > > >> add
> > > >> >> > --link".  Matter of fact, braden suggested that "plugin
create"
> > > should
> > > >> >> > default to --link-ing to some external location so that
you
> don't
> > > risk
> > > >> >> > deleting your only copy inside plugins/.  (I personally
don't
> > think
> > > >> >> thats a
> > > >> >> > necessary concern, but I think its a conversation for
later).
> > > >> >> >
> > > >> >> > I'm not even sure what a 'watch' would do, just uninstall
&
> > install
> > > >> each
> > > >> >> > time the plugin changes?  I think that ends up being
just
> > slightly
> > > >> worse
> > > >> >> > than the current proposal if you factor in that we already
do
> > > support
> > > >> >> > --link (except without the above change its been useless).
> > > >> >> >
> > > >> >> >
> > > >> >> > However, we may still want some form of 'watch' command
for
> devs
> > > using
> > > >> >> > plugman directly.  I had assumed that those devs just
edit in
> > > place,
> > > >> >> since
> > > >> >> > they don't use a prepare step anyway.
> > > >> >> >
> > > >> >> > -Michal
> > > >> >> >
> > > >> >> >
> > > >> >> >
> > > >> >> > On Wed, Sep 25, 2013 at 7:50 AM, Anis KADRI <
> > anis.kadri@gmail.com>
> > > >> >> wrote:
> > > >> >> >
> > > >> >> > > If we're talking about developing plugins inside
the
> > > >> >> > > plugins/org.myplugin.id folder than I think it's
a great
> > > workflow
> > > >> and
> > > >> >> > > I would just hide the cached version of plugin.xml
inside
> that
> > > >> >> > > plugins/org.myplugin.id folder.
> > > >> >> > >
> > > >> >> > > However, if you're developing a plugin outside
of a cordova
> CLI
> > > >> >> > > project, I think a `watch` (and add --watch) command
is more
> > > >> >> > > appropriate. One of the reasons you would develop
a plugin
> > > outside
> > > >> of
> > > >> >> > > a cordova CLI project is for easier version control
(each
> > plugin
> > > >> would
> > > >> >> > > have its own repository). The other cool thing
about `watch`
> is
> > > that
> > > >> >> > > it would copy the files that have actually changed
and not
> > > >> everything
> > > >> >> > > (some plugins have a LOT of files [1]).
> > > >> >> > >
> > > >> >> > > [1] https://github.com/phonegap/phonegap-facebook-plugin
> > > >> >> > >
> > > >> >> > > On Wed, Sep 25, 2013 at 3:30 AM, James Jong <
> > > wjamesjong@gmail.com>
> > > >> >> > wrote:
> > > >> >> > > > +1 This is a cleaner workflow and should reduce
some
> > confusion.
> > > >> >> > > >
> > > >> >> > > > -James Jong
> > > >> >> > > >
> > > >> >> > > > On Sep 24, 2013, at 3:09 PM, Michal Mocny
<
> > mmocny@chromium.org
> > > >
> > > >> >> wrote:
> > > >> >> > > >
> > > >> >> > > >> Just to add, the reason for the "if" statement
in step (2)
> > is
> > > >> that
> > > >> >> > > >> uninstall & reinstall take a lot longer
than just moving a
> > few
> > > >> >> files,
> > > >> >> > > which
> > > >> >> > > >> is the 99.9% case for most end users who
aren't making
> > > >> modifications
> > > >> >> > to
> > > >> >> > > >> plugins.
> > > >> >> > > >>
> > > >> >> > > >> This way, we only do the heavy lifting
if your plugin
> > > structure
> > > >> >> > actually
> > > >> >> > > >> changed.  Doing it automatically means
we no longer have
> to
> > > >> advise
> > > >> >> > users
> > > >> >> > > >> that making edits inside plugin/ folder
is useless.  Now
> we
> > > just
> > > >> >> > advise
> > > >> >> > > >> them to run "prepare" after making changes
to either www/
> or
> > > >> >> plugins/.
> > > >> >> > > >>
> > > >> >> > > >> This key insight was Braden's idea and
I think its just an
> > > >> awesome
> > > >> >> > > change
> > > >> >> > > >> for workflow.
> > > >> >> > > >>
> > > >> >> > > >> -Michal
> > > >> >> > > >>
> > > >> >> > > >>
> > > >> >> > > >> On Tue, Sep 24, 2013 at 2:58 PM, Braden
Shepherdson <
> > > >> >> > > braden@chromium.org>wrote:
> > > >> >> > > >>
> > > >> >> > > >>> Michal and I were discussing how to
make the plugin
> > developer
> > > >> >> > > experience
> > > >> >> > > >>> better, by having `cordova prepare`
update the platform
> > > projects
> > > >> >> > > properly
> > > >> >> > > >>> when you change a plugin in place.
> > > >> >> > > >>>
> > > >> >> > > >>> I propose the following changes:
> > > >> >> > > >>>
> > > >> >> > > >>> 1. On plugin install, we cache the
plugin.xml in
> > > >> $PROJECT/.cordova
> > > >> >> > > >>> somewhere.
> > > >> >> > > >>> 2. On 'cordova prepare', compare each
plugin's plugin.xml
> > > >> against
> > > >> >> the
> > > >> >> > > >>> cached one.
> > > >> >> > > >>>    a. If they have changed, uninstall
the plugin using
> the
> > > old
> > > >> >> > > plugin.xml,
> > > >> >> > > >>> then reinstall using the new one (and
update the cached
> > > >> >> plugin.xml).
> > > >> >> > > >>>    b. If they are identical, copy
all the native code
> files
> > > from
> > > >> >> the
> > > >> >> > > >>> plugin into the project again.
> > > >> >> > > >>>
> > > >> >> > > >>> The idea is that you can change your
plugin's native
> code,
> > JS
> > > >> >> > modules,
> > > >> >> > > or
> > > >> >> > > >>> assets, and after a prepare you'll
be running the latest.
> > We
> > > >> >> already
> > > >> >> > > have
> > > >> >> > > >>> cordova plugin add foo --link, but
it wasn't very useful.
> > > This
> > > >> will
> > > >> >> > > make
> > > >> >> > > >>> plugin development a much smoother
flow, without too much
> > > >> >> > > implementation
> > > >> >> > > >>> effort.
> > > >> >> > > >>>
> > > >> >> > > >>> Checking for changes to plugin.xml
lets us know that no
> > files
> > > >> have
> > > >> >> > been
> > > >> >> > > >>> added or removed, that <config-file>
edits haven't
> changed,
> > > and
> > > >> so
> > > >> >> > on,
> > > >> >> > > >>> meaning that simply copying the native
code again will be
> > > >> >> sufficient.
> > > >> >> > > >>>
> > > >> >> > > >>> What do people think? Any gotchas
that I overlooked?
> > > >> >> > > >>>
> > > >> >> > > >>> Braden
> > > >> >> > > >>>
> > > >> >> > > >
> > > >> >> > >
> > > >> >> >
> > > >> >>
> > > >>
> > >
> >
>

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