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 18:42:24 GMT
On Thu, Sep 26, 2013 at 2:03 PM, Carlos Santana <csantana23@gmail.com>wrote:

> I think we can do something outside cordova in grunt using the
> grunt-contrib-watch plugin in user land.
>
Agreed.  I think watch command should leverage grunt, and is just a future
value-add on top of cordova-cli base functionality.  This proposal is
entirely orthogonal, thought a watch feature will certainly be very useful.


> If after a while there is a compelling reason to add some portion or
> lessons learned to cordova  then it can be expose to users.
>
> Also there is the possibility of star experimenting just for cordova usage
> for cordova contributors workflows like we have today in
> cordova-js\Gruntfile
>
> TLDR: lets eat our own dog food before we adopted as something to support
> in apache cordova for consumer of the project.
>
>
>
>
> On Thu, Sep 26, 2013 at 1:42 PM, Tyler Wilson <twilson@pulse-robotics.com
> >wrote:
>
> > Just one comment: if I understand this feature correctly, it watches the
> > top-level www folder and will copy any updated files into the platform
> > files.
> >
> > My issue with this is that I typically create the project, add the
> > platform (iOS in my case) and then load the Xcode project. And what is
> > shown in the iOS project is the platform www folder. And since we
> naturally
> > edit the code directly in Xcode, this watch command would never really do
> > anything for me.
>

This, I consider a major UX bug on our part.  That xcode www/ folder should
just point directly to your top level www/.  Otherwise, you will blow away
your work with each prepare, as you notice.  The solution is not to ignore
the prepare command, indeed that is defeating the point, if not impossible,
when using the CLI.  The solution is not to edit the platform copy of www/.

However, I completely agree that it is more comfortable to edit directly
inside xcode if that is your prefered workflow.  I am not advising against
that.  The answer is perhaps to have a "prepare" hook tred to the xcode
build command, so that your www/ assets are edited directly in, and updated
from, the top level www/ folder automatically whenever you build.

The specifics here are likely topic for another thread since different
parties have different opinions about the idea IDE workflow, but it seems
very clear that what we have right now is confusing to every single user,
like yourself.


> >
> > What I would like a reverse watch, which will detect changes in the
> > platform www and copy them up to the top-level shared www folder. Perhaps
> > this is part of the feature set - more like a 'sync' than a watch.
> >
> > Thanks,
> > Tyler
> >
> > On Sep 26, 2013, at 1:09 PM, 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
> > >>>>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>
> > >>>>
> > >>
> >
> >
>
>
> --
> Carlos Santana
> <csantana23@gmail.com>
>

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