subject:"config.xml discussion, we need to talk"

John: If you decided to take a stab a blogging about it, please think about
blogging on the cordova site! We can all review it before publishing it too!

Erik: that video was awesome! Let me know when Gorkem does a release and I
can post it on the cordova twitter feed.

Michal: Could just be CLI vs Plugman workflow


On Fri, Oct 18, 2013 at 10:21 AM, Michal Mocny mmo...@chromium.org wrote:

 I wonder if we should not work out better names for the two workflows.
  Both are kinda command-line-based so saying CLI vs old is confusing.
  As is saying the bin/ script flow confusing.  Not sure if multi vs
 single platform flow is any better, since you can use both flows for one
 or more platforms.

 Anyway, if we have more obvious/catchy names, then we can be more clear in
 our communications which flow our answers are relevant to.  i.e., use
 plugman to ... (only for ___ flow).  i.e., Be carefully when editing in
 IDE ... (only for ___ flow).

 -Michal


 On Fri, Oct 18, 2013 at 1:14 PM, Anis KADRI anis.ka...@gmail.com wrote:

  Erik that's great! Where can we download it?
  On Oct 18, 2013 8:01 AM, Andrew Grieve agri...@chromium.org wrote:
 
   Awesome video!!
  
  
   On Fri, Oct 18, 2013 at 3:43 AM, Erik Jan de Wit ede...@redhat.com
   wrote:
  
On the topic of IDE support my collage Gorkem has made a nice wizard
 in
eclipse that mimics the CLI have a look at this video
   
http://www.youtube.com/watch?v=QUyUUtmTYok
   
On 18 Oct,2013, at 4:29 , Maxime LUCE max...@somatic.fr wrote:
   
 Great Bryan
 Totally agree !!!

 Cordialement.
 ---
 Maxime LUCE - Somatic
 maxime.l...@somatic.fr
 06 28 60 72 34
 
 De : Brian LeRouxmailto:b...@brian.io
 Envoyé : 18/10/2013 01:48
 À : dev@cordova.apache.orgmailto:dev@cordova.apache.org
 Objet : Re: config.xml discussion, we need to talk

 I don't really appreciate comments that we don't talk to our users,
  or
build apps in anger. Neither of those assertions are true. The
 origins
  of
these initiatives are based on both community feedback, and direct
experience.

 Keeping your focus on just pure platform side of a project is fine,
  of
course, since the CLI delegates to the platform. This was also a
   deliberate
learning from MANY attempts at an architecture that satisfies both
approaches. It separates the concerns and respects the platform will
 be
canonical for the common workflows supported. This is a very real
  example
of Conway's Law btw. [1]

 Anyhow. Deep breath! Software has bugs, people will report them,
 and
we'll continue to improve. This is a very large group with a very
  diverse
community that spans regular old hackers to the humble web designers.
  We
need to respect that, and maybe be a little more compassionate to
 each
other too. All software is fucked up, and at the end of the day, it
 is
   our
perpetual job to make it a little less fucked up.

 [1] http://en.wikipedia.org/wiki/Conway's_law


 [Inline image 1]






 On Thu, Oct 17, 2013 at 1:16 PM, Tommy Williams 
 to...@devgeeks.org
mailto:to...@devgeeks.org wrote:
 Late to the party due to timezone fun, but I just want to chime in
 in
 support of the CLI.

 As a dev working on an actual nontrivial real world app, I would
  like
to
 let it be known that we (SpiderOak) have been heavy drinkers of the
  CLI
 Kool-Aid since its infancy.

 We have even managed to get to the point where ./platforms/**/* is
   just a
 build artefact (mostly by using hooks and tying the whole thing
   together
 with Grunt).

 We have a fast and fairly complex app (both many core plugins as
 well
and a
 few custom/third party ones), that even includes the ability to
 white
label
 it with relative ease.

 I feel pretty strongly in favour of the CLI and strongly advocate
 its
   use
 when asked in the #phonegap IRC channel.

 Just my opinion, but thought it was important to add to the
  discussion.

 - tommy / devgeeks
 On 18 Oct 2013 04:44, Anis KADRI anis.ka...@gmail.commailto:
anis.ka...@gmail.com wrote:

 Sweet. So I think we all agree (expect Joe perhaps?) that both
 approaches should be supported :-)

 On Thu, Oct 17, 2013 at 10:31 AM, Carlos Santana 
   csantan...@gmail.com
mailto:csantan...@gmail.com
 wrote:
 I meant in addition of .cordova/lib also allow also to do
  something
 like
 cordova platform add ios
 --path=./cordova_components/cordova-ios



 On Thu, Oct 17, 2013 at 1:28 PM, Carlos Santana 
   csantan...@gmail.com
mailto:csantan...@gmail.com
 wrote:

 ++1  to install from a given directory instead of
 .cordova/libs.



 On Thu, Oct 17, 2013 at 12:10 PM, Viras 
   vi

Re: config.xml discussion, we need to talk

2013-10-18 Thread Jesse

SinglePlatform vs MultiPlatform makes the most sense to me.

SinglePlatform = Focus on a single platform, and use plugman and the
platform scripts directly. Useful when you only have that particular device
to test on, or only have access to that device's marketplace.  Also useful
for platform developers who are focused primarily on the native code.
( aka DivideAndConquer )

MultiPlatform = Build your app for a bunch of platforms at the same time.
Great for when you know you are targeting multiple stores/devices.
( aka DucksInARow or MagicBullet )

I tend to lean towards the SinglePlatform, so maybe someone else could
enumerate more Multi benefits.


@purplecabbage
risingj.com


On Fri, Oct 18, 2013 at 11:28 AM, Steven Gill stevengil...@gmail.comwrote:

 John: If you decided to take a stab a blogging about it, please think about
 blogging on the cordova site! We can all review it before publishing it
 too!

 Erik: that video was awesome! Let me know when Gorkem does a release and I
 can post it on the cordova twitter feed.

 Michal: Could just be CLI vs Plugman workflow


 On Fri, Oct 18, 2013 at 10:21 AM, Michal Mocny mmo...@chromium.org
 wrote:

  I wonder if we should not work out better names for the two workflows.
   Both are kinda command-line-based so saying CLI vs old is confusing.
   As is saying the bin/ script flow confusing.  Not sure if multi vs
  single platform flow is any better, since you can use both flows for
 one
  or more platforms.
 
  Anyway, if we have more obvious/catchy names, then we can be more clear
 in
  our communications which flow our answers are relevant to.  i.e., use
  plugman to ... (only for ___ flow).  i.e., Be carefully when editing in
  IDE ... (only for ___ flow).
 
  -Michal
 
 
  On Fri, Oct 18, 2013 at 1:14 PM, Anis KADRI anis.ka...@gmail.com
 wrote:
 
   Erik that's great! Where can we download it?
   On Oct 18, 2013 8:01 AM, Andrew Grieve agri...@chromium.org wrote:
  
Awesome video!!
   
   
On Fri, Oct 18, 2013 at 3:43 AM, Erik Jan de Wit ede...@redhat.com
wrote:
   
 On the topic of IDE support my collage Gorkem has made a nice
 wizard
  in
 eclipse that mimics the CLI have a look at this video

 http://www.youtube.com/watch?v=QUyUUtmTYok

 On 18 Oct,2013, at 4:29 , Maxime LUCE max...@somatic.fr wrote:

  Great Bryan
  Totally agree !!!
 
  Cordialement.
  ---
  Maxime LUCE - Somatic
  maxime.l...@somatic.fr
  06 28 60 72 34
  
  De : Brian LeRouxmailto:b...@brian.io
  Envoyé : 18/10/2013 01:48
  À : dev@cordova.apache.orgmailto:dev@cordova.apache.org
  Objet : Re: config.xml discussion, we need to talk
 
  I don't really appreciate comments that we don't talk to our
 users,
   or
 build apps in anger. Neither of those assertions are true. The
  origins
   of
 these initiatives are based on both community feedback, and direct
 experience.
 
  Keeping your focus on just pure platform side of a project is
 fine,
   of
 course, since the CLI delegates to the platform. This was also a
deliberate
 learning from MANY attempts at an architecture that satisfies both
 approaches. It separates the concerns and respects the platform
 will
  be
 canonical for the common workflows supported. This is a very real
   example
 of Conway's Law btw. [1]
 
  Anyhow. Deep breath! Software has bugs, people will report them,
  and
 we'll continue to improve. This is a very large group with a very
   diverse
 community that spans regular old hackers to the humble web
 designers.
   We
 need to respect that, and maybe be a little more compassionate to
  each
 other too. All software is fucked up, and at the end of the day, it
  is
our
 perpetual job to make it a little less fucked up.
 
  [1] http://en.wikipedia.org/wiki/Conway's_law
 
 
  [Inline image 1]
 
 
 
 
 
 
  On Thu, Oct 17, 2013 at 1:16 PM, Tommy Williams 
  to...@devgeeks.org
 mailto:to...@devgeeks.org wrote:
  Late to the party due to timezone fun, but I just want to chime
 in
  in
  support of the CLI.
 
  As a dev working on an actual nontrivial real world app, I
 would
   like
 to
  let it be known that we (SpiderOak) have been heavy drinkers of
 the
   CLI
  Kool-Aid since its infancy.
 
  We have even managed to get to the point where ./platforms/**/*
 is
just a
  build artefact (mostly by using hooks and tying the whole thing
together
  with Grunt).
 
  We have a fast and fairly complex app (both many core plugins as
  well
 and a
  few custom/third party ones), that even includes the ability to
  white
 label
  it with relative ease.
 
  I feel pretty strongly in favour of the CLI and strongly advocate
  its
use
  when asked

Re: config.xml discussion, we need to talk

2013-10-18 Thread Michal Mocny

On Fri, Oct 18, 2013 at 2:28 PM, Steven Gill stevengil...@gmail.com wrote:

 John: If you decided to take a stab a blogging about it, please think about
 blogging on the cordova site! We can all review it before publishing it
 too!

 Erik: that video was awesome! Let me know when Gorkem does a release and I
 can post it on the cordova twitter feed.

 Michal: Could just be CLI vs Plugman workflow


I'm not necessarily against that naming, but the observation is that both
use the command line (aka a CLI if not the CLI), and CLI also uses
new-plugin style, which is documented with plugman, and Plugman flow may
be used without actually using the plugman tool in theory (just old style
manual moving of assets).

For someone new to cordova without history of how/why we got to these
names, what would very clearly convey the intent?



 On Fri, Oct 18, 2013 at 10:21 AM, Michal Mocny mmo...@chromium.org
 wrote:

  I wonder if we should not work out better names for the two workflows.
   Both are kinda command-line-based so saying CLI vs old is confusing.
   As is saying the bin/ script flow confusing.  Not sure if multi vs
  single platform flow is any better, since you can use both flows for
 one
  or more platforms.
 
  Anyway, if we have more obvious/catchy names, then we can be more clear
 in
  our communications which flow our answers are relevant to.  i.e., use
  plugman to ... (only for ___ flow).  i.e., Be carefully when editing in
  IDE ... (only for ___ flow).
 
  -Michal
 
 
  On Fri, Oct 18, 2013 at 1:14 PM, Anis KADRI anis.ka...@gmail.com
 wrote:
 
   Erik that's great! Where can we download it?
   On Oct 18, 2013 8:01 AM, Andrew Grieve agri...@chromium.org wrote:
  
Awesome video!!
   
   
On Fri, Oct 18, 2013 at 3:43 AM, Erik Jan de Wit ede...@redhat.com
wrote:
   
 On the topic of IDE support my collage Gorkem has made a nice
 wizard
  in
 eclipse that mimics the CLI have a look at this video

 http://www.youtube.com/watch?v=QUyUUtmTYok

 On 18 Oct,2013, at 4:29 , Maxime LUCE max...@somatic.fr wrote:

  Great Bryan
  Totally agree !!!
 
  Cordialement.
  ---
  Maxime LUCE - Somatic
  maxime.l...@somatic.fr
  06 28 60 72 34
  
  De : Brian LeRouxmailto:b...@brian.io
  Envoyé : 18/10/2013 01:48
  À : dev@cordova.apache.orgmailto:dev@cordova.apache.org
  Objet : Re: config.xml discussion, we need to talk
 
  I don't really appreciate comments that we don't talk to our
 users,
   or
 build apps in anger. Neither of those assertions are true. The
  origins
   of
 these initiatives are based on both community feedback, and direct
 experience.
 
  Keeping your focus on just pure platform side of a project is
 fine,
   of
 course, since the CLI delegates to the platform. This was also a
deliberate
 learning from MANY attempts at an architecture that satisfies both
 approaches. It separates the concerns and respects the platform
 will
  be
 canonical for the common workflows supported. This is a very real
   example
 of Conway's Law btw. [1]
 
  Anyhow. Deep breath! Software has bugs, people will report them,
  and
 we'll continue to improve. This is a very large group with a very
   diverse
 community that spans regular old hackers to the humble web
 designers.
   We
 need to respect that, and maybe be a little more compassionate to
  each
 other too. All software is fucked up, and at the end of the day, it
  is
our
 perpetual job to make it a little less fucked up.
 
  [1] http://en.wikipedia.org/wiki/Conway's_law
 
 
  [Inline image 1]
 
 
 
 
 
 
  On Thu, Oct 17, 2013 at 1:16 PM, Tommy Williams 
  to...@devgeeks.org
 mailto:to...@devgeeks.org wrote:
  Late to the party due to timezone fun, but I just want to chime
 in
  in
  support of the CLI.
 
  As a dev working on an actual nontrivial real world app, I
 would
   like
 to
  let it be known that we (SpiderOak) have been heavy drinkers of
 the
   CLI
  Kool-Aid since its infancy.
 
  We have even managed to get to the point where ./platforms/**/*
 is
just a
  build artefact (mostly by using hooks and tying the whole thing
together
  with Grunt).
 
  We have a fast and fairly complex app (both many core plugins as
  well
 and a
  few custom/third party ones), that even includes the ability to
  white
 label
  it with relative ease.
 
  I feel pretty strongly in favour of the CLI and strongly advocate
  its
use
  when asked in the #phonegap IRC channel.
 
  Just my opinion, but thought it was important to add to the
   discussion.
 
  - tommy / devgeeks
  On 18 Oct 2013 04:44, Anis KADRI anis.ka...@gmail.commailto:
 anis.ka...@gmail.com wrote

Re: config.xml discussion, we need to talk

I think SinplePlatform vs MultiPlatform is misleading because you can use
the CLI to do single platform development.


On Fri, Oct 18, 2013 at 11:51 AM, Jesse purplecabb...@gmail.com wrote:

 SinglePlatform vs MultiPlatform makes the most sense to me.

 SinglePlatform = Focus on a single platform, and use plugman and the
 platform scripts directly. Useful when you only have that particular device
 to test on, or only have access to that device's marketplace.  Also useful
 for platform developers who are focused primarily on the native code.
 ( aka DivideAndConquer )

 MultiPlatform = Build your app for a bunch of platforms at the same time.
 Great for when you know you are targeting multiple stores/devices.
 ( aka DucksInARow or MagicBullet )

 I tend to lean towards the SinglePlatform, so maybe someone else could
 enumerate more Multi benefits.


 @purplecabbage
 risingj.com


 On Fri, Oct 18, 2013 at 11:28 AM, Steven Gill stevengil...@gmail.com
 wrote:

  John: If you decided to take a stab a blogging about it, please think
 about
  blogging on the cordova site! We can all review it before publishing it
  too!
 
  Erik: that video was awesome! Let me know when Gorkem does a release and
 I
  can post it on the cordova twitter feed.
 
  Michal: Could just be CLI vs Plugman workflow
 
 
  On Fri, Oct 18, 2013 at 10:21 AM, Michal Mocny mmo...@chromium.org
  wrote:
 
   I wonder if we should not work out better names for the two workflows.
Both are kinda command-line-based so saying CLI vs old is
 confusing.
As is saying the bin/ script flow confusing.  Not sure if multi vs
   single platform flow is any better, since you can use both flows for
  one
   or more platforms.
  
   Anyway, if we have more obvious/catchy names, then we can be more clear
  in
   our communications which flow our answers are relevant to.  i.e., use
   plugman to ... (only for ___ flow).  i.e., Be carefully when editing
 in
   IDE ... (only for ___ flow).
  
   -Michal
  
  
   On Fri, Oct 18, 2013 at 1:14 PM, Anis KADRI anis.ka...@gmail.com
  wrote:
  
Erik that's great! Where can we download it?
On Oct 18, 2013 8:01 AM, Andrew Grieve agri...@chromium.org
 wrote:
   
 Awesome video!!


 On Fri, Oct 18, 2013 at 3:43 AM, Erik Jan de Wit 
 ede...@redhat.com
 wrote:

  On the topic of IDE support my collage Gorkem has made a nice
  wizard
   in
  eclipse that mimics the CLI have a look at this video
 
  http://www.youtube.com/watch?v=QUyUUtmTYok
 
  On 18 Oct,2013, at 4:29 , Maxime LUCE max...@somatic.fr wrote:
 
   Great Bryan
   Totally agree !!!
  
   Cordialement.
   ---
   Maxime LUCE - Somatic
   maxime.l...@somatic.fr
   06 28 60 72 34
   
   De : Brian LeRouxmailto:b...@brian.io
   Envoyé : 18/10/2013 01:48
   À : dev@cordova.apache.orgmailto:dev@cordova.apache.org
   Objet : Re: config.xml discussion, we need to talk
  
   I don't really appreciate comments that we don't talk to our
  users,
or
  build apps in anger. Neither of those assertions are true. The
   origins
of
  these initiatives are based on both community feedback, and
 direct
  experience.
  
   Keeping your focus on just pure platform side of a project is
  fine,
of
  course, since the CLI delegates to the platform. This was also a
 deliberate
  learning from MANY attempts at an architecture that satisfies
 both
  approaches. It separates the concerns and respects the platform
  will
   be
  canonical for the common workflows supported. This is a very real
example
  of Conway's Law btw. [1]
  
   Anyhow. Deep breath! Software has bugs, people will report
 them,
   and
  we'll continue to improve. This is a very large group with a very
diverse
  community that spans regular old hackers to the humble web
  designers.
