cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Gauthier <m...@silverorange.com>
Subject Re: Updating plugin code on prepare
Date Mon, 07 Oct 2013 14:57:30 GMT
Did this feature land in 3.1.0 or is it targeted for 3.2.0?

On 2013-10-03 11:30, Michal Mocny 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