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 <bra...@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 <csantan...@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.ka...@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 <mmo...@chromium.org>
wrote:
On Fri, Sep 27, 2013 at 2:10 PM, Andrew Grieve <agri...@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 <mmo...@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 <
bra...@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 <
agri...@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 <
msie...@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 [twil...@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.ka...@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 <
mmo...@chromium.org
wrote:
On Thu, Sep 26, 2013 at 1:39 PM, Jesse <
purplecabb...@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.ka...@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 <
bra...@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.ka...@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 <
mmo...@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
<
bra...@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 <
mmo...@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.ka...@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 <
wjamesj...@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 <
mmo...@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 <
bra...@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
<csantan...@gmail.com>