We
  need to respect that, and maybe be a little more compassionate to
   each
  other too. All software is fucked up, and at the end of the day,
 it
   is
 our
  perpetual job to make it a little less fucked up.
  
   [1] http://en.wikipedia.org/wiki/Conway's_law
  
  
   [Inline image 1]
  
  
  
  
  
  
   On Thu, Oct 17, 2013 at 1:16 PM, Tommy Williams 
   to...@devgeeks.org
  mailto:to...@devgeeks.org wrote:
   Late to the party due to timezone fun, but I just want to chime
  in
   in
   support of the CLI.
  
   As a dev working on an actual nontrivial real world app, I
  would
like
  to
   let it be known that we (SpiderOak) have been heavy drinkers of
  the
CLI
   Kool-Aid since its infancy.
  
   We have even managed to get to the point where ./platforms/**/*
  is
 just a
   build artefact (mostly by using hooks and tying the whole thing
 together

Re: config.xml discussion, we need to talk

2013-10-18 Thread Jesse

 IDE or cordova-cli ??

@purplecabbage
risingj.com


On Fri, Oct 18, 2013 at 12:02 PM, Steven Gill stevengil...@gmail.comwrote:

 I think SinplePlatform vs MultiPlatform is misleading because you can use
 the CLI to do single platform development.


 On Fri, Oct 18, 2013 at 11:51 AM, Jesse purplecabb...@gmail.com wrote:

  SinglePlatform vs MultiPlatform makes the most sense to me.
 
  SinglePlatform = Focus on a single platform, and use plugman and the
  platform scripts directly. Useful when you only have that particular
 device
  to test on, or only have access to that device's marketplace.  Also
 useful
  for platform developers who are focused primarily on the native code.
  ( aka DivideAndConquer )
 
  MultiPlatform = Build your app for a bunch of platforms at the same time.
  Great for when you know you are targeting multiple stores/devices.
  ( aka DucksInARow or MagicBullet )
 
  I tend to lean towards the SinglePlatform, so maybe someone else could
  enumerate more Multi benefits.
 
 
  @purplecabbage
  risingj.com
 
 
  On Fri, Oct 18, 2013 at 11:28 AM, Steven Gill stevengil...@gmail.com
  wrote:
 
   John: If you decided to take a stab a blogging about it, please think
  about
   blogging on the cordova site! We can all review it before publishing it
   too!
  
   Erik: that video was awesome! Let me know when Gorkem does a release
 and
  I
   can post it on the cordova twitter feed.
  
   Michal: Could just be CLI vs Plugman workflow
  
  
   On Fri, Oct 18, 2013 at 10:21 AM, Michal Mocny mmo...@chromium.org
   wrote:
  
I wonder if we should not work out better names for the two
 workflows.
 Both are kinda command-line-based so saying CLI vs old is
  confusing.
 As is saying the bin/ script flow confusing.  Not sure if multi
 vs
single platform flow is any better, since you can use both flows
 for
   one
or more platforms.
   
Anyway, if we have more obvious/catchy names, then we can be more
 clear
   in
our communications which flow our answers are relevant to.  i.e.,
 use
plugman to ... (only for ___ flow).  i.e., Be carefully when
 editing
  in
IDE ... (only for ___ flow).
   
-Michal
   
   
On Fri, Oct 18, 2013 at 1:14 PM, Anis KADRI anis.ka...@gmail.com
   wrote:
   
 Erik that's great! Where can we download it?
 On Oct 18, 2013 8:01 AM, Andrew Grieve agri...@chromium.org
  wrote:

  Awesome video!!
 
 
  On Fri, Oct 18, 2013 at 3:43 AM, Erik Jan de Wit 
  ede...@redhat.com
  wrote:
 
   On the topic of IDE support my collage Gorkem has made a nice
   wizard
in
   eclipse that mimics the CLI have a look at this video
  
   http://www.youtube.com/watch?v=QUyUUtmTYok
  
   On 18 Oct,2013, at 4:29 , Maxime LUCE max...@somatic.fr
 wrote:
  
Great Bryan
Totally agree !!!
   
Cordialement.
---
Maxime LUCE - Somatic
maxime.l...@somatic.fr
06 28 60 72 34

De : Brian LeRouxmailto:b...@brian.io
Envoyé : 18/10/2013 01:48
À : dev@cordova.apache.orgmailto:dev@cordova.apache.org
Objet : Re: config.xml discussion, we need to talk
   
I don't really appreciate comments that we don't talk to our
   users,
 or
   build apps in anger. Neither of those assertions are true. The
origins
 of
   these initiatives are based on both community feedback, and
  direct
   experience.
   
Keeping your focus on just pure platform side of a project is
   fine,
 of
   course, since the CLI delegates to the platform. This was also
 a
  deliberate
   learning from MANY attempts at an architecture that satisfies
  both
   approaches. It separates the concerns and respects the platform
   will
be
   canonical for the common workflows supported. This is a very
 real
 example
   of Conway's Law btw. [1]
   
Anyhow. Deep breath! Software has bugs, people will report
  them,
and
   we'll continue to improve. This is a very large group with a
 very
 diverse
   community that spans regular old hackers to the humble web
   designers.
 We
   need to respect that, and maybe be a little more compassionate
 to
each
   other too. All software is fucked up, and at the end of the
 day,
  it
is
  our
   perpetual job to make it a little less fucked up.
   
[1] http://en.wikipedia.org/wiki/Conway's_law
   
   
[Inline image 1]
   
   
   
   
   
   
On Thu, Oct 17, 2013 at 1:16 PM, Tommy Williams 
to...@devgeeks.org
   mailto:to...@devgeeks.org wrote:
Late to the party due to timezone fun, but I just want to
 chime
   in
in
support of the CLI.
   
As a dev working on an actual nontrivial real world app, I
   would
 like

Re: config.xml discussion, we need to talk

I like that better.

I know that both methods use the command line, but the cordova-cli has cli
in its name! We call the tool the cordova-cli so it might be more confusing
going away from that and calling it anything else. Not saying we shouldn't
be open to a name change though just because we called it X since its
inception (or am I saying that? :P).

When we write the docs about the other workflow (bin/create, plugman),
maybe making the IDE an integral part of it would make it make more sense
calling that workflow IDE. Just a thought.


On Fri, Oct 18, 2013 at 12:09 PM, Jesse purplecabb...@gmail.com wrote:

  IDE or cordova-cli ??

 @purplecabbage
 risingj.com


 On Fri, Oct 18, 2013 at 12:02 PM, Steven Gill stevengil...@gmail.com
 wrote:

  I think SinplePlatform vs MultiPlatform is misleading because you can use
  the CLI to do single platform development.
 
 
  On Fri, Oct 18, 2013 at 11:51 AM, Jesse purplecabb...@gmail.com wrote:
 
   SinglePlatform vs MultiPlatform makes the most sense to me.
  
   SinglePlatform = Focus on a single platform, and use plugman and the
   platform scripts directly. Useful when you only have that particular
  device
   to test on, or only have access to that device's marketplace.  Also
  useful
   for platform developers who are focused primarily on the native code.
   ( aka DivideAndConquer )
  
   MultiPlatform = Build your app for a bunch of platforms at the same
 time.
   Great for when you know you are targeting multiple stores/devices.
   ( aka DucksInARow or MagicBullet )
  
   I tend to lean towards the SinglePlatform, so maybe someone else could
   enumerate more Multi benefits.
  
  
   @purplecabbage
   risingj.com
  
  
   On Fri, Oct 18, 2013 at 11:28 AM, Steven Gill stevengil...@gmail.com
   wrote:
  
John: If you decided to take a stab a blogging about it, please think
   about
blogging on the cordova site! We can all review it before publishing
 it
too!
   
Erik: that video was awesome! Let me know when Gorkem does a release
  and
   I
can post it on the cordova twitter feed.
   
Michal: Could just be CLI vs Plugman workflow
   
   
On Fri, Oct 18, 2013 at 10:21 AM, Michal Mocny mmo...@chromium.org
wrote:
   
 I wonder if we should not work out better names for the two
  workflows.
  Both are kinda command-line-based so saying CLI vs old is
   confusing.
  As is saying the bin/ script flow confusing.  Not sure if
 multi
  vs
 single platform flow is any better, since you can use both flows
  for
one
 or more platforms.

 Anyway, if we have more obvious/catchy names, then we can be more
  clear
in
 our communications which flow our answers are relevant to.  i.e.,
  use
 plugman to ... (only for ___ flow).  i.e., Be carefully when
  editing
   in
 IDE ... (only for ___ flow).

 -Michal


 On Fri, Oct 18, 2013 at 1:14 PM, Anis KADRI anis.ka...@gmail.com
wrote:

  Erik that's great! Where can we download it?
  On Oct 18, 2013 8:01 AM, Andrew Grieve agri...@chromium.org
   wrote:
 
   Awesome video!!
  
  
   On Fri, Oct 18, 2013 at 3:43 AM, Erik Jan de Wit 
   ede...@redhat.com
   wrote:
  
On the topic of IDE support my collage Gorkem has made a nice
wizard
 in
eclipse that mimics the CLI have a look at this video
   
http://www.youtube.com/watch?v=QUyUUtmTYok
   
On 18 Oct,2013, at 4:29 , Maxime LUCE max...@somatic.fr
  wrote:
   
 Great Bryan
 Totally agree !!!

 Cordialement.
 ---
 Maxime LUCE - Somatic
 maxime.l...@somatic.fr
 06 28 60 72 34
 
 De : Brian LeRouxmailto:b...@brian.io
 Envoyé : 18/10/2013 01:48
 À : dev@cordova.apache.orgmailto:dev@cordova.apache.org
 Objet : Re: config.xml discussion, we need to talk

 I don't really appreciate comments that we don't talk to
 our
users,
  or
build apps in anger. Neither of those assertions are true.
 The
 origins
  of
these initiatives are based on both community feedback, and
   direct
experience.

 Keeping your focus on just pure platform side of a project
 is
fine,
  of
course, since the CLI delegates to the platform. This was
 also
  a
   deliberate
learning from MANY attempts at an architecture that satisfies
   both
approaches. It separates the concerns and respects the
 platform
will
 be
canonical for the common workflows supported. This is a very
  real
  example
of Conway's Law btw. [1]

 Anyhow. Deep breath! Software has bugs, people will report
   them,
 and
we'll continue to improve. This is a very large group with a
  very
  diverse
community that spans regular old

Re: config.xml discussion, we need to talk

  
   Objet : Re: config.xml discussion, we need to talk
  
   I don't really appreciate comments that we don't talk
 to
   our
  users,
or
  build apps in anger. Neither of those assertions are
 true.
   The
   origins
of
  these initiatives are based on both community feedback,
 and
 direct
  experience.
  
   Keeping your focus on just pure platform side of a
  project
   is
  fine,
of
  course, since the CLI delegates to the platform. This was
   also
a
 deliberate
  learning from MANY attempts at an architecture that
  satisfies
 both
  approaches. It separates the concerns and respects the
   platform
  will
   be
  canonical for the common workflows supported. This is a
  very
real
example
  of Conway's Law btw. [1]
  
   Anyhow. Deep breath! Software has bugs, people will
  report
 them,
   and
  we'll continue to improve. This is a very large group
 with
  a
very
diverse
  community that spans regular old hackers to the humble
 web
  designers.
We
  need to respect that, and maybe be a little more
   compassionate
to
   each
  other too. All software is fucked up, and at the end of
 the
day,
 it
   is
 our
  perpetual job to make it a little less fucked up.
  
   [1] http://en.wikipedia.org/wiki/Conway's_law
  
  
   [Inline image 1]
  
  
  
  
  
  
   On Thu, Oct 17, 2013 at 1:16 PM, Tommy Williams 
   to...@devgeeks.org
  mailto:to...@devgeeks.org wrote:
   Late to the party due to timezone fun, but I just want
 to
chime
  in
   in
   support of the CLI.
  
   As a dev working on an actual nontrivial real world
  app,
   I
  would
like
  to
   let it be known that we (SpiderOak) have been heavy
   drinkers
of
  the
CLI
   Kool-Aid since its infancy.
  
   We have even managed to get to the point where
./platforms/**/*
  is
 just a
   build artefact (mostly by using hooks and tying the
 whole
thing
 together
   with Grunt).
  
   We have a fast and fairly complex app (both many core
   plugins
 as
   well
  and a
   few custom/third party ones), that even includes the
   ability
to
   white
  label
   it with relative ease.
  
   I feel pretty strongly in favour of the CLI and
 strongly
 advocate
   its
 use
   when asked in the #phonegap IRC channel.
  
   Just my opinion, but thought it was important to add to
  the
discussion.
  
   - tommy / devgeeks
   On 18 Oct 2013 04:44, Anis KADRI 
 anis.ka...@gmail.com
 mailto:
  anis.ka...@gmail.com wrote:
  
   Sweet. So I think we all agree (expect Joe perhaps?)
  that
both
   approaches should be supported :-)
  
   On Thu, Oct 17, 2013 at 10:31 AM, Carlos Santana 
 csantan...@gmail.com
  mailto:csantan...@gmail.com
   wrote:
   I meant in addition of .cordova/lib also allow also
  to
   do
something
   like
   cordova platform add ios
   --path=./cordova_components/cordova-ios
  
  
  
   On Thu, Oct 17, 2013 at 1:28 PM, Carlos Santana 
 csantan...@gmail.com
  mailto:csantan...@gmail.com
   wrote:
  
   ++1  to install from a given directory instead of
   .cordova/libs.
  
  
  
   On Thu, Oct 17, 2013 at 12:10 PM, Viras 
 vi...@users.sourceforge.net
  mailto:vi...@users.sourceforge.net
   wrote:
  
   This might be true - it took me quite some time to
   figure
 out
   how
 the
   CLI
   actually works - despite also having to fix one or
  two
bugs
  for
the
  WPX
   implementation of the CLI code (as well as the
  Windows
   8
 CLI
code).
  But
   still I would hate to see the CLI go, since I think
   once
 you
   are
 used
   to
   it, it saves you quite a lot of time (I still have
   those
 old
  documents
   which guide me through the setup of the IDE
 projects
   for
 the
  different
   platforms - which is now mostly obsolete).
  
   So I guess supporting both methods is the way to
  go...
   :)
  
   Best,
   Wolfgang
  
   Am 2013-10-17 16:13, schrieb Michal Mocny

Re: config.xml discussion, we need to talk

   
   De : Brian LeRouxmailto:b...@brian.io
   Envoyé : 18/10/2013 01:48
   À : dev@cordova.apache.orgmailto:
 dev@cordova.apache.org
  
   Objet : Re: config.xml discussion, we need to talk
  
   I don't really appreciate comments that we don't talk
 to
   our
  users,
or
  build apps in anger. Neither of those assertions are
 true.
   The
   origins
of
  these initiatives are based on both community feedback,
 and
 direct
  experience.
  
   Keeping your focus on just pure platform side of a
  project
   is
  fine,
of
  course, since the CLI delegates to the platform. This
 was
   also
a
 deliberate
  learning from MANY attempts at an architecture that
  satisfies
 both
  approaches. It separates the concerns and respects the
   platform
  will
   be
  canonical for the common workflows supported. This is a
  very
real
example
  of Conway's Law btw. [1]
  
   Anyhow. Deep breath! Software has bugs, people will
  report
 them,
   and
  we'll continue to improve. This is a very large group
 with
  a
very
diverse
  community that spans regular old hackers to the humble
 web
  designers.
We
  need to respect that, and maybe be a little more
   compassionate
to
   each
  other too. All software is fucked up, and at the end of
 the
day,
 it
   is
 our
  perpetual job to make it a little less fucked up.
  
   [1] http://en.wikipedia.org/wiki/Conway's_law
  
  
   [Inline image 1]
  
  
  
  
  
  
   On Thu, Oct 17, 2013 at 1:16 PM, Tommy Williams 
   to...@devgeeks.org
  mailto:to...@devgeeks.org wrote:
   Late to the party due to timezone fun, but I just
 want to
chime
  in
   in
   support of the CLI.
  
   As a dev working on an actual nontrivial real world
  app,
   I
  would
like
  to
   let it be known that we (SpiderOak) have been heavy
   drinkers
of
  the
CLI
   Kool-Aid since its infancy.
  
   We have even managed to get to the point where
./platforms/**/*
  is
 just a
   build artefact (mostly by using hooks and tying the
 whole
thing
 together
   with Grunt).
  
   We have a fast and fairly complex app (both many core
   plugins
 as
   well
  and a
   few custom/third party ones), that even includes the
   ability
to
   white
  label
   it with relative ease.
  
   I feel pretty strongly in favour of the CLI and
 strongly
 advocate
   its
 use
   when asked in the #phonegap IRC channel.
  
   Just my opinion, but thought it was important to add
 to
  the
discussion.
  
   - tommy / devgeeks
   On 18 Oct 2013 04:44, Anis KADRI 
 anis.ka...@gmail.com
 mailto:
  anis.ka...@gmail.com wrote:
  
   Sweet. So I think we all agree (expect Joe perhaps?)
  that
both
   approaches should be supported :-)
  
   On Thu, Oct 17, 2013 at 10:31 AM, Carlos Santana 
 csantan...@gmail.com
  mailto:csantan...@gmail.com
   wrote:
   I meant in addition of .cordova/lib also allow
 also
  to
   do
something
   like
   cordova platform add ios
   --path=./cordova_components/cordova-ios
  
  
  
   On Thu, Oct 17, 2013 at 1:28 PM, Carlos Santana 
 csantan...@gmail.com
  mailto:csantan...@gmail.com
   wrote:
  
   ++1  to install from a given directory instead of
   .cordova/libs.
  
  
  
   On Thu, Oct 17, 2013 at 12:10 PM, Viras 
 vi...@users.sourceforge.net
  mailto:vi...@users.sourceforge.net
   wrote:
  
   This might be true - it took me quite some time to
   figure
 out
   how
 the
   CLI
   actually works - despite also having to fix one or
  two
bugs
  for
the
  WPX
   implementation of the CLI code (as well as the
  Windows
   8
 CLI
code).
  But
   still I would hate to see the CLI go, since I
 think
   once
 you
   are
 used
   to
   it, it saves you quite a lot of time (I still have
   those
 old
  documents
   which guide me through the setup of the IDE
 projects
   for
 the
  different
   platforms - which is now mostly obsolete).
  
   So I

Re: config.xml discussion, we need to talk

2013-10-18 Thread Brian LeRoux

!!
 
 
  On Fri, Oct 18, 2013 at 3:43 AM, Erik Jan de Wit 
  ede...@redhat.com
  wrote:
 
   On the topic of IDE support my collage Gorkem has
 made a
   nice
   wizard
