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, 26 Sep 2013 22:11:10 GMT
@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
>> > > >> >> > > >>>
>> > > >> >> > > >
>> > > >> >> > >
>> > > >> >> >
>> > > >> >>
>> > > >>
>> > >
>> >
>>

Mime
View raw message