cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: Updating plugin code on prepare
Date Fri, 27 Sep 2013 15:45:22 GMT
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.

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.

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