in
   eclipse that mimics the CLI have a look at this video
  
   http://www.youtube.com/watch?v=QUyUUtmTYok
  
   On 18 Oct,2013, at 4:29 , Maxime LUCE 
  max...@somatic.fr
 wrote:
  
Great Bryan
Totally agree !!!
   
Cordialement.
---
Maxime LUCE - Somatic
maxime.l...@somatic.fr
06 28 60 72 34

De : Brian LeRouxmailto:b...@brian.io
Envoyé : 18/10/2013 01:48
À : dev@cordova.apache.orgmailto:
  dev@cordova.apache.org
   
Objet : Re: config.xml discussion, we need to talk
   
I don't really appreciate comments that we don't
 talk
  to
our
   users,
 or
   build apps in anger. Neither of those assertions are
  true.
The
origins
 of
   these initiatives are based on both community
 feedback,
  and
  direct
   experience.
   
Keeping your focus on just pure platform side of a
   project
is
   fine,
 of
   course, since the CLI delegates to the platform. This
  was
also
 a
  deliberate
   learning from MANY attempts at an architecture that
   satisfies
  both
   approaches. It separates the concerns and respects the
platform
   will
be
   canonical for the common workflows supported. This is
 a
   very
 real
 example
   of Conway's Law btw. [1]
   
Anyhow. Deep breath! Software has bugs, people will
   report
  them,
and
   we'll continue to improve. This is a very large group
  with
   a
 very
 diverse
   community that spans regular old hackers to the humble
  web
   designers.
 We
   need to respect that, and maybe be a little more
compassionate
 to
each
   other too. All software is fucked up, and at the end
 of
  the
 day,
  it
is
  our
   perpetual job to make it a little less fucked up.
   
[1] http://en.wikipedia.org/wiki/Conway's_law
   
   
[Inline image 1]
   
   
   
   
   
   
On Thu, Oct 17, 2013 at 1:16 PM, Tommy Williams 
to...@devgeeks.org
   mailto:to...@devgeeks.org wrote:
Late to the party due to timezone fun, but I just
  want to
 chime
   in
in
support of the CLI.
   
As a dev working on an actual nontrivial real
 world
   app,
I
   would
 like
   to
let it be known that we (SpiderOak) have been heavy
drinkers
 of
   the
 CLI
Kool-Aid since its infancy.
   
We have even managed to get to the point where
 ./platforms/**/*
   is
  just a
build artefact (mostly by using hooks and tying the
  whole
 thing
  together
with Grunt).
   
We have a fast and fairly complex app (both many
 core
plugins
  as
well
   and a
few custom/third party ones), that even includes the
ability
 to
white
   label
it with relative ease.
   
I feel pretty strongly in favour of the CLI and
  strongly
  advocate
its
  use
when asked in the #phonegap IRC channel.
   
Just my opinion, but thought it was important to add
  to
   the
 discussion.
   
- tommy / devgeeks
On 18 Oct 2013 04:44, Anis KADRI 
  anis.ka...@gmail.com
  mailto:
   anis.ka...@gmail.com wrote:
   
Sweet. So I think we all agree (expect Joe
 perhaps?)
   that
 both
approaches should be supported :-)
   
On Thu, Oct 17, 2013 at 10:31 AM, Carlos Santana 
  csantan...@gmail.com
   mailto:csantan...@gmail.com
wrote:
I meant in addition of .cordova/lib also allow
  also
   to
do
 something
like
cordova platform add ios
--path=./cordova_components/cordova-ios
   
   
   
On Thu, Oct 17, 2013 at 1:28 PM, Carlos Santana 
  csantan...@gmail.com
   mailto:csantan...@gmail.com
wrote:
   
++1  to install from a given directory instead
 of
.cordova/libs.
   
   
   
On Thu, Oct

Re: config.xml discussion, we need to talk

2013-10-18 Thread Carlos Santana

Cross Platform - use Merge Flow

Single Platform - use Legacy Flow

Using Multi Platform or Cross Platform is also fine

Using Flow or Mode is also fine


On Friday, October 18, 2013, Brian LeRoux wrote:

 Ya, to me the difference is that one workflow embraces the native platform
 and tooling (plugman and bin/scripts) while the other focuses on building a
 web project (cli/merges/etc).

 As a dev, if I'm ONLY worried about one platform (like a Cordova
 implementor or many of our community folk) then bin/scripts suffices. As
 soon as I'm concerned with more than one platform the CLI workflows kick
 in. That was the use case anyhow.


 On Fri, Oct 18, 2013 at 3:21 PM, Steven Gill stevengil...@gmail.com
 wrote:

  Brian suggested Project Development (CLI workflow) vs Platform
 Development
  (bin/scripts)
 
 
  On Fri, Oct 18, 2013 at 3:09 PM, Steven Gill stevengil...@gmail.com
  wrote:
 
   We need more suggestions!
  
   Anis suggested picking to arbitrary names that don't reflect the
  workflows
   but would be easy to refer to.
  
  
  
  
   On Fri, Oct 18, 2013 at 12:41 PM, Michal Mocny mmo...@chromium.org
  wrote:
  
   I use the IDE with the CLI and hope to make it better.
  
   In my mind, the old way is for making platform modifications, and the
  new
   way threads platforms/ as a build artifact.
  
   If you must control the platform code, you sacrifice easy upgrades and
   ease
   of multi-platform development, but gain control.
   If you want to use the CLI, you lose the ability to make modifications
  to
   directly platform code without worrying about the implications.
  
   -Michal
  
  
   On Fri, Oct 18, 2013 at 3:18 PM, Steven Gill stevengil...@gmail.com
   wrote:
  
I like that better.
   
I know that both methods use the command line, but the cordova-cli
 has
   cli
in its name! We call the tool the cordova-cli so it might be more
   confusing
going away from that and calling it anything else. Not saying we
   shouldn't
be open to a name change though just because we called it X since
 its
inception (or am I saying that? :P).
   
When we write the docs about the other workflow (bin/create,
 plugman),
maybe making the IDE an integral part of it would make it make more
   sense
calling that workflow IDE. Just a thought.
   
   
On Fri, Oct 18, 2013 at 12:09 PM, Jesse purplecabb...@gmail.com
   wrote:
   
  IDE or cordova-cli ??

 @purplecabbage
 risingj.com


 On Fri, Oct 18, 2013 at 12:02 PM, Steven Gill 
  stevengil...@gmail.com
 wrote:

  I think SinplePlatform vs MultiPlatform is misleading because
 you
   can
use
  the CLI to do single platform development.
 
 
  On Fri, Oct 18, 2013 at 11:51 AM, Jesse 
 purplecabb...@gmail.com
wrote:
 
   SinglePlatform vs MultiPlatform makes the most sense to me.
  
   SinglePlatform = Focus on a single platform, and use plugman
 and
   the
   platform scripts directly. Useful when you only have that
   particular
  device
   to test on, or only have access to that device's marketplace.
Also
  useful
   for platform developers who are focused primarily on the
 native
   code.
   ( aka DivideAndConquer )
  
   



-- 
Carlos Santana
csantan...@gmail.com

Re: config.xml discussion, we need to talk

2013-10-18 Thread purplecabbage

I like merge-flow and legacy-flow

Sent from my iPhone

 On Oct 18, 2013, at 6:59 PM, Carlos Santana csantan...@gmail.com wrote:
 
 Cross Platform - use Merge Flow
 
 Single Platform - use Legacy Flow
 
 Using Multi Platform or Cross Platform is also fine
 
 Using Flow or Mode is also fine
 
 
 On Friday, October 18, 2013, Brian LeRoux wrote:
 
 Ya, to me the difference is that one workflow embraces the native platform
 and tooling (plugman and bin/scripts) while the other focuses on building a
 web project (cli/merges/etc).
 
 As a dev, if I'm ONLY worried about one platform (like a Cordova
 implementor or many of our community folk) then bin/scripts suffices. As
 soon as I'm concerned with more than one platform the CLI workflows kick
 in. That was the use case anyhow.
 
 
 On Fri, Oct 18, 2013 at 3:21 PM, Steven Gill stevengil...@gmail.com
 wrote:
 
 Brian suggested Project Development (CLI workflow) vs Platform
 Development
 (bin/scripts)
 
 
 On Fri, Oct 18, 2013 at 3:09 PM, Steven Gill stevengil...@gmail.com
 wrote:
 
 We need more suggestions!
 
 Anis suggested picking to arbitrary names that don't reflect the
 workflows
 but would be easy to refer to.
 
 
 
 
 On Fri, Oct 18, 2013 at 12:41 PM, Michal Mocny mmo...@chromium.org
 wrote:
 
 I use the IDE with the CLI and hope to make it better.
 
 In my mind, the old way is for making platform modifications, and the
 new
 way threads platforms/ as a build artifact.
 
 If you must control the platform code, you sacrifice easy upgrades and
 ease
 of multi-platform development, but gain control.
 If you want to use the CLI, you lose the ability to make modifications
 to
 directly platform code without worrying about the implications.
 
 -Michal
 
 
 On Fri, Oct 18, 2013 at 3:18 PM, Steven Gill stevengil...@gmail.com
 wrote:
 
 I like that better.
 
 I know that both methods use the command line, but the cordova-cli
 has
 cli
 in its name! We call the tool the cordova-cli so it might be more
 confusing
 going away from that and calling it anything else. Not saying we
 shouldn't
 be open to a name change though just because we called it X since
 its
 inception (or am I saying that? :P).
 
 When we write the docs about the other workflow (bin/create,
 plugman),
 maybe making the IDE an integral part of it would make it make more
 sense
 calling that workflow IDE. Just a thought.
 
 
 On Fri, Oct 18, 2013 at 12:09 PM, Jesse purplecabb...@gmail.com
 wrote:
 
 IDE or cordova-cli ??
 
 @purplecabbage
 risingj.com
 
 
 On Fri, Oct 18, 2013 at 12:02 PM, Steven Gill 
 stevengil...@gmail.com
 wrote:
 
 I think SinplePlatform vs MultiPlatform is misleading because
 you
 can
 use
 the CLI to do single platform development.
 
 
 On Fri, Oct 18, 2013 at 11:51 AM, Jesse 
 purplecabb...@gmail.com
 wrote:
 
 SinglePlatform vs MultiPlatform makes the most sense to me.
 
 SinglePlatform = Focus on a single platform, and use plugman
 and
 the
 platform scripts directly. Useful when you only have that
 particular
 device
 to test on, or only have access to that device's marketplace.
 Also
 useful
 for platform developers who are focused primarily on the
 native
 code.
 ( aka DivideAndConquer )
 
 
 
 -- 
 Carlos Santana
 csantan...@gmail.com

Re: config.xml discussion, we need to talk

2013-10-17 Thread Lucas Holmquist

while not perfect, i like the CLI/plugman .  it's still in its infancy and can 
get better.



