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 Fri, 27 Sep 2013 17:21:41 GMT
On Fri, Sep 27, 2013 at 11:45 AM, Andrew Grieve <agrieve@chromium.org>wrote:

> I think it'd be good to enumerate our options for workflow before we
> decided on which to implement (or maybe choose multiple).
>
> Tyler's idea about a sync command seems like it would be handy. Edit your
> plugin files within platforms/, and then run `cordova plugin copychanges
> org.my.plugin` to do a reverse copy of the source files back to the install
> source location of the plugin. Big caveat though is that you run the risk
> of prepare clobbering your changes. I think that's too killer a risk.
>
> Another thought is that we could use symlinks when running prepare. Have
> files within platforms/ symlink to files within plugins/, then symlink
> again back to their original sources. Would this work with editors in
> practice? I don't know, but worth exploring. Wikipedia says symlinks work
> on NTFS as of Vista.
>

I would love to see this explored.  Its not quite perfect, since you cannot
add/remove files to your plugins from within platform/ copy (i.e. from
IDE), but at least you can edit what's already there.


>
> Braden / Michael - I think yours is a good idea as well. Although, I don't
> think we should encourage people to edit files within plugins/. They should
> edit their plugins from install point. We should record the install path,
> and maybe have prepare have a prepare --update-local-plugins.
>

I agree you should edit the source location of your plugin, but this
happens to be plugins/ quite often:

- When you fetch from registry.  Sure, its not the canonical source, but
its probably too much overhead to tell the dev to clone the original repo
somewhere local and reinstall from path just to try a local change.  They
can do that once they have a patch ready to share/etc.
- When you install with --link, which we should do by default for local
paths
- When you 'plugin create' using CLI, which is not implemented yet, but
we've got on our list

Basically, in almost all cases, I think it should be fine to make edits
inside plugins, and expect to see them reflected after a prepare.


>
> Any other ideas?
>
>
>
> On Fri, Sep 27, 2013 at 3:13 PM, Michael Sierra <msierra@adobe.com> wrote:
>
> > Can you please file JIRAs on doc problems like this?   Existing overview
> > doc says you can use the CLI to bootstrap & hand off to an SDK &
> supporting
> > platform command-line utilities.  I take your comment to mean doc should
> > better stress that once you start working with platform tools downstream,
> > you can't go back to the CLI. Correct?
> >
> > --Mike Sierra
> >
> >
> > ________________________________________
> > From: Tyler Wilson [twilson@pulse-robotics.com]
> > Sent: Thursday, September 26, 2013 8:19 PM
> > To: dev@cordova.apache.org
> > Subject: Re: Updating plugin code on prepare
> >
> > Re: IDEs: if it is the case that the CLI should not be used along with an
> > IDE, perhaps the documentation - including Getting Started Guides, etc. -
> > ought to be much clearer about this. Perhaps a big warning that "Xcode
> > project files are created by the CLI, but they should not be opened and
> > used by Xcode. And you definitely should not edit code within the IDE".
> >
> > I just went to the main documentation site here -
> >
> http://cordova.apache.org/docs/en/3.0.0/guide_overview_index.md.html#Overview-and it
appears it only mentions the new CLI interface. No mention of the
> > old bin/create method. Seems to me there may be communication problem
> here.
> >
> > Thanks,
> > Tyler
> >
> > On Sep 26, 2013, at 6:11 PM, Anis KADRI <anis.kadri@gmail.com> wrote:
> >
> > > @purplecabbage: I have the same workflow but I think the proposed
> > > solution is a step in the right direction. It would allow us to easily
> > > develop platform plugins without having to delete project/create
> > > project/install plugin/uninstall plugin constantly. The plugin would
> > > be packaged (plugin.xml) from day 1 and one can only focus on
> > > development.
> > >
> > > As far as IDEs, the answer is simple. You should not use IDEs and
> > > cordova-cli at the same time. Until IDEs are aware of cordova-cli
> > > there is no point in creating projects with cordova-cli because
> > > everything gets blown on every build. I am not even sure we can make
> > > Xcode aware of cordova-cli. We've already talked about this prior to
> > > the 3.0 release and that is why we have the create scripts and plugman
> > > approach. You should not be using cordova-cli either if you're doing
> > > some custom native dev that can't be pluginized (changing the main
> > > Activity.java or AppDelegate.m or whatever). If you're using
> > > cordova-cli just to create a project and then open an IDE to develop,
> > > you're probably doing it wrong. You should be creating a native
> > > project and using plugman instead.
> > >
> > > On Thu, Sep 26, 2013 at 9:01 PM, Michal Mocny <mmocny@chromium.org>
> > wrote:
> > >> 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