cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carlos Santana <csantan...@gmail.com>
Subject Re: Updating plugin code on prepare
Date Sun, 29 Sep 2013 17:43:24 GMT
+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-anditappearsitonly mentions the new CLI interface. No mention of the
> >> > > > > old bin/create method. Seems to me there may be communication
> >> problem
> >> > > > here.
> >> > > > >
> >> > > > > Thanks,
> >> > > > > Tyler
> >> > > > >
> >> > > > > On Sep 26, 2013, at 6:11 PM, Anis KADRI <anis.kadri@gmail.com>
> >> > wrote:
> >> > > > >
> >> > > > > > @purplecabbage: I have the same workflow but I think the
> proposed
> >> > > > > > solution is a step in the right direction. It would allow us
> to
> >> > > easily
> >> > > > > > develop platform plugins without having to delete
> project/create
> >> > > > > > project/install plugin/uninstall plugin constantly. The plugin
> >> > would
> >> > > > > > be packaged (plugin.xml) from day 1 and one can only focus on
> >> > > > > > development.
> >> > > > > >
> >> > > > > > As far as IDEs, the answer is simple. You should not use IDEs
> and
> >> > > > > > cordova-cli at the same time. Until IDEs are aware of
> cordova-cli
> >> > > > > > there is no point in creating projects with cordova-cli
> because
> >> > > > > > everything gets blown on every build. I am not even sure we
> can
> >> > make
> >> > > > > > Xcode aware of cordova-cli. We've already talked about this
> prior
> >> > to
> >> > > > > > the 3.0 release and that is why we have the create scripts and
> >> > > plugman
> >> > > > > > approach. You should not be using cordova-cli either if you're
> >> > doing
> >> > > > > > some custom native dev that can't be pluginized (changing the
> >> main
> >> > > > > > Activity.java or AppDelegate.m or whatever). If you're using
> >> > > > > > cordova-cli just to create a project and then open an IDE to
> >> > develop,
> >> > > > > > you're probably doing it wrong. You should be creating a
> native
> >> > > > > > project and using plugman instead.
> >> > > > > >
> >> > > > > > On Thu, Sep 26, 2013 at 9:01 PM, Michal Mocny <
> >> mmocny@chromium.org
> >> > >
> >> > > > > wrote:
> >> > > > > >> On Thu, Sep 26, 2013 at 1:39 PM, Jesse <
> purplecabbage@gmail.com
> >> >
> >> > > > wrote:
> >> > > > > >>
> >> > > > > >>> What does a watch mean?
> >> > > > > >>> - if I reboot, is it still watched?
> >> > > > > >>>
> >> > > > > >>
> >> > > > > >> No, this would start a process that lives until you CTRL+C.
>  You
> >> > > could
> >> > > > > have
> >> > > > > >> it run it in the background, or set it to start of startup,
> but
> >> > that
> >> > > > > would
> >> > > > > >> be using local system tools, not part of the command itself.
> >> > > > > >>
> >> > > > > >> Ideally, "watch" should run "prepare" whenever you would have
> >> > wanted
> >> > > > it
> >> > > > > to.
> >> > > > > >> Though obviously that cannot be perfect, it can be a useful
> tool
> >> > > when
> >> > > > > >> iterating.
> >> > > > > >>
> >> > > > > >>
> >> > > > > >>>
> >> > > > > >>> I think it would be best to consider separating development
> >> from
> >> > > > > packaging
> >> > > > > >>> in your use-case for workflow.
> >> > > > > >>> If I am going to develop featureX as a plugin I would :
> >> > > > > >>>
> >> > > > > >>> 1. create a project for a single cordova platform, and
> develop
> >> > the
> >> > > > > feature
> >> > > > > >>> as a native piece, and a js piece.
> >> > > > > >>> 2. test thoroughly
> >> > > > > >>> 3. create a project for a second cordova platform, and
> develop
> >> > the
> >> > > > > native
> >> > > > > >>> bit, preserving the js from 1
> >> > > > > >>> 4. test thoroughly
> >> > > > > >>> 5. repeat steps 3+4 for any remaining platforms
> >> > > > > >>> 6. package featureX as a plugin by organizing relevant bits
> in
> >> > the
> >> > > > > correct
> >> > > > > >>> folder structure, and adding a plugin.xml
> >> > > > > >>> 7. test each platform by installing with plugman
> >> > > > > >>> 8. publish
> >> > > > > >>>
> >> > > > > >>
> >> > > > > >> As a plugin developer, that is not my workflow.
> >> > > > > >>
> >> > > > > >> Typically for me its:
> >> > > > > >>
> >> > > > > >> Write a sample app/manual test for some new feature that
> isn't
> >> > > > > implemented
> >> > > > > >> yet.
> >> > > > > >> Create a new plugin Foo for iOS & Android, and stub the
> >> > > > implementation.
> >> > > > > >> Implement feature A of plugin Foo for iOS, test, add it for
> >> > Android,
> >> > > > > test.
> >> > > > > >> Implement feature B of plugin Foo for iOS, test, add it for
> >> > Android,
> >> > > > > test.
> >> > > > > >> ...
> >> > > > > >>
> >> > > > > >> Usually the js implementation is shared, the auto tests are
> >> > shared,
> >> > > > and
> >> > > > > the
> >> > > > > >> sample test app is shared.
> >> > > > > >>
> >> > > > > >> Sure, I do platform specific stuff for testing and
> >> implementation,
> >> > > > but I
> >> > > > > >> certainly wouldn't say I do plugin development in platform
> >> > > isolation.
> >> > > > > >>
> >> > > > > >> Also, right now we do not have a "plugin create" command,
> and so
> >> > > > leaving
> >> > > > > >> the "packaging" step for last doesn't add affect total work.
> >>  But
> >> > > once
> >> > > > > we
> >> > > > > >> do have such a command, plugins could start packaged, and
> adding
> >> > the
> >> > > > > small
> >> > > > > >> changes to plugin.xml as you need them is likely a good way
> to
> >> go.
> >> > > > > >>
> >> > > > > >> Finally, this workflow would get people out of the habit of
> >> making
> >> > > > > changes
> >> > > > > >> to the platform artifacts directly.  I'm not sure that can be
> >> > > entirely
> >> > > > > >> avoided in all cases, but why shouldn't we work towards
> making
> >> > that
> >> > > > > easier?
> >> > > > > >>
> >> > > > > >>
> >> > > > > >>> We seem to have this notion come up repeatedly that our
> users +
> >> > > > plugin
> >> > > > > >>> developers are working on multiple platforms at the same
> time,
> >> > > which
> >> > > > I
> >> > > > > >>> think is entirely false.
> >> > > > > >>>
> >> > > > > >>
> >> > > > > >> Since we differ in opinion, how can we put this to the test?
> >> > > > > >>
> >> > > > > >> Also, we specifically make sure all our features address the
> >> needs
> >> > > of
> >> > > > > those
> >> > > > > >> doing single platform development, so in a world of 3.0+
> cli, I
> >> > > really
> >> > > > > >> don't see how we can not do the same to address the needs of
> >> those
> >> > > who
> >> > > > > do
> >> > > > > >> do multi-platform development, especially when we have a good
> >> > > proposal
> >> > > > > of
> >> > > > > >> how to do so and someone willing to do it.
> >> > > > > >>
> >> > > > > >>
> >> > > > > >>> I also think we're trying to help the wrong people; If I am
> a
> >> > > > > developer who
> >> > > > > >>> is working on multiple platforms at once, and I have a
> bunch of
> >> > > > devices
> >> > > > > >>> attached, I probably also have the skills to set up my own
> >> grunt
> >> > > > > continuous
> >> > > > > >>> integration system. Setting up tooling for potential plugin
> >> > > > developers
> >> > > > > is
> >> > > > > >>> the wrong approach, imho. We should actually just go and
> >> > implement
> >> > > > > some new
> >> > > > > >>> plugin and evaluate the process instead of creating and
> >> imposing
> >> > a
> >> > > > > specific
> >> > > > > >>> workflow.
> >> > > > > >>>
> >> > > > > >>
> >> > > > > >> The first part of this argument has some merit, I agree.  We
> the
> >> > > > > >> power-users have found ways to address our problems.
>  However, I
> >> > > think
> >> > > > > that
> >> > > > > >> with this change it means that even the end user can make
> >> changes
> >> > to
> >> > > > > plugin
> >> > > > > >> folder as they find bugs/etc, and expect to see the change
> >> > reflected
> >> > > > > after
> >> > > > > >> running prepare.  This is principle of least surprise, and
> just
> >> > good
> >> > > > > design.
> >> > > > > >>
> >> > > > > >> I also don't think we are imposing any specific workflow
> here,
> >> > just
> >> > > > > >> enabling a new one.  Personally I think that its quite
> >> surprising
> >> > > and
> >> > > > > >> embarrassing that we haven't enabled this workflow since 3.0.
> >> > > > > >>
> >> > > > > >>
> >> > > > > >>>
> >> > > > > >>>
> >> > > > > >>>
> >> > > > > >>>
> >> > > > > >>>
> >> > > > > >>>
> >> > > > > >>>
> >> > > > > >>>
> >> > > > > >>>
> >> > > > > >>> @purplecabbage
> >> > > > > >>> risingj.com
> >> > > > > >>>
> >> > > > > >>>
> >> > > > > >>> On Thu, Sep 26, 2013 at 10:09 AM, Brian LeRoux <b@brian.io>
> >> > wrote:
> >> > > > > >>>
> >> > > > > >>>> I love the idea of a watch command.
> >> > > > > >>>>
> >> > > > > >>>>
> >> > > > > >>>> On Thu, Sep 26, 2013 at 4:48 PM, Anis KADRI <
> >> > anis.kadri@gmail.com
> >> > > >
> >> > > > > >>> wrote:
> >> > > > > >>>>
> >> > > > > >>>>> Forgot about the existence of --link for a second. I think
> >> this
> >> > > is
> >> > > > a
> >> > > > > >>>>> good solution (not temporary). watch can be an
> enhancement to
> >> > > this
> >> > > > > >>>>> solution. This might get people like Joe Bowser and other
> >> > people
> >> > > > who
> >> > > > > >>>>> do native dev to give cordova-cli a try (only maybe
> though).
> >> > > > > >>>>>
> >> > > > > >>>>> On Thu, Sep 26, 2013 at 4:25 PM, Braden Shepherdson <
> >> > > > > >>> braden@chromium.org
> >> > > > > >>>>>
> >> > > > > >>>>> wrote:
> >> > > > > >>>>>> If the proposal above is temporary, what's permanent?
> >> cordova
> >> > > > watch?
> >> > > > > >>> I
> >> > > > > >>>>> want
> >> > > > > >>>>>> to make sure we're on the same page.
> >> > > > > >>>>>>
> >> > > > > >>>>>> Braden
> >> > > > > >>>>>>
> >> > > > > >>>>>>
> >> > > > > >>>>>> On Thu, Sep 26, 2013 at 6:08 AM, Anis KADRI <
> >> > > anis.kadri@gmail.com
> >> > > > >
> >> > > > > >>>>> wrote:
> >> > > > > >>>>>>
> >> > > > > >>>>>>> No I didn't mean implement `plugman --watch`. I don't
> think
> >> > > > plugman
> >> > > > > >>>>>>> needs a `watch` command.
> >> > > > > >>>>>>>
> >> > > > > >>>>>>> I was indeed talking about `cordova watch` which should
> >> watch
> >> > > for
> >> > > > > >>>>>>> changes in plugins/ (and maybe in merges/ and www/ as
> well)
> >> > and
> >> > > > > >>> update
> >> > > > > >>>>>>> the platform projects (prepare?) on every change.  I am
> >> happy
> >> > > to
> >> > > > > >>> know
> >> > > > > >>>>>>> that it's on the wish list.
> >> > > > > >>>>>>>
> >> > > > > >>>>>>> As far as the original proposal, I believe it is a
> descent
> >> > > > > temporary
> >> > > > > >>>>>>> solution for plugin developers who want to use
> cordova-cli.
> >> > > > > >>>>>>>
> >> > > > > >>>>>>> On Wed, Sep 25, 2013 at 7:17 PM, Michal Mocny <
> >> > > > mmocny@chromium.org
> >> > > > > >
> >> > > > > >>>>> wrote:
> >> > > > > >>>>>>>> Braden, thats has been on the wish list (cordova
> watch),
> >> > but I
> >> > > > > >>>> suspect
> >> > > > > >>>>>>> Anis
> >> > > > > >>>>>>>> was suggesting something different with plugman
> --watch,
> >> to
> >> > do
> >> > > > > >>>>>>> specifically
> >> > > > > >>>>>>>> with plugin development.  Am I right, Anis?  How does
> your
> >> > > idea
> >> > > > > >>>>> compare
> >> > > > > >>>>>>>> with using --link with cordova watch?  Would plugman
> >> --watch
> >> > > be
> >> > > > > >>>> useful
> >> > > > > >>>>>>> for
> >> > > > > >>>>>>>> non cli projects?
> >> > > > > >>>>>>>>
> >> > > > > >>>>>>>> -Michal
> >> > > > > >>>>>>>>
> >> > > > > >>>>>>>>
> >> > > > > >>>>>>>> On Wed, Sep 25, 2013 at 10:31 AM, Braden Shepherdson <
> >> > > > > >>>>>>> braden@chromium.org>wrote:
> >> > > > > >>>>>>>>
> >> > > > > >>>>>>>>> We've had a vague feature planned for a while now to
> do a
> >> > > > cordova
> >> > > > > >>>>>>> watch. It
> >> > > > > >>>>>>>>> would watch your plugins/, www/, and merges/* for any
> >> > > changes.
> >> > > > If
> >> > > > > >>>> any
> >> > > > > >>>>>>>>> changes are detected, it would re-run cordova
> prepare, so
> >> > > that
> >> > > > > >>> your
> >> > > > > >>>>>>> native
> >> > > > > >>>>>>>>> projects are always up-to-date.
> >> > > > > >>>>>>>>>
> >> > > > > >>>>>>>>> I'm open to checking (hashes?) which files have
> changed
> >> and
> >> > > > which
> >> > > > > >>>>> have
> >> > > > > >>>>>>> not,
> >> > > > > >>>>>>>>> but hashing them all is touching them all anyway, and
> it
> >> > > might
> >> > > > be
> >> > > > > >>>>> faster
> >> > > > > >>>>>>>>> for small files to just copy them instead of checking
> >> > first.
> >> > > > > >>> We'll
> >> > > > > >>>>> have
> >> > > > > >>>>>>> to
> >> > > > > >>>>>>>>> try it and see; for v1 I'm going with the simple
> option
> >> of
> >> > > > > >>> copying
> >> > > > > >>>>>>>>> everything.
> >> > > > > >>>>>>>>>
> >> > > > > >>>>>>>>> Braden
> >> > > > > >>>>>>>>>
> >> > > > > >>>>>>>>>
> >> > > > > >>>>>>>>> On Wed, Sep 25, 2013 at 9:44 AM, Michal Mocny <
> >> > > > > >>> mmocny@chromium.org
> >> > > > > >>>>>
> >> > > > > >>>>>>> wrote:
> >> > > > > >>>>>>>>>
> >> > > > > >>>>>>>>>> The idea for plugin dev outside of plugins/ folder
> was
> >> to
> >> > > use
> >> > > > > >>>>> "plugin
> >> > > > > >>>>>>> add
> >> > > > > >>>>>>>>>> --link".  Matter of fact, braden suggested that
> "plugin
> >> > > > create"
> >> > > > > >>>>> should
> >> > > > > >>>>>>>>>> default to --link-ing to some external location so
> that
> >> > you
> >> > > > > >>> don't
> >> > > > > >>>>> risk
> >> > > > > >>>>>>>>>> deleting your only copy inside plugins/.  (I
> personally
> >> > > don't
> >> > > > > >>>> think
> >> > > > > >>>>>>>>> thats a
> >> > > > > >>>>>>>>>> necessary concern, but I think its a conversation for
> >> > > later).
> >> > > > > >>>>>>>>>>
> >> > > > > >>>>>>>>>> I'm not even sure what a 'watch' would do, just
> >> uninstall
> >> > &
> >> > > > > >>>> install
> >> > > > > >>>>>>> each
> >> > > > > >>>>>>>>>> time the plugin changes?  I think that ends up being
> >> just
> >> > > > > >>>> slightly
> >> > > > > >>>>>>> worse
> >> > > > > >>>>>>>>>> than the current proposal if you factor in that we
> >> already
> >> > > do
> >> > > > > >>>>> support
> >> > > > > >>>>>>>>>> --link (except without the above change its been
> >> useless).
> >> > > > > >>>>>>>>>>
> >> > > > > >>>>>>>>>>
> >> > > > > >>>>>>>>>> However, we may still want some form of 'watch'
> command
> >> > for
> >> > > > > >>> devs
> >> > > > > >>>>> using
> >> > > > > >>>>>>>>>> plugman directly.  I had assumed that those devs just
> >> edit
> >> > > in
> >> > > > > >>>>> place,
> >> > > > > >>>>>>>>> since
> >> > > > > >>>>>>>>>> they don't use a prepare step anyway.
> >> > > > > >>>>>>>>>>
> >> > > > > >>>>>>>>>> -Michal
> >> > > > > >>>>>>>>>>
> >> > > > > >>>>>>>>>>
> >> > > > > >>>>>>>>>>
> >> > > > > >>>>>>>>>> On Wed, Sep 25, 2013 at 7:50 AM, Anis KADRI <
> >> > > > > >>>> anis.kadri@gmail.com>
> >> > > > > >>>>>>>>> wrote:
> >> > > > > >>>>>>>>>>
> >> > > > > >>>>>>>>>>> If we're talking about developing plugins inside the
> >> > > > > >>>>>>>>>>> plugins/org.myplugin.id folder than I think it's a
> >> great
> >> > > > > >>>>> workflow
> >> > > > > >>>>>>> and
> >> > > > > >>>>>>>>>>> I would just hide the cached version of plugin.xml
> >> inside
> >> > > > > >>> that
> >> > > > > >>>>>>>>>>> plugins/org.myplugin.id folder.
> >> > > > > >>>>>>>>>>>
> >> > > > > >>>>>>>>>>> However, if you're developing a plugin outside of a
> >> > cordova
> >> > > > > >>> CLI
> >> > > > > >>>>>>>>>>> project, I think a `watch` (and add --watch)
> command is
> >> > > more
> >> > > > > >>>>>>>>>>> appropriate. One of the reasons you would develop a
> >> > plugin
> >> > > > > >>>>> outside
> >> > > > > >>>>>>> of
> >> > > > > >>>>>>>>>>> a cordova CLI project is for easier version control
> >> (each
> >> > > > > >>>> plugin
> >> > > > > >>>>>>> would
> >> > > > > >>>>>>>>>>> have its own repository). The other cool thing about
> >> > > `watch`
> >> > > > > >>> is
> >> > > > > >>>>> that
> >> > > > > >>>>>>>>>>> it would copy the files that have actually changed
> and
> >> > not
> >> > > > > >>>>>>> everything
> >> > > > > >>>>>>>>>>> (some plugins have a LOT of files [1]).
> >> > > > > >>>>>>>>>>>
> >> > > > > >>>>>>>>>>> [1]
> >> https://github.com/phonegap/phonegap-facebook-plugin
> >> > > > > >>>>>>>>>>>
> >> > > > > >>>>>>>>>>> On Wed, Sep 25, 2013 at 3:30 AM, James Jong <
> >> > > > > >>>>> wjamesjong@gmail.com>
> >> > > > > >>>>>>>>>> wrote:
> >> > > > > >>>>>>>>>>>> +1 This is a cleaner workflow and should reduce
> some
> >> > > > > >>>> confusion.
> >> > > > > >>>>>>>>>>>>
> >> > > > > >>>>>>>>>>>> -James Jong
> >> > > > > >>>>>>>>>>>>
> >> > > > > >>>>>>>>>>>> On Sep 24, 2013, at 3:09 PM, Michal Mocny <
> >> > > > > >>>> mmocny@chromium.org
> >> > > > > >>>>>>
> >> > > > > >>>>>>>>> wrote:
> >> > > > > >>>>>>>>>>>>
> >> > > > > >>>>>>>>>>>>> Just to add, the reason for the "if" statement in
> >> step
> >> > > (2)
> >> > > > > >>>> is
> >> > > > > >>>>>>> that
> >> > > > > >>>>>>>>>>>>> uninstall & reinstall take a lot longer than just
> >> > moving
> >> > > a
> >> > > > > >>>> few
> >> > > > > >>>>>>>>> files,
> >> > > > > >>>>>>>>>>> which
> >> > > > > >>>>>>>>>>>>> is the 99.9% case for most end users who aren't
> >> making
> >> > > > > >>>>>>> modifications
> >> > > > > >>>>>>>>>> to
> >> > > > > >>>>>>>>>>>>> plugins.
> >> > > > > >>>>>>>>>>>>>
> >> > > > > >>>>>>>>>>>>> This way, we only do the heavy lifting if your
> plugin
> >> > > > > >>>>> structure
> >> > > > > >>>>>>>>>> actually
> >> > > > > >>>>>>>>>>>>> changed.  Doing it automatically means we no
> longer
> >> > have
> >> > > > > >>> to
> >> > > > > >>>>>>> advise
> >> > > > > >>>>>>>>>> users
> >> > > > > >>>>>>>>>>>>> that making edits inside plugin/ folder is
> useless.
> >> >  Now
> >> > > > > >>> we
> >> > > > > >>>>> just
> >> > > > > >>>>>>>>>> advise
> >> > > > > >>>>>>>>>>>>> them to run "prepare" after making changes to
> either
> >> > www/
> >> > > > > >>> or
> >> > > > > >>>>>>>>> plugins/.
> >> > > > > >>>>>>>>>>>>>
> >> > > > > >>>>>>>>>>>>> This key insight was Braden's idea and I think its
> >> just
> >> > > an
> >> > > > > >>>>>>> awesome
> >> > > > > >>>>>>>>>>> change
> >> > > > > >>>>>>>>>>>>> for workflow.
> >> > > > > >>>>>>>>>>>>>
> >> > > > > >>>>>>>>>>>>> -Michal
> >> > > > > >>>>>>>>>>>>>
> >> > > > > >>>>>>>>>>>>>
> >> > > > > >>>>>>>>>>>>> On Tue, Sep 24, 2013 at 2:58 PM, Braden
> Shepherdson <
> >> > > > > >>>>>>>>>>> braden@chromium.org>wrote:
> >> > > > > >>>>>>>>>>>>>
> >> > > > > >>>>>>>>>>>>>> Michal and I were discussing how to make the
> plugin
> >> > > > > >>>> developer
> >> > > > > >>>>>>>>>>> experience
> >> > > > > >>>>>>>>>>>>>> better, by having `cordova prepare` update the
> >> > platform
> >> > > > > >>>>> projects
> >> > > > > >>>>>>>>>>> properly
> >> > > > > >>>>>>>>>>>>>> when you change a plugin in place.
> >> > > > > >>>>>>>>>>>>>>
> >> > > > > >>>>>>>>>>>>>> I propose the following changes:
> >> > > > > >>>>>>>>>>>>>>
> >> > > > > >>>>>>>>>>>>>> 1. On plugin install, we cache the plugin.xml in
> >> > > > > >>>>>>> $PROJECT/.cordova
> >> > > > > >>>>>>>>>>>>>> somewhere.
> >> > > > > >>>>>>>>>>>>>> 2. On 'cordova prepare', compare each plugin's
> >> > > plugin.xml
> >> > > > > >>>>>>> against
> >> > > > > >>>>>>>>> the
> >> > > > > >>>>>>>>>>>>>> cached one.
> >> > > > > >>>>>>>>>>>>>>   a. If they have changed, uninstall the plugin
> >> using
> >> > > > > >>> the
> >> > > > > >>>>> old
> >> > > > > >>>>>>>>>>> plugin.xml,
> >> > > > > >>>>>>>>>>>>>> then reinstall using the new one (and update the
> >> > cached
> >> > > > > >>>>>>>>> plugin.xml).
> >> > > > > >>>>>>>>>>>>>>   b. If they are identical, copy all the native
> code
> >> > > > > >>> files
> >> > > > > >>>>> from
> >> > > > > >>>>>>>>> the
> >> > > > > >>>>>>>>>>>>>> plugin into the project again.
> >> > > > > >>>>>>>>>>>>>>
> >> > > > > >>>>>>>>>>>>>> The idea is that you can change your plugin's
> native
> >> > > > > >>> code,
> >> > > > > >>>> JS
> >> > > > > >>>>>>>>>> modules,
> >> > > > > >>>>>>>>>>> or
> >> > > > > >>>>>>>>>>>>>> assets, and after a prepare you'll be running the
> >> > > latest.
> >> > > > > >>>> We
> >> > > > > >>>>>>>>> already
> >> > > > > >>>>>>>>>>> have
> >> > > > > >>>>>>>>>>>>>> cordova plugin add foo --link, but it wasn't very
> >> > > useful.
> >> > > > > >>>>> This
> >> > > > > >>>>>>> will
> >> > > > > >>>>>>>>>>> make
> >> > > > > >>>>>>>>>>>>>> plugin development a much smoother flow, without
> too
> >> > > much
> >> > > > > >>>>>>>>>>> implementation
> >> > > > > >>>>>>>>>>>>>> effort.
> >> > > > > >>>>>>>>>>>>>>
> >> > > > > >>>>>>>>>>>>>> Checking for changes to plugin.xml lets us know
> that
> >> > no
> >> > > > > >>>> files
> >> > > > > >>>>>>> have
> >> > > > > >>>>>>>>>> been
> >> > > > > >>>>>>>>>>>>>> added or removed, that <config-file> edits
> haven't
> >> > > > > >>> changed,
> >> > > > > >>>>> and
> >> > > > > >>>>>>> so
> >> > > > > >>>>>>>>>> on,
> >> > > > > >>>>>>>>>>>>>> meaning that simply copying the native code again
> >> will
> >> > > be
> >> > > > > >>>>>>>>> sufficient.
> >> > > > > >>>>>>>>>>>>>>
> >> > > > > >>>>>>>>>>>>>> What do people think? Any gotchas that I
> overlooked?
> >> > > > > >>>>>>>>>>>>>>
> >> > > > > >>>>>>>>>>>>>> Braden
> >> > > > > >>>>>>>>>>>>>>
> >> > > > > >>>>>>>>>>>>
> >> > > > > >>>>>>>>>>>
> >> > > > > >>>>>>>>>>
> >> > > > > >>>>>>>>>
> >> > > > > >>>>>>>
> >> > > > > >>>>>
> >> > > > > >>>>
> >> > > > > >>>
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
>



-- 
Carlos Santana
<csantana23@gmail.com>

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