On Oct 17, 2013, at 12:13 AM, Viras vi...@users.sourceforge.net wrote:

 my view on this discussion:
 
 I've used the CLI to release the latest version of GOFG Sports Computer for 
 Windows Phone. The support for the merges directory is a fantastic feature 
 which allows me to focus on the javascript code using e.g. the NetBeans IDE - 
 I can finally handle all my platform specific code from JavaScript in one 
 consistent directory structure - which is what Cordova should be about.
 
 In addition the CLI forces you to write clean code (not implying that the 
 other method forces to write messy code). If you need something native write 
 a clean plugin for it (which also makes the code reusable) - no need to mess 
 around in the native projects code - this also makes upgrading cordova much 
 easier.
 
 Once I've done the Windows Phone version I've simply added Android as a 
 platform, build it and I was done - no need for fiddling around with SDK / 
 IDE setup etc (besides actually installing it). So CLI is my favorite way to 
 develop now - and it is far more powerful than the old approach (in my 
 opinion) - since it saves you from fiddling around with project settings, 
 etc. when you do a multi-platform release.
 
 Oh yes - and GOFG SC uses two custom plugins, 5 official plugins and cordova 
 3.0 - so it is a bit beyond the Hello World application
 
 And I do not agree that it isn't possible to work with the native IDEs with 
 their own projects - this is simply wrong since you can always go to the 
 platforms directory and open the platform-projects using their native IDE 
 from there (I've done this myself for e.g. plugin development).
 
 Still I agree that both versions should be supported - but don't make the 
 assumption that the CLI is for n00bs only!
 
 Best,
 Wolfgang
 
 Am 2013-10-16 23:11, schrieb Joe Bowser:
 On Wed, Oct 16, 2013 at 1:37 PM, Michal Mocny mmo...@chromium.org wrote:
 Anis: Totally agrees, but its important to highlight that both directions
 for that arguments hold.  We've done our best to support bin/ scripts post
 3.0, yet blanket statements like CLI should not be used with IDE, or CLI
 sucks unless you just doing something trivial are being thrown around,
 which are harmful in my opinion, and I don't think its fair that some of us
 are promoting that message to users.
 I don't think we're communicating with our users at all, so I don't
 see how this could be communicated.  When users communicate their
 frustrations, it's usually something like this
 (http://www.infil00p.org/config-xml-changes-for-ios-and-android/#comment-10731)
 and this
 (http://www.infil00p.org/introducing-cordova-3-0-0-for-android/#comment-10694).
 CLI works well for me, and while its not perfect, I strive to learn its
 limitations and make it better, not condemn it.
 I avoid it because it's not developed for me, or developers like me
 who like to see a big pile of output when things fail.  I avoided
 having any part in its development because I thought it was the wrong
 way to do things.  I assumed that the majority of users actually
 wanted this and that I should do my best to work around this, but with
 the backlash that we're getting, such as the blog posts and some
 comments on the Google Groups, it seems that this is a feature very
 few people actually wanted.
 As far as the CordovaWebView use case, I actually have never tried that.
 Has anyone bothered to make sure it works well post-3.0, or does Joe have
 a point that we missed addressing this?
 We have JUnit unit tests in the Android repository to make sure that
 this still works.  However, I would like to see this test case
 revisited since it may be more appropriate to have CordovaActivity be
 inherited instead of CordovaInterface, or for both to be supported.
 This is so that we can make more hybrid applications and deal with the
 fact that we're so brutally non-complaint with Android UI guidelines
 instead of just ignoring it.  I'll probably bring this up and present
 more source code when it's ready to explain why we need this feature
 in the next couple of weeks, and why it's important to respect the
 platform, even when the platform doesn't respect the web.
 
 -- 
 GOFG - Get On Fat Guy
 http://www.gofg.at/ - powered by Cordova

Re: config.xml discussion, we need to talk

2013-10-17 Thread Michal Mocny

Thanks so much for chiming in, I'm very happy to see that you've figured
out how to leverage the benefits and avoid the drawbacks of the new
workflow, and that it has led to increased productivity for you.

I do think that perhaps it is still too difficult for every developer to
learn what you already have.

-Michal

On Thu, Oct 17, 2013 at 12:13 AM, Viras vi...@users.sourceforge.net wrote:

my view on this discussion:

I've used the CLI to release the latest version of GOFG Sports Computer
for Windows Phone. The support for the merges directory is a fantastic
feature which allows me to focus on the javascript code using e.g. the
NetBeans IDE - I can finally handle all my platform specific code from
JavaScript in one consistent directory structure - which is what Cordova
should be about.

In addition the CLI forces you to write clean code (not implying that the
other method forces to write messy code). If you need something native
write a clean plugin for it (which also makes the code reusable) - no need
to mess around in the native projects code - this also makes upgrading
cordova much easier.

Once I've done the Windows Phone version I've simply added Android as a
platform, build it and I was done - no need for fiddling around with SDK /
IDE setup etc (besides actually installing it). So CLI is my favorite way
to develop now - and it is far more powerful than the old approach (in my
opinion) - since it saves you from fiddling around with project settings,
etc. when you do a multi-platform release.

Oh yes - and GOFG SC uses two custom plugins, 5 official plugins and
cordova 3.0 - so it is a bit beyond the Hello World application

And I do not agree that it isn't possible to work with the native IDEs
with their own projects - this is simply wrong since you can always go to
the platforms directory and open the platform-projects using their native
IDE from there (I've done this myself for e.g. plugin development).

Still I agree that both versions should be supported - but don't make the
assumption that the CLI is for n00bs only!

Best,
Wolfgang

Am 2013-10-16 23:11, schrieb Joe Bowser:

On Wed, Oct 16, 2013 at 1:37 PM, Michal Mocny mmo...@chromium.org
wrote:

Anis: Totally agrees, but its important to highlight that both directions
for that arguments hold. We've done our best to support bin/ scripts
post
3.0, yet blanket statements like CLI should not be used with IDE, or
CLI
sucks unless you just doing something trivial are being thrown around,
which are harmful in my opinion, and I don't think its fair that some of
us
are promoting that message to users.

I don't think we're communicating with our users at all, so I don't
see how this could be communicated. When users communicate their
frustrations, it's usually something like this
(http://www.infil00p.org/**config-xml-changes-for-ios-**
and-android/#comment-10731http://www.infil00p.org/config-xml-changes-for-ios-and-android/#comment-10731
)
and this
(http://www.infil00p.org/**introducing-cordova-3-0-0-for-**
android/#comment-10694http://www.infil00p.org/introducing-cordova-3-0-0-for-android/#comment-10694
).

CLI works well for me, and while its not perfect, I strive to learn its
limitations and make it better, not condemn it.

I avoid it because it's not developed for me, or developers like me
who like to see a big pile of output when things fail. I avoided
having any part in its development because I thought it was the wrong
way to do things. I assumed that the majority of users actually
wanted this and that I should do my best to work around this, but with
the backlash that we're getting, such as the blog posts and some
comments on the Google Groups, it seems that this is a feature very
few people actually wanted.

As far as the CordovaWebView use case, I actually have never tried that.
Has anyone bothered to make sure it works well post-3.0, or does Joe
have
a point that we missed addressing this?

We have JUnit unit tests in the Android repository to make sure that
this still works. However, I would like to see this test case
revisited since it may be more appropriate to have CordovaActivity be
inherited instead of CordovaInterface, or for both to be supported.
This is so that we can make more hybrid applications and deal with the
fact that we're so brutally non-complaint with Android UI guidelines
instead of just ignoring it. I'll probably bring this up and present
more source code when it's ready to explain why we need this feature
in the next couple of weeks, and why it's important to respect the
platform, even when the platform doesn't respect the web.

--
GOFG - Get On Fat Guy
http://www.gofg.at/ - powered by Cordova

Re: config.xml discussion, we need to talk

2013-10-17 Thread Shazron

We definitely need to do better with understanding the general user. We
can't predict however how they choose to do development ultimately but I
believe the CLI is getting there -- I think it will be a building block
towards (maybe) improved tooling, if not by us, then the community (which I
hope they will contribute back).

Personally its easier for me to use bin/create and plugman, not only
because of the rapid turnaround time for debugging, but also to eliminate
side effects possibly from the CLI. This has caused me to missed bugs
however (like CB-5031).


On Thu, Oct 17, 2013 at 8:03 AM, Braden Shepherdson bra...@chromium.orgwrote:

 Viras, thank you for your feedback. I find myself missing Google's Consumer
 Ops people from when I was working on G+, whose job it was to keep their
 finger on the user community's pulse, reviewing the feedback given inside
 the apps, on blogs, comments, Groups, etc., and pass along the major pain
 points and feature requests to the developers. I've learned about several
 new pain points in this email thread - things that are not in the
 CLI/Plugman JIRA or elsewhere.

 We're in the unfortunate position that the people who are primarily working
 on these tools are not using them in anger, building apps with them.

 Here are some things I've learned from this thread and will be treating
 like CLI feature requests:

 - Command-line flags for platform add that let's you specify (a) to install
 source rather than the jar, where relevant, (b) to install from a given
 directory instead of .cordova/libs. (Currently you can achieve (b) by
 editing .cordova/config.json, but that's both global and lame.)

 - There are needs to make various edits to the WebView's logic on Android,
 and probably elsewhere too. In the short term, we should make by-hand
 editing of the source code easier (above); in the long term any of these
 that are more common than weird one-off cases should be turned into
 plugins, or failing that, preferences in the platform's config.xml.

 - When people talk about CLI not working with IDEs, what is meant is that
 if you load your platforms/ios in Xcode, for example, you can't edit the
 web assets because they'll be overwritten on prepare. It's not a normal
 Xcode project in that sense. We already have a feature request for this.
 Xcode in particular makes this difficult, since it doesn't handle symlinks
 well. Eclipse is somewhat better. I'm not sure how much we can really do
 here, beyond educating our users about where they should actually be making
 their edits (top-level www, inside the plugins, merges, etc.).
 Alternatively, we support cordova build, run and emulate, which are
 designed to hide the use of Xcode, Eclipse and friends completely. My
 Eclipse is actually broken right now, some PermGen space nonsense, and I
 can still build Android apps cheerfully. I only use the IDEs now when I
 need to debug the native code. But I work primarily on CLI and Plugman, and
 use vim for editing, so I have little desire or cause to use the IDEs.

 Braden




 On Thu, Oct 17, 2013 at 8:31 AM, Lucas Holmquist lholm...@redhat.com
 wrote:

  while not perfect, i like the CLI/plugman .  it's still in its infancy
 and
  can get better.
 
 
 
  On Oct 17, 2013, at 12:13 AM, Viras vi...@users.sourceforge.net wrote:
 
   my view on this discussion:
  
   I've used the CLI to release the latest version of GOFG Sports Computer
  for Windows Phone. The support for the merges directory is a fantastic
  feature which allows me to focus on the javascript code using e.g. the
  NetBeans IDE - I can finally handle all my platform specific code from
  JavaScript in one consistent directory structure - which is what Cordova
  should be about.
  
   In addition the CLI forces you to write clean code (not implying that
  the other method forces to write messy code). If you need something
 native
  write a clean plugin for it (which also makes the code reusable) - no
 need
  to mess around in the native projects code - this also makes upgrading
  cordova much easier.
  
   Once I've done the Windows Phone version I've simply added Android as a
  platform, build it and I was done - no need for fiddling around with SDK
 /
  IDE setup etc (besides actually installing it). So CLI is my favorite way
  to develop now - and it is far more powerful than the old approach (in my
  opinion) - since it saves you from fiddling around with project settings,
  etc. when you do a multi-platform release.
  
   Oh yes - and GOFG SC uses two custom plugins, 5 official plugins and
  cordova 3.0 - so it is a bit beyond the Hello World application
  
   And I do not agree that it isn't possible to work with the native IDEs
  with their own projects - this is simply wrong since you can always go to
  the platforms directory and open the platform-projects using their
 native
  IDE from there (I've done this myself for e.g. plugin development).
  
   Still I agree that both versions should be supported - but

Re: config.xml discussion, we need to talk

2013-10-17 Thread Viras

This might be true - it took me quite some time to figure out how the
CLI actually works - despite also having to fix one or two bugs for the
WPX implementation of the CLI code (as well as the Windows 8 CLI code).
But still I would hate to see the CLI go, since I think once you are
used to it, it saves you quite a lot of time (I still have those old
documents which guide me through the setup of the IDE projects for the
different platforms - which is now mostly obsolete).

So I guess supporting both methods is the way to go... :)

Best,
Wolfgang

Am 2013-10-17 16:13, schrieb Michal Mocny:
Thanks so much for chiming in, I'm very happy to see that you've
figured

out how to leverage the benefits and avoid the drawbacks of the new
workflow, and that it has led to increased productivity for you.

I do think that perhaps it is still too difficult for every developer
to

learn what you already have.

-Michal

On Thu, Oct 17, 2013 at 12:13 AM, Viras vi...@users.sourceforge.net
wrote:

my view on this discussion:

I've used the CLI to release the latest version of GOFG Sports
Computer
for Windows Phone. The support for the merges directory is a
fantastic
feature which allows me to focus on the javascript code using e.g.
the
NetBeans IDE - I can finally handle all my platform specific code
from
JavaScript in one consistent directory structure - which is what
Cordova

should be about.

In addition the CLI forces you to write clean code (not implying that
the
other method forces to write messy code). If you need something
native
write a clean plugin for it (which also makes the code reusable) - no
need
to mess around in the native projects code - this also makes
upgrading

cordova much easier.

Once I've done the Windows Phone version I've simply added Android as
a
platform, build it and I was done - no need for fiddling around with
SDK /
IDE setup etc (besides actually installing it). So CLI is my favorite
way
to develop now - and it is far more powerful than the old approach
(in my
opinion) - since it saves you from fiddling around with project
settings,

etc. when you do a multi-platform release.

Oh yes - and GOFG SC uses two custom plugins, 5 official plugins and
cordova 3.0 - so it is a bit beyond the Hello World application

And I do not agree that it isn't possible to work with the native
IDEs
with their own projects - this is simply wrong since you can always
go to
the platforms directory and open the platform-projects using their
native

IDE from there (I've done this myself for e.g. plugin development).

Still I agree that both versions should be supported - but don't make
the

assumption that the CLI is for n00bs only!

Best,
Wolfgang

Am 2013-10-16 23:11, schrieb Joe Bowser:

On Wed, Oct 16, 2013 at 1:37 PM, Michal Mocny mmo...@chromium.org

wrote:

Anis: Totally agrees, but its important to highlight that both
directions
for that arguments hold. We've done our best to support bin/
scripts

post
3.0, yet blanket statements like CLI should not be used with IDE,
or

CLI
sucks unless you just doing something trivial are being thrown
around,
which are harmful in my opinion, and I don't think its fair that
some of

us
are promoting that message to users.

CLI works well for me, and while its not perfect, I strive to learn
its

limitations and make it better, not condemn it.

way to do things. I assumed that the majority of users actually
wanted this and that I should do my best to work around this, but
with

the backlash that we're getting, such as the blog posts and some
comments on the Google Groups, it seems that this is a feature very
few people actually wanted.

As far as the CordovaWebView use case, I actually have never tried
that.
Has anyone bothered to make sure it works well post-3.0, or does
Joe

have
a point that we missed addressing this?

inherited instead of CordovaInterface, or for both to be supported.
This is so that we can make more hybrid applications and deal with
the

fact that we're so brutally non-complaint with Android

Re: config.xml discussion, we need to talk

2013-10-17 Thread Carlos Santana

++1 to install from a given directory instead of .cordova/libs.

On Thu, Oct 17, 2013 at 12:10 PM, Viras vi...@users.sourceforge.net wrote:

This might be true - it took me quite some time to figure out how the CLI
actually works - despite also having to fix one or two bugs for the WPX
implementation of the CLI code (as well as the Windows 8 CLI code). But
still I would hate to see the CLI go, since I think once you are used to
it, it saves you quite a lot of time (I still have those old documents
which guide me through the setup of the IDE projects for the different
platforms - which is now mostly obsolete).

So I guess supporting both methods is the way to go... :)

Best,
Wolfgang

Am 2013-10-17 16:13, schrieb Michal Mocny:

I do think that perhaps it is still too difficult for every developer to
learn what you already have.

-Michal

On Thu, Oct 17, 2013 at 12:13 AM, Viras vi...@users.sourceforge.net
wrote:

my view on this discussion:

In addition the CLI forces you to write clean code (not implying that the
other method forces to write messy code). If you need something native
write a clean plugin for it (which also makes the code reusable) - no
need
to mess around in the native projects code - this also makes upgrading
cordova much easier.

Once I've done the Windows Phone version I've simply added Android as a
platform, build it and I was done - no need for fiddling around with SDK
/
IDE setup etc (besides actually installing it). So CLI is my favorite way
to develop now - and it is far more powerful than the old approach (in my
opinion) - since it saves you from fiddling around with project settings,
etc. when you do a multi-platform release.

Oh yes - and GOFG SC uses two custom plugins, 5 official plugins and
cordova 3.0 - so it is a bit beyond the Hello World application

And I do not agree that it isn't possible to work with the native IDEs
with their own projects - this is simply wrong since you can always go to
the platforms directory and open the platform-projects using their
native
IDE from there (I've done this myself for e.g. plugin development).

Still I agree that both versions should be supported - but don't make the
assumption that the CLI is for n00bs only!

Best,
Wolfgang

Am 2013-10-16 23:11, schrieb Joe Bowser:

On Wed, Oct 16, 2013 at 1:37 PM, Michal Mocny mmo...@chromium.org

wrote:

Anis: Totally agrees, but its important to highlight that both
directions
for that arguments hold. We've done our best to support bin/ scripts
post
3.0, yet blanket statements like CLI should not be used with IDE, or
CLI
sucks unless you just doing something trivial are being thrown around,
which are harmful in my opinion, and I don't think its fair that some
of
us
are promoting that message to users.

I don't think we're communicating with our users at all, so I don't
see how this could be communicated. When users communicate their
frustrations, it's usually something like this
(http://www.infil00p.org/config-xml-changes-for-ios-**http://www.infil00p.org/**config-xml-changes-for-ios-**
and-android/#comment-10731htt**p://www.infil00p.org/config-**
xml-changes-for-ios-and-**android/#comment-10731http://www.infil00p.org/config-xml-changes-for-ios-and-android/#comment-10731

)
and this
(http://www.infil00p.org/introducing-cordova-3-0-0-for-http://www.infil00p.org/**introducing-cordova-3-0-0-for-**
android/#comment-10694http://**www.infil00p.org/introducing-**
cordova-3-0-0-for-android/#**comment-10694http://www.infil00p.org/introducing-cordova-3-0-0-for-android/#comment-10694

CLI works well for me, and while its not perfect, I strive to learn its

limitations and make it better, not condemn it.

As far as the CordovaWebView use case, I actually have never tried
that.

Has anyone bothered to make sure it works

Re: config.xml discussion, we need to talk

2013-10-17 Thread Carlos Santana

I meant in addition of .cordova/lib also allow also to do something like
 cordova platform add ios --path=./cordova_components/cordova-ios



On Thu, Oct 17, 2013 at 1:28 PM, Carlos Santana csantan...@gmail.comwrote:

 ++1  to install from a given directory instead of .cordova/libs.



 On Thu, Oct 17, 2013 at 12:10 PM, Viras vi...@users.sourceforge.netwrote:

 This might be true - it took me quite some time to figure out how the CLI
 actually works - despite also having to fix one or two bugs for the WPX
 implementation of the CLI code (as well as the Windows 8 CLI code). But
 still I would hate to see the CLI go, since I think once you are used to
 it, it saves you quite a lot of time (I still have those old documents
 which guide me through the setup of the IDE projects for the different
 platforms - which is now mostly obsolete).

 So I guess supporting both methods is the way to go... :)

 Best,
 Wolfgang

 Am 2013-10-17 16:13, schrieb Michal Mocny:

  Thanks so much for chiming in, I'm very happy to see that you've figured
 out how to leverage the benefits and avoid the drawbacks of the new
 workflow, and that it has led to increased productivity for you.

 I do think that perhaps it is still too difficult for every developer to
 learn what you already have.

 -Michal


 On Thu, Oct 17, 2013 at 12:13 AM, Viras vi...@users.sourceforge.net
 wrote:

  my view on this discussion:

 I've used the CLI to release the latest version of GOFG Sports Computer
 for Windows Phone. The support for the merges directory is a fantastic
 feature which allows me to focus on the javascript code using e.g. the
 NetBeans IDE - I can finally handle all my platform specific code from
 JavaScript in one consistent directory structure - which is what Cordova
 should be about.

 In addition the CLI forces you to write clean code (not implying that
 the
 other method forces to write messy code). If you need something native
 write a clean plugin for it (which also makes the code reusable) - no
 need
 to mess around in the native projects code - this also makes upgrading
 cordova much easier.

 Once I've done the Windows Phone version I've simply added Android as a
 platform, build it and I was done - no need for fiddling around with
 SDK /
 IDE setup etc (besides actually installing it). So CLI is my favorite
 way
 to develop now - and it is far more powerful than the old approach (in
 my
 opinion) - since it saves you from fiddling around with project
 settings,
 etc. when you do a multi-platform release.

 Oh yes - and GOFG SC uses two custom plugins, 5 official plugins and
 cordova 3.0 - so it is a bit beyond the Hello World application

 And I do not agree that it isn't possible to work with the native IDEs
 with their own projects - this is simply wrong since you can always go
 to
 the platforms directory and open the platform-projects using their
 native
 IDE from there (I've done this myself for e.g. plugin development).

 Still I agree that both versions should be supported - but don't make
 the
 assumption that the CLI is for n00bs only!

 Best,
 Wolfgang

 Am 2013-10-16 23:11, schrieb Joe Bowser:

  On Wed, Oct 16, 2013 at 1:37 PM, Michal Mocny mmo...@chromium.org

 wrote:

  Anis: Totally agrees, but its important to highlight that both
 directions
 for that arguments hold.  We've done our best to support bin/ scripts
 post
 3.0, yet blanket statements like CLI should not be used with IDE, or
 CLI
 sucks unless you just doing something trivial are being thrown
 around,
 which are harmful in my opinion, and I don't think its fair that some
 of
 us
 are promoting that message to users.


  I don't think we're communicating with our users at all, so I don't
 see how this could be communicated.  When users communicate their
 frustrations, it's usually something like this
 (http://www.infil00p.org/config-xml-changes-for-ios-**http://www.infil00p.org/**config-xml-changes-for-ios-**
 and-android/#comment-10731htt**p://www.infil00p.org/config-**
 xml-changes-for-ios-and-**android/#comment-10731http://www.infil00p.org/config-xml-changes-for-ios-and-android/#comment-10731
 
 )
 and this
 (http://www.infil00p.org/introducing-cordova-3-0-0-for-http://www.infil00p.org/**introducing-cordova-3-0-0-for-**
 android/#comment-10694http://**www.infil00p.org/introducing-**
 cordova-3-0-0-for-android/#**comment-10694http://www.infil00p.org/introducing-cordova-3-0-0-for-android/#comment-10694
 
 ).

  CLI works well for me, and while its not perfect, I strive to learn
 its

 limitations and make it better, not condemn it.


 I avoid it because it's not developed for me, or developers like me
 who like to see a big pile of output when things fail.  I avoided
 having any part in its development because I thought it was the wrong
 way to do things.  I assumed that the majority of users actually
 wanted this and that I should do my best to work around this, but with
 the backlash that we're getting, such as the blog posts and

Re: config.xml discussion, we need to talk

2013-10-17 Thread Anis KADRI

Sweet. So I think we all agree (expect Joe perhaps?) that both
approaches should be supported :-)

On Thu, Oct 17, 2013 at 10:31 AM, Carlos Santana csantan...@gmail.com wrote:
 I meant in addition of .cordova/lib also allow also to do something like
  cordova platform add ios --path=./cordova_components/cordova-ios



 On Thu, Oct 17, 2013 at 1:28 PM, Carlos Santana csantan...@gmail.comwrote:

 ++1  to install from a given directory instead of .cordova/libs.



 On Thu, Oct 17, 2013 at 12:10 PM, Viras vi...@users.sourceforge.netwrote:

 This might be true - it took me quite some time to figure out how the CLI
 actually works - despite also having to fix one or two bugs for the WPX
 implementation of the CLI code (as well as the Windows 8 CLI code). But
 still I would hate to see the CLI go, since I think once you are used to
 it, it saves you quite a lot of time (I still have those old documents
 which guide me through the setup of the IDE projects for the different
 platforms - which is now mostly obsolete).

 So I guess supporting both methods is the way to go... :)

 Best,
 Wolfgang

 Am 2013-10-17 16:13, schrieb Michal Mocny:

  Thanks so much for chiming in, I'm very happy to see that you've figured
 out how to leverage the benefits and avoid the drawbacks of the new
 workflow, and that it has led to increased productivity for you.

 I do think that perhaps it is still too difficult for every developer to
 learn what you already have.

 -Michal


 On Thu, Oct 17, 2013 at 12:13 AM, Viras vi...@users.sourceforge.net
 wrote:

  my view on this discussion:

 I've used the CLI to release the latest version of GOFG Sports Computer
 for Windows Phone. The support for the merges directory is a fantastic
 feature which allows me to focus on the javascript code using e.g. the
 NetBeans IDE - I can finally handle all my platform specific code from
 JavaScript in one consistent directory structure - which is what Cordova
 should be about.

 In addition the CLI forces you to write clean code (not implying that
 the
 other method forces to write messy code). If you need something native
 write a clean plugin for it (which also makes the code reusable) - no
 need
 to mess around in the native projects code - this also makes upgrading
 cordova much easier.

 Once I've done the Windows Phone version I've simply added Android as a
 platform, build it and I was done - no need for fiddling around with
 SDK /
 IDE setup etc (besides actually installing it). So CLI is my favorite
 way
 to develop now - and it is far more powerful than the old approach (in
 my
 opinion) - since it saves you from fiddling around with project
 settings,
 etc. when you do a multi-platform release.

 Oh yes - and GOFG SC uses two custom plugins, 5 official plugins and
 cordova 3.0 - so it is a bit beyond the Hello World application

 And I do not agree that it isn't possible to work with the native IDEs
 with their own projects - this is simply wrong since you can always go
 to
 the platforms directory and open the platform-projects using their
 native
 IDE from there (I've done this myself for e.g. plugin development).

 Still I agree that both versions should be supported - but don't make
 the
 assumption that the CLI is for n00bs only!

 Best,
 Wolfgang

 Am 2013-10-16 23:11, schrieb Joe Bowser:

  On Wed, Oct 16, 2013 at 1:37 PM, Michal Mocny mmo...@chromium.org

 wrote:

  Anis: Totally agrees, but its important to highlight that both
 directions
 for that arguments hold.  We've done our best to support bin/ scripts
 post
 3.0, yet blanket statements like CLI should not be used with IDE, or
 CLI
 sucks unless you just doing something trivial are being thrown
 around,
 which are harmful in my opinion, and I don't think its fair that some
 of
 us
 are promoting that message to users.


  I don't think we're communicating with our users at all, so I don't
 see how this could be communicated.  When users communicate their
 frustrations, it's usually something like this
 (http://www.infil00p.org/config-xml-changes-for-ios-**http://www.infil00p.org/**config-xml-changes-for-ios-**
 and-android/#comment-10731htt**p://www.infil00p.org/config-**
 xml-changes-for-ios-and-**android/#comment-10731http://www.infil00p.org/config-xml-changes-for-ios-and-android/#comment-10731
 
 )
 and this
 (http://www.infil00p.org/introducing-cordova-3-0-0-for-http://www.infil00p.org/**introducing-cordova-3-0-0-for-**
 android/#comment-10694http://**www.infil00p.org/introducing-**
 cordova-3-0-0-for-android/#**comment-10694http://www.infil00p.org/introducing-cordova-3-0-0-for-android/#comment-10694
 
 ).

  CLI works well for me, and while its not perfect, I strive to learn
 its

 limitations and make it better, not condemn it.


 I avoid it because it's not developed for me, or developers like me
 who like to see a big pile of output when things fail.  I avoided
 having any part in its development because I thought it was the wrong
 way to do things.

Re: config.xml discussion, we need to talk

2013-10-17 Thread Joe Bowser

On Thu, Oct 17, 2013 at 10:43 AM, Anis KADRI anis.ka...@gmail.com wrote:
 Sweet. So I think we all agree (expect Joe perhaps?) that both
 approaches should be supported :-)

I don't care.  I'll keep using the source and plugman and making sure
that works, and I'll just ignore the complaints and the bugs regarding
the CLI.  I personally think that one way will eventually win out, but
it'll probably be years down the road, and I'm not even sure if I'll
still be working on Cordova when that happens, so I won't worry about
it.

Re: config.xml discussion, we need to talk

2013-10-17 Thread Mike Billau

Would it be helpful to document both of the supported workflows?  We kind
of have this documentation in place under Development Paths section in
the Overview, but I think we could edit this section to make it more clear
that there really are two different development paths, and both are okay
and supported. We could include pros and cons of each and link to the
appropriate documentation (which is mostly written already, under The
Command-line Interface and the various {Platform} Command-line Tools
guides.)  If there are no objections I can add this into Jira and start
working on it.


On Thu, Oct 17, 2013 at 1:54 PM, Joe Bowser bows...@gmail.com wrote:

 On Thu, Oct 17, 2013 at 10:43 AM, Anis KADRI anis.ka...@gmail.com wrote:
  Sweet. So I think we all agree (expect Joe perhaps?) that both
  approaches should be supported :-)

 I don't care.  I'll keep using the source and plugman and making sure
 that works, and I'll just ignore the complaints and the bugs regarding
 the CLI.  I personally think that one way will eventually win out, but
 it'll probably be years down the road, and I'm not even sure if I'll
 still be working on Cordova when that happens, so I won't worry about
 it.

Re: config.xml discussion, we need to talk

2013-10-17 Thread Anis KADRI

That would be awesome Mike!

On Thu, Oct 17, 2013 at 12:01 PM, Mike Billau mike.bil...@gmail.com wrote:
 Would it be helpful to document both of the supported workflows?  We kind
 of have this documentation in place under Development Paths section in
 the Overview, but I think we could edit this section to make it more clear
 that there really are two different development paths, and both are okay
 and supported. We could include pros and cons of each and link to the
 appropriate documentation (which is mostly written already, under The
 Command-line Interface and the various {Platform} Command-line Tools
 guides.)  If there are no objections I can add this into Jira and start
 working on it.


 On Thu, Oct 17, 2013 at 1:54 PM, Joe Bowser bows...@gmail.com wrote:

 On Thu, Oct 17, 2013 at 10:43 AM, Anis KADRI anis.ka...@gmail.com wrote:
  Sweet. So I think we all agree (expect Joe perhaps?) that both
  approaches should be supported :-)

 I don't care.  I'll keep using the source and plugman and making sure
 that works, and I'll just ignore the complaints and the bugs regarding
 the CLI.  I personally think that one way will eventually win out, but
 it'll probably be years down the road, and I'm not even sure if I'll
 still be working on Cordova when that happens, so I won't worry about
 it.

Re: config.xml discussion, we need to talk

2013-10-17 Thread Steven Gill

YES! We could really use this Mike!


On Thu, Oct 17, 2013 at 12:06 PM, Anis KADRI anis.ka...@gmail.com wrote:

 That would be awesome Mike!

 On Thu, Oct 17, 2013 at 12:01 PM, Mike Billau mike.bil...@gmail.com
 wrote:
  Would it be helpful to document both of the supported workflows?  We kind
  of have this documentation in place under Development Paths section in
  the Overview, but I think we could edit this section to make it more
 clear
  that there really are two different development paths, and both are okay
  and supported. We could include pros and cons of each and link to the
  appropriate documentation (which is mostly written already, under The
  Command-line Interface and the various {Platform} Command-line Tools
  guides.)  If there are no objections I can add this into Jira and start
  working on it.
 
 
  On Thu, Oct 17, 2013 at 1:54 PM, Joe Bowser bows...@gmail.com wrote:
 
  On Thu, Oct 17, 2013 at 10:43 AM, Anis KADRI anis.ka...@gmail.com
 wrote:
   Sweet. So I think we all agree (expect Joe perhaps?) that both
   approaches should be supported :-)
 
  I don't care.  I'll keep using the source and plugman and making sure
  that works, and I'll just ignore the complaints and the bugs regarding
  the CLI.  I personally think that one way will eventually win out, but
  it'll probably be years down the road, and I'm not even sure if I'll
  still be working on Cordova when that happens, so I won't worry about
  it.

Re: config.xml discussion, we need to talk

2013-10-17 Thread Tyler Wilson

Sounds awesome to me. 

Thanks,
Tyler

On Oct 17, 2013, at 3:10 PM, Steven Gill stevengil...@gmail.com wrote:

 YES! We could really use this Mike!
 
 
 On Thu, Oct 17, 2013 at 12:06 PM, Anis KADRI anis.ka...@gmail.com wrote:
 
 That would be awesome Mike!
 
 On Thu, Oct 17, 2013 at 12:01 PM, Mike Billau mike.bil...@gmail.com
 wrote:
 Would it be helpful to document both of the supported workflows?  We kind
 of have this documentation in place under Development Paths section in
 the Overview, but I think we could edit this section to make it more
 clear
 that there really are two different development paths, and both are okay
 and supported. We could include pros and cons of each and link to the
 appropriate documentation (which is mostly written already, under The
 Command-line Interface and the various {Platform} Command-line Tools
 guides.)  If there are no objections I can add this into Jira and start
 working on it.
 
 
 On Thu, Oct 17, 2013 at 1:54 PM, Joe Bowser bows...@gmail.com wrote:
 
 On Thu, Oct 17, 2013 at 10:43 AM, Anis KADRI anis.ka...@gmail.com
 wrote:
 Sweet. So I think we all agree (expect Joe perhaps?) that both
 approaches should be supported :-)
 
 I don't care.  I'll keep using the source and plugman and making sure
 that works, and I'll just ignore the complaints and the bugs regarding
 the CLI.  I personally think that one way will eventually win out, but
 it'll probably be years down the road, and I'm not even sure if I'll
 still be working on Cordova when that happens, so I won't worry about
 it.

Re: config.xml discussion, we need to talk

2013-10-17 Thread Mike Billau

Great, I filed https://issues.apache.org/jira/browse/CB-5122


On Thu, Oct 17, 2013 at 3:17 PM, Tyler Wilson twil...@symbeeco.com wrote:

 Sounds awesome to me.

 Thanks,
 Tyler

 On Oct 17, 2013, at 3:10 PM, Steven Gill stevengil...@gmail.com wrote:

  YES! We could really use this Mike!
 
 
  On Thu, Oct 17, 2013 at 12:06 PM, Anis KADRI anis.ka...@gmail.com
 wrote:
 
  That would be awesome Mike!
 
  On Thu, Oct 17, 2013 at 12:01 PM, Mike Billau mike.bil...@gmail.com
  wrote:
  Would it be helpful to document both of the supported workflows?  We
 kind
  of have this documentation in place under Development Paths section
 in
  the Overview, but I think we could edit this section to make it more
  clear
  that there really are two different development paths, and both are
 okay
  and supported. We could include pros and cons of each and link to the
  appropriate documentation (which is mostly written already, under The
  Command-line Interface and the various {Platform} Command-line Tools
  guides.)  If there are no objections I can add this into Jira and start
  working on it.
 
 
  On Thu, Oct 17, 2013 at 1:54 PM, Joe Bowser bows...@gmail.com wrote:
 
  On Thu, Oct 17, 2013 at 10:43 AM, Anis KADRI anis.ka...@gmail.com
  wrote:
  Sweet. So I think we all agree (expect Joe perhaps?) that both
  approaches should be supported :-)
 
  I don't care.  I'll keep using the source and plugman and making sure
  that works, and I'll just ignore the complaints and the bugs regarding
  the CLI.  I personally think that one way will eventually win out, but
  it'll probably be years down the road, and I'm not even sure if I'll
  still be working on Cordova when that happens, so I won't worry about
  it.

