cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anis KADRI <anis.ka...@gmail.com>
Subject Re: Updating plugin code on prepare
Date Thu, 03 Oct 2013 20:59:54 GMT
+1!

On Thu, Oct 3, 2013 at 4:30 PM, Michal Mocny <mmocny@chromium.org> wrote:
> 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
View raw message