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 Thu, 03 Oct 2013 14:30:30 GMT
Yeah Braden we've diverged sorry, lets focus.

Big +1 for your proposal to make prepare step do what users expect.

-Michal


On Thu, Oct 3, 2013 at 10:20 AM, Braden Shepherdson <braden@chromium.org>wrote:

> 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-anditappearsitonlymentionsthe 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