cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Braden Shepherdson <bra...@chromium.org>
Subject Re: Updating plugin code on prepare
Date Thu, 03 Oct 2013 14:20:59 GMT
I agree that the syncing solutions are too complex and confusing.

I return, then, to my original proposal all those emails ago: updating the
native plugin files in platforms/foo when you prepare, to make life easier
for plugin developers. When coupled with the present cordova plugin add
--link, and future cordova watch, I think this makes the plugin developer
flow pretty good, and without making it too magical or harder to
understand. I think it simplifies prepare: on prepare, your native projects
are updated to reflect the state of plugins/ and www/. Right now, only
www/, <asset>s and <js-module>s get updated, but not native code.

As to Xcode and symlinks and all the rest of the borderline thread
hijacking, I think that regardless of what editor you use, you have to be
editing the right file. Xcode and Eclipse make this harder than it needs to
be, but our job is not to make them suck less.

Braden


On Sun, Sep 29, 2013 at 1:43 PM, Carlos Santana <csantana23@gmail.com>wrote:

> +1 Anis
> corodova-cli/plugman should be building block components to higher level
> Tools/IDE.
>
> That we can do better sure, lets provide a few examples using blog pots and
> maybe videos tutorials vs. trying to support every use case with code.
>
> A watch function could be as simple as using "grunt-contrib-watch" to a
> more complicated environment like "rsync/Eclipse"
>
> I agree lets put emphasis on documenting use cases and the correct
> approach.
> When to get the best out of using prepare,  merges, and hooks
>
> All I said applies when you have the "Web Developer" hat.
>
> For people that have the "Native Plugin Developer" hat then we can do
> things first for cordova-contributors than others can choose to use on
> their own risk since it could be changing too fast and maybe too narrow use
> case.
>
> --Carlos
>
> --Carlos
>
>
>
> On Sun, Sep 29, 2013 at 9:18 AM, Anis KADRI <anis.kadri@gmail.com> wrote:
>
> > I gave some thought to this problem and I think we should just leave
> > everything as is. Here's my reasoning:
> >
> > - Most web developers use a text editor (vim, sublime text, text mate,
> > notepad++, ....) to edit their HTML/CSS/Javascript. I've never seen
> > anyone use a fully fledged IDE to edit web assets. It would be like
> > using Microsoft Word to edit a simple .TXT or .MD file
> > - Other developers, people who write Java or Objective C, etc.. use
> > Xcode, Eclipse, IntelliJ, ...and I think these people are not good
> > candidates for cordova-cli.
> >
> > The original PhoneGap promise (now Apache Cordova) was to make it easy
> > for Web Developers to write Mobile Apps using web technologies and I
> > believe that promise is fulfilled with cordova-cli. You have a folder
> > where you drop in your web assets and you can build/deploy to a device
> > or simulate.
> >
> > If people want to use an IDE, then they should be creating native
> > projects with our create scripts and use plugman to manage their
> > plugins.
> >
> > Our documentation should point our users to the right approach
> > depending on the use case. For example:
> >
> > - Building for only one platform ? Building a hybrid app ? Want to use
> > an IDE (Eclipse, Xcode) ? You should use the create scripts and
> > plugman to manage plugins
> >
> > - Building a cross-platform app ? Like managing your project from the
> > command-line ? Want to use your favo(u)rite text editor ? Use
> > cordova-cli
> >
> > These double symlinking, backsyncing solutions will be a source of
> > confusion and issues in my humble opinion. I've said it before but
> > sometimes by trying to please everyone you end up pleasing no one.
> >
> > my .02c
> >
> > -a
> >
> > On Fri, Sep 27, 2013 at 8:20 PM, Michal Mocny <mmocny@chromium.org>
> wrote:
> > > 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-anditappearsitonlymentions 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
> > >> > > > > >>>>>>>>>>>>>>
> > >> > > > > >>>>>>>>>>>>
> > >> > > > > >>>>>>>>>>>
> > >> > > > > >>>>>>>>>>
> > >> > > > > >>>>>>>>>
> > >> > > > > >>>>>>>
> > >> > > > > >>>>>
> > >> > > > > >>>>
> > >> > > > > >>>
> > >> > > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> >
>
>
>
> --
> Carlos Santana
> <csantana23@gmail.com>
>

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