Re: config.xml discussion, we need to talk

2013-10-17 Thread Tommy Williams

Late to the party due to timezone fun, but I just want to chime in in
support of the CLI.

As a dev working on an actual nontrivial real world app, I would like to
let it be known that we (SpiderOak) have been heavy drinkers of the CLI
Kool-Aid since its infancy.

We have even managed to get to the point where ./platforms/**/* is just a
build artefact (mostly by using hooks and tying the whole thing together
with Grunt).

We have a fast and fairly complex app (both many core plugins as well and a
few custom/third party ones), that even includes the ability to white label
it with relative ease.

I feel pretty strongly in favour of the CLI and strongly advocate its use
when asked in the #phonegap IRC channel.

Just my opinion, but thought it was important to add to the discussion.

- tommy / devgeeks
On 18 Oct 2013 04:44, Anis KADRI anis.ka...@gmail.com wrote:

 Sweet. So I think we all agree (expect Joe perhaps?) that both
 approaches should be supported :-)

 On Thu, Oct 17, 2013 at 10:31 AM, Carlos Santana csantan...@gmail.com
 wrote:
  I meant in addition of .cordova/lib also allow also to do something
 like
   cordova platform add ios --path=./cordova_components/cordova-ios
 
 
 
  On Thu, Oct 17, 2013 at 1:28 PM, Carlos Santana csantan...@gmail.com
 wrote:
 
  ++1  to install from a given directory instead of .cordova/libs.
 
 
 
  On Thu, Oct 17, 2013 at 12:10 PM, Viras vi...@users.sourceforge.net
 wrote:
 
  This might be true - it took me quite some time to figure out how the
 CLI
  actually works - despite also having to fix one or two bugs for the WPX
  implementation of the CLI code (as well as the Windows 8 CLI code). But
  still I would hate to see the CLI go, since I think once you are used
 to
  it, it saves you quite a lot of time (I still have those old documents
  which guide me through the setup of the IDE projects for the different
  platforms - which is now mostly obsolete).
 
  So I guess supporting both methods is the way to go... :)
 
  Best,
  Wolfgang
 
  Am 2013-10-17 16:13, schrieb Michal Mocny:
 
   Thanks so much for chiming in, I'm very happy to see that you've
 figured
  out how to leverage the benefits and avoid the drawbacks of the new
  workflow, and that it has led to increased productivity for you.
 
  I do think that perhaps it is still too difficult for every developer
 to
  learn what you already have.
 
  -Michal
 
 
  On Thu, Oct 17, 2013 at 12:13 AM, Viras vi...@users.sourceforge.net
  wrote:
 
   my view on this discussion:
 
  I've used the CLI to release the latest version of GOFG Sports
 Computer
  for Windows Phone. The support for the merges directory is a
 fantastic
  feature which allows me to focus on the javascript code using e.g.
 the
  NetBeans IDE - I can finally handle all my platform specific code
 from
  JavaScript in one consistent directory structure - which is what
 Cordova
  should be about.
 
  In addition the CLI forces you to write clean code (not implying that
  the
  other method forces to write messy code). If you need something
 native
  write a clean plugin for it (which also makes the code reusable) - no
  need
  to mess around in the native projects code - this also makes
 upgrading
  cordova much easier.
 
  Once I've done the Windows Phone version I've simply added Android
 as a
  platform, build it and I was done - no need for fiddling around with
  SDK /
  IDE setup etc (besides actually installing it). So CLI is my favorite
  way
  to develop now - and it is far more powerful than the old approach
 (in
  my
  opinion) - since it saves you from fiddling around with project
  settings,
  etc. when you do a multi-platform release.
 
  Oh yes - and GOFG SC uses two custom plugins, 5 official plugins and
  cordova 3.0 - so it is a bit beyond the Hello World application
 
  And I do not agree that it isn't possible to work with the native
 IDEs
  with their own projects - this is simply wrong since you can always
 go
  to
  the platforms directory and open the platform-projects using their
  native
  IDE from there (I've done this myself for e.g. plugin development).
 
  Still I agree that both versions should be supported - but don't make
  the
  assumption that the CLI is for n00bs only!
 
  Best,
  Wolfgang
 
  Am 2013-10-16 23:11, schrieb Joe Bowser:
 
   On Wed, Oct 16, 2013 at 1:37 PM, Michal Mocny mmo...@chromium.org
 
  wrote:
 
   Anis: Totally agrees, but its important to highlight that both
  directions
  for that arguments hold.  We've done our best to support bin/
 scripts
  post
  3.0, yet blanket statements like CLI should not be used with
 IDE, or
  CLI
  sucks unless you just doing something trivial are being thrown
  around,
  which are harmful in my opinion, and I don't think its fair that
 some
  of
  us
  are promoting that message to users.
 
 
   I don't think we're communicating with our users at all, so I
 don't
  see how this could be communicated.  When users communicate their
  frustrations, it's usually

Re: config.xml discussion, we need to talk

2013-10-17 Thread Brian LeRoux

I don't really appreciate comments that we don't talk to our users, or
build apps in anger. Neither of those assertions are true. The origins of
these initiatives are based on both community feedback, and direct
experience.

Keeping your focus on just pure platform side of a project is fine, of
course, since the CLI delegates to the platform. This was also a deliberate
learning from MANY attempts at an architecture that satisfies both
approaches. It separates the concerns and respects the platform will be
canonical for the common workflows supported. This is a very real example
of Conway's Law btw. [1]

Anyhow. Deep breath! Software has bugs, people will report them, and we'll
continue to improve. This is a very large group with a very diverse
community that spans regular old hackers to the humble web designers. We
need to respect that, and maybe be a little more compassionate to each
other too. All software is fucked up, and at the end of the day, it is our
perpetual job to make it a little less fucked up.

[1] http://en.wikipedia.org/wiki/Conway's_law


[image: Inline image 1]






On Thu, Oct 17, 2013 at 1:16 PM, Tommy Williams to...@devgeeks.org wrote:

 Late to the party due to timezone fun, but I just want to chime in in
 support of the CLI.

 As a dev working on an actual nontrivial real world app, I would like to
 let it be known that we (SpiderOak) have been heavy drinkers of the CLI
 Kool-Aid since its infancy.

 We have even managed to get to the point where ./platforms/**/* is just a
 build artefact (mostly by using hooks and tying the whole thing together
 with Grunt).

 We have a fast and fairly complex app (both many core plugins as well and a
 few custom/third party ones), that even includes the ability to white label
 it with relative ease.

 I feel pretty strongly in favour of the CLI and strongly advocate its use
 when asked in the #phonegap IRC channel.

 Just my opinion, but thought it was important to add to the discussion.

 - tommy / devgeeks
 On 18 Oct 2013 04:44, Anis KADRI anis.ka...@gmail.com wrote:

  Sweet. So I think we all agree (expect Joe perhaps?) that both
  approaches should be supported :-)
 
  On Thu, Oct 17, 2013 at 10:31 AM, Carlos Santana csantan...@gmail.com
  wrote:
   I meant in addition of .cordova/lib also allow also to do something
  like
cordova platform add ios --path=./cordova_components/cordova-ios
  
  
  
   On Thu, Oct 17, 2013 at 1:28 PM, Carlos Santana csantan...@gmail.com
  wrote:
  
   ++1  to install from a given directory instead of .cordova/libs.
  
  
  
   On Thu, Oct 17, 2013 at 12:10 PM, Viras vi...@users.sourceforge.net
  wrote:
  
   This might be true - it took me quite some time to figure out how the
  CLI
   actually works - despite also having to fix one or two bugs for the
 WPX
   implementation of the CLI code (as well as the Windows 8 CLI code).
 But
   still I would hate to see the CLI go, since I think once you are used
  to
   it, it saves you quite a lot of time (I still have those old
 documents
   which guide me through the setup of the IDE projects for the
 different
   platforms - which is now mostly obsolete).
  
   So I guess supporting both methods is the way to go... :)
  
   Best,
   Wolfgang
  
   Am 2013-10-17 16:13, schrieb Michal Mocny:
  
Thanks so much for chiming in, I'm very happy to see that you've
  figured
   out how to leverage the benefits and avoid the drawbacks of the new
   workflow, and that it has led to increased productivity for you.
  
   I do think that perhaps it is still too difficult for every
 developer
  to
   learn what you already have.
  
   -Michal
  
  
   On Thu, Oct 17, 2013 at 12:13 AM, Viras 
 vi...@users.sourceforge.net
   wrote:
  
