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:25:23 GMT
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-andit 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