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 18:20:40 GMT
On Fri, Sep 27, 2013 at 2:10 PM, Andrew Grieve <agrieve@chromium.org> wrote:

> Just tried some symlinks in Xcode 5:
> - Copying assets work (due to our custom build step)
> - Building works (compiler follows links just fine)
> - Editing a fail (big fail. Files open but changes cannot be saved.)
>

Hmm, changes via xcode to symlinks fail, you mean?  That would be hard to
fix, but perhaps at least its feedback to the user not to make direct edits
there, when using CLI workflow ;) so may still be a valid change to make.


>
> For Xcode though, it is an option to change our installation step to have
> Xcode reference the native files within plugins/ rather than within
> platforms/.
>
>
> Symlinks in Eclipse:
> - Copying assets works out-of-the-box
> - Build works fine
> - Editing seems to work fine (edits saved to symlinked location).
>
>
>
> Still though, maybe the best solution would be a combination of the two?
> Have prepare know when an remove+add is necessary?
>

Yes, I think thats what we are suggesting.

The original email mentioned prepare knowing when remove+add are necessary,
which I think is already settled as a good idea.  Not sure if you had more
to add about how prepare should know when to do this (currently, its only
on plugin.xml changes).
The more recent suggestions about making links between platform&plugins
were additional requests to address the rest of the workflow issues (ie,
most users prefer to edit inside platforms/ folder because of IDE
integration etc).

Were you implying anything different here?


>
> On Fri, Sep 27, 2013 at 6:25 PM, Michal Mocny <mmocny@chromium.org> wrote:
>
> > Have we not previously solved the symlink problem in xcode with a build
> > hook, or was that for prepare step?
> >
> > The --link concept doesn't do anything for that platforms -> plugins file
> > mapping.  Its useful for mapping plugins/ to local source, but it doesn't
> > help with the problem Tyler mentions, right?
> >
> > -Michal
> >
> >
> > On Fri, Sep 27, 2013 at 1:20 PM, Braden Shepherdson <braden@chromium.org
> > >wrote:
> >
> > > Symlinks in platforms/ are a problem because Xcode doesn't honour them,
> > at
> > > least last time we tried it.
> > >
> > > I'm much more enthused about the --link concept than any syncing,
> though.
> > > Also if someone wants to sync, they can already use rsync to do it
> > > manually.
> > >
> > > Braden
> > >
> > >
> > > 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.
> > > >
> > > > 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-anditappearsit
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