my view on this discussion:
  
   I've used the CLI to release the latest version of GOFG Sports
  Computer
   for Windows Phone. The support for the merges directory is a
  fantastic
   feature which allows me to focus on the javascript code using e.g.
  the
   NetBeans IDE - I can finally handle all my platform specific code
  from
   JavaScript in one consistent directory structure - which is what
  Cordova
   should be about.
  
   In addition the CLI forces you to write clean code (not implying
 that
   the
   other method forces to write messy code). If you need something
  native
   write a clean plugin for it (which also makes the code reusable) -
 no
   need
   to mess around in the native projects code - this also makes
  upgrading
   cordova much easier.
  
   Once I've done the Windows Phone version I've simply added Android
  as a
   platform, build it and I was done - no need for fiddling around
 with
   SDK /
   IDE setup etc (besides actually installing it). So CLI is my
 favorite
   way
   to develop now - and it is far more powerful than the old approach
  (in
   my
   opinion) - since it saves you from fiddling around with project
   settings,
   etc. when you do a multi-platform release.
  
   Oh yes - and GOFG SC uses

Re: config.xml discussion, we need to talk

2013-10-16 Thread Wargo, John

Joe,

What is your issue with the CLI?  Isn't not using it making your life more 
difficult if you're doing cordova development (An app which includes one or 
more plugins).  I assumed that with 3.0 everyone would use the Cli for their 
cordova (not cordova plugin) development.  What am I missing?

John M. Wargo

 On Sep 26, 2013, at 11:58 AM, Joe Bowser bows...@gmail.com wrote:
 
 On Thu, Sep 26, 2013 at 8:53 AM, Lindsey Simon els...@gmail.com wrote:
 
 When you say www are you referring to project/www or
 project/platform/android/assets/www?
 
 That's the kicker, isn't it?  If you're using the CLI, we're talking
 project/www, but not everyone uses the CLI, or should use the CLI.  I
 think we should tell people not using the CLI where it's located on
 each of the platforms.  The CLI can play pretend with the spec, and
 the platforms can move on with actually making things more usable.

Re: config.xml discussion, we need to talk

2013-10-16 Thread Tyler Wilson


On Oct 16, 2013, at 1:47 PM, Joe Bowser bows...@gmail.com wrote:

 On Wed, Oct 16, 2013 at 10:13 AM, Wargo, John john.wa...@sap.com wrote:
 Joe,
 
 What is your issue with the CLI?  Isn't not using it making your life more 
 difficult if you're doing cordova development (An app which includes one or 
 more plugins).  I assumed that with 3.0 everyone would use the Cli for their 
 cordova (not cordova plugin) development.  What am I missing?
 
 
 I was going to keep quiet, because this is going to make me extremely
 unpopular with the people who worked and promoted the CLI, since I've
 mostly left them alone until now. The CLI actually makes your life
 more difficult if you're making anything more complex than hello
 world.  If you care about details, you'll want the source code for
 Android and iOS at the very least.
 
 The biggest problem with the CLI is the fact that it hides the
 platforms in the .cordova directory and that if you're an advanced
 user of Cordova you have no way to make custom modifications to the
 source code on a per-project basis.  We've run into this numerous
 times where certain things need to be modified on a webview on 3.0
 that you can't easily do anymore.  Now, these changes by themselves
 are individual edge cases, which I don't want to see put in the XML of
 the project, but if you hide the source, you end up having to do crazy
 things like declare Java code in XML to override these cases.  I think
 that people should be able to modify the code and use it whichever way
 they want and that they should be able to do this on a per-project
 basis if they want, and I view the CLI as something that gets in the
 way of that, which is why I have such a low opinion of it.
 
 The CLI also makes it much harder for the CordovaWebView use case
 where you use Cordova as a small part of a larger native application.
 Given that this was one of the big features of PhoneGap 2.0, it makes
 no sense for us to make it harder to use that feature.
 
 Finally, I have yet to see anyone actually release a real application
 to the App Store or the Play Store with it.  Developing an application
 is great, but if I can't release it, then the tool is absolutely
 worthless.  While the CLI may look impressive in demos in front of an
 audience, it's not helpful in reality.
 
 Joe

While we are piling on: I have mentioned issues I have had with iOS builds 
using the CLI. The worst is having to edit code somewhere outside the IDE, do a 
cordova prepare, then go back to Xcode. If I am using an IDE, I expect to be 
able to use it to edit code. If the CLI is not designed to be used with an IDE, 
perhaps it should just create Makefiles, ant scripts, etc. and not make us 
think we can use an IDE by generated Xcode project files (maybe this is the 
only way to build apps on OSX/iOS now - I am not that knowledgeable in that 
area).

I have moved all my projects back to using the bin/create method and using 
plugman to install all the plugins I need. I use the --shared option as well to 
a local git clone of the iOS Cordova so that all  my projects get updates at 
the same time. Much easier to develop this way for me.

Thanks,
Tyler

Re: config.xml discussion, we need to talk

2013-10-16 Thread Michal Mocny

Anis: Totally agrees, but its important to highlight that both directions
for that arguments hold.  We've done our best to support bin/ scripts post
3.0, yet blanket statements like CLI should not be used with IDE, or CLI
sucks unless you just doing something trivial are being thrown around,
which are harmful in my opinion, and I don't think its fair that some of us
are promoting that message to users.

CLI works well for me, and while its not perfect, I strive to learn its
limitations and make it better, not condemn it.

As far as the CordovaWebView use case, I actually have never tried that.
 Has anyone bothered to make sure it works well post-3.0, or does Joe have
a point that we missed addressing this?

-Michal


On Wed, Oct 16, 2013 at 3:07 PM, Anis KADRI anis.ka...@gmail.com wrote:

 This confirms the point that I've made numerous times. Different
 people have different needs and expectations. There is no right or
 wrong way. It all depends on what you want to achieve. It sounds like
 we will be promoting bin/ and cordova/ scripts + plugman for a while.
 CLI is not (and should not be) the only way to build cordova apps.

 On Wed, Oct 16, 2013 at 11:35 AM, Tyler Wilson twil...@symbeeco.com
 wrote:
 
  On Oct 16, 2013, at 1:47 PM, Joe Bowser bows...@gmail.com wrote:
 
  On Wed, Oct 16, 2013 at 10:13 AM, Wargo, John john.wa...@sap.com
 wrote:
  Joe,
 
  What is your issue with the CLI?  Isn't not using it making your life
 more difficult if you're doing cordova development (An app which includes
 one or more plugins).  I assumed that with 3.0 everyone would use the Cli
 for their cordova (not cordova plugin) development.  What am I missing?
 
 
  I was going to keep quiet, because this is going to make me extremely
  unpopular with the people who worked and promoted the CLI, since I've
  mostly left them alone until now. The CLI actually makes your life
  more difficult if you're making anything more complex than hello
  world.  If you care about details, you'll want the source code for
  Android and iOS at the very least.
 
  The biggest problem with the CLI is the fact that it hides the
  platforms in the .cordova directory and that if you're an advanced
  user of Cordova you have no way to make custom modifications to the
  source code on a per-project basis.  We've run into this numerous
  times where certain things need to be modified on a webview on 3.0
  that you can't easily do anymore.  Now, these changes by themselves
  are individual edge cases, which I don't want to see put in the XML of
  the project, but if you hide the source, you end up having to do crazy
  things like declare Java code in XML to override these cases.  I think
  that people should be able to modify the code and use it whichever way
  they want and that they should be able to do this on a per-project
  basis if they want, and I view the CLI as something that gets in the
  way of that, which is why I have such a low opinion of it.
 
  The CLI also makes it much harder for the CordovaWebView use case
  where you use Cordova as a small part of a larger native application.
  Given that this was one of the big features of PhoneGap 2.0, it makes
  no sense for us to make it harder to use that feature.
 
  Finally, I have yet to see anyone actually release a real application
  to the App Store or the Play Store with it.  Developing an application
  is great, but if I can't release it, then the tool is absolutely
  worthless.  While the CLI may look impressive in demos in front of an
  audience, it's not helpful in reality.
 
  Joe
 
  While we are piling on: I have mentioned issues I have had with iOS
 builds using the CLI. The worst is having to edit code somewhere outside
 the IDE, do a cordova prepare, then go back to Xcode. If I am using an IDE,
 I expect to be able to use it to edit code. If the CLI is not designed to
 be used with an IDE, perhaps it should just create Makefiles, ant scripts,
 etc. and not make us think we can use an IDE by generated Xcode project
 files (maybe this is the only way to build apps on OSX/iOS now - I am not
 that knowledgeable in that area).
 
  I have moved all my projects back to using the bin/create method and
 using plugman to install all the plugins I need. I use the --shared option
 as well to a local git clone of the iOS Cordova so that all  my projects
 get updates at the same time. Much easier to develop this way for me.
 
  Thanks,
  Tyler

Re: config.xml discussion, we need to talk

2013-10-16 Thread Steven Gill

I agree with Michal on this.

I think it is important to support both methods but very harmful to the
project to be bashing one way if it is not your preferred.

With the cli, you can edit the .cordova/config.json on a per project basis
and point that file to use specific local versions of platform libraries.
It is partially described in http://wiki.apache.org/cordova/WorkingWithThree.
Not saying this is a great solution, just wanted to say it is possible for
advanced users.


On Wed, Oct 16, 2013 at 1:37 PM, Michal Mocny mmo...@chromium.org wrote:

 Anis: Totally agrees, but its important to highlight that both directions
 for that arguments hold.  We've done our best to support bin/ scripts post
 3.0, yet blanket statements like CLI should not be used with IDE, or CLI
 sucks unless you just doing something trivial are being thrown around,
 which are harmful in my opinion, and I don't think its fair that some of us
 are promoting that message to users.

 CLI works well for me, and while its not perfect, I strive to learn its
 limitations and make it better, not condemn it.

 As far as the CordovaWebView use case, I actually have never tried that.
  Has anyone bothered to make sure it works well post-3.0, or does Joe have
 a point that we missed addressing this?

 -Michal


 On Wed, Oct 16, 2013 at 3:07 PM, Anis KADRI anis.ka...@gmail.com wrote:

  This confirms the point that I've made numerous times. Different
  people have different needs and expectations. There is no right or
  wrong way. It all depends on what you want to achieve. It sounds like
  we will be promoting bin/ and cordova/ scripts + plugman for a while.
  CLI is not (and should not be) the only way to build cordova apps.
 
  On Wed, Oct 16, 2013 at 11:35 AM, Tyler Wilson twil...@symbeeco.com
  wrote:
  
   On Oct 16, 2013, at 1:47 PM, Joe Bowser bows...@gmail.com wrote:
  
   On Wed, Oct 16, 2013 at 10:13 AM, Wargo, John john.wa...@sap.com
  wrote:
   Joe,
  
   What is your issue with the CLI?  Isn't not using it making your life
  more difficult if you're doing cordova development (An app which includes
  one or more plugins).  I assumed that with 3.0 everyone would use the Cli
  for their cordova (not cordova plugin) development.  What am I missing?
  
  
   I was going to keep quiet, because this is going to make me extremely
   unpopular with the people who worked and promoted the CLI, since I've
   mostly left them alone until now. The CLI actually makes your life
   more difficult if you're making anything more complex than hello
   world.  If you care about details, you'll want the source code for
   Android and iOS at the very least.
  
   The biggest problem with the CLI is the fact that it hides the
   platforms in the .cordova directory and that if you're an advanced
   user of Cordova you have no way to make custom modifications to the
   source code on a per-project basis.  We've run into this numerous
   times where certain things need to be modified on a webview on 3.0
   that you can't easily do anymore.  Now, these changes by themselves
   are individual edge cases, which I don't want to see put in the XML of
   the project, but if you hide the source, you end up having to do crazy
   things like declare Java code in XML to override these cases.  I think
   that people should be able to modify the code and use it whichever way
   they want and that they should be able to do this on a per-project
   basis if they want, and I view the CLI as something that gets in the
   way of that, which is why I have such a low opinion of it.
  
   The CLI also makes it much harder for the CordovaWebView use case
   where you use Cordova as a small part of a larger native application.
   Given that this was one of the big features of PhoneGap 2.0, it makes
   no sense for us to make it harder to use that feature.
  
   Finally, I have yet to see anyone actually release a real application
   to the App Store or the Play Store with it.  Developing an application
   is great, but if I can't release it, then the tool is absolutely
   worthless.  While the CLI may look impressive in demos in front of an
   audience, it's not helpful in reality.
  
   Joe
  
   While we are piling on: I have mentioned issues I have had with iOS
  builds using the CLI. The worst is having to edit code somewhere outside
  the IDE, do a cordova prepare, then go back to Xcode. If I am using an
 IDE,
  I expect to be able to use it to edit code. If the CLI is not designed to
  be used with an IDE, perhaps it should just create Makefiles, ant
 scripts,
  etc. and not make us think we can use an IDE by generated Xcode project
  files (maybe this is the only way to build apps on OSX/iOS now - I am not
  that knowledgeable in that area).
  
   I have moved all my projects back to using the bin/create method and
  using plugman to install all the plugins I need. I use the --shared
 option
  as well to a local git clone of the iOS Cordova so that all  my projects
  get

Re: config.xml discussion, we need to talk

2013-10-16 Thread Joe Bowser

On Wed, Oct 16, 2013 at 1:37 PM, Michal Mocny mmo...@chromium.org wrote:
 Anis: Totally agrees, but its important to highlight that both directions
 for that arguments hold.  We've done our best to support bin/ scripts post
 3.0, yet blanket statements like CLI should not be used with IDE, or CLI
 sucks unless you just doing something trivial are being thrown around,
 which are harmful in my opinion, and I don't think its fair that some of us
 are promoting that message to users.


I don't think we're communicating with our users at all, so I don't
see how this could be communicated.  When users communicate their
frustrations, it's usually something like this
(http://www.infil00p.org/config-xml-changes-for-ios-and-android/#comment-10731)
and this 
(http://www.infil00p.org/introducing-cordova-3-0-0-for-android/#comment-10694).

 CLI works well for me, and while its not perfect, I strive to learn its
 limitations and make it better, not condemn it.

I avoid it because it's not developed for me, or developers like me
who like to see a big pile of output when things fail.  I avoided
having any part in its development because I thought it was the wrong
way to do things.  I assumed that the majority of users actually
wanted this and that I should do my best to work around this, but with
the backlash that we're getting, such as the blog posts and some
comments on the Google Groups, it seems that this is a feature very
few people actually wanted.

 As far as the CordovaWebView use case, I actually have never tried that.
  Has anyone bothered to make sure it works well post-3.0, or does Joe have
 a point that we missed addressing this?

We have JUnit unit tests in the Android repository to make sure that
this still works.  However, I would like to see this test case
revisited since it may be more appropriate to have CordovaActivity be
inherited instead of CordovaInterface, or for both to be supported.
This is so that we can make more hybrid applications and deal with the
fact that we're so brutally non-complaint with Android UI guidelines
instead of just ignoring it.  I'll probably bring this up and present
more source code when it's ready to explain why we need this feature
in the next couple of weeks, and why it's important to respect the
platform, even when the platform doesn't respect the web.

Re: config.xml discussion, we need to talk

2013-10-16 Thread Viras


my view on this discussion:

I've used the CLI to release the latest version of GOFG Sports Computer 
for Windows Phone. The support for the merges directory is a fantastic 
feature which allows me to focus on the javascript code using e.g. the 
NetBeans IDE - I can finally handle all my platform specific code from 
JavaScript in one consistent directory structure - which is what Cordova 
should be about.


In addition the CLI forces you to write clean code (not implying that 
the other method forces to write messy code). If you need something 
native write a clean plugin for it (which also makes the code reusable) 
- no need to mess around in the native projects code - this also makes 
upgrading cordova much easier.


Once I've done the Windows Phone version I've simply added Android as a 
platform, build it and I was done - no need for fiddling around with SDK 
/ IDE setup etc (besides actually installing it). So CLI is my favorite 
way to develop now - and it is far more powerful than the old approach 
(in my opinion) - since it saves you from fiddling around with project 
settings, etc. when you do a multi-platform release.


Oh yes - and GOFG SC uses two custom plugins, 5 official plugins and 
cordova 3.0 - so it is a bit beyond the Hello World application


And I do not agree that it isn't possible to work with the native IDEs 
with their own projects - this is simply wrong since you can always go 
to the platforms directory and open the platform-projects using their 
native IDE from there (I've done this myself for e.g. plugin 
development).


Still I agree that both versions should be supported - but don't make 
the assumption that the CLI is for n00bs only!


Best,
Wolfgang

Am 2013-10-16 23:11, schrieb Joe Bowser:
On Wed, Oct 16, 2013 at 1:37 PM, Michal Mocny mmo...@chromium.org 
wrote:
Anis: Totally agrees, but its important to highlight that both 
directions
for that arguments hold.  We've done our best to support bin/ scripts 
post
3.0, yet blanket statements like CLI should not be used with IDE, 
or CLI
sucks unless you just doing something trivial are being thrown 
around,
which are harmful in my opinion, and I don't think its fair that some 
of us

are promoting that message to users.



I don't think we're communicating with our users at all, so I don't
see how this could be communicated.  When users communicate their
frustrations, it's usually something like this
(http://www.infil00p.org/config-xml-changes-for-ios-and-android/#comment-10731)
and this
(http://www.infil00p.org/introducing-cordova-3-0-0-for-android/#comment-10694).

CLI works well for me, and while its not perfect, I strive to learn 
its

limitations and make it better, not condemn it.


I avoid it because it's not developed for me, or developers like me
who like to see a big pile of output when things fail.  I avoided
having any part in its development because I thought it was the wrong
way to do things.  I assumed that the majority of users actually
wanted this and that I should do my best to work around this, but with
the backlash that we're getting, such as the blog posts and some
comments on the Google Groups, it seems that this is a feature very
few people actually wanted.

As far as the CordovaWebView use case, I actually have never tried 
that.
 Has anyone bothered to make sure it works well post-3.0, or does Joe 
have

a point that we missed addressing this?


We have JUnit unit tests in the Android repository to make sure that
this still works.  However, I would like to see this test case
revisited since it may be more appropriate to have CordovaActivity be
inherited instead of CordovaInterface, or for both to be supported.
This is so that we can make more hybrid applications and deal with the
fact that we're so brutally non-complaint with Android UI guidelines
instead of just ignoring it.  I'll probably bring this up and present
more source code when it's ready to explain why we need this feature
in the next couple of weeks, and why it's important to respect the
platform, even when the platform doesn't respect the web.


--
GOFG - Get On Fat Guy
http://www.gofg.at/ - powered by Cordova

Re: config.xml discussion, we need to talk

I am strongly opposed to splitting into one file per platform. We want to
support platform tags in config.xml, which will allow platform-specific
content within the single config.xml.

There are good reasons why the CLI moves the config.xml on some platforms.
On Android, it's really easy to load XML files from res/xml/foo.xml, so
that's where we put it. We should be deleting the
platforms/android/assets/www/config.xml though, since it's an unused
duplicate and confusing.

Braden


On Wed, Sep 25, 2013 at 4:59 PM, Carlos Santana csantan...@gmail.comwrote:

 I was not trying to be purist with the w3c www/config.xml

 I just want to see some consistency across all platforms for configuration
 settings for a Cordova App.

 The same way I have a single index.html, app.css and app.js. I want see one
 config.xml for all platforms inside www/ or many config.xml per platform
 config.ios.xml, config.android.xml, etc... But as a web developer I'm
 excepting all the files that I need to modify inside www/ using CLI or not

 Even if I have to run something like ./bin/processconfig.sh to propagate
 changes from the /www/config.xml

 As web developer I might update the config.xml once for every 100 edits to
 my app web files (HTML, JS, CSS)

 TLDR: consistency wins over correctness

 PS: what is the phonegap team doing? I think you tell users to edit one
 config.xml for the web app and pgbuild takes care of the rest


 -- Carlos

 On Wednesday, September 25, 2013, Braden Shepherdson wrote:

  I'm in favour of CLI (platform parsers, probably) deleting this
  www/config.xml that they don't use. It's a waste of space and has
 confused
  people in the past.
 
  It even confused the iOS prepare code and caused that odd my project
  doesn't work if it starts with x, y or z bug (because xFactor/config.xml
  sorts after www/config.xml, and it was blindly taking the first one).
 
  Braden
 
 
  On Wed, Sep 25, 2013 at 4:22 PM, Bryan Higgins bhigg...@blackberry.com
 javascript:;
  wrote:
 
   Thanks for the clarification. BlackBerry happened to luck out because
 we
   expect config.xml in www.
  
   Perhaps copying of config.xml should become a responsibility of the
   platform parsers.
  
   I can understand moving config.xml to root or cordova for the reason
  stated
   in the JIRA, but my vote would be to keep it config.xml rather than
   app.xml.
  
  
   On Wed, Sep 25, 2013 at 3:55 PM, Jesse purplecabb...@gmail.com
 wrote:
  
I am not saying deviate, I am saying, what is it supposed to be? If
 you
look at the various platforms you will see it is all over the map.
   
Looking at Android code, and talking to Joe, the only location that
 the
config.xml file is loaded from is in res/xml, and the fact that
   cordova-cli
creates another one sitting in the www folder is just irrelevant
sloppiness.
   
It may make sense for the config.xml file to sit in the root/www
 folder
   of
the CLI project, but in reality at runtime, it's location will vary
 by
platform.
   
   
   
@purplecabbage
risingj.com
   
   
On Wed, Sep 25, 2013 at 12:29 PM, Bryan Higgins 
  bhigg...@blackberry.com
wrote:
   
 www/config.xml aligns nicely with the w3c widget spec [1]. Why
 would
  we
 want to deviate?

 [1] http://www.w3.org/TR/widgets/#reserved-file-and-folder-names


 On Wed, Sep 25, 2013 at 3:23 PM, Jesse purplecabb...@gmail.com
   wrote:

  Seems any project created with the CLI has a config.xml in the
 www
 folder.
  [1]
  Why do we have 2 of these?
 
  I also recently closed a defect created by Carlos, stating that
 WP8
   did
 NOT
  have it's config.xml in the www folder. [2] Now I am not sure I
   should
 have
  called this invalid, however, after creating a new WP8 project
 with
   the
  CLI, I see a config.xml in the www folder AND one in the app
 root.
   wtf?
 
  There is an open issue [3] to re-org config files, where Braden
   states
 We
  already have plans to move $PROJECT/www/config.xml to
   $PROJECT/app.xml,
  which more or less addresses ...Have we formalized what
  exactly
this
  is?
 
  Seems we still have a lot of discussion that has to happen before
  we
can
  move ahead on these items.  I am currently adding config.xml
  support
   to
  Windows 8, and was hoping to have a nice clear path of what to
 do,
   but
it
  still looks pretty muddy. [4]
 
 
  [1] https://issues.apache.org/jira/browse/CB-4476
  [2] https://issues.apache.org/jira/browse/CB-46
  https://issues.apache.org/jira/browse/CB-4658
  58 https://issues.apache.org/jira/browse/CB-4658
  [3] https://issues.apache.org/jira/browse/CB-4910
  [4] https://issues.apache.org/jira/browse/CB-4608
 
  @purplecabbage
  http://risingj.com



 --
 Carlos Santana
 csantan...@gmail.com

Re: config.xml discussion, we need to talk

2013-09-26 Thread Joe Bowser

On Thu, Sep 26, 2013 at 7:18 AM, Braden Shepherdson bra...@chromium.org wrote:
 I am strongly opposed to splitting into one file per platform. We want to
 support platform tags in config.xml, which will allow platform-specific
 content within the single config.xml.

Agreed.  I'm not sure if Android actually supports this.  We should
probably write some JUnit tests against a multi-platform config.xml to
test this and make sure that our parser actually works well.


 There are good reasons why the CLI moves the config.xml on some platforms.
 On Android, it's really easy to load XML files from res/xml/foo.xml, so
 that's where we put it. We should be deleting the
 platforms/android/assets/www/config.xml though, since it's an unused
 duplicate and confusing.


+1 on this as well. The problem is that the documentation covers the
PhoneGap Build use case and the CLI use case, but not the stand-alone
use case.  We should document the stand-alone use case, since that's
really for people who are detail-oriented, and are using things such
as the CordovaWebView component.

Re: config.xml discussion, we need to talk

On Thu, Sep 26, 2013 at 11:03 AM, Joe Bowser bows...@gmail.com wrote:

 On Thu, Sep 26, 2013 at 7:18 AM, Braden Shepherdson bra...@chromium.org
 wrote:
  I am strongly opposed to splitting into one file per platform. We want to
  support platform tags in config.xml, which will allow platform-specific
  content within the single config.xml.

 Agreed.  I'm not sure if Android actually supports this.  We should
 probably write some JUnit tests against a multi-platform config.xml to
 test this and make sure that our parser actually works well.


Let me clarify: I was talking about adding platform tags to CLI's
top-level www/config.xml. The actual entries would be extracted into that
platform's final config.xml, without a platform tag.



 
  There are good reasons why the CLI moves the config.xml on some
 platforms.
  On Android, it's really easy to load XML files from res/xml/foo.xml, so
  that's where we put it. We should be deleting the
  platforms/android/assets/www/config.xml though, since it's an unused
  duplicate and confusing.
 

 +1 on this as well. The problem is that the documentation covers the
 PhoneGap Build use case and the CLI use case, but not the stand-alone
 use case.  We should document the stand-alone use case, since that's
 really for people who are detail-oriented, and are using things such
 as the CordovaWebView component.

Re: config.xml discussion, we need to talk

Branden,
   On Android, it's really easy to load XML files from res/xml/foo.xml,
so that's where we put it.

Easy for who?
I think is difficult for web developer to not find it in www/config.xml and
start searching for it

I don't know much about Android so maybe I'm putting my foot in my mouth
because it's too complex to read the file from www/


--Carlos


On Thursday, September 26, 2013, Braden Shepherdson wrote:

 I am strongly opposed to splitting into one file per platform. We want to
 support platform tags in config.xml, which will allow platform-specific
 content within the single config.xml.

 There are good reasons why the CLI moves the config.xml on some platforms.
 On Android, it's really easy to load XML files from res/xml/foo.xml, so
 that's where we put it. We should be deleting the
 platforms/android/assets/www/config.xml though, since it's an unused
 duplicate and confusing.

 Braden


 On Wed, Sep 25, 2013 at 4:59 PM, Carlos Santana 
 csantan...@gmail.comjavascript:;
 wrote:

  I was not trying to be purist with the w3c www/config.xml
 
  I just want to see some consistency across all platforms for
 configuration
  settings for a Cordova App.
 
  The same way I have a single index.html, app.css and app.js. I want see
 one
  config.xml for all platforms inside www/ or many config.xml per platform
  config.ios.xml, config.android.xml, etc... But as a web developer I'm
  excepting all the files that I need to modify inside www/ using CLI or
 not
 
  Even if I have to run something like ./bin/processconfig.sh to propagate
  changes from the /www/config.xml
 
  As web developer I might update the config.xml once for every 100 edits
 to
  my app web files (HTML, JS, CSS)
 
  TLDR: consistency wins over correctness
 
  PS: what is the phonegap team doing? I think you tell users to edit one
  config.xml for the web app and pgbuild takes care of the rest
 
 
  -- Carlos
 
  On Wednesday, September 25, 2013, Braden Shepherdson wrote:
 
   I'm in favour of CLI (platform parsers, probably) deleting this
   www/config.xml that they don't use. It's a waste of space and has
  confused
   people in the past.
  
   It even confused the iOS prepare code and caused that odd my project
   doesn't work if it starts with x, y or z bug (because
 xFactor/config.xml
   sorts after www/config.xml, and it was blindly taking the first one).
  
   Braden
  
  
   On Wed, Sep 25, 2013 at 4:22 PM, Bryan Higgins 
 bhigg...@blackberry.com javascript:;
  javascript:;
   wrote:
  
Thanks for the clarification. BlackBerry happened to luck out because
  we
expect config.xml in www.
   
Perhaps copying of config.xml should become a responsibility of the
platform parsers.
   
I can understand moving config.xml to root or cordova for the reason
   stated
in the JIRA, but my vote would be to keep it config.xml rather than
app.xml.
   
   
On Wed, Sep 25, 2013 at 3:55 PM, Jesse purplecabb...@gmail.com
  wrote:
   
 I am not saying deviate, I am saying, what is it supposed to be? If
  you
 look at the various platforms you will see it is all over the map.

 Looking at Android code, and talking to Joe, the only location that
  the
 config.xml file is loaded from is in res/xml, and the fact that
cordova-cli
 creates another one sitting in the www folder is just irrelevant
 sloppiness.

 It may make sense for the config.xml file to sit in the root/www
  folder
of
 the CLI project, but in reality at runtime, it's location will vary
  by
 platform.



 @purplecabbage
 risingj.com


 On Wed, Sep 25, 2013 at 12:29 PM, Bryan Higgins 
   bhigg...@blackberry.com
 wrote:

  www/config.xml aligns nicely with the w3c widget spec [1]. Why
  would
   we
  want to deviate?
 
  [1] http://www.w3.org/TR/widgets/#reserved-file-and-folder-names
 
 
  On Wed, Sep 25, 2013 at 3:23 PM, Jesse purplecabb...@gmail.com
wrote:
 
   Seems any project created with the CLI has a config.xml in the
  www
  folder.
   [1]
   Why do we have 2 of these?
  
   I also recently closed a defect created by Carlos, stating that
  WP8
did
  NOT
   have it's config.xml in the www folder. [2] Now I am not sure I
should
  have
   called this invalid, however, after creating a new WP8 project
  with
the
   CLI, I see a config.xml in the www folder AND one in the app
  root.
wtf?
  
   There is an open issue [3] to re-org config files, where Braden
states
  We
   already have plans to move $PROJECT/www/config.xml to
$PROJECT/app.xml,
   which more or less addresses ...Have we formalized what
   exactly
 this
   is?
  
   Seems we still have a lot of discussion that has to happen
 before
   we
 can
   move ahead on these items.  I am currently adding config.xml
   support
to
   Windows 8, and was

Re: config.xml discussion, we need to talk

2013-09-26 Thread Jesse

I too am opposed to splitting up into multiple files.

The existing config.xml should already be usable cross device without
change.

 feature name=Device
  param name=android-package value=org.apache.cordova.device.Device /
param name=ios-package value=CDVDevice /
param name=wp-package value=Device/
/feature

BlackBerry needs to make a small change to add it's own param.name, and
plugman needs to be aware of all the available targets and combine the
output from multiple platform tags.

content src=index.html
is already cross device

The access tags for whitelisting have some minor differences but there is
an open issue for that already. [1]


As far as the location of the file, I agree it would be nice if it was
consistent, but I think we should worry first about the contents of the
file being consistent, then the location.  It does make sense for the file
to sit in the www folder so that this folder is portable, and can be
dropped in another location, however this expectation is already broken by
the different cordova.js files.


[1] https://issues.apache.org/jira/browse/CB-4093


@purplecabbage
risingj.com


On Thu, Sep 26, 2013 at 8:07 AM, Braden Shepherdson bra...@chromium.orgwrote:

 On Thu, Sep 26, 2013 at 11:03 AM, Joe Bowser bows...@gmail.com wrote:

  On Thu, Sep 26, 2013 at 7:18 AM, Braden Shepherdson bra...@chromium.org
 
  wrote:
   I am strongly opposed to splitting into one file per platform. We want
 to
   support platform tags in config.xml, which will allow
 platform-specific
   content within the single config.xml.
 
  Agreed.  I'm not sure if Android actually supports this.  We should
  probably write some JUnit tests against a multi-platform config.xml to
  test this and make sure that our parser actually works well.
 
 
 Let me clarify: I was talking about adding platform tags to CLI's
 top-level www/config.xml. The actual entries would be extracted into that
 platform's final config.xml, without a platform tag.



  
   There are good reasons why the CLI moves the config.xml on some
  platforms.
   On Android, it's really easy to load XML files from res/xml/foo.xml, so
   that's where we put it. We should be deleting the
   platforms/android/assets/www/config.xml though, since it's an unused
   duplicate and confusing.
  
 
  +1 on this as well. The problem is that the documentation covers the
  PhoneGap Build use case and the CLI use case, but not the stand-alone
  use case.  We should document the stand-alone use case, since that's
  really for people who are detail-oriented, and are using things such
  as the CordovaWebView component.

Re: config.xml discussion, we need to talk

2013-09-26 Thread Lindsey Simon

On Thu, Sep 26, 2013 at 8:32 AM, Carlos Santana csantan...@gmail.comwrote:

 Branden,
On Android, it's really easy to load XML files from res/xml/foo.xml,
 so that's where we put it.

 Easy for who?
 I think is difficult for web developer to not find it in www/config.xml and
 start searching for it

 I don't know much about Android so maybe I'm putting my foot in my mouth
 because it's too complex to read the file from www/


When you say www are you referring to project/www or
project/platform/android/assets/www?




 --Carlos


 On Thursday, September 26, 2013, Braden Shepherdson wrote:

  I am strongly opposed to splitting into one file per platform. We want to
  support platform tags in config.xml, which will allow platform-specific
  content within the single config.xml.
 
  There are good reasons why the CLI moves the config.xml on some
 platforms.
  On Android, it's really easy to load XML files from res/xml/foo.xml, so
  that's where we put it. We should be deleting the
  platforms/android/assets/www/config.xml though, since it's an unused
  duplicate and confusing.
 
  Braden
 
 
  On Wed, Sep 25, 2013 at 4:59 PM, Carlos Santana csantan...@gmail.com
 javascript:;
  wrote:
 
   I was not trying to be purist with the w3c www/config.xml
  
   I just want to see some consistency across all platforms for
  configuration
   settings for a Cordova App.
  
   The same way I have a single index.html, app.css and app.js. I want see
  one
   config.xml for all platforms inside www/ or many config.xml per
 platform
   config.ios.xml, config.android.xml, etc... But as a web developer I'm
   excepting all the files that I need to modify inside www/ using CLI or
  not
  
   Even if I have to run something like ./bin/processconfig.sh to
 propagate
   changes from the /www/config.xml
  
   As web developer I might update the config.xml once for every 100 edits
  to
   my app web files (HTML, JS, CSS)
  
   TLDR: consistency wins over correctness
  
   PS: what is the phonegap team doing? I think you tell users to edit one
   config.xml for the web app and pgbuild takes care of the rest
  
  
   -- Carlos
  
   On Wednesday, September 25, 2013, Braden Shepherdson wrote:
  
I'm in favour of CLI (platform parsers, probably) deleting this
www/config.xml that they don't use. It's a waste of space and has
   confused
people in the past.
   
It even confused the iOS prepare code and caused that odd my project
doesn't work if it starts with x, y or z bug (because
  xFactor/config.xml
sorts after www/config.xml, and it was blindly taking the first one).
   
Braden
   
   
On Wed, Sep 25, 2013 at 4:22 PM, Bryan Higgins 
  bhigg...@blackberry.com javascript:;
   javascript:;
wrote:
   
 Thanks for the clarification. BlackBerry happened to luck out
 because
   we
 expect config.xml in www.

 Perhaps copying of config.xml should become a responsibility of the
 platform parsers.

 I can understand moving config.xml to root or cordova for the
 reason
stated
 in the JIRA, but my vote would be to keep it config.xml rather
 than
 app.xml.


 On Wed, Sep 25, 2013 at 3:55 PM, Jesse purplecabb...@gmail.com
   wrote:

  I am not saying deviate, I am saying, what is it supposed to be?
 If
   you
  look at the various platforms you will see it is all over the
 map.
 
  Looking at Android code, and talking to Joe, the only location
 that
   the
  config.xml file is loaded from is in res/xml, and the fact that
 cordova-cli
  creates another one sitting in the www folder is just irrelevant
  sloppiness.
 
  It may make sense for the config.xml file to sit in the root/www
   folder
 of
  the CLI project, but in reality at runtime, it's location will
 vary
   by
  platform.
 
 
 
  @purplecabbage
  risingj.com
 
 
  On Wed, Sep 25, 2013 at 12:29 PM, Bryan Higgins 
bhigg...@blackberry.com
  wrote:
 
   www/config.xml aligns nicely with the w3c widget spec [1]. Why
   would
we
   want to deviate?
  
   [1]
 http://www.w3.org/TR/widgets/#reserved-file-and-folder-names
  
  
   On Wed, Sep 25, 2013 at 3:23 PM, Jesse 
 purplecabb...@gmail.com
 wrote:
  
Seems any project created with the CLI has a config.xml in
 the
   www
   folder.
[1]
Why do we have 2 of these?
   
I also recently closed a defect created by Carlos, stating
 that
   WP8
 did
   NOT
have it's config.xml in the www folder. [2] Now I am not
 sure I
 should
   have
called this invalid, however, after creating a new WP8
 project
   with
 the
CLI, I see a config.xml in the www folder AND one in the app
   root.
 wtf?
   
There is an open issue [3] to re-org config files, where
 Braden
 states
   We
already have plans to move

Re: config.xml discussion, we need to talk

2013-09-26 Thread Joe Bowser

On Thu, Sep 26, 2013 at 8:53 AM, Lindsey Simon els...@gmail.com wrote:

 When you say www are you referring to project/www or
 project/platform/android/assets/www?


That's the kicker, isn't it?  If you're using the CLI, we're talking
project/www, but not everyone uses the CLI, or should use the CLI.  I
think we should tell people not using the CLI where it's located on
each of the platforms.  The CLI can play pretend with the spec, and
the platforms can move on with actually making things more usable.

Re: config.xml discussion, we need to talk

2013-09-26 Thread Jesse

Personally, when I refer to the www folder I am referring to the folder as
part of the app package at runtime, which is usually the same as the device
specific project layout.

iOS: AppRoot/www
wp7: AppRoot/www
wp8: AppRoot/www
windows8: AppRoot/www
Android: AppRoot/assets/www ?

The fact that even the www folder can live in different places on different
devices implies that it is okay for config.xml to live in different places
also.
I don't think it would be worthwhile to move files at loadtime, as Joe
warns.
I also don't think it is worth having a build time script to 'magically'
move files around before they get packaged.


@purplecabbage
risingj.com


On Thu, Sep 26, 2013 at 8:57 AM, Joe Bowser bows...@gmail.com wrote:

 On Thu, Sep 26, 2013 at 8:53 AM, Lindsey Simon els...@gmail.com wrote:
 
  When you say www are you referring to project/www or
  project/platform/android/assets/www?
 

 That's the kicker, isn't it?  If you're using the CLI, we're talking
 project/www, but not everyone uses the CLI, or should use the CLI.  I
 think we should tell people not using the CLI where it's located on
 each of the platforms.  The CLI can play pretend with the spec, and
 the platforms can move on with actually making things more usable.

Re: config.xml discussion, we need to talk

2013-09-26 Thread Joe Bowser

On Thu, Sep 26, 2013 at 8:32 AM, Carlos Santana csantan...@gmail.com wrote:
 Branden,
On Android, it's really easy to load XML files from res/xml/foo.xml,
 so that's where we put it.

 Easy for who?

Easy for anyone who has to actually maintain this.  We have to do this
on startup, and adding extra code to unzip the jar just to get the
config.xml is not something that I want to do, especially since this
can slow down the PluginManager and make Cordova slower.

There's a point where making things easier for the Web Developer will
make the app suck more.  I honestly think that we should focus on
actually enabling developers to make apps that don't suck, which means
that delays for deviceReady for things like this don't belong here.
We have more than enough already.

Re: config.xml discussion, we need to talk

I agree 100% with you Joe enabling developers to make apps that don't suck
And can slow down the PluginManager and make Cordova slower

Just saying because is really easy is sounded a little bit odd to be the
ONLY reason.

But a performance hit is a very good reason to not include the file at
runtime inside with the payload.

At least in mobile performance is king!

Like I said not very familiar with Android yet :-(

--Carlos



On Thu, Sep 26, 2013 at 11:53 AM, Joe Bowser bows...@gmail.com wrote:

 On Thu, Sep 26, 2013 at 8:32 AM, Carlos Santana csantan...@gmail.com
 wrote:
  Branden,
 On Android, it's really easy to load XML files from res/xml/foo.xml,
  so that's where we put it.
 
  Easy for who?

 Easy for anyone who has to actually maintain this.  We have to do this
 on startup, and adding extra code to unzip the jar just to get the
 config.xml is not something that I want to do, especially since this
 can slow down the PluginManager and make Cordova slower.

 There's a point where making things easier for the Web Developer will
 make the app suck more.  I honestly think that we should focus on
 actually enabling developers to make apps that don't suck, which means
 that delays for deviceReady for things like this don't belong here.
 We have more than enough already.




-- 
Carlos Santana
csantan...@gmail.com

Re: config.xml discussion, we need to talk

I agree with Jesse proposal.

1. Clean up ghost copies of config.xml
2. Document a single Table in docs/config_ref_index.md.html
Two columns CLI, Not CLI location of config.xml to be edit by user

--Carlos



On Thu, Sep 26, 2013 at 12:03 PM, Jesse purplecabb...@gmail.com wrote:

 Personally, when I refer to the www folder I am referring to the folder as
 part of the app package at runtime, which is usually the same as the device
 specific project layout.

 iOS: AppRoot/www
 wp7: AppRoot/www
 wp8: AppRoot/www
 windows8: AppRoot/www
 Android: AppRoot/assets/www ?

 The fact that even the www folder can live in different places on different
 devices implies that it is okay for config.xml to live in different places
 also.
 I don't think it would be worthwhile to move files at loadtime, as Joe
 warns.
 I also don't think it is worth having a build time script to 'magically'
 move files around before they get packaged.


 @purplecabbage
 risingj.com


 On Thu, Sep 26, 2013 at 8:57 AM, Joe Bowser bows...@gmail.com wrote:

  On Thu, Sep 26, 2013 at 8:53 AM, Lindsey Simon els...@gmail.com wrote:
  
   When you say www are you referring to project/www or
   project/platform/android/assets/www?
  
 
  That's the kicker, isn't it?  If you're using the CLI, we're talking
  project/www, but not everyone uses the CLI, or should use the CLI.  I
  think we should tell people not using the CLI where it's located on
  each of the platforms.  The CLI can play pretend with the spec, and
  the platforms can move on with actually making things more usable.
 




-- 
Carlos Santana
csantan...@gmail.com

RE: config.xml discussion, we need to talk

2013-09-26 Thread Jonathan Bond-Caron

On Thu Sep 26 10:18 AM, Braden Shepherdson wrote:
 I am strongly opposed to splitting into one file per platform. We want to 
 support
 platform tags in config.xml, which will allow platform-specific content 
 within
 the single config.xml.
 

+1, a single configuration file not in the www/ folder

Re: config.xml discussion, we need to talk

I also agree to keep  a single config.xml and the content as it is today
(not to have platform sections)
just document which one to edit and where is located for the two scenarios
(CLI and not-CLI)



On Thu, Sep 26, 2013 at 1:28 PM, Jonathan Bond-Caron 
jbo...@gdesolutions.com wrote:

 On Thu Sep 26 10:18 AM, Braden Shepherdson wrote:
  I am strongly opposed to splitting into one file per platform. We want
 to support
  platform tags in config.xml, which will allow platform-specific
 content within
  the single config.xml.
 

 +1, a single configuration file not in the www/ folder




-- 
Carlos Santana
csantan...@gmail.com

RE: config.xml discussion, we need to talk

2013-09-26 Thread Jonathan Bond-Caron

On Thu Sep 26 11:32 AM, Carlos Santana wrote:
 Branden,
On Android, it's really easy to load XML files from res/xml/foo.xml, so 
 that's
 where we put it.
 
 Easy for who?
 I think is difficult for web developer to not find it in www/config.xml and 
 start
 searching for it
 

But config.xml has nothing to do with an HTML5 application, it's a cordova 
specific thing (hybrid app config).

It's nice to have it align with the w3c spec for widgets but we're talking 
about 2 different things:
- Hybrid application configuration (which may have enable platform specific 
features)
- HTML5 application configuration (~ w3c widget spec which I'm personally not a 
fan)
The scope of the HTML5 app configuration IMHO is outside of cordova and 
certainly up for debate.

Re: config.xml discussion, we need to talk

This discussion is getting a little tangled, with CLI and not-CLI and so
on. I'm trying to bring together the current situation:

In CLI: there is a top level myproject/www/config.xml. This file is
*accidentally* copied into www/config.xml in each platform.

A **totally different file** with the same name is also generated by the
CLI, based on settings from the defaults.xml, plugin config-file edits,
and the top-level config.xml. This file is placed in
platforms/android/res/xml/config.xml on Android, in
platforms/ios/MyProject/config.xml on iOS, and other places.

I repeat, the platforms/android/res/xml/config.xml and
platforms/android/assets/www/config.xml are **different**.

It's the top-level www/config.xml that we want to give platform tag
support to, so that you can set platform-specific things without editing
the config.xml files inside those platforms.

Not-CLI: Just the latter file, in eg. res/xml/config.xml. Edited by hand,
always specific to this platform.

As far as the standards, it's the latter, res/xml/config.xml, that sort-of
matches the widget spec. The top-level Cordova one doesn't, and we're
moving farther away with adding platform tags.

Braden


On Thu, Sep 26, 2013 at 1:28 PM, Jonathan Bond-Caron 
jbo...@gdesolutions.com wrote:

 On Thu Sep 26 10:18 AM, Braden Shepherdson wrote:
  I am strongly opposed to splitting into one file per platform. We want
 to support
  platform tags in config.xml, which will allow platform-specific
 content within
  the single config.xml.
 

 +1, a single configuration file not in the www/ folder

Re: config.xml discussion, we need to talk

maybe a new file cordova.xml for CLI scenario?


On Thu, Sep 26, 2013 at 1:40 PM, Braden Shepherdson bra...@chromium.orgwrote:

 This discussion is getting a little tangled, with CLI and not-CLI and so
 on. I'm trying to bring together the current situation:

 In CLI: there is a top level myproject/www/config.xml. This file is
 *accidentally* copied into www/config.xml in each platform.

 A **totally different file** with the same name is also generated by the
 CLI, based on settings from the defaults.xml, plugin config-file edits,
 and the top-level config.xml. This file is placed in
 platforms/android/res/xml/config.xml on Android, in
 platforms/ios/MyProject/config.xml on iOS, and other places.

 I repeat, the platforms/android/res/xml/config.xml and
 platforms/android/assets/www/config.xml are **different**.

 It's the top-level www/config.xml that we want to give platform tag
 support to, so that you can set platform-specific things without editing
 the config.xml files inside those platforms.

 Not-CLI: Just the latter file, in eg. res/xml/config.xml. Edited by hand,
 always specific to this platform.

 As far as the standards, it's the latter, res/xml/config.xml, that sort-of
 matches the widget spec. The top-level Cordova one doesn't, and we're
 moving farther away with adding platform tags.

 Braden


 On Thu, Sep 26, 2013 at 1:28 PM, Jonathan Bond-Caron 
 jbo...@gdesolutions.com wrote:

  On Thu Sep 26 10:18 AM, Braden Shepherdson wrote:
   I am strongly opposed to splitting into one file per platform. We want
  to support
   platform tags in config.xml, which will allow platform-specific
  content within
   the single config.xml.
  
 
  +1, a single configuration file not in the www/ folder
 
 




-- 
Carlos Santana
csantan...@gmail.com

Re: config.xml discussion, we need to talk

I'm not sure which file you're suggesting that we rename. We have talked in
the past about moving the top-level one out of www and calling it app.xml
or similar. I don't think there are any plans to rename the
platform-specific ones.

Braden


On Thu, Sep 26, 2013 at 1:59 PM, Carlos Santana csantan...@gmail.comwrote:

 maybe a new file cordova.xml for CLI scenario?


 On Thu, Sep 26, 2013 at 1:40 PM, Braden Shepherdson bra...@chromium.org
 wrote:

  This discussion is getting a little tangled, with CLI and not-CLI and so
  on. I'm trying to bring together the current situation:
 
  In CLI: there is a top level myproject/www/config.xml. This file is
  *accidentally* copied into www/config.xml in each platform.
 
  A **totally different file** with the same name is also generated by the
  CLI, based on settings from the defaults.xml, plugin config-file edits,
  and the top-level config.xml. This file is placed in
  platforms/android/res/xml/config.xml on Android, in
  platforms/ios/MyProject/config.xml on iOS, and other places.
 
  I repeat, the platforms/android/res/xml/config.xml and
  platforms/android/assets/www/config.xml are **different**.
 
  It's the top-level www/config.xml that we want to give platform tag
  support to, so that you can set platform-specific things without editing
  the config.xml files inside those platforms.
 
  Not-CLI: Just the latter file, in eg. res/xml/config.xml. Edited by hand,
  always specific to this platform.
 
  As far as the standards, it's the latter, res/xml/config.xml, that
 sort-of
  matches the widget spec. The top-level Cordova one doesn't, and we're
  moving farther away with adding platform tags.
 
  Braden
 
 
  On Thu, Sep 26, 2013 at 1:28 PM, Jonathan Bond-Caron 
  jbo...@gdesolutions.com wrote:
 
   On Thu Sep 26 10:18 AM, Braden Shepherdson wrote:
I am strongly opposed to splitting into one file per platform. We
 want
   to support
platform tags in config.xml, which will allow platform-specific
   content within
the single config.xml.
   
  
   +1, a single configuration file not in the www/ folder
  
  
 



 --
 Carlos Santana
 csantan...@gmail.com

Re: config.xml discussion, we need to talk

we have one config.xml today lets keep it but lets not add a different file
with same name config.xml in a different location.

maybe I got completely lost in your explanation, sorry :-(


On Thu, Sep 26, 2013 at 2:01 PM, Braden Shepherdson bra...@chromium.orgwrote:

 I'm not sure which file you're suggesting that we rename. We have talked in
 the past about moving the top-level one out of www and calling it app.xml
 or similar. I don't think there are any plans to rename the
 platform-specific ones.

 Braden


 On Thu, Sep 26, 2013 at 1:59 PM, Carlos Santana csantan...@gmail.com
 wrote:

  maybe a new file cordova.xml for CLI scenario?
 
 
  On Thu, Sep 26, 2013 at 1:40 PM, Braden Shepherdson bra...@chromium.org
  wrote:
 
   This discussion is getting a little tangled, with CLI and not-CLI and
 so
   on. I'm trying to bring together the current situation:
  
   In CLI: there is a top level myproject/www/config.xml. This file is
   *accidentally* copied into www/config.xml in each platform.
  
   A **totally different file** with the same name is also generated by
 the
   CLI, based on settings from the defaults.xml, plugin config-file
 edits,
   and the top-level config.xml. This file is placed in
   platforms/android/res/xml/config.xml on Android, in
   platforms/ios/MyProject/config.xml on iOS, and other places.
  
   I repeat, the platforms/android/res/xml/config.xml and
   platforms/android/assets/www/config.xml are **different**.
  
   It's the top-level www/config.xml that we want to give platform tag
   support to, so that you can set platform-specific things without
 editing
   the config.xml files inside those platforms.
  
   Not-CLI: Just the latter file, in eg. res/xml/config.xml. Edited by
 hand,
   always specific to this platform.
  
   As far as the standards, it's the latter, res/xml/config.xml, that
  sort-of
   matches the widget spec. The top-level Cordova one doesn't, and we're
   moving farther away with adding platform tags.
  
   Braden
  
  
   On Thu, Sep 26, 2013 at 1:28 PM, Jonathan Bond-Caron 
   jbo...@gdesolutions.com wrote:
  
On Thu Sep 26 10:18 AM, Braden Shepherdson wrote:
 I am strongly opposed to splitting into one file per platform. We
  want
to support
 platform tags in config.xml, which will allow platform-specific
content within
 the single config.xml.

   
+1, a single configuration file not in the www/ folder
   
   
  
 
 
 
  --
  Carlos Santana
  csantan...@gmail.com
 




-- 
Carlos Santana
csantan...@gmail.com

Re: config.xml discussion, we need to talk

I don't understand at all what you're suggesting. Nobody is proposing
adding any new files.

We have a bug filed to remove the unused accidental duplicates, other than
that I don't think much is going to change here. At least we'd need a
compelling reason to be moving and renaming files. In the non-CLI world,
there's one file to edit, done. In the CLI world, there's still one file to
edit (top-level www/config.xml) and the rest is CLI magic you don't need to
care about as an app developer. I don't see how we can improve on one
central place to edit.

Braden


On Thu, Sep 26, 2013 at 2:05 PM, Carlos Santana csantan...@gmail.comwrote:

 we have one config.xml today lets keep it but lets not add a different file
 with same name config.xml in a different location.

 maybe I got completely lost in your explanation, sorry :-(


 On Thu, Sep 26, 2013 at 2:01 PM, Braden Shepherdson bra...@chromium.org
 wrote:

  I'm not sure which file you're suggesting that we rename. We have talked
 in
  the past about moving the top-level one out of www and calling it app.xml
  or similar. I don't think there are any plans to rename the
  platform-specific ones.
 
  Braden
 
 
  On Thu, Sep 26, 2013 at 1:59 PM, Carlos Santana csantan...@gmail.com
  wrote:
 
   maybe a new file cordova.xml for CLI scenario?
  
  
   On Thu, Sep 26, 2013 at 1:40 PM, Braden Shepherdson 
 bra...@chromium.org
   wrote:
  
This discussion is getting a little tangled, with CLI and not-CLI and
  so
on. I'm trying to bring together the current situation:
   
In CLI: there is a top level myproject/www/config.xml. This file is
*accidentally* copied into www/config.xml in each platform.
   
A **totally different file** with the same name is also generated by
  the
CLI, based on settings from the defaults.xml, plugin config-file
  edits,
and the top-level config.xml. This file is placed in
platforms/android/res/xml/config.xml on Android, in
platforms/ios/MyProject/config.xml on iOS, and other places.
   
I repeat, the platforms/android/res/xml/config.xml and
platforms/android/assets/www/config.xml are **different**.
   
It's the top-level www/config.xml that we want to give platform tag
support to, so that you can set platform-specific things without
  editing
the config.xml files inside those platforms.
   
Not-CLI: Just the latter file, in eg. res/xml/config.xml. Edited by
  hand,
always specific to this platform.
   
As far as the standards, it's the latter, res/xml/config.xml, that
   sort-of
matches the widget spec. The top-level Cordova one doesn't, and we're
moving farther away with adding platform tags.
   
Braden
   
   
On Thu, Sep 26, 2013 at 1:28 PM, Jonathan Bond-Caron 
jbo...@gdesolutions.com wrote:
   
 On Thu Sep 26 10:18 AM, Braden Shepherdson wrote:
  I am strongly opposed to splitting into one file per platform. We
   want
 to support
  platform tags in config.xml, which will allow platform-specific
 content within
  the single config.xml.
 

 +1, a single configuration file not in the www/ folder


   
  
  
  
   --
   Carlos Santana
   csantan...@gmail.com
  
 



 --
 Carlos Santana
 csantan...@gmail.com

Re: config.xml discussion, we need to talk