You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Jesse <pu...@gmail.com> on 2013/09/25 21:23:03 UTC
config.xml discussion, we need to talk
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
risingj.com
Re: config.xml discussion, we need to talk
Posted by Joe Bowser <bo...@gmail.com>.
Because only Blackberry implements it this way.
On iOS, it lives in the root of the iOS project, and on Android it
lives in res/xml, because it's an XML file on Android. I'm fine with
the CLI abstracting out reality as long as we're clear that's what's
being done, and indicate that this is for the CLI users only.
I know that there's some people who would like it if everyone used the
CLI but that's never going to happen, which is why I'm fine with the
CLI being the part of the project that enforces ideological purity.
On Wed, Sep 25, 2013 at 12:29 PM, Bryan Higgins <bh...@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 <pu...@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
>> risingj.com
>>
Re: config.xml discussion, we need to talk
Posted by Carlos Santana <cs...@gmail.com>.
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 <bo...@gmail.com> wrote:
> On Thu, Sep 26, 2013 at 8:32 AM, Carlos Santana <cs...@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
<cs...@gmail.com>
Re: config.xml discussion, we need to talk
Posted by Joe Bowser <bo...@gmail.com>.
On Thu, Sep 26, 2013 at 8:32 AM, Carlos Santana <cs...@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
Posted by "Wargo, John" <jo...@sap.com>.
I may take a pass at a blog post or something highlighting the issues between the two, that might be useful.
John M. Wargo
Mobile Platform Product Management
SAP | Charlotte, NC | USA
Office: +1 704.321.0265 | Mobile: +1 704.249.7476
Email: john.wargo@sap.com
Twitter: @johnwargo
-----Original Message-----
From: Anis KADRI [mailto:anis.kadri@gmail.com]
Sent: Wednesday, October 16, 2013 3:08 PM
To: dev@cordova.apache.org
Subject: Re: config.xml discussion, we need to talk
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 <tw...@symbeeco.com> wrote:
>
> On Oct 16, 2013, at 1:47 PM, Joe Bowser <bo...@gmail.com> wrote:
>
>> On Wed, Oct 16, 2013 at 10:13 AM, Wargo, John <jo...@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
Posted by "Wargo, John" <jo...@sap.com>.
Absolutely. That's ultimately my issue with this conversation - we're being too absolute. I use the CLI with IDEs all the time and it never gives me issues. It's not optimal, but I can get what I need done.
John M. Wargo
Mobile Platform Product Management
SAP | Charlotte, NC | USA
Office: +1 704.321.0265 | Mobile: +1 704.249.7476
Email: john.wargo@sap.com
Twitter: @johnwargo
-----Original Message-----
From: mmocny@google.com [mailto:mmocny@google.com] On Behalf Of Michal Mocny
Sent: Wednesday, October 16, 2013 4:38 PM
To: dev
Subject: Re: config.xml discussion, we need to talk
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 <an...@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 <tw...@symbeeco.com>
> wrote:
> >
> > On Oct 16, 2013, at 1:47 PM, Joe Bowser <bo...@gmail.com> wrote:
> >
> >> On Wed, Oct 16, 2013 at 10:13 AM, Wargo, John <jo...@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
Posted by "Wargo, John" <jo...@sap.com>.
To plugman or not to plugman, that is the question.
Or
Different styles of plugin management.
John M. Wargo
> On Oct 18, 2013, at 3:03 PM, "Steven Gill" <st...@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 <pu...@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 <stevengill97@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 <mm...@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 <an...@gmail.com>
>>>> wrote:
>>>>
>>>>> Erik that's great! Where can we download it?
>>>>> On Oct 18, 2013 8:01 AM, "Andrew Grieve" <ag...@chromium.org>
>> wrote:
>>>>>
>>>>>> Awesome video!!
>>>>>>
>>>>>>
>>>>>> On Fri, Oct 18, 2013 at 3:43 AM, Erik Jan de Wit <
>> edewit@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 <Ma...@somatic.fr> wrote:
>>>>>>>>
>>>>>>>> Great Bryan
>>>>>>>> Totally agree !!!
>>>>>>>>
>>>>>>>> Cordialement.
>>>>>>>> -------------------------------
>>>>>>>> Maxime LUCE - Somatic
>>>>>>>> maxime.luce@somatic.fr
>>>>>>>> 06 28 60 72 34
>>>>>>>> ________________________________
>>>>>>>> De : Brian LeRoux<ma...@brian.io>
>>>>>>>> Envoyé : 18/10/2013 01:48
>>>>>>>> À : dev@cordova.apache.org<ma...@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 <
>>>> tommy@devgeeks.org
>>>>>>> <ma...@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.kadri@gmail.com
>> <mailto:
>>>>>>> anis.kadri@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 <
>>>>>> csantana23@gmail.com
>>>>>>> <ma...@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 <
>>>>>> csantana23@gmail.com
>>>>>>> <ma...@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> ++1 "to install from a given directory instead of
>>>> .cordova/libs."
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Oct 17, 2013 at 12:10 PM, Viras <
>>>>>> viras@users.sourceforge.net
>>>>>>> <ma...@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 <
>>>>>>> viras@users.sourceforge.net<ma...@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 <
>>>>>> mmocny@chromium.org
>>>>>>> <ma...@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-10731<htt**p://
>>>>> www.infil00p.org/config-**<
>>>>>>> http://www.infil00p.org/config-**>
>>>>>>>>>>>>>>> xml-changes-for-ios-and-**android/#comment-10731<
>> 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-****
>>>>>> <
>>>>>>>>> http://www.infil00p.org/**introducing-cordova-3-0-0-for-**>
>>>>>>>>>>>>>>> android/#comment-10694<http://**
>>>>> www.infil00p.org/introducing-**
>>>>>> <
>>>>>>> http://www.infil00p.org/introducing-**>
>>>>>>>>>>>>>>> cordova-3-0-0-for-android/#**comment-10694<
>> 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
>>>>>>>>>>>> --
>>>>>>>>>>>> GOFG - Get On Fat Guy
>>>>>>>>>>>> http://www.gofg.at/ - powered by Cordova
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Carlos Santana
>>>>>>>>>>> <cs...@gmail.com>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Carlos Santana
>>>>>>>>>> <cs...@gmail.com>>
>>
Re: config.xml discussion, we need to talk
Posted by "Wargo, John" <jo...@sap.com>.
Don't forget the short lived deviceReady! ;-)
Most suggestions so far can't be easily understood at first glance. Legacy, merges, workflow and so on aren't words a reader is going to understand immediately when they look at the docs and decide if that is an article they want to read. We can't name it using terms we use, but instead naming it as something that unfamiliar developers will intuitively understand.
John M. Wargo
> On Oct 21, 2013, at 11:26 AM, "Mike Billau" <mi...@gmail.com> wrote:
>
> Lets make the name as confusing as possible, to live up to our history
> (callback, phonegap, cordova.) ;)
>
> Personally I think that the names should try to describe the difference
> between the workflows instead of trying to prescribe some type of usage,
> since there are unknown and developing use cases.
>
> To me the main difference between the workflows is that with the CLI,
> things get merged for you automatically, so I'm in favor of something like
> "CLI/Merges Workflow" and "Non-CLI/Legacy Workflow", and in the very first
> sentence of "Non-CLI/Legacy" we say "It's called "Legacy" because it was
> the pre-3.0 worfklow, not because it is no longer supported."
>
> Michal, we created an item to track the doc changes:
> https://issues.apache.org/jira/browse/CB-5122 I think the bulk of the
> workflow discussion can fit into the "Development Paths" section in the
> main Overview Guide. I'll get started but will continue to monitor this
> thread.
>
>
>> On Mon, Oct 21, 2013 at 10:01 AM, Michal Mocny <mm...@chromium.org> wrote:
>>
>> (Okay, this thread at high risk of bikeshedding, just going to mention that
>> ;) But I do think it would be great to settle once and for all.
>>
>> I like the distinction Steven/Brian are making: Project flow vs Platform
>> flow. I'm not sure that those names are immediately 100% clear (I'll
>> ponder over it) but I like the focus points.
>>
>> I think Ian nails the description: "CLI encourages the "Your cordova web
>> view *IS* your application" mindset"
>>
>> I don't have a big preference one way or the other regarding attaching the
>> word "legacy" to the Platform Flow. I like that it conveys: "the flow you
>> are used to" and "there exists a new flow now that you should evaluate" but
>> I don't like that it may also convey "this flow is going to be deprecated"
>> which I don't think is true.
>>
>> Whatever we call it, I think its important to signal that Platform workflow
>> is for supporting "mucking with platform internals" not for "single
>> platform dev". Single platform dev can be done using CLI just as easily.
>>
>> Should we create a wiki/doc which explains the flow and lists the
>> pros/cons?
>>
>>
>> On Mon, Oct 21, 2013 at 9:20 AM, Ian Clelland <ic...@google.com>
>> wrote:
>>
>>> Legacy, though, sounds like it's something that we're actively moving
>> away
>>> from; something that we support only grudgingly, and which we might
>>> deprecate at the drop of a hat.
>>> The platform-only workflow supports legitimate use-cases which CLI
>> probably
>>> will never cover -- things like embedding a cordova web view inside of a
>>> larger platform-native project.
>>>
>>> The major difference I see with CLI is that it encourages the "Your
>> cordova
>>> web view *IS* your application" mindset. (And if that's true, then why
>>> wouldn't you aim for cross-platform development?) The pre-CLI workflow is
>>> still the way to build all other sorts of applications.
>>>
>>> Ian
>>>
>>>
>>> On Fri, Oct 18, 2013 at 11:30 PM, purplecabbage <purplecabbage@gmail.com
>>>> wrote:
>>>
>>>> I like merge-flow and legacy-flow
>>>>
>>>> Sent from my iPhone
>>>>
>>>>>> On Oct 18, 2013, at 6:59 PM, Carlos Santana <cs...@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 <
>> stevengill97@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 <
>> stevengill97@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 <
>> mmocny@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 <
>>> stevengill97@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 <
>> purplecabbage@gmail.com
>>>>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> IDE or cordova-cli ??
>>>>>>>>>>>
>>>>>>>>>>> @purplecabbage
>>>>>>>>>>> risingj.com
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Oct 18, 2013 at 12:02 PM, Steven Gill <
>>>>>>> stevengill97@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 <
>>>>>> purplecabbage@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
>>>>> <cs...@gmail.com>
>>
RE: config.xml discussion, we need to talk
Posted by Michael Sierra <ms...@adobe.com>.
I've been meaning to catch up with this thread, and haven't had time to do it justice. My high-level takeaway so far is: doc must better clarify relative benefits of CLI vs. platform-level tooling. I've been revamping doc to try to address both workflows, so any lapses on that front are surely mine. There does not yet appear be be a full consensus here, but once there is I'd appreciate if we distill the main points here into an actionable JIRA & assign it to me. I believe the Overview page would need more detail with which developers can make crucial decisions up front, but that changes may affect other sections in less obvious ways.
--Mike Sierra
________________________________________
From: Joe Bowser [bowserj@gmail.com]
Sent: Monday, October 21, 2013 11:40 AM
To: dev
Subject: Re: config.xml discussion, we need to talk
+1 for "More Magic/Less Magic"
On Oct 21, 2013 8:34 AM, "Braden Shepherdson" <br...@chromium.org> wrote:
> "Less Magic" (bin/create, Plugman) and "More Magic" (CLI).[1]
>
> Mike Billau's suggestions look decent to me. How about "classic" instead of
> "legacy"? Removes the "it sucks and will die someday" connotation, since
> that's not true.
>
> Braden
>
>
> On Mon, Oct 21, 2013 at 11:25 AM, Mike Billau <mi...@gmail.com>
> wrote:
>
> > Lets make the name as confusing as possible, to live up to our history
> > (callback, phonegap, cordova.) ;)
> >
> > Personally I think that the names should try to describe the difference
> > between the workflows instead of trying to prescribe some type of usage,
> > since there are unknown and developing use cases.
> >
> > To me the main difference between the workflows is that with the CLI,
> > things get merged for you automatically, so I'm in favor of something
> like
> > "CLI/Merges Workflow" and "Non-CLI/Legacy Workflow", and in the very
> first
> > sentence of "Non-CLI/Legacy" we say "It's called "Legacy" because it was
> > the pre-3.0 worfklow, not because it is no longer supported."
> >
> > Michal, we created an item to track the doc changes:
> > https://issues.apache.org/jira/browse/CB-5122 I think the bulk of the
> > workflow discussion can fit into the "Development Paths" section in the
> > main Overview Guide. I'll get started but will continue to monitor this
> > thread.
> >
> >
> > On Mon, Oct 21, 2013 at 10:01 AM, Michal Mocny <mm...@chromium.org>
> > wrote:
> >
> > > (Okay, this thread at high risk of bikeshedding, just going to mention
> > that
> > > ;) But I do think it would be great to settle once and for all.
> > >
> > > I like the distinction Steven/Brian are making: Project flow vs
> Platform
> > > flow. I'm not sure that those names are immediately 100% clear (I'll
> > > ponder over it) but I like the focus points.
> > >
> > > I think Ian nails the description: "CLI encourages the "Your cordova
> web
> > > view *IS* your application" mindset"
> > >
> > > I don't have a big preference one way or the other regarding attaching
> > the
> > > word "legacy" to the Platform Flow. I like that it conveys: "the flow
> > you
> > > are used to" and "there exists a new flow now that you should evaluate"
> > but
> > > I don't like that it may also convey "this flow is going to be
> > deprecated"
> > > which I don't think is true.
> > >
> > > Whatever we call it, I think its important to signal that Platform
> > workflow
> > > is for supporting "mucking with platform internals" not for "single
> > > platform dev". Single platform dev can be done using CLI just as
> easily.
> > >
> > > Should we create a wiki/doc which explains the flow and lists the
> > > pros/cons?
> > >
> > >
> > > On Mon, Oct 21, 2013 at 9:20 AM, Ian Clelland <ic...@google.com>
> > > wrote:
> > >
> > > > Legacy, though, sounds like it's something that we're actively moving
> > > away
> > > > from; something that we support only grudgingly, and which we might
> > > > deprecate at the drop of a hat.
> > > > The platform-only workflow supports legitimate use-cases which CLI
> > > probably
> > > > will never cover -- things like embedding a cordova web view inside
> of
> > a
> > > > larger platform-native project.
> > > >
> > > > The major difference I see with CLI is that it encourages the "Your
> > > cordova
> > > > web view *IS* your application" mindset. (And if that's true, then
> why
> > > > wouldn't you aim for cross-platform development?) The pre-CLI
> workflow
> > is
> > > > still the way to build all other sorts of applications.
> > > >
> > > > Ian
> > > >
> > > >
> > > > On Fri, Oct 18, 2013 at 11:30 PM, purplecabbage <
> > purplecabbage@gmail.com
> > > > >wrote:
> > > >
> > > > > I like merge-flow and legacy-flow
> > > > >
> > > > > Sent from my iPhone
> > > > >
> > > > > > On Oct 18, 2013, at 6:59 PM, Carlos Santana <
> csantana23@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 <
> > > stevengill97@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 <
> > > stevengill97@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 <
> > > mmocny@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 <
> > > > stevengill97@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 <
> > > purplecabbage@gmail.com
> > > > >
> > > > > >>>>>> wrote:
> > > > > >>>>>>
> > > > > >>>>>>> IDE or cordova-cli ??
> > > > > >>>>>>>
> > > > > >>>>>>> @purplecabbage
> > > > > >>>>>>> risingj.com
> > > > > >>>>>>>
> > > > > >>>>>>>
> > > > > >>>>>>> On Fri, Oct 18, 2013 at 12:02 PM, Steven Gill <
> > > > > >>> stevengill97@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 <
> > > > > >> purplecabbage@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
> > > > > > <cs...@gmail.com>
> > > > >
> > > >
> > >
> >
>
Re: config.xml discussion, we need to talk
Posted by Michal Mocny <mm...@chromium.org>.
On Mon, Oct 21, 2013 at 1:35 PM, Brian LeRoux <b...@brian.io> wrote:
> I think we need to be explicit, not talk about legacy or magic. I'd like to
> propose:
>
> Native Platform Dev -- Build Cordova apps on the metal. No helpers for
> moving across platforms.
> Web Project Dev -- Build web first projects that (mostly) treats native
> projects as build artifacts.
>
+1 !! Thats perfect.
>
>
>
> On Mon, Oct 21, 2013 at 8:34 AM, Braden Shepherdson <braden@chromium.org
> >wrote:
>
> > Whoops, forgot my citation:
> >
> > [1] http://www.catb.org/jargon/html/magic-story.html
> >
> >
> > On Mon, Oct 21, 2013 at 11:33 AM, Braden Shepherdson <
> braden@chromium.org
> > >wrote:
> >
> > > "Less Magic" (bin/create, Plugman) and "More Magic" (CLI).[1]
> > >
> > > Mike Billau's suggestions look decent to me. How about "classic"
> instead
> > > of "legacy"? Removes the "it sucks and will die someday" connotation,
> > since
> > > that's not true.
> > >
> > > Braden
> > >
> > >
> > > On Mon, Oct 21, 2013 at 11:25 AM, Mike Billau <mike.billau@gmail.com
> > >wrote:
> > >
> > >> Lets make the name as confusing as possible, to live up to our history
> > >> (callback, phonegap, cordova.) ;)
> > >>
> > >> Personally I think that the names should try to describe the
> difference
> > >> between the workflows instead of trying to prescribe some type of
> usage,
> > >> since there are unknown and developing use cases.
> > >>
> > >> To me the main difference between the workflows is that with the CLI,
> > >> things get merged for you automatically, so I'm in favor of something
> > like
> > >> "CLI/Merges Workflow" and "Non-CLI/Legacy Workflow", and in the very
> > first
> > >> sentence of "Non-CLI/Legacy" we say "It's called "Legacy" because it
> was
> > >> the pre-3.0 worfklow, not because it is no longer supported."
> > >>
> > >> Michal, we created an item to track the doc changes:
> > >> https://issues.apache.org/jira/browse/CB-5122 I think the bulk of
> the
> > >> workflow discussion can fit into the "Development Paths" section in
> the
> > >> main Overview Guide. I'll get started but will continue to monitor
> this
> > >> thread.
> > >>
> > >>
> > >> On Mon, Oct 21, 2013 at 10:01 AM, Michal Mocny <mm...@chromium.org>
> > >> wrote:
> > >>
> > >> > (Okay, this thread at high risk of bikeshedding, just going to
> mention
> > >> that
> > >> > ;) But I do think it would be great to settle once and for all.
> > >> >
> > >> > I like the distinction Steven/Brian are making: Project flow vs
> > Platform
> > >> > flow. I'm not sure that those names are immediately 100% clear
> (I'll
> > >> > ponder over it) but I like the focus points.
> > >> >
> > >> > I think Ian nails the description: "CLI encourages the "Your
> cordova
> > >> web
> > >> > view *IS* your application" mindset"
> > >> >
> > >> > I don't have a big preference one way or the other regarding
> attaching
> > >> the
> > >> > word "legacy" to the Platform Flow. I like that it conveys: "the
> flow
> > >> you
> > >> > are used to" and "there exists a new flow now that you should
> > evaluate"
> > >> but
> > >> > I don't like that it may also convey "this flow is going to be
> > >> deprecated"
> > >> > which I don't think is true.
> > >> >
> > >> > Whatever we call it, I think its important to signal that Platform
> > >> workflow
> > >> > is for supporting "mucking with platform internals" not for "single
> > >> > platform dev". Single platform dev can be done using CLI just as
> > >> easily.
> > >> >
> > >> > Should we create a wiki/doc which explains the flow and lists the
> > >> > pros/cons?
> > >> >
> > >> >
> > >> > On Mon, Oct 21, 2013 at 9:20 AM, Ian Clelland <iclelland@google.com
> >
> > >> > wrote:
> > >> >
> > >> > > Legacy, though, sounds like it's something that we're actively
> > moving
> > >> > away
> > >> > > from; something that we support only grudgingly, and which we
> might
> > >> > > deprecate at the drop of a hat.
> > >> > > The platform-only workflow supports legitimate use-cases which CLI
> > >> > probably
> > >> > > will never cover -- things like embedding a cordova web view
> inside
> > >> of a
> > >> > > larger platform-native project.
> > >> > >
> > >> > > The major difference I see with CLI is that it encourages the
> "Your
> > >> > cordova
> > >> > > web view *IS* your application" mindset. (And if that's true, then
> > why
> > >> > > wouldn't you aim for cross-platform development?) The pre-CLI
> > >> workflow is
> > >> > > still the way to build all other sorts of applications.
> > >> > >
> > >> > > Ian
> > >> > >
> > >> > >
> > >> > > On Fri, Oct 18, 2013 at 11:30 PM, purplecabbage <
> > >> purplecabbage@gmail.com
> > >> > > >wrote:
> > >> > >
> > >> > > > I like merge-flow and legacy-flow
> > >> > > >
> > >> > > > Sent from my iPhone
> > >> > > >
> > >> > > > > On Oct 18, 2013, at 6:59 PM, Carlos Santana <
> > csantana23@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 <
> > >> > stevengill97@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 <
> > >> > stevengill97@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 <
> > >> > mmocny@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 <
> > >> > > stevengill97@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 <
> > >> > purplecabbage@gmail.com
> > >> > > >
> > >> > > > >>>>>> wrote:
> > >> > > > >>>>>>
> > >> > > > >>>>>>> IDE or cordova-cli ??
> > >> > > > >>>>>>>
> > >> > > > >>>>>>> @purplecabbage
> > >> > > > >>>>>>> risingj.com
> > >> > > > >>>>>>>
> > >> > > > >>>>>>>
> > >> > > > >>>>>>> On Fri, Oct 18, 2013 at 12:02 PM, Steven Gill <
> > >> > > > >>> stevengill97@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 <
> > >> > > > >> purplecabbage@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
> > >> > > > > <cs...@gmail.com>
> > >> > > >
> > >> > >
> > >> >
> > >>
> > >
> > >
> >
>
Re: config.xml discussion, we need to talk
Posted by Ian Clelland <ic...@chromium.org>.
+1 -- I like both of those quite a lot
On Mon, Oct 21, 2013 at 1:35 PM, Brian LeRoux <b...@brian.io> wrote:
> I think we need to be explicit, not talk about legacy or magic. I'd like to
> propose:
>
> Native Platform Dev -- Build Cordova apps on the metal. No helpers for
> moving across platforms.
> Web Project Dev -- Build web first projects that (mostly) treats native
> projects as build artifacts.
>
>
>
> On Mon, Oct 21, 2013 at 8:34 AM, Braden Shepherdson <braden@chromium.org
> >wrote:
>
> > Whoops, forgot my citation:
> >
> > [1] http://www.catb.org/jargon/html/magic-story.html
> >
> >
> > On Mon, Oct 21, 2013 at 11:33 AM, Braden Shepherdson <
> braden@chromium.org
> > >wrote:
> >
> > > "Less Magic" (bin/create, Plugman) and "More Magic" (CLI).[1]
> > >
> > > Mike Billau's suggestions look decent to me. How about "classic"
> instead
> > > of "legacy"? Removes the "it sucks and will die someday" connotation,
> > since
> > > that's not true.
> > >
> > > Braden
> > >
> > >
> > > On Mon, Oct 21, 2013 at 11:25 AM, Mike Billau <mike.billau@gmail.com
> > >wrote:
> > >
> > >> Lets make the name as confusing as possible, to live up to our history
> > >> (callback, phonegap, cordova.) ;)
> > >>
> > >> Personally I think that the names should try to describe the
> difference
> > >> between the workflows instead of trying to prescribe some type of
> usage,
> > >> since there are unknown and developing use cases.
> > >>
> > >> To me the main difference between the workflows is that with the CLI,
> > >> things get merged for you automatically, so I'm in favor of something
> > like
> > >> "CLI/Merges Workflow" and "Non-CLI/Legacy Workflow", and in the very
> > first
> > >> sentence of "Non-CLI/Legacy" we say "It's called "Legacy" because it
> was
> > >> the pre-3.0 worfklow, not because it is no longer supported."
> > >>
> > >> Michal, we created an item to track the doc changes:
> > >> https://issues.apache.org/jira/browse/CB-5122 I think the bulk of
> the
> > >> workflow discussion can fit into the "Development Paths" section in
> the
> > >> main Overview Guide. I'll get started but will continue to monitor
> this
> > >> thread.
> > >>
> > >>
> > >> On Mon, Oct 21, 2013 at 10:01 AM, Michal Mocny <mm...@chromium.org>
> > >> wrote:
> > >>
> > >> > (Okay, this thread at high risk of bikeshedding, just going to
> mention
> > >> that
> > >> > ;) But I do think it would be great to settle once and for all.
> > >> >
> > >> > I like the distinction Steven/Brian are making: Project flow vs
> > Platform
> > >> > flow. I'm not sure that those names are immediately 100% clear
> (I'll
> > >> > ponder over it) but I like the focus points.
> > >> >
> > >> > I think Ian nails the description: "CLI encourages the "Your
> cordova
> > >> web
> > >> > view *IS* your application" mindset"
> > >> >
> > >> > I don't have a big preference one way or the other regarding
> attaching
> > >> the
> > >> > word "legacy" to the Platform Flow. I like that it conveys: "the
> flow
> > >> you
> > >> > are used to" and "there exists a new flow now that you should
> > evaluate"
> > >> but
> > >> > I don't like that it may also convey "this flow is going to be
> > >> deprecated"
> > >> > which I don't think is true.
> > >> >
> > >> > Whatever we call it, I think its important to signal that Platform
> > >> workflow
> > >> > is for supporting "mucking with platform internals" not for "single
> > >> > platform dev". Single platform dev can be done using CLI just as
> > >> easily.
> > >> >
> > >> > Should we create a wiki/doc which explains the flow and lists the
> > >> > pros/cons?
> > >> >
> > >> >
> > >> > On Mon, Oct 21, 2013 at 9:20 AM, Ian Clelland <iclelland@google.com
> >
> > >> > wrote:
> > >> >
> > >> > > Legacy, though, sounds like it's something that we're actively
> > moving
> > >> > away
> > >> > > from; something that we support only grudgingly, and which we
> might
> > >> > > deprecate at the drop of a hat.
> > >> > > The platform-only workflow supports legitimate use-cases which CLI
> > >> > probably
> > >> > > will never cover -- things like embedding a cordova web view
> inside
> > >> of a
> > >> > > larger platform-native project.
> > >> > >
> > >> > > The major difference I see with CLI is that it encourages the
> "Your
> > >> > cordova
> > >> > > web view *IS* your application" mindset. (And if that's true, then
> > why
> > >> > > wouldn't you aim for cross-platform development?) The pre-CLI
> > >> workflow is
> > >> > > still the way to build all other sorts of applications.
> > >> > >
> > >> > > Ian
> > >> > >
> > >> > >
> > >> > > On Fri, Oct 18, 2013 at 11:30 PM, purplecabbage <
> > >> purplecabbage@gmail.com
> > >> > > >wrote:
> > >> > >
> > >> > > > I like merge-flow and legacy-flow
> > >> > > >
> > >> > > > Sent from my iPhone
> > >> > > >
> > >> > > > > On Oct 18, 2013, at 6:59 PM, Carlos Santana <
> > csantana23@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 <
> > >> > stevengill97@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 <
> > >> > stevengill97@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 <
> > >> > mmocny@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 <
> > >> > > stevengill97@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 <
> > >> > purplecabbage@gmail.com
> > >> > > >
> > >> > > > >>>>>> wrote:
> > >> > > > >>>>>>
> > >> > > > >>>>>>> IDE or cordova-cli ??
> > >> > > > >>>>>>>
> > >> > > > >>>>>>> @purplecabbage
> > >> > > > >>>>>>> risingj.com
> > >> > > > >>>>>>>
> > >> > > > >>>>>>>
> > >> > > > >>>>>>> On Fri, Oct 18, 2013 at 12:02 PM, Steven Gill <
> > >> > > > >>> stevengill97@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 <
> > >> > > > >> purplecabbage@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
> > >> > > > > <cs...@gmail.com>
> > >> > > >
> > >> > >
> > >> >
> > >>
> > >
> > >
> >
>
Re: config.xml discussion, we need to talk
Posted by Mike Billau <mi...@gmail.com>.
Mike Sierra made a good point here[1] that throughout the docs it will
probably be better to not explicitly refer to those names and instead use
causual references to "cross-platform" or "platform-centered" workflows and
then link to the Overview section, where these workflows are explicit and
the differences explained. This way if we end up changing the names or
adding more workflows, we only have to change this section.
[1]https://github.com/apache/cordova-docs/pull/140#discussion_r7437249
On Mon, Nov 18, 2013 at 1:28 PM, Michal Mocny <mm...@chromium.org> wrote:
> Closest we came to consensus was:
>
> "Web Project Dev"
> vs
> "Native Platform Dev"
>
> Though I wouldn't say that that was nailed down (just a few +1's here and
> there).
>
> -Michal
>
>
> On Mon, Nov 18, 2013 at 11:10 AM, Dan Moore <mo...@yahoo.com> wrote:
>
> > Hi folks,
> >
> > Did the nomenclature to help users distinguish between cordova cli and
> the
> > older create scripts ever get nailed down?
> >
> > Thanks,
> > Dan
> >
> >
> >
> >
> >
> > On Monday, October 21, 2013 2:33 PM, Steven Gill <stevengill97@gmail.com
> >
> > wrote:
> >
> > +1 to Native Platform Dev vs Web Project Dev
> >
> >
> >
> > On Mon, Oct 21, 2013 at 1:31 PM, Axel Nennker <ig...@gmail.com>
> > wrote:
> >
> > > +1
> > > Although I was about to suggest "single platform development" and
> "multi
> > > platform development".
> > >
> > > Axel
> > > Am 21.10.2013 19:36 schrieb "Brian LeRoux" <b...@brian.io>:
> > >
> > > > I think we need to be explicit, not talk about legacy or magic. I'd
> > like
> > > to
> > > > propose:
> > > >
> > > > Native Platform Dev -- Build Cordova apps on the metal. No helpers
> for
> > > > moving across platforms.
> > > > Web Project Dev -- Build web first projects that (mostly) treats
> native
> > > > projects as build artifacts.
> > > >
> > > >
> > > >
> > > > On Mon, Oct 21, 2013 at 8:34 AM, Braden Shepherdson <
> > braden@chromium.org
> > > > >wrote:
> > > >
> > > > > Whoops, forgot my citation:
> > > > >
> > > > > [1] http://www.catb.org/jargon/html/magic-story.html
> > > > >
> > > > >
> > > > > On Mon, Oct 21, 2013 at 11:33 AM, Braden Shepherdson <
> > > > braden@chromium.org
> > > > > >wrote:
> > > > >
> > > > > > "Less Magic" (bin/create, Plugman) and "More Magic" (CLI).[1]
> > > > > >
> > > > > > Mike Billau's suggestions look decent to me. How about "classic"
> > > > instead
> > > > > > of "legacy"? Removes the "it sucks and will die someday"
> > connotation,
> > > > > since
> > > > > > that's not true.
> > > > > >
> > > > > > Braden
> > > > > >
> > > > > >
> > > > > > On Mon, Oct 21, 2013 at 11:25 AM, Mike Billau <
> > mike.billau@gmail.com
> > > > > >wrote:
> > > > > >
> > > > > >> Lets make the name as confusing as possible, to live up to our
> > > history
> > > > > >> (callback, phonegap, cordova.) ;)
> > > > > >>
> > > > > >> Personally I think that the names should try to describe the
> > > > difference
> > > > > >> between the workflows instead of trying to prescribe some type
> of
> > > > usage,
> > > > > >> since there are unknown and developing use cases.
> > > > > >>
> > > > > >> To me the main difference between the workflows is that with the
> > > CLI,
> > > > > >> things get merged for you automatically, so I'm in favor of
> > > something
> > > > > like
> > > > > >> "CLI/Merges Workflow" and "Non-CLI/Legacy Workflow", and in the
> > very
> > > > > first
> > > > > >> sentence of "Non-CLI/Legacy" we say "It's called "Legacy"
> because
> > it
> > > > was
> > > > > >> the pre-3.0 worfklow, not because it is no longer supported."
> > > > > >>
> > > > > >> Michal, we created an item to track the doc changes:
> > > > > >> https://issues.apache.org/jira/browse/CB-5122 I think the bulk
> > of
> > > > the
> > > > > >> workflow discussion can fit into the "Development Paths" section
> > in
> > > > the
> > > > > >> main Overview Guide. I'll get started but will continue to
> monitor
> > > > this
> > > > > >> thread.
> > > > > >>
> > > > > >>
> > > > > >> On Mon, Oct 21, 2013 at 10:01 AM, Michal Mocny <
> > mmocny@chromium.org
> > > >
> > > > > >> wrote:
> > > > > >>
> > > > > >> > (Okay, this thread at high risk of bikeshedding, just going to
> > > > mention
> > > > > >> that
> > > > > >> > ;) But I do think it would be great to settle once and for
> all.
> > > > > >> >
> > > > > >> > I like the distinction Steven/Brian are making: Project flow
> vs
> > > > > Platform
> > > > > >> > flow. I'm not sure that those names are immediately 100%
> clear
> > > > (I'll
> > > > > >> > ponder over it) but I like the focus points.
> > > > > >> >
> > > > > >> > I think Ian nails the description: "CLI encourages the "Your
> > > > cordova
> > > > > >> web
> > > > > >> > view *IS* your application" mindset"
> > > > > >> >
> > > > > >> > I don't have a big preference one way or the other regarding
> > > > attaching
> > > > > >> the
> > > > > >> > word "legacy" to the Platform Flow. I like that it conveys:
> > "the
> > > > flow
> > > > > >> you
> > > > > >> > are used to" and "there exists a new flow now that you should
> > > > > evaluate"
> > > > > >> but
> > > > > >> > I don't like that it may also convey "this flow is going to be
> > > > > >> deprecated"
> > > > > >> > which I don't think is true.
> > > > > >> >
> > > > > >> > Whatever we call it, I think its important to signal that
> > Platform
> > > > > >> workflow
> > > > > >> > is for supporting "mucking with platform internals" not for
> > > "single
> > > > > >> > platform dev". Single platform dev can be done using CLI just
> > as
> > > > > >> easily.
> > > > > >> >
> > > > > >> > Should we create a wiki/doc which explains the flow and lists
> > the
> > > > > >> > pros/cons?
> > > > > >> >
> > > > > >> >
> > > > > >> > On Mon, Oct 21, 2013 at 9:20 AM, Ian Clelland <
> > > iclelland@google.com
> > > > >
> > > > > >> > wrote:
> > > > > >> >
> > > > > >> > > Legacy, though, sounds like it's something that we're
> actively
> > > > > moving
> > > > > >> > away
> > > > > >> > > from; something that we support only grudgingly, and which
> we
> > > > might
> > > > > >> > > deprecate at the drop of a hat.
> > > > > >> > > The platform-only workflow supports legitimate use-cases
> which
> > > CLI
> > > > > >> > probably
> > > > > >> > > will never cover -- things like embedding a cordova web view
> > > > inside
> > > > > >> of a
> > > > > >> > > larger platform-native project.
> > > > > >> > >
> > > > > >> > > The major difference I see with CLI is that it encourages
> the
> > > > "Your
> > > > > >> > cordova
> > > > > >> > > web view *IS* your application" mindset. (And if that's
> true,
> > > then
> > > > > why
> > > > > >> > > wouldn't you aim for cross-platform development?) The
> pre-CLI
> > > > > >> workflow is
> > > > > >> > > still the way to build all other sorts of applications.
> > > > > >> > >
> > > > > >> > > Ian
> > > > > >> > >
> > > > > >> > >
> > > > > >> > > On Fri, Oct 18, 2013 at 11:30 PM, purplecabbage <
> > > > > >> purplecabbage@gmail.com
> > > > > >> > > >wrote:
> > > > > >> > >
> > > > > >> > > > I like merge-flow and legacy-flow
> > > > > >> > > >
> > > > > >> > > > Sent from my iPhone
> > > > > >> > > >
> > > > > >> > > > > On Oct 18, 2013, at 6:59 PM, Carlos Santana <
> > > > > csantana23@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 <
> > > > > >> > stevengill97@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 <
> > > > > >> > stevengill97@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 <
> > > > > >> > mmocny@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 <
> > > > > >> > > stevengill97@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 <
> > > > > >> > purplecabbage@gmail.com
> > > > > >> > > >
> > > > > >> > > > >>>>>> wrote:
> > > > > >> > > > >>>>>>
> > > > > >> > > > >>>>>>> IDE or cordova-cli ??
> > > > > >> > > > >>>>>>>
> > > > > >> > > > >>>>>>> @purplecabbage
> > > > > >> > > > >>>>>>> risingj.com
> > > > > >> > > > >>>>>>>
> > > > > >> > > > >>>>>>>
> > > > > >> > > > >>>>>>> On Fri, Oct 18, 2013 at 12:02 PM, Steven Gill <
> > > > > >> > > > >>> stevengill97@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 <
> > > > > >> > > > >> purplecabbage@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
> > > > > >> > > > > <cs...@gmail.com>
> > > > > >> > > >
> > > > > >> > >
> > > > > >> >
> > > > > >>
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: config.xml discussion, we need to talk
Posted by Michal Mocny <mm...@chromium.org>.
Closest we came to consensus was:
"Web Project Dev"
vs
"Native Platform Dev"
Though I wouldn't say that that was nailed down (just a few +1's here and
there).
-Michal
On Mon, Nov 18, 2013 at 11:10 AM, Dan Moore <mo...@yahoo.com> wrote:
> Hi folks,
>
> Did the nomenclature to help users distinguish between cordova cli and the
> older create scripts ever get nailed down?
>
> Thanks,
> Dan
>
>
>
>
>
> On Monday, October 21, 2013 2:33 PM, Steven Gill <st...@gmail.com>
> wrote:
>
> +1 to Native Platform Dev vs Web Project Dev
>
>
>
> On Mon, Oct 21, 2013 at 1:31 PM, Axel Nennker <ig...@gmail.com>
> wrote:
>
> > +1
> > Although I was about to suggest "single platform development" and "multi
> > platform development".
> >
> > Axel
> > Am 21.10.2013 19:36 schrieb "Brian LeRoux" <b...@brian.io>:
> >
> > > I think we need to be explicit, not talk about legacy or magic. I'd
> like
> > to
> > > propose:
> > >
> > > Native Platform Dev -- Build Cordova apps on the metal. No helpers for
> > > moving across platforms.
> > > Web Project Dev -- Build web first projects that (mostly) treats native
> > > projects as build artifacts.
> > >
> > >
> > >
> > > On Mon, Oct 21, 2013 at 8:34 AM, Braden Shepherdson <
> braden@chromium.org
> > > >wrote:
> > >
> > > > Whoops, forgot my citation:
> > > >
> > > > [1] http://www.catb.org/jargon/html/magic-story.html
> > > >
> > > >
> > > > On Mon, Oct 21, 2013 at 11:33 AM, Braden Shepherdson <
> > > braden@chromium.org
> > > > >wrote:
> > > >
> > > > > "Less Magic" (bin/create, Plugman) and "More Magic" (CLI).[1]
> > > > >
> > > > > Mike Billau's suggestions look decent to me. How about "classic"
> > > instead
> > > > > of "legacy"? Removes the "it sucks and will die someday"
> connotation,
> > > > since
> > > > > that's not true.
> > > > >
> > > > > Braden
> > > > >
> > > > >
> > > > > On Mon, Oct 21, 2013 at 11:25 AM, Mike Billau <
> mike.billau@gmail.com
> > > > >wrote:
> > > > >
> > > > >> Lets make the name as confusing as possible, to live up to our
> > history
> > > > >> (callback, phonegap, cordova.) ;)
> > > > >>
> > > > >> Personally I think that the names should try to describe the
> > > difference
> > > > >> between the workflows instead of trying to prescribe some type of
> > > usage,
> > > > >> since there are unknown and developing use cases.
> > > > >>
> > > > >> To me the main difference between the workflows is that with the
> > CLI,
> > > > >> things get merged for you automatically, so I'm in favor of
> > something
> > > > like
> > > > >> "CLI/Merges Workflow" and "Non-CLI/Legacy Workflow", and in the
> very
> > > > first
> > > > >> sentence of "Non-CLI/Legacy" we say "It's called "Legacy" because
> it
> > > was
> > > > >> the pre-3.0 worfklow, not because it is no longer supported."
> > > > >>
> > > > >> Michal, we created an item to track the doc changes:
> > > > >> https://issues.apache.org/jira/browse/CB-5122 I think the bulk
> of
> > > the
> > > > >> workflow discussion can fit into the "Development Paths" section
> in
> > > the
> > > > >> main Overview Guide. I'll get started but will continue to monitor
> > > this
> > > > >> thread.
> > > > >>
> > > > >>
> > > > >> On Mon, Oct 21, 2013 at 10:01 AM, Michal Mocny <
> mmocny@chromium.org
> > >
> > > > >> wrote:
> > > > >>
> > > > >> > (Okay, this thread at high risk of bikeshedding, just going to
> > > mention
> > > > >> that
> > > > >> > ;) But I do think it would be great to settle once and for all.
> > > > >> >
> > > > >> > I like the distinction Steven/Brian are making: Project flow vs
> > > > Platform
> > > > >> > flow. I'm not sure that those names are immediately 100% clear
> > > (I'll
> > > > >> > ponder over it) but I like the focus points.
> > > > >> >
> > > > >> > I think Ian nails the description: "CLI encourages the "Your
> > > cordova
> > > > >> web
> > > > >> > view *IS* your application" mindset"
> > > > >> >
> > > > >> > I don't have a big preference one way or the other regarding
> > > attaching
> > > > >> the
> > > > >> > word "legacy" to the Platform Flow. I like that it conveys:
> "the
> > > flow
> > > > >> you
> > > > >> > are used to" and "there exists a new flow now that you should
> > > > evaluate"
> > > > >> but
> > > > >> > I don't like that it may also convey "this flow is going to be
> > > > >> deprecated"
> > > > >> > which I don't think is true.
> > > > >> >
> > > > >> > Whatever we call it, I think its important to signal that
> Platform
> > > > >> workflow
> > > > >> > is for supporting "mucking with platform internals" not for
> > "single
> > > > >> > platform dev". Single platform dev can be done using CLI just
> as
> > > > >> easily.
> > > > >> >
> > > > >> > Should we create a wiki/doc which explains the flow and lists
> the
> > > > >> > pros/cons?
> > > > >> >
> > > > >> >
> > > > >> > On Mon, Oct 21, 2013 at 9:20 AM, Ian Clelland <
> > iclelland@google.com
> > > >
> > > > >> > wrote:
> > > > >> >
> > > > >> > > Legacy, though, sounds like it's something that we're actively
> > > > moving
> > > > >> > away
> > > > >> > > from; something that we support only grudgingly, and which we
> > > might
> > > > >> > > deprecate at the drop of a hat.
> > > > >> > > The platform-only workflow supports legitimate use-cases which
> > CLI
> > > > >> > probably
> > > > >> > > will never cover -- things like embedding a cordova web view
> > > inside
> > > > >> of a
> > > > >> > > larger platform-native project.
> > > > >> > >
> > > > >> > > The major difference I see with CLI is that it encourages the
> > > "Your
> > > > >> > cordova
> > > > >> > > web view *IS* your application" mindset. (And if that's true,
> > then
> > > > why
> > > > >> > > wouldn't you aim for cross-platform development?) The pre-CLI
> > > > >> workflow is
> > > > >> > > still the way to build all other sorts of applications.
> > > > >> > >
> > > > >> > > Ian
> > > > >> > >
> > > > >> > >
> > > > >> > > On Fri, Oct 18, 2013 at 11:30 PM, purplecabbage <
> > > > >> purplecabbage@gmail.com
> > > > >> > > >wrote:
> > > > >> > >
> > > > >> > > > I like merge-flow and legacy-flow
> > > > >> > > >
> > > > >> > > > Sent from my iPhone
> > > > >> > > >
> > > > >> > > > > On Oct 18, 2013, at 6:59 PM, Carlos Santana <
> > > > csantana23@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 <
> > > > >> > stevengill97@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 <
> > > > >> > stevengill97@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 <
> > > > >> > mmocny@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 <
> > > > >> > > stevengill97@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 <
> > > > >> > purplecabbage@gmail.com
> > > > >> > > >
> > > > >> > > > >>>>>> wrote:
> > > > >> > > > >>>>>>
> > > > >> > > > >>>>>>> IDE or cordova-cli ??
> > > > >> > > > >>>>>>>
> > > > >> > > > >>>>>>> @purplecabbage
> > > > >> > > > >>>>>>> risingj.com
> > > > >> > > > >>>>>>>
> > > > >> > > > >>>>>>>
> > > > >> > > > >>>>>>> On Fri, Oct 18, 2013 at 12:02 PM, Steven Gill <
> > > > >> > > > >>> stevengill97@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 <
> > > > >> > > > >> purplecabbage@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
> > > > >> > > > > <cs...@gmail.com>
> > > > >> > > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > > >
> > > > >
> > > >
> > >
> >
>
Re: config.xml discussion, we need to talk
Posted by Dan Moore <mo...@yahoo.com>.
Hi folks,
Did the nomenclature to help users distinguish between cordova cli and the older create scripts ever get nailed down?
Thanks,
Dan
On Monday, October 21, 2013 2:33 PM, Steven Gill <st...@gmail.com> wrote:
+1 to Native Platform Dev vs Web Project Dev
On Mon, Oct 21, 2013 at 1:31 PM, Axel Nennker <ig...@gmail.com> wrote:
> +1
> Although I was about to suggest "single platform development" and "multi
> platform development".
>
> Axel
> Am 21.10.2013 19:36 schrieb "Brian LeRoux" <b...@brian.io>:
>
> > I think we need to be explicit, not talk about legacy or magic. I'd like
> to
> > propose:
> >
> > Native Platform Dev -- Build Cordova apps on the metal. No helpers for
> > moving across platforms.
> > Web Project Dev -- Build web first projects that (mostly) treats native
> > projects as build artifacts.
> >
> >
> >
> > On Mon, Oct 21, 2013 at 8:34 AM, Braden Shepherdson <braden@chromium.org
> > >wrote:
> >
> > > Whoops, forgot my citation:
> > >
> > > [1] http://www.catb.org/jargon/html/magic-story.html
> > >
> > >
> > > On Mon, Oct 21, 2013 at 11:33 AM, Braden Shepherdson <
> > braden@chromium.org
> > > >wrote:
> > >
> > > > "Less Magic" (bin/create, Plugman) and "More Magic" (CLI).[1]
> > > >
> > > > Mike Billau's suggestions look decent to me. How about "classic"
> > instead
> > > > of "legacy"? Removes the "it sucks and will die someday" connotation,
> > > since
> > > > that's not true.
> > > >
> > > > Braden
> > > >
> > > >
> > > > On Mon, Oct 21, 2013 at 11:25 AM, Mike Billau <mike.billau@gmail.com
> > > >wrote:
> > > >
> > > >> Lets make the name as confusing as possible, to live up to our
> history
> > > >> (callback, phonegap, cordova.) ;)
> > > >>
> > > >> Personally I think that the names should try to describe the
> > difference
> > > >> between the workflows instead of trying to prescribe some type of
> > usage,
> > > >> since there are unknown and developing use cases.
> > > >>
> > > >> To me the main difference between the workflows is that with the
> CLI,
> > > >> things get merged for you automatically, so I'm in favor of
> something
> > > like
> > > >> "CLI/Merges Workflow" and "Non-CLI/Legacy Workflow", and in the very
> > > first
> > > >> sentence of "Non-CLI/Legacy" we say "It's called "Legacy" because it
> > was
> > > >> the pre-3.0 worfklow, not because it is no longer supported."
> > > >>
> > > >> Michal, we created an item to track the doc changes:
> > > >> https://issues.apache.org/jira/browse/CB-5122 I think the bulk of
> > the
> > > >> workflow discussion can fit into the "Development Paths" section in
> > the
> > > >> main Overview Guide. I'll get started but will continue to monitor
> > this
> > > >> thread.
> > > >>
> > > >>
> > > >> On Mon, Oct 21, 2013 at 10:01 AM, Michal Mocny <mmocny@chromium.org
> >
> > > >> wrote:
> > > >>
> > > >> > (Okay, this thread at high risk of bikeshedding, just going to
> > mention
> > > >> that
> > > >> > ;) But I do think it would be great to settle once and for all.
> > > >> >
> > > >> > I like the distinction Steven/Brian are making: Project flow vs
> > > Platform
> > > >> > flow. I'm not sure that those names are immediately 100% clear
> > (I'll
> > > >> > ponder over it) but I like the focus points.
> > > >> >
> > > >> > I think Ian nails the description: "CLI encourages the "Your
> > cordova
> > > >> web
> > > >> > view *IS* your application" mindset"
> > > >> >
> > > >> > I don't have a big preference one way or the other regarding
> > attaching
> > > >> the
> > > >> > word "legacy" to the Platform Flow. I like that it conveys: "the
> > flow
> > > >> you
> > > >> > are used to" and "there exists a new flow now that you should
> > > evaluate"
> > > >> but
> > > >> > I don't like that it may also convey "this flow is going to be
> > > >> deprecated"
> > > >> > which I don't think is true.
> > > >> >
> > > >> > Whatever we call it, I think its important to signal that Platform
> > > >> workflow
> > > >> > is for supporting "mucking with platform internals" not for
> "single
> > > >> > platform dev". Single platform dev can be done using CLI just as
> > > >> easily.
> > > >> >
> > > >> > Should we create a wiki/doc which explains the flow and lists the
> > > >> > pros/cons?
> > > >> >
> > > >> >
> > > >> > On Mon, Oct 21, 2013 at 9:20 AM, Ian Clelland <
> iclelland@google.com
> > >
> > > >> > wrote:
> > > >> >
> > > >> > > Legacy, though, sounds like it's something that we're actively
> > > moving
> > > >> > away
> > > >> > > from; something that we support only grudgingly, and which we
> > might
> > > >> > > deprecate at the drop of a hat.
> > > >> > > The platform-only workflow supports legitimate use-cases which
> CLI
> > > >> > probably
> > > >> > > will never cover -- things like embedding a cordova web view
> > inside
> > > >> of a
> > > >> > > larger platform-native project.
> > > >> > >
> > > >> > > The major difference I see with CLI is that it encourages the
> > "Your
> > > >> > cordova
> > > >> > > web view *IS* your application" mindset. (And if that's true,
> then
> > > why
> > > >> > > wouldn't you aim for cross-platform development?) The pre-CLI
> > > >> workflow is
> > > >> > > still the way to build all other sorts of applications.
> > > >> > >
> > > >> > > Ian
> > > >> > >
> > > >> > >
> > > >> > > On Fri, Oct 18, 2013 at 11:30 PM, purplecabbage <
> > > >> purplecabbage@gmail.com
> > > >> > > >wrote:
> > > >> > >
> > > >> > > > I like merge-flow and legacy-flow
> > > >> > > >
> > > >> > > > Sent from my iPhone
> > > >> > > >
> > > >> > > > > On Oct 18, 2013, at 6:59 PM, Carlos Santana <
> > > csantana23@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 <
> > > >> > stevengill97@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 <
> > > >> > stevengill97@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 <
> > > >> > mmocny@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 <
> > > >> > > stevengill97@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 <
> > > >> > purplecabbage@gmail.com
> > > >> > > >
> > > >> > > > >>>>>> wrote:
> > > >> > > > >>>>>>
> > > >> > > > >>>>>>> IDE or cordova-cli ??
> > > >> > > > >>>>>>>
> > > >> > > > >>>>>>> @purplecabbage
> > > >> > > > >>>>>>> risingj.com
> > > >> > > > >>>>>>>
> > > >> > > > >>>>>>>
> > > >> > > > >>>>>>> On Fri, Oct 18, 2013 at 12:02 PM, Steven Gill <
> > > >> > > > >>> stevengill97@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 <
> > > >> > > > >> purplecabbage@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
> > > >> > > > > <cs...@gmail.com>
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > > >
> > > >
> > >
> >
>
Re: config.xml discussion, we need to talk
Posted by Steven Gill <st...@gmail.com>.
+1 to Native Platform Dev vs Web Project Dev
On Mon, Oct 21, 2013 at 1:31 PM, Axel Nennker <ig...@gmail.com> wrote:
> +1
> Although I was about to suggest "single platform development" and "multi
> platform development".
>
> Axel
> Am 21.10.2013 19:36 schrieb "Brian LeRoux" <b...@brian.io>:
>
> > I think we need to be explicit, not talk about legacy or magic. I'd like
> to
> > propose:
> >
> > Native Platform Dev -- Build Cordova apps on the metal. No helpers for
> > moving across platforms.
> > Web Project Dev -- Build web first projects that (mostly) treats native
> > projects as build artifacts.
> >
> >
> >
> > On Mon, Oct 21, 2013 at 8:34 AM, Braden Shepherdson <braden@chromium.org
> > >wrote:
> >
> > > Whoops, forgot my citation:
> > >
> > > [1] http://www.catb.org/jargon/html/magic-story.html
> > >
> > >
> > > On Mon, Oct 21, 2013 at 11:33 AM, Braden Shepherdson <
> > braden@chromium.org
> > > >wrote:
> > >
> > > > "Less Magic" (bin/create, Plugman) and "More Magic" (CLI).[1]
> > > >
> > > > Mike Billau's suggestions look decent to me. How about "classic"
> > instead
> > > > of "legacy"? Removes the "it sucks and will die someday" connotation,
> > > since
> > > > that's not true.
> > > >
> > > > Braden
> > > >
> > > >
> > > > On Mon, Oct 21, 2013 at 11:25 AM, Mike Billau <mike.billau@gmail.com
> > > >wrote:
> > > >
> > > >> Lets make the name as confusing as possible, to live up to our
> history
> > > >> (callback, phonegap, cordova.) ;)
> > > >>
> > > >> Personally I think that the names should try to describe the
> > difference
> > > >> between the workflows instead of trying to prescribe some type of
> > usage,
> > > >> since there are unknown and developing use cases.
> > > >>
> > > >> To me the main difference between the workflows is that with the
> CLI,
> > > >> things get merged for you automatically, so I'm in favor of
> something
> > > like
> > > >> "CLI/Merges Workflow" and "Non-CLI/Legacy Workflow", and in the very
> > > first
> > > >> sentence of "Non-CLI/Legacy" we say "It's called "Legacy" because it
> > was
> > > >> the pre-3.0 worfklow, not because it is no longer supported."
> > > >>
> > > >> Michal, we created an item to track the doc changes:
> > > >> https://issues.apache.org/jira/browse/CB-5122 I think the bulk of
> > the
> > > >> workflow discussion can fit into the "Development Paths" section in
> > the
> > > >> main Overview Guide. I'll get started but will continue to monitor
> > this
> > > >> thread.
> > > >>
> > > >>
> > > >> On Mon, Oct 21, 2013 at 10:01 AM, Michal Mocny <mmocny@chromium.org
> >
> > > >> wrote:
> > > >>
> > > >> > (Okay, this thread at high risk of bikeshedding, just going to
> > mention
> > > >> that
> > > >> > ;) But I do think it would be great to settle once and for all.
> > > >> >
> > > >> > I like the distinction Steven/Brian are making: Project flow vs
> > > Platform
> > > >> > flow. I'm not sure that those names are immediately 100% clear
> > (I'll
> > > >> > ponder over it) but I like the focus points.
> > > >> >
> > > >> > I think Ian nails the description: "CLI encourages the "Your
> > cordova
> > > >> web
> > > >> > view *IS* your application" mindset"
> > > >> >
> > > >> > I don't have a big preference one way or the other regarding
> > attaching
> > > >> the
> > > >> > word "legacy" to the Platform Flow. I like that it conveys: "the
> > flow
> > > >> you
> > > >> > are used to" and "there exists a new flow now that you should
> > > evaluate"
> > > >> but
> > > >> > I don't like that it may also convey "this flow is going to be
> > > >> deprecated"
> > > >> > which I don't think is true.
> > > >> >
> > > >> > Whatever we call it, I think its important to signal that Platform
> > > >> workflow
> > > >> > is for supporting "mucking with platform internals" not for
> "single
> > > >> > platform dev". Single platform dev can be done using CLI just as
> > > >> easily.
> > > >> >
> > > >> > Should we create a wiki/doc which explains the flow and lists the
> > > >> > pros/cons?
> > > >> >
> > > >> >
> > > >> > On Mon, Oct 21, 2013 at 9:20 AM, Ian Clelland <
> iclelland@google.com
> > >
> > > >> > wrote:
> > > >> >
> > > >> > > Legacy, though, sounds like it's something that we're actively
> > > moving
> > > >> > away
> > > >> > > from; something that we support only grudgingly, and which we
> > might
> > > >> > > deprecate at the drop of a hat.
> > > >> > > The platform-only workflow supports legitimate use-cases which
> CLI
> > > >> > probably
> > > >> > > will never cover -- things like embedding a cordova web view
> > inside
> > > >> of a
> > > >> > > larger platform-native project.
> > > >> > >
> > > >> > > The major difference I see with CLI is that it encourages the
> > "Your
> > > >> > cordova
> > > >> > > web view *IS* your application" mindset. (And if that's true,
> then
> > > why
> > > >> > > wouldn't you aim for cross-platform development?) The pre-CLI
> > > >> workflow is
> > > >> > > still the way to build all other sorts of applications.
> > > >> > >
> > > >> > > Ian
> > > >> > >
> > > >> > >
> > > >> > > On Fri, Oct 18, 2013 at 11:30 PM, purplecabbage <
> > > >> purplecabbage@gmail.com
> > > >> > > >wrote:
> > > >> > >
> > > >> > > > I like merge-flow and legacy-flow
> > > >> > > >
> > > >> > > > Sent from my iPhone
> > > >> > > >
> > > >> > > > > On Oct 18, 2013, at 6:59 PM, Carlos Santana <
> > > csantana23@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 <
> > > >> > stevengill97@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 <
> > > >> > stevengill97@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 <
> > > >> > mmocny@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 <
> > > >> > > stevengill97@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 <
> > > >> > purplecabbage@gmail.com
> > > >> > > >
> > > >> > > > >>>>>> wrote:
> > > >> > > > >>>>>>
> > > >> > > > >>>>>>> IDE or cordova-cli ??
> > > >> > > > >>>>>>>
> > > >> > > > >>>>>>> @purplecabbage
> > > >> > > > >>>>>>> risingj.com
> > > >> > > > >>>>>>>
> > > >> > > > >>>>>>>
> > > >> > > > >>>>>>> On Fri, Oct 18, 2013 at 12:02 PM, Steven Gill <
> > > >> > > > >>> stevengill97@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 <
> > > >> > > > >> purplecabbage@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
> > > >> > > > > <cs...@gmail.com>
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > > >
> > > >
> > >
> >
>
Re: config.xml discussion, we need to talk
Posted by Axel Nennker <ig...@gmail.com>.
+1
Although I was about to suggest "single platform development" and "multi
platform development".
Axel
Am 21.10.2013 19:36 schrieb "Brian LeRoux" <b...@brian.io>:
> I think we need to be explicit, not talk about legacy or magic. I'd like to
> propose:
>
> Native Platform Dev -- Build Cordova apps on the metal. No helpers for
> moving across platforms.
> Web Project Dev -- Build web first projects that (mostly) treats native
> projects as build artifacts.
>
>
>
> On Mon, Oct 21, 2013 at 8:34 AM, Braden Shepherdson <braden@chromium.org
> >wrote:
>
> > Whoops, forgot my citation:
> >
> > [1] http://www.catb.org/jargon/html/magic-story.html
> >
> >
> > On Mon, Oct 21, 2013 at 11:33 AM, Braden Shepherdson <
> braden@chromium.org
> > >wrote:
> >
> > > "Less Magic" (bin/create, Plugman) and "More Magic" (CLI).[1]
> > >
> > > Mike Billau's suggestions look decent to me. How about "classic"
> instead
> > > of "legacy"? Removes the "it sucks and will die someday" connotation,
> > since
> > > that's not true.
> > >
> > > Braden
> > >
> > >
> > > On Mon, Oct 21, 2013 at 11:25 AM, Mike Billau <mike.billau@gmail.com
> > >wrote:
> > >
> > >> Lets make the name as confusing as possible, to live up to our history
> > >> (callback, phonegap, cordova.) ;)
> > >>
> > >> Personally I think that the names should try to describe the
> difference
> > >> between the workflows instead of trying to prescribe some type of
> usage,
> > >> since there are unknown and developing use cases.
> > >>
> > >> To me the main difference between the workflows is that with the CLI,
> > >> things get merged for you automatically, so I'm in favor of something
> > like
> > >> "CLI/Merges Workflow" and "Non-CLI/Legacy Workflow", and in the very
> > first
> > >> sentence of "Non-CLI/Legacy" we say "It's called "Legacy" because it
> was
> > >> the pre-3.0 worfklow, not because it is no longer supported."
> > >>
> > >> Michal, we created an item to track the doc changes:
> > >> https://issues.apache.org/jira/browse/CB-5122 I think the bulk of
> the
> > >> workflow discussion can fit into the "Development Paths" section in
> the
> > >> main Overview Guide. I'll get started but will continue to monitor
> this
> > >> thread.
> > >>
> > >>
> > >> On Mon, Oct 21, 2013 at 10:01 AM, Michal Mocny <mm...@chromium.org>
> > >> wrote:
> > >>
> > >> > (Okay, this thread at high risk of bikeshedding, just going to
> mention
> > >> that
> > >> > ;) But I do think it would be great to settle once and for all.
> > >> >
> > >> > I like the distinction Steven/Brian are making: Project flow vs
> > Platform
> > >> > flow. I'm not sure that those names are immediately 100% clear
> (I'll
> > >> > ponder over it) but I like the focus points.
> > >> >
> > >> > I think Ian nails the description: "CLI encourages the "Your
> cordova
> > >> web
> > >> > view *IS* your application" mindset"
> > >> >
> > >> > I don't have a big preference one way or the other regarding
> attaching
> > >> the
> > >> > word "legacy" to the Platform Flow. I like that it conveys: "the
> flow
> > >> you
> > >> > are used to" and "there exists a new flow now that you should
> > evaluate"
> > >> but
> > >> > I don't like that it may also convey "this flow is going to be
> > >> deprecated"
> > >> > which I don't think is true.
> > >> >
> > >> > Whatever we call it, I think its important to signal that Platform
> > >> workflow
> > >> > is for supporting "mucking with platform internals" not for "single
> > >> > platform dev". Single platform dev can be done using CLI just as
> > >> easily.
> > >> >
> > >> > Should we create a wiki/doc which explains the flow and lists the
> > >> > pros/cons?
> > >> >
> > >> >
> > >> > On Mon, Oct 21, 2013 at 9:20 AM, Ian Clelland <iclelland@google.com
> >
> > >> > wrote:
> > >> >
> > >> > > Legacy, though, sounds like it's something that we're actively
> > moving
> > >> > away
> > >> > > from; something that we support only grudgingly, and which we
> might
> > >> > > deprecate at the drop of a hat.
> > >> > > The platform-only workflow supports legitimate use-cases which CLI
> > >> > probably
> > >> > > will never cover -- things like embedding a cordova web view
> inside
> > >> of a
> > >> > > larger platform-native project.
> > >> > >
> > >> > > The major difference I see with CLI is that it encourages the
> "Your
> > >> > cordova
> > >> > > web view *IS* your application" mindset. (And if that's true, then
> > why
> > >> > > wouldn't you aim for cross-platform development?) The pre-CLI
> > >> workflow is
> > >> > > still the way to build all other sorts of applications.
> > >> > >
> > >> > > Ian
> > >> > >
> > >> > >
> > >> > > On Fri, Oct 18, 2013 at 11:30 PM, purplecabbage <
> > >> purplecabbage@gmail.com
> > >> > > >wrote:
> > >> > >
> > >> > > > I like merge-flow and legacy-flow
> > >> > > >
> > >> > > > Sent from my iPhone
> > >> > > >
> > >> > > > > On Oct 18, 2013, at 6:59 PM, Carlos Santana <
> > csantana23@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 <
> > >> > stevengill97@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 <
> > >> > stevengill97@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 <
> > >> > mmocny@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 <
> > >> > > stevengill97@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 <
> > >> > purplecabbage@gmail.com
> > >> > > >
> > >> > > > >>>>>> wrote:
> > >> > > > >>>>>>
> > >> > > > >>>>>>> IDE or cordova-cli ??
> > >> > > > >>>>>>>
> > >> > > > >>>>>>> @purplecabbage
> > >> > > > >>>>>>> risingj.com
> > >> > > > >>>>>>>
> > >> > > > >>>>>>>
> > >> > > > >>>>>>> On Fri, Oct 18, 2013 at 12:02 PM, Steven Gill <
> > >> > > > >>> stevengill97@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 <
> > >> > > > >> purplecabbage@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
> > >> > > > > <cs...@gmail.com>
> > >> > > >
> > >> > >
> > >> >
> > >>
> > >
> > >
> >
>
Re: config.xml discussion, we need to talk
Posted by Brian LeRoux <b...@brian.io>.
I think we need to be explicit, not talk about legacy or magic. I'd like to
propose:
Native Platform Dev -- Build Cordova apps on the metal. No helpers for
moving across platforms.
Web Project Dev -- Build web first projects that (mostly) treats native
projects as build artifacts.
On Mon, Oct 21, 2013 at 8:34 AM, Braden Shepherdson <br...@chromium.org>wrote:
> Whoops, forgot my citation:
>
> [1] http://www.catb.org/jargon/html/magic-story.html
>
>
> On Mon, Oct 21, 2013 at 11:33 AM, Braden Shepherdson <braden@chromium.org
> >wrote:
>
> > "Less Magic" (bin/create, Plugman) and "More Magic" (CLI).[1]
> >
> > Mike Billau's suggestions look decent to me. How about "classic" instead
> > of "legacy"? Removes the "it sucks and will die someday" connotation,
> since
> > that's not true.
> >
> > Braden
> >
> >
> > On Mon, Oct 21, 2013 at 11:25 AM, Mike Billau <mike.billau@gmail.com
> >wrote:
> >
> >> Lets make the name as confusing as possible, to live up to our history
> >> (callback, phonegap, cordova.) ;)
> >>
> >> Personally I think that the names should try to describe the difference
> >> between the workflows instead of trying to prescribe some type of usage,
> >> since there are unknown and developing use cases.
> >>
> >> To me the main difference between the workflows is that with the CLI,
> >> things get merged for you automatically, so I'm in favor of something
> like
> >> "CLI/Merges Workflow" and "Non-CLI/Legacy Workflow", and in the very
> first
> >> sentence of "Non-CLI/Legacy" we say "It's called "Legacy" because it was
> >> the pre-3.0 worfklow, not because it is no longer supported."
> >>
> >> Michal, we created an item to track the doc changes:
> >> https://issues.apache.org/jira/browse/CB-5122 I think the bulk of the
> >> workflow discussion can fit into the "Development Paths" section in the
> >> main Overview Guide. I'll get started but will continue to monitor this
> >> thread.
> >>
> >>
> >> On Mon, Oct 21, 2013 at 10:01 AM, Michal Mocny <mm...@chromium.org>
> >> wrote:
> >>
> >> > (Okay, this thread at high risk of bikeshedding, just going to mention
> >> that
> >> > ;) But I do think it would be great to settle once and for all.
> >> >
> >> > I like the distinction Steven/Brian are making: Project flow vs
> Platform
> >> > flow. I'm not sure that those names are immediately 100% clear (I'll
> >> > ponder over it) but I like the focus points.
> >> >
> >> > I think Ian nails the description: "CLI encourages the "Your cordova
> >> web
> >> > view *IS* your application" mindset"
> >> >
> >> > I don't have a big preference one way or the other regarding attaching
> >> the
> >> > word "legacy" to the Platform Flow. I like that it conveys: "the flow
> >> you
> >> > are used to" and "there exists a new flow now that you should
> evaluate"
> >> but
> >> > I don't like that it may also convey "this flow is going to be
> >> deprecated"
> >> > which I don't think is true.
> >> >
> >> > Whatever we call it, I think its important to signal that Platform
> >> workflow
> >> > is for supporting "mucking with platform internals" not for "single
> >> > platform dev". Single platform dev can be done using CLI just as
> >> easily.
> >> >
> >> > Should we create a wiki/doc which explains the flow and lists the
> >> > pros/cons?
> >> >
> >> >
> >> > On Mon, Oct 21, 2013 at 9:20 AM, Ian Clelland <ic...@google.com>
> >> > wrote:
> >> >
> >> > > Legacy, though, sounds like it's something that we're actively
> moving
> >> > away
> >> > > from; something that we support only grudgingly, and which we might
> >> > > deprecate at the drop of a hat.
> >> > > The platform-only workflow supports legitimate use-cases which CLI
> >> > probably
> >> > > will never cover -- things like embedding a cordova web view inside
> >> of a
> >> > > larger platform-native project.
> >> > >
> >> > > The major difference I see with CLI is that it encourages the "Your
> >> > cordova
> >> > > web view *IS* your application" mindset. (And if that's true, then
> why
> >> > > wouldn't you aim for cross-platform development?) The pre-CLI
> >> workflow is
> >> > > still the way to build all other sorts of applications.
> >> > >
> >> > > Ian
> >> > >
> >> > >
> >> > > On Fri, Oct 18, 2013 at 11:30 PM, purplecabbage <
> >> purplecabbage@gmail.com
> >> > > >wrote:
> >> > >
> >> > > > I like merge-flow and legacy-flow
> >> > > >
> >> > > > Sent from my iPhone
> >> > > >
> >> > > > > On Oct 18, 2013, at 6:59 PM, Carlos Santana <
> csantana23@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 <
> >> > stevengill97@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 <
> >> > stevengill97@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 <
> >> > mmocny@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 <
> >> > > stevengill97@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 <
> >> > purplecabbage@gmail.com
> >> > > >
> >> > > > >>>>>> wrote:
> >> > > > >>>>>>
> >> > > > >>>>>>> IDE or cordova-cli ??
> >> > > > >>>>>>>
> >> > > > >>>>>>> @purplecabbage
> >> > > > >>>>>>> risingj.com
> >> > > > >>>>>>>
> >> > > > >>>>>>>
> >> > > > >>>>>>> On Fri, Oct 18, 2013 at 12:02 PM, Steven Gill <
> >> > > > >>> stevengill97@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 <
> >> > > > >> purplecabbage@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
> >> > > > > <cs...@gmail.com>
> >> > > >
> >> > >
> >> >
> >>
> >
> >
>
Re: config.xml discussion, we need to talk
Posted by Braden Shepherdson <br...@chromium.org>.
Whoops, forgot my citation:
[1] http://www.catb.org/jargon/html/magic-story.html
On Mon, Oct 21, 2013 at 11:33 AM, Braden Shepherdson <br...@chromium.org>wrote:
> "Less Magic" (bin/create, Plugman) and "More Magic" (CLI).[1]
>
> Mike Billau's suggestions look decent to me. How about "classic" instead
> of "legacy"? Removes the "it sucks and will die someday" connotation, since
> that's not true.
>
> Braden
>
>
> On Mon, Oct 21, 2013 at 11:25 AM, Mike Billau <mi...@gmail.com>wrote:
>
>> Lets make the name as confusing as possible, to live up to our history
>> (callback, phonegap, cordova.) ;)
>>
>> Personally I think that the names should try to describe the difference
>> between the workflows instead of trying to prescribe some type of usage,
>> since there are unknown and developing use cases.
>>
>> To me the main difference between the workflows is that with the CLI,
>> things get merged for you automatically, so I'm in favor of something like
>> "CLI/Merges Workflow" and "Non-CLI/Legacy Workflow", and in the very first
>> sentence of "Non-CLI/Legacy" we say "It's called "Legacy" because it was
>> the pre-3.0 worfklow, not because it is no longer supported."
>>
>> Michal, we created an item to track the doc changes:
>> https://issues.apache.org/jira/browse/CB-5122 I think the bulk of the
>> workflow discussion can fit into the "Development Paths" section in the
>> main Overview Guide. I'll get started but will continue to monitor this
>> thread.
>>
>>
>> On Mon, Oct 21, 2013 at 10:01 AM, Michal Mocny <mm...@chromium.org>
>> wrote:
>>
>> > (Okay, this thread at high risk of bikeshedding, just going to mention
>> that
>> > ;) But I do think it would be great to settle once and for all.
>> >
>> > I like the distinction Steven/Brian are making: Project flow vs Platform
>> > flow. I'm not sure that those names are immediately 100% clear (I'll
>> > ponder over it) but I like the focus points.
>> >
>> > I think Ian nails the description: "CLI encourages the "Your cordova
>> web
>> > view *IS* your application" mindset"
>> >
>> > I don't have a big preference one way or the other regarding attaching
>> the
>> > word "legacy" to the Platform Flow. I like that it conveys: "the flow
>> you
>> > are used to" and "there exists a new flow now that you should evaluate"
>> but
>> > I don't like that it may also convey "this flow is going to be
>> deprecated"
>> > which I don't think is true.
>> >
>> > Whatever we call it, I think its important to signal that Platform
>> workflow
>> > is for supporting "mucking with platform internals" not for "single
>> > platform dev". Single platform dev can be done using CLI just as
>> easily.
>> >
>> > Should we create a wiki/doc which explains the flow and lists the
>> > pros/cons?
>> >
>> >
>> > On Mon, Oct 21, 2013 at 9:20 AM, Ian Clelland <ic...@google.com>
>> > wrote:
>> >
>> > > Legacy, though, sounds like it's something that we're actively moving
>> > away
>> > > from; something that we support only grudgingly, and which we might
>> > > deprecate at the drop of a hat.
>> > > The platform-only workflow supports legitimate use-cases which CLI
>> > probably
>> > > will never cover -- things like embedding a cordova web view inside
>> of a
>> > > larger platform-native project.
>> > >
>> > > The major difference I see with CLI is that it encourages the "Your
>> > cordova
>> > > web view *IS* your application" mindset. (And if that's true, then why
>> > > wouldn't you aim for cross-platform development?) The pre-CLI
>> workflow is
>> > > still the way to build all other sorts of applications.
>> > >
>> > > Ian
>> > >
>> > >
>> > > On Fri, Oct 18, 2013 at 11:30 PM, purplecabbage <
>> purplecabbage@gmail.com
>> > > >wrote:
>> > >
>> > > > I like merge-flow and legacy-flow
>> > > >
>> > > > Sent from my iPhone
>> > > >
>> > > > > On Oct 18, 2013, at 6:59 PM, Carlos Santana <csantana23@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 <
>> > stevengill97@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 <
>> > stevengill97@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 <
>> > mmocny@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 <
>> > > stevengill97@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 <
>> > purplecabbage@gmail.com
>> > > >
>> > > > >>>>>> wrote:
>> > > > >>>>>>
>> > > > >>>>>>> IDE or cordova-cli ??
>> > > > >>>>>>>
>> > > > >>>>>>> @purplecabbage
>> > > > >>>>>>> risingj.com
>> > > > >>>>>>>
>> > > > >>>>>>>
>> > > > >>>>>>> On Fri, Oct 18, 2013 at 12:02 PM, Steven Gill <
>> > > > >>> stevengill97@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 <
>> > > > >> purplecabbage@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
>> > > > > <cs...@gmail.com>
>> > > >
>> > >
>> >
>>
>
>
Re: config.xml discussion, we need to talk
Posted by Joe Bowser <bo...@gmail.com>.
+1 for "More Magic/Less Magic"
On Oct 21, 2013 8:34 AM, "Braden Shepherdson" <br...@chromium.org> wrote:
> "Less Magic" (bin/create, Plugman) and "More Magic" (CLI).[1]
>
> Mike Billau's suggestions look decent to me. How about "classic" instead of
> "legacy"? Removes the "it sucks and will die someday" connotation, since
> that's not true.
>
> Braden
>
>
> On Mon, Oct 21, 2013 at 11:25 AM, Mike Billau <mi...@gmail.com>
> wrote:
>
> > Lets make the name as confusing as possible, to live up to our history
> > (callback, phonegap, cordova.) ;)
> >
> > Personally I think that the names should try to describe the difference
> > between the workflows instead of trying to prescribe some type of usage,
> > since there are unknown and developing use cases.
> >
> > To me the main difference between the workflows is that with the CLI,
> > things get merged for you automatically, so I'm in favor of something
> like
> > "CLI/Merges Workflow" and "Non-CLI/Legacy Workflow", and in the very
> first
> > sentence of "Non-CLI/Legacy" we say "It's called "Legacy" because it was
> > the pre-3.0 worfklow, not because it is no longer supported."
> >
> > Michal, we created an item to track the doc changes:
> > https://issues.apache.org/jira/browse/CB-5122 I think the bulk of the
> > workflow discussion can fit into the "Development Paths" section in the
> > main Overview Guide. I'll get started but will continue to monitor this
> > thread.
> >
> >
> > On Mon, Oct 21, 2013 at 10:01 AM, Michal Mocny <mm...@chromium.org>
> > wrote:
> >
> > > (Okay, this thread at high risk of bikeshedding, just going to mention
> > that
> > > ;) But I do think it would be great to settle once and for all.
> > >
> > > I like the distinction Steven/Brian are making: Project flow vs
> Platform
> > > flow. I'm not sure that those names are immediately 100% clear (I'll
> > > ponder over it) but I like the focus points.
> > >
> > > I think Ian nails the description: "CLI encourages the "Your cordova
> web
> > > view *IS* your application" mindset"
> > >
> > > I don't have a big preference one way or the other regarding attaching
> > the
> > > word "legacy" to the Platform Flow. I like that it conveys: "the flow
> > you
> > > are used to" and "there exists a new flow now that you should evaluate"
> > but
> > > I don't like that it may also convey "this flow is going to be
> > deprecated"
> > > which I don't think is true.
> > >
> > > Whatever we call it, I think its important to signal that Platform
> > workflow
> > > is for supporting "mucking with platform internals" not for "single
> > > platform dev". Single platform dev can be done using CLI just as
> easily.
> > >
> > > Should we create a wiki/doc which explains the flow and lists the
> > > pros/cons?
> > >
> > >
> > > On Mon, Oct 21, 2013 at 9:20 AM, Ian Clelland <ic...@google.com>
> > > wrote:
> > >
> > > > Legacy, though, sounds like it's something that we're actively moving
> > > away
> > > > from; something that we support only grudgingly, and which we might
> > > > deprecate at the drop of a hat.
> > > > The platform-only workflow supports legitimate use-cases which CLI
> > > probably
> > > > will never cover -- things like embedding a cordova web view inside
> of
> > a
> > > > larger platform-native project.
> > > >
> > > > The major difference I see with CLI is that it encourages the "Your
> > > cordova
> > > > web view *IS* your application" mindset. (And if that's true, then
> why
> > > > wouldn't you aim for cross-platform development?) The pre-CLI
> workflow
> > is
> > > > still the way to build all other sorts of applications.
> > > >
> > > > Ian
> > > >
> > > >
> > > > On Fri, Oct 18, 2013 at 11:30 PM, purplecabbage <
> > purplecabbage@gmail.com
> > > > >wrote:
> > > >
> > > > > I like merge-flow and legacy-flow
> > > > >
> > > > > Sent from my iPhone
> > > > >
> > > > > > On Oct 18, 2013, at 6:59 PM, Carlos Santana <
> csantana23@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 <
> > > stevengill97@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 <
> > > stevengill97@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 <
> > > mmocny@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 <
> > > > stevengill97@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 <
> > > purplecabbage@gmail.com
> > > > >
> > > > > >>>>>> wrote:
> > > > > >>>>>>
> > > > > >>>>>>> IDE or cordova-cli ??
> > > > > >>>>>>>
> > > > > >>>>>>> @purplecabbage
> > > > > >>>>>>> risingj.com
> > > > > >>>>>>>
> > > > > >>>>>>>
> > > > > >>>>>>> On Fri, Oct 18, 2013 at 12:02 PM, Steven Gill <
> > > > > >>> stevengill97@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 <
> > > > > >> purplecabbage@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
> > > > > > <cs...@gmail.com>
> > > > >
> > > >
> > >
> >
>
Re: config.xml discussion, we need to talk
Posted by Braden Shepherdson <br...@chromium.org>.
"Less Magic" (bin/create, Plugman) and "More Magic" (CLI).[1]
Mike Billau's suggestions look decent to me. How about "classic" instead of
"legacy"? Removes the "it sucks and will die someday" connotation, since
that's not true.
Braden
On Mon, Oct 21, 2013 at 11:25 AM, Mike Billau <mi...@gmail.com> wrote:
> Lets make the name as confusing as possible, to live up to our history
> (callback, phonegap, cordova.) ;)
>
> Personally I think that the names should try to describe the difference
> between the workflows instead of trying to prescribe some type of usage,
> since there are unknown and developing use cases.
>
> To me the main difference between the workflows is that with the CLI,
> things get merged for you automatically, so I'm in favor of something like
> "CLI/Merges Workflow" and "Non-CLI/Legacy Workflow", and in the very first
> sentence of "Non-CLI/Legacy" we say "It's called "Legacy" because it was
> the pre-3.0 worfklow, not because it is no longer supported."
>
> Michal, we created an item to track the doc changes:
> https://issues.apache.org/jira/browse/CB-5122 I think the bulk of the
> workflow discussion can fit into the "Development Paths" section in the
> main Overview Guide. I'll get started but will continue to monitor this
> thread.
>
>
> On Mon, Oct 21, 2013 at 10:01 AM, Michal Mocny <mm...@chromium.org>
> wrote:
>
> > (Okay, this thread at high risk of bikeshedding, just going to mention
> that
> > ;) But I do think it would be great to settle once and for all.
> >
> > I like the distinction Steven/Brian are making: Project flow vs Platform
> > flow. I'm not sure that those names are immediately 100% clear (I'll
> > ponder over it) but I like the focus points.
> >
> > I think Ian nails the description: "CLI encourages the "Your cordova web
> > view *IS* your application" mindset"
> >
> > I don't have a big preference one way or the other regarding attaching
> the
> > word "legacy" to the Platform Flow. I like that it conveys: "the flow
> you
> > are used to" and "there exists a new flow now that you should evaluate"
> but
> > I don't like that it may also convey "this flow is going to be
> deprecated"
> > which I don't think is true.
> >
> > Whatever we call it, I think its important to signal that Platform
> workflow
> > is for supporting "mucking with platform internals" not for "single
> > platform dev". Single platform dev can be done using CLI just as easily.
> >
> > Should we create a wiki/doc which explains the flow and lists the
> > pros/cons?
> >
> >
> > On Mon, Oct 21, 2013 at 9:20 AM, Ian Clelland <ic...@google.com>
> > wrote:
> >
> > > Legacy, though, sounds like it's something that we're actively moving
> > away
> > > from; something that we support only grudgingly, and which we might
> > > deprecate at the drop of a hat.
> > > The platform-only workflow supports legitimate use-cases which CLI
> > probably
> > > will never cover -- things like embedding a cordova web view inside of
> a
> > > larger platform-native project.
> > >
> > > The major difference I see with CLI is that it encourages the "Your
> > cordova
> > > web view *IS* your application" mindset. (And if that's true, then why
> > > wouldn't you aim for cross-platform development?) The pre-CLI workflow
> is
> > > still the way to build all other sorts of applications.
> > >
> > > Ian
> > >
> > >
> > > On Fri, Oct 18, 2013 at 11:30 PM, purplecabbage <
> purplecabbage@gmail.com
> > > >wrote:
> > >
> > > > I like merge-flow and legacy-flow
> > > >
> > > > Sent from my iPhone
> > > >
> > > > > On Oct 18, 2013, at 6:59 PM, Carlos Santana <cs...@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 <
> > stevengill97@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 <
> > stevengill97@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 <
> > mmocny@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 <
> > > stevengill97@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 <
> > purplecabbage@gmail.com
> > > >
> > > > >>>>>> wrote:
> > > > >>>>>>
> > > > >>>>>>> IDE or cordova-cli ??
> > > > >>>>>>>
> > > > >>>>>>> @purplecabbage
> > > > >>>>>>> risingj.com
> > > > >>>>>>>
> > > > >>>>>>>
> > > > >>>>>>> On Fri, Oct 18, 2013 at 12:02 PM, Steven Gill <
> > > > >>> stevengill97@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 <
> > > > >> purplecabbage@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
> > > > > <cs...@gmail.com>
> > > >
> > >
> >
>
Re: config.xml discussion, we need to talk
Posted by Mike Billau <mi...@gmail.com>.
Lets make the name as confusing as possible, to live up to our history
(callback, phonegap, cordova.) ;)
Personally I think that the names should try to describe the difference
between the workflows instead of trying to prescribe some type of usage,
since there are unknown and developing use cases.
To me the main difference between the workflows is that with the CLI,
things get merged for you automatically, so I'm in favor of something like
"CLI/Merges Workflow" and "Non-CLI/Legacy Workflow", and in the very first
sentence of "Non-CLI/Legacy" we say "It's called "Legacy" because it was
the pre-3.0 worfklow, not because it is no longer supported."
Michal, we created an item to track the doc changes:
https://issues.apache.org/jira/browse/CB-5122 I think the bulk of the
workflow discussion can fit into the "Development Paths" section in the
main Overview Guide. I'll get started but will continue to monitor this
thread.
On Mon, Oct 21, 2013 at 10:01 AM, Michal Mocny <mm...@chromium.org> wrote:
> (Okay, this thread at high risk of bikeshedding, just going to mention that
> ;) But I do think it would be great to settle once and for all.
>
> I like the distinction Steven/Brian are making: Project flow vs Platform
> flow. I'm not sure that those names are immediately 100% clear (I'll
> ponder over it) but I like the focus points.
>
> I think Ian nails the description: "CLI encourages the "Your cordova web
> view *IS* your application" mindset"
>
> I don't have a big preference one way or the other regarding attaching the
> word "legacy" to the Platform Flow. I like that it conveys: "the flow you
> are used to" and "there exists a new flow now that you should evaluate" but
> I don't like that it may also convey "this flow is going to be deprecated"
> which I don't think is true.
>
> Whatever we call it, I think its important to signal that Platform workflow
> is for supporting "mucking with platform internals" not for "single
> platform dev". Single platform dev can be done using CLI just as easily.
>
> Should we create a wiki/doc which explains the flow and lists the
> pros/cons?
>
>
> On Mon, Oct 21, 2013 at 9:20 AM, Ian Clelland <ic...@google.com>
> wrote:
>
> > Legacy, though, sounds like it's something that we're actively moving
> away
> > from; something that we support only grudgingly, and which we might
> > deprecate at the drop of a hat.
> > The platform-only workflow supports legitimate use-cases which CLI
> probably
> > will never cover -- things like embedding a cordova web view inside of a
> > larger platform-native project.
> >
> > The major difference I see with CLI is that it encourages the "Your
> cordova
> > web view *IS* your application" mindset. (And if that's true, then why
> > wouldn't you aim for cross-platform development?) The pre-CLI workflow is
> > still the way to build all other sorts of applications.
> >
> > Ian
> >
> >
> > On Fri, Oct 18, 2013 at 11:30 PM, purplecabbage <purplecabbage@gmail.com
> > >wrote:
> >
> > > I like merge-flow and legacy-flow
> > >
> > > Sent from my iPhone
> > >
> > > > On Oct 18, 2013, at 6:59 PM, Carlos Santana <cs...@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 <
> stevengill97@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 <
> stevengill97@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 <
> mmocny@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 <
> > stevengill97@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 <
> purplecabbage@gmail.com
> > >
> > > >>>>>> wrote:
> > > >>>>>>
> > > >>>>>>> IDE or cordova-cli ??
> > > >>>>>>>
> > > >>>>>>> @purplecabbage
> > > >>>>>>> risingj.com
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>> On Fri, Oct 18, 2013 at 12:02 PM, Steven Gill <
> > > >>> stevengill97@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 <
> > > >> purplecabbage@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
> > > > <cs...@gmail.com>
> > >
> >
>
Re: config.xml discussion, we need to talk
Posted by Michal Mocny <mm...@chromium.org>.
(Okay, this thread at high risk of bikeshedding, just going to mention that
;) But I do think it would be great to settle once and for all.
I like the distinction Steven/Brian are making: Project flow vs Platform
flow. I'm not sure that those names are immediately 100% clear (I'll
ponder over it) but I like the focus points.
I think Ian nails the description: "CLI encourages the "Your cordova web
view *IS* your application" mindset"
I don't have a big preference one way or the other regarding attaching the
word "legacy" to the Platform Flow. I like that it conveys: "the flow you
are used to" and "there exists a new flow now that you should evaluate" but
I don't like that it may also convey "this flow is going to be deprecated"
which I don't think is true.
Whatever we call it, I think its important to signal that Platform workflow
is for supporting "mucking with platform internals" not for "single
platform dev". Single platform dev can be done using CLI just as easily.
Should we create a wiki/doc which explains the flow and lists the pros/cons?
On Mon, Oct 21, 2013 at 9:20 AM, Ian Clelland <ic...@google.com> wrote:
> Legacy, though, sounds like it's something that we're actively moving away
> from; something that we support only grudgingly, and which we might
> deprecate at the drop of a hat.
> The platform-only workflow supports legitimate use-cases which CLI probably
> will never cover -- things like embedding a cordova web view inside of a
> larger platform-native project.
>
> The major difference I see with CLI is that it encourages the "Your cordova
> web view *IS* your application" mindset. (And if that's true, then why
> wouldn't you aim for cross-platform development?) The pre-CLI workflow is
> still the way to build all other sorts of applications.
>
> Ian
>
>
> On Fri, Oct 18, 2013 at 11:30 PM, purplecabbage <purplecabbage@gmail.com
> >wrote:
>
> > I like merge-flow and legacy-flow
> >
> > Sent from my iPhone
> >
> > > On Oct 18, 2013, at 6:59 PM, Carlos Santana <cs...@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 <st...@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 <stevengill97@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 <mmocny@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 <
> stevengill97@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 <purplecabbage@gmail.com
> >
> > >>>>>> wrote:
> > >>>>>>
> > >>>>>>> IDE or cordova-cli ??
> > >>>>>>>
> > >>>>>>> @purplecabbage
> > >>>>>>> risingj.com
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> On Fri, Oct 18, 2013 at 12:02 PM, Steven Gill <
> > >>> stevengill97@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 <
> > >> purplecabbage@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
> > > <cs...@gmail.com>
> >
>
Re: config.xml discussion, we need to talk
Posted by Ian Clelland <ic...@google.com>.
Legacy, though, sounds like it's something that we're actively moving away
from; something that we support only grudgingly, and which we might
deprecate at the drop of a hat.
The platform-only workflow supports legitimate use-cases which CLI probably
will never cover -- things like embedding a cordova web view inside of a
larger platform-native project.
The major difference I see with CLI is that it encourages the "Your cordova
web view *IS* your application" mindset. (And if that's true, then why
wouldn't you aim for cross-platform development?) The pre-CLI workflow is
still the way to build all other sorts of applications.
Ian
On Fri, Oct 18, 2013 at 11:30 PM, purplecabbage <pu...@gmail.com>wrote:
> I like merge-flow and legacy-flow
>
> Sent from my iPhone
>
> > On Oct 18, 2013, at 6:59 PM, Carlos Santana <cs...@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 <st...@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 <st...@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 <mmocny@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 <stevengill97@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 <pu...@gmail.com>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> IDE or cordova-cli ??
> >>>>>>>
> >>>>>>> @purplecabbage
> >>>>>>> risingj.com
> >>>>>>>
> >>>>>>>
> >>>>>>> On Fri, Oct 18, 2013 at 12:02 PM, Steven Gill <
> >>> stevengill97@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 <
> >> purplecabbage@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
> > <cs...@gmail.com>
>
Re: config.xml discussion, we need to talk
Posted by purplecabbage <pu...@gmail.com>.
I like merge-flow and legacy-flow
Sent from my iPhone
> On Oct 18, 2013, at 6:59 PM, Carlos Santana <cs...@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 <st...@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 <st...@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 <mmocny@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 <st...@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 <pu...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> IDE or cordova-cli ??
>>>>>>>
>>>>>>> @purplecabbage
>>>>>>> risingj.com
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Oct 18, 2013 at 12:02 PM, Steven Gill <
>>> stevengill97@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 <
>> purplecabbage@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
> <cs...@gmail.com>
Re: config.xml discussion, we need to talk
Posted by Carlos Santana <cs...@gmail.com>.
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 <st...@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 <st...@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 <mmocny@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 <st...@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 <pu...@gmail.com>
> > >> wrote:
> > >> >
> > >> > > IDE or cordova-cli ??
> > >> > >
> > >> > > @purplecabbage
> > >> > > risingj.com
> > >> > >
> > >> > >
> > >> > > On Fri, Oct 18, 2013 at 12:02 PM, Steven Gill <
> > stevengill97@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 <
> purplecabbage@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
<cs...@gmail.com>
Re: config.xml discussion, we need to talk
Posted by Brian LeRoux <b...@brian.io>.
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 <st...@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 <st...@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 <mmocny@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 <st...@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 <pu...@gmail.com>
> >> wrote:
> >> >
> >> > > IDE or cordova-cli ??
> >> > >
> >> > > @purplecabbage
> >> > > risingj.com
> >> > >
> >> > >
> >> > > On Fri, Oct 18, 2013 at 12:02 PM, Steven Gill <
> stevengill97@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 <pu...@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 <
> >> > stevengill97@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 <
> >> > mmocny@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.kadri@gmail.com>
> >> > > > > > wrote:
> >> > > > > > >
> >> > > > > > > > Erik that's great! Where can we download it?
> >> > > > > > > > On Oct 18, 2013 8:01 AM, "Andrew Grieve" <
> >> agrieve@chromium.org
> >> > >
> >> > > > > wrote:
> >> > > > > > > >
> >> > > > > > > > > Awesome video!!
> >> > > > > > > > >
> >> > > > > > > > >
> >> > > > > > > > > On Fri, Oct 18, 2013 at 3:43 AM, Erik Jan de Wit <
> >> > > > > edewit@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 <
> >> Maxime@somatic.fr>
> >> > > > wrote:
> >> > > > > > > > > >
> >> > > > > > > > > > > Great Bryan
> >> > > > > > > > > > > Totally agree !!!
> >> > > > > > > > > > >
> >> > > > > > > > > > > Cordialement.
> >> > > > > > > > > > > -------------------------------
> >> > > > > > > > > > > Maxime LUCE - Somatic
> >> > > > > > > > > > > maxime.luce@somatic.fr
> >> > > > > > > > > > > 06 28 60 72 34
> >> > > > > > > > > > > ________________________________
> >> > > > > > > > > > > De : Brian LeRoux<ma...@brian.io>
> >> > > > > > > > > > > Envoyé : 18/10/2013 01:48
> >> > > > > > > > > > > À : dev@cordova.apache.org<mailto:
> >> 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 <
> >> > > > > > > tommy@devgeeks.org
> >> > > > > > > > > > <ma...@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.kadri@gmail.com
> >> > > > > <mailto:
> >> > > > > > > > > > anis.kadri@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 <
> >> > > > > > > > > csantana23@gmail.com
> >> > > > > > > > > > <ma...@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 <
> >> > > > > > > > > csantana23@gmail.com
> >> > > > > > > > > > <ma...@gmail.com>
> >> > > > > > > > > > >>> wrote:
> >> > > > > > > > > > >>>
> >> > > > > > > > > > >>>> ++1 "to install from a given directory instead
> of
> >> > > > > > > .cordova/libs."
> >> > > > > > > > > > >>>>
> >> > > > > > > > > > >>>>
> >> > > > > > > > > > >>>>
> >> > > > > > > > > > >>>> On Thu, Oct 17, 2013 at 12:10 PM, Viras <
> >> > > > > > > > > viras@users.sourceforge.net
> >> > > > > > > > > > <ma...@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 <
> >> > > > > > > > > > viras@users.sourceforge.net<mailto:
> >> > > viras@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
> <
> >> > > > > > > > > mmocny@chromium.org
> >> > > > > > > > > > <ma...@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-10731<htt**p://
> >> > > > > > > > www.infil00p.org/config-**<
> >> > > > > > > > > > http://www.infil00p.org/config-**>
> >> > > > > > > > > > >>>>>>>>
> >> xml-changes-for-ios-and-**android/#comment-10731<
> >> > > > > > > > > > >>
> >> > > > > > > > > >
> >> > > > > > > > >
> >> > > > > > > >
> >> > > > > > >
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> 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-****
> >> > > > > > > > > <
> >> > > > > > > > > > >>
> >> > > http://www.infil00p.org/**introducing-cordova-3-0-0-for-**>
> >> > > > > > > > > > >>>>>>>> android/#comment-10694<http://**
> >> > > > > > > > www.infil00p.org/introducing-**
> >> > > > > > > > > <
> >> > > > > > > > > > http://www.infil00p.org/introducing-**>
> >> > > > > > > > > > >>>>>>>> cordova-3-0-0-for-android/#**comment-10694<
> >> > > > > > > > > > >>
> >> > > > > > > > > >
> >> > > > > > > > >
> >> > > > > > > >
> >> > > > > > >
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> 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
> >> > > > > > > > > > >>>>>>>
> >> > > > > > > > > > >>>>>>>
> >> > > > > > > > > > >>>>> --
> >> > > > > > > > > > >>>>> GOFG - Get On Fat Guy
> >> > > > > > > > > > >>>>> http://www.gofg.at/ - powered by Cordova
> >> > > > > > > > > > >>>>>
> >> > > > > > > > > > >>>>
> >> > > > > > > > > > >>>>
> >> > > > > > > > > > >>>>
> >> > > > > > > > > > >>>> --
> >> > > > > > > > > > >>>> Carlos Santana
> >> > > > > > > > > > >>>> <csantana23@gmail.com<mailto:
> csantana23@gmail.com
> >> >>
> >> > > > > > > > > > >>>>
> >> > > > > > > > > > >>>
> >> > > > > > > > > > >>>
> >> > > > > > > > > > >>>
> >> > > > > > > > > > >>> --
> >> > > > > > > > > > >>> Carlos Santana
> >> > > > > > > > > > >>> <csantana23@gmail.com<mailto:csantana23@gmail.com
> >>
> >> > > > > > > > > > >>
> >> > > > > > > > > > >
> >> > > > > > > > > >
> >> > > > > > > > > >
> >> > > > > > > > >
> >> > > > > > > >
> >> > > > > > >
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> >
> >
>
Re: config.xml discussion, we need to talk
Posted by Steven Gill <st...@gmail.com>.
Brian suggested Project Development (CLI workflow) vs Platform Development
(bin/scripts)
On Fri, Oct 18, 2013 at 3:09 PM, Steven Gill <st...@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 <mm...@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 <st...@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 <pu...@gmail.com>
>> wrote:
>> >
>> > > IDE or cordova-cli ??
>> > >
>> > > @purplecabbage
>> > > risingj.com
>> > >
>> > >
>> > > On Fri, Oct 18, 2013 at 12:02 PM, Steven Gill <stevengill97@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 <pu...@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 <
>> > stevengill97@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 <
>> > mmocny@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.kadri@gmail.com>
>> > > > > > wrote:
>> > > > > > >
>> > > > > > > > Erik that's great! Where can we download it?
>> > > > > > > > On Oct 18, 2013 8:01 AM, "Andrew Grieve" <
>> agrieve@chromium.org
>> > >
>> > > > > wrote:
>> > > > > > > >
>> > > > > > > > > Awesome video!!
>> > > > > > > > >
>> > > > > > > > >
>> > > > > > > > > On Fri, Oct 18, 2013 at 3:43 AM, Erik Jan de Wit <
>> > > > > edewit@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 <
>> Maxime@somatic.fr>
>> > > > wrote:
>> > > > > > > > > >
>> > > > > > > > > > > Great Bryan
>> > > > > > > > > > > Totally agree !!!
>> > > > > > > > > > >
>> > > > > > > > > > > Cordialement.
>> > > > > > > > > > > -------------------------------
>> > > > > > > > > > > Maxime LUCE - Somatic
>> > > > > > > > > > > maxime.luce@somatic.fr
>> > > > > > > > > > > 06 28 60 72 34
>> > > > > > > > > > > ________________________________
>> > > > > > > > > > > De : Brian LeRoux<ma...@brian.io>
>> > > > > > > > > > > Envoyé : 18/10/2013 01:48
>> > > > > > > > > > > À : dev@cordova.apache.org<mailto:
>> 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 <
>> > > > > > > tommy@devgeeks.org
>> > > > > > > > > > <ma...@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.kadri@gmail.com
>> > > > > <mailto:
>> > > > > > > > > > anis.kadri@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 <
>> > > > > > > > > csantana23@gmail.com
>> > > > > > > > > > <ma...@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 <
>> > > > > > > > > csantana23@gmail.com
>> > > > > > > > > > <ma...@gmail.com>
>> > > > > > > > > > >>> wrote:
>> > > > > > > > > > >>>
>> > > > > > > > > > >>>> ++1 "to install from a given directory instead of
>> > > > > > > .cordova/libs."
>> > > > > > > > > > >>>>
>> > > > > > > > > > >>>>
>> > > > > > > > > > >>>>
>> > > > > > > > > > >>>> On Thu, Oct 17, 2013 at 12:10 PM, Viras <
>> > > > > > > > > viras@users.sourceforge.net
>> > > > > > > > > > <ma...@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 <
>> > > > > > > > > > viras@users.sourceforge.net<mailto:
>> > > viras@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 <
>> > > > > > > > > mmocny@chromium.org
>> > > > > > > > > > <ma...@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-10731<htt**p://
>> > > > > > > > www.infil00p.org/config-**<
>> > > > > > > > > > http://www.infil00p.org/config-**>
>> > > > > > > > > > >>>>>>>>
>> xml-changes-for-ios-and-**android/#comment-10731<
>> > > > > > > > > > >>
>> > > > > > > > > >
>> > > > > > > > >
>> > > > > > > >
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>> 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-****
>> > > > > > > > > <
>> > > > > > > > > > >>
>> > > http://www.infil00p.org/**introducing-cordova-3-0-0-for-**>
>> > > > > > > > > > >>>>>>>> android/#comment-10694<http://**
>> > > > > > > > www.infil00p.org/introducing-**
>> > > > > > > > > <
>> > > > > > > > > > http://www.infil00p.org/introducing-**>
>> > > > > > > > > > >>>>>>>> cordova-3-0-0-for-android/#**comment-10694<
>> > > > > > > > > > >>
>> > > > > > > > > >
>> > > > > > > > >
>> > > > > > > >
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>> 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
>> > > > > > > > > > >>>>>>>
>> > > > > > > > > > >>>>>>>
>> > > > > > > > > > >>>>> --
>> > > > > > > > > > >>>>> GOFG - Get On Fat Guy
>> > > > > > > > > > >>>>> http://www.gofg.at/ - powered by Cordova
>> > > > > > > > > > >>>>>
>> > > > > > > > > > >>>>
>> > > > > > > > > > >>>>
>> > > > > > > > > > >>>>
>> > > > > > > > > > >>>> --
>> > > > > > > > > > >>>> Carlos Santana
>> > > > > > > > > > >>>> <csantana23@gmail.com<mailto:csantana23@gmail.com
>> >>
>> > > > > > > > > > >>>>
>> > > > > > > > > > >>>
>> > > > > > > > > > >>>
>> > > > > > > > > > >>>
>> > > > > > > > > > >>> --
>> > > > > > > > > > >>> Carlos Santana
>> > > > > > > > > > >>> <cs...@gmail.com>>
>> > > > > > > > > > >>
>> > > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > >
>> > > > > > > >
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>
>
Re: config.xml discussion, we need to talk
Posted by Steven Gill <st...@gmail.com>.
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 <mm...@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 <st...@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 <pu...@gmail.com> wrote:
> >
> > > IDE or cordova-cli ??
> > >
> > > @purplecabbage
> > > risingj.com
> > >
> > >
> > > On Fri, Oct 18, 2013 at 12:02 PM, Steven Gill <stevengill97@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 <pu...@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 <
> > stevengill97@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 <
> > mmocny@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.kadri@gmail.com>
> > > > > > wrote:
> > > > > > >
> > > > > > > > Erik that's great! Where can we download it?
> > > > > > > > On Oct 18, 2013 8:01 AM, "Andrew Grieve" <
> agrieve@chromium.org
> > >
> > > > > wrote:
> > > > > > > >
> > > > > > > > > Awesome video!!
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Fri, Oct 18, 2013 at 3:43 AM, Erik Jan de Wit <
> > > > > edewit@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 <Maxime@somatic.fr
> >
> > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > Great Bryan
> > > > > > > > > > > Totally agree !!!
> > > > > > > > > > >
> > > > > > > > > > > Cordialement.
> > > > > > > > > > > -------------------------------
> > > > > > > > > > > Maxime LUCE - Somatic
> > > > > > > > > > > maxime.luce@somatic.fr
> > > > > > > > > > > 06 28 60 72 34
> > > > > > > > > > > ________________________________
> > > > > > > > > > > De : Brian LeRoux<ma...@brian.io>
> > > > > > > > > > > Envoyé : 18/10/2013 01:48
> > > > > > > > > > > À : dev@cordova.apache.org<mailto:
> 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 <
> > > > > > > tommy@devgeeks.org
> > > > > > > > > > <ma...@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.kadri@gmail.com
> > > > > <mailto:
> > > > > > > > > > anis.kadri@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 <
> > > > > > > > > csantana23@gmail.com
> > > > > > > > > > <ma...@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 <
> > > > > > > > > csantana23@gmail.com
> > > > > > > > > > <ma...@gmail.com>
> > > > > > > > > > >>> wrote:
> > > > > > > > > > >>>
> > > > > > > > > > >>>> ++1 "to install from a given directory instead of
> > > > > > > .cordova/libs."
> > > > > > > > > > >>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>> On Thu, Oct 17, 2013 at 12:10 PM, Viras <
> > > > > > > > > viras@users.sourceforge.net
> > > > > > > > > > <ma...@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 <
> > > > > > > > > > viras@users.sourceforge.net<mailto:
> > > viras@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 <
> > > > > > > > > mmocny@chromium.org
> > > > > > > > > > <ma...@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-10731<htt**p://
> > > > > > > > www.infil00p.org/config-**<
> > > > > > > > > > http://www.infil00p.org/config-**>
> > > > > > > > > > >>>>>>>>
> xml-changes-for-ios-and-**android/#comment-10731<
> > > > > > > > > > >>
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> 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-****
> > > > > > > > > <
> > > > > > > > > > >>
> > > http://www.infil00p.org/**introducing-cordova-3-0-0-for-**>
> > > > > > > > > > >>>>>>>> android/#comment-10694<http://**
> > > > > > > > www.infil00p.org/introducing-**
> > > > > > > > > <
> > > > > > > > > > http://www.infil00p.org/introducing-**>
> > > > > > > > > > >>>>>>>> cordova-3-0-0-for-android/#**comment-10694<
> > > > > > > > > > >>
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> 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
> > > > > > > > > > >>>>>>>
> > > > > > > > > > >>>>>>>
> > > > > > > > > > >>>>> --
> > > > > > > > > > >>>>> GOFG - Get On Fat Guy
> > > > > > > > > > >>>>> http://www.gofg.at/ - powered by Cordova
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>> --
> > > > > > > > > > >>>> Carlos Santana
> > > > > > > > > > >>>> <cs...@gmail.com>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > > > >>>
> > > > > > > > > > >>>
> > > > > > > > > > >>> --
> > > > > > > > > > >>> Carlos Santana
> > > > > > > > > > >>> <cs...@gmail.com>>
> > > > > > > > > > >>
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: config.xml discussion, we need to talk
Posted by Michal Mocny <mm...@chromium.org>.
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 <st...@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 <pu...@gmail.com> wrote:
>
> > IDE or cordova-cli ??
> >
> > @purplecabbage
> > risingj.com
> >
> >
> > On Fri, Oct 18, 2013 at 12:02 PM, Steven Gill <stevengill97@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 <pu...@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 <
> stevengill97@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 <
> mmocny@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.kadri@gmail.com>
> > > > > wrote:
> > > > > >
> > > > > > > Erik that's great! Where can we download it?
> > > > > > > On Oct 18, 2013 8:01 AM, "Andrew Grieve" <agrieve@chromium.org
> >
> > > > wrote:
> > > > > > >
> > > > > > > > Awesome video!!
> > > > > > > >
> > > > > > > >
> > > > > > > > On Fri, Oct 18, 2013 at 3:43 AM, Erik Jan de Wit <
> > > > edewit@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 <Ma...@somatic.fr>
> > > wrote:
> > > > > > > > >
> > > > > > > > > > Great Bryan
> > > > > > > > > > Totally agree !!!
> > > > > > > > > >
> > > > > > > > > > Cordialement.
> > > > > > > > > > -------------------------------
> > > > > > > > > > Maxime LUCE - Somatic
> > > > > > > > > > maxime.luce@somatic.fr
> > > > > > > > > > 06 28 60 72 34
> > > > > > > > > > ________________________________
> > > > > > > > > > De : Brian LeRoux<ma...@brian.io>
> > > > > > > > > > Envoyé : 18/10/2013 01:48
> > > > > > > > > > À : dev@cordova.apache.org<mailto: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 <
> > > > > > tommy@devgeeks.org
> > > > > > > > > <ma...@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.kadri@gmail.com
> > > > <mailto:
> > > > > > > > > anis.kadri@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 <
> > > > > > > > csantana23@gmail.com
> > > > > > > > > <ma...@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 <
> > > > > > > > csantana23@gmail.com
> > > > > > > > > <ma...@gmail.com>
> > > > > > > > > >>> wrote:
> > > > > > > > > >>>
> > > > > > > > > >>>> ++1 "to install from a given directory instead of
> > > > > > .cordova/libs."
> > > > > > > > > >>>>
> > > > > > > > > >>>>
> > > > > > > > > >>>>
> > > > > > > > > >>>> On Thu, Oct 17, 2013 at 12:10 PM, Viras <
> > > > > > > > viras@users.sourceforge.net
> > > > > > > > > <ma...@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 <
> > > > > > > > > viras@users.sourceforge.net<mailto:
> > viras@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 <
> > > > > > > > mmocny@chromium.org
> > > > > > > > > <ma...@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-10731<htt**p://
> > > > > > > www.infil00p.org/config-**<
> > > > > > > > > http://www.infil00p.org/config-**>
> > > > > > > > > >>>>>>>> xml-changes-for-ios-and-**android/#comment-10731<
> > > > > > > > > >>
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> 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-****
> > > > > > > > <
> > > > > > > > > >>
> > http://www.infil00p.org/**introducing-cordova-3-0-0-for-**>
> > > > > > > > > >>>>>>>> android/#comment-10694<http://**
> > > > > > > www.infil00p.org/introducing-**
> > > > > > > > <
> > > > > > > > > http://www.infil00p.org/introducing-**>
> > > > > > > > > >>>>>>>> cordova-3-0-0-for-android/#**comment-10694<
> > > > > > > > > >>
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> 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
> > > > > > > > > >>>>>>>
> > > > > > > > > >>>>>>>
> > > > > > > > > >>>>> --
> > > > > > > > > >>>>> GOFG - Get On Fat Guy
> > > > > > > > > >>>>> http://www.gofg.at/ - powered by Cordova
> > > > > > > > > >>>>>
> > > > > > > > > >>>>
> > > > > > > > > >>>>
> > > > > > > > > >>>>
> > > > > > > > > >>>> --
> > > > > > > > > >>>> Carlos Santana
> > > > > > > > > >>>> <cs...@gmail.com>>
> > > > > > > > > >>>>
> > > > > > > > > >>>
> > > > > > > > > >>>
> > > > > > > > > >>>
> > > > > > > > > >>> --
> > > > > > > > > >>> Carlos Santana
> > > > > > > > > >>> <cs...@gmail.com>>
> > > > > > > > > >>
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: config.xml discussion, we need to talk
Posted by Steven Gill <st...@gmail.com>.
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 <pu...@gmail.com> wrote:
> IDE or cordova-cli ??
>
> @purplecabbage
> risingj.com
>
>
> On Fri, Oct 18, 2013 at 12:02 PM, Steven Gill <stevengill97@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 <pu...@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 <stevengill97@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 <mm...@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 <an...@gmail.com>
> > > > wrote:
> > > > >
> > > > > > Erik that's great! Where can we download it?
> > > > > > On Oct 18, 2013 8:01 AM, "Andrew Grieve" <ag...@chromium.org>
> > > wrote:
> > > > > >
> > > > > > > Awesome video!!
> > > > > > >
> > > > > > >
> > > > > > > On Fri, Oct 18, 2013 at 3:43 AM, Erik Jan de Wit <
> > > edewit@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 <Ma...@somatic.fr>
> > wrote:
> > > > > > > >
> > > > > > > > > Great Bryan
> > > > > > > > > Totally agree !!!
> > > > > > > > >
> > > > > > > > > Cordialement.
> > > > > > > > > -------------------------------
> > > > > > > > > Maxime LUCE - Somatic
> > > > > > > > > maxime.luce@somatic.fr
> > > > > > > > > 06 28 60 72 34
> > > > > > > > > ________________________________
> > > > > > > > > De : Brian LeRoux<ma...@brian.io>
> > > > > > > > > Envoyé : 18/10/2013 01:48
> > > > > > > > > À : dev@cordova.apache.org<ma...@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 <
> > > > > tommy@devgeeks.org
> > > > > > > > <ma...@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.kadri@gmail.com
> > > <mailto:
> > > > > > > > anis.kadri@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 <
> > > > > > > csantana23@gmail.com
> > > > > > > > <ma...@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 <
> > > > > > > csantana23@gmail.com
> > > > > > > > <ma...@gmail.com>
> > > > > > > > >>> wrote:
> > > > > > > > >>>
> > > > > > > > >>>> ++1 "to install from a given directory instead of
> > > > > .cordova/libs."
> > > > > > > > >>>>
> > > > > > > > >>>>
> > > > > > > > >>>>
> > > > > > > > >>>> On Thu, Oct 17, 2013 at 12:10 PM, Viras <
> > > > > > > viras@users.sourceforge.net
> > > > > > > > <ma...@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 <
> > > > > > > > viras@users.sourceforge.net<mailto:
> viras@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 <
> > > > > > > mmocny@chromium.org
> > > > > > > > <ma...@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-10731<htt**p://
> > > > > > www.infil00p.org/config-**<
> > > > > > > > http://www.infil00p.org/config-**>
> > > > > > > > >>>>>>>> xml-changes-for-ios-and-**android/#comment-10731<
> > > > > > > > >>
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> 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-****
> > > > > > > <
> > > > > > > > >>
> http://www.infil00p.org/**introducing-cordova-3-0-0-for-**>
> > > > > > > > >>>>>>>> android/#comment-10694<http://**
> > > > > > www.infil00p.org/introducing-**
> > > > > > > <
> > > > > > > > http://www.infil00p.org/introducing-**>
> > > > > > > > >>>>>>>> cordova-3-0-0-for-android/#**comment-10694<
> > > > > > > > >>
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> 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
> > > > > > > > >>>>>>>
> > > > > > > > >>>>>>>
> > > > > > > > >>>>> --
> > > > > > > > >>>>> GOFG - Get On Fat Guy
> > > > > > > > >>>>> http://www.gofg.at/ - powered by Cordova
> > > > > > > > >>>>>
> > > > > > > > >>>>
> > > > > > > > >>>>
> > > > > > > > >>>>
> > > > > > > > >>>> --
> > > > > > > > >>>> Carlos Santana
> > > > > > > > >>>> <cs...@gmail.com>>
> > > > > > > > >>>>
> > > > > > > > >>>
> > > > > > > > >>>
> > > > > > > > >>>
> > > > > > > > >>> --
> > > > > > > > >>> Carlos Santana
> > > > > > > > >>> <cs...@gmail.com>>
> > > > > > > > >>
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: config.xml discussion, we need to talk
Posted by Jesse <pu...@gmail.com>.
IDE or cordova-cli ??
@purplecabbage
risingj.com
On Fri, Oct 18, 2013 at 12:02 PM, Steven Gill <st...@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 <pu...@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 <stevengill97@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 <mm...@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 <an...@gmail.com>
> > > wrote:
> > > >
> > > > > Erik that's great! Where can we download it?
> > > > > On Oct 18, 2013 8:01 AM, "Andrew Grieve" <ag...@chromium.org>
> > wrote:
> > > > >
> > > > > > Awesome video!!
> > > > > >
> > > > > >
> > > > > > On Fri, Oct 18, 2013 at 3:43 AM, Erik Jan de Wit <
> > edewit@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 <Ma...@somatic.fr>
> wrote:
> > > > > > >
> > > > > > > > Great Bryan
> > > > > > > > Totally agree !!!
> > > > > > > >
> > > > > > > > Cordialement.
> > > > > > > > -------------------------------
> > > > > > > > Maxime LUCE - Somatic
> > > > > > > > maxime.luce@somatic.fr
> > > > > > > > 06 28 60 72 34
> > > > > > > > ________________________________
> > > > > > > > De : Brian LeRoux<ma...@brian.io>
> > > > > > > > Envoyé : 18/10/2013 01:48
> > > > > > > > À : dev@cordova.apache.org<ma...@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 <
> > > > tommy@devgeeks.org
> > > > > > > <ma...@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.kadri@gmail.com
> > <mailto:
> > > > > > > anis.kadri@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 <
> > > > > > csantana23@gmail.com
> > > > > > > <ma...@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 <
> > > > > > csantana23@gmail.com
> > > > > > > <ma...@gmail.com>
> > > > > > > >>> wrote:
> > > > > > > >>>
> > > > > > > >>>> ++1 "to install from a given directory instead of
> > > > .cordova/libs."
> > > > > > > >>>>
> > > > > > > >>>>
> > > > > > > >>>>
> > > > > > > >>>> On Thu, Oct 17, 2013 at 12:10 PM, Viras <
> > > > > > viras@users.sourceforge.net
> > > > > > > <ma...@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 <
> > > > > > > viras@users.sourceforge.net<mailto:viras@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 <
> > > > > > mmocny@chromium.org
> > > > > > > <ma...@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-10731<htt**p://
> > > > > www.infil00p.org/config-**<
> > > > > > > http://www.infil00p.org/config-**>
> > > > > > > >>>>>>>> xml-changes-for-ios-and-**android/#comment-10731<
> > > > > > > >>
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> 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-****
> > > > > > <
> > > > > > > >> http://www.infil00p.org/**introducing-cordova-3-0-0-for-**>
> > > > > > > >>>>>>>> android/#comment-10694<http://**
> > > > > www.infil00p.org/introducing-**
> > > > > > <
> > > > > > > http://www.infil00p.org/introducing-**>
> > > > > > > >>>>>>>> cordova-3-0-0-for-android/#**comment-10694<
> > > > > > > >>
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> 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
> > > > > > > >>>>>>>
> > > > > > > >>>>>>>
> > > > > > > >>>>> --
> > > > > > > >>>>> GOFG - Get On Fat Guy
> > > > > > > >>>>> http://www.gofg.at/ - powered by Cordova
> > > > > > > >>>>>
> > > > > > > >>>>
> > > > > > > >>>>
> > > > > > > >>>>
> > > > > > > >>>> --
> > > > > > > >>>> Carlos Santana
> > > > > > > >>>> <cs...@gmail.com>>
> > > > > > > >>>>
> > > > > > > >>>
> > > > > > > >>>
> > > > > > > >>>
> > > > > > > >>> --
> > > > > > > >>> Carlos Santana
> > > > > > > >>> <cs...@gmail.com>>
> > > > > > > >>
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: config.xml discussion, we need to talk
Posted by Steven Gill <st...@gmail.com>.
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 <pu...@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 <stevengill97@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 <mm...@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 <an...@gmail.com>
> > wrote:
> > >
> > > > Erik that's great! Where can we download it?
> > > > On Oct 18, 2013 8:01 AM, "Andrew Grieve" <ag...@chromium.org>
> wrote:
> > > >
> > > > > Awesome video!!
> > > > >
> > > > >
> > > > > On Fri, Oct 18, 2013 at 3:43 AM, Erik Jan de Wit <
> edewit@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 <Ma...@somatic.fr> wrote:
> > > > > >
> > > > > > > Great Bryan
> > > > > > > Totally agree !!!
> > > > > > >
> > > > > > > Cordialement.
> > > > > > > -------------------------------
> > > > > > > Maxime LUCE - Somatic
> > > > > > > maxime.luce@somatic.fr
> > > > > > > 06 28 60 72 34
> > > > > > > ________________________________
> > > > > > > De : Brian LeRoux<ma...@brian.io>
> > > > > > > Envoyé : 18/10/2013 01:48
> > > > > > > À : dev@cordova.apache.org<ma...@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 <
> > > tommy@devgeeks.org
> > > > > > <ma...@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.kadri@gmail.com
> <mailto:
> > > > > > anis.kadri@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 <
> > > > > csantana23@gmail.com
> > > > > > <ma...@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 <
> > > > > csantana23@gmail.com
> > > > > > <ma...@gmail.com>
> > > > > > >>> wrote:
> > > > > > >>>
> > > > > > >>>> ++1 "to install from a given directory instead of
> > > .cordova/libs."
> > > > > > >>>>
> > > > > > >>>>
> > > > > > >>>>
> > > > > > >>>> On Thu, Oct 17, 2013 at 12:10 PM, Viras <
> > > > > viras@users.sourceforge.net
> > > > > > <ma...@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 <
> > > > > > viras@users.sourceforge.net<ma...@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 <
> > > > > mmocny@chromium.org
> > > > > > <ma...@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-10731<htt**p://
> > > > www.infil00p.org/config-**<
> > > > > > http://www.infil00p.org/config-**>
> > > > > > >>>>>>>> xml-changes-for-ios-and-**android/#comment-10731<
> > > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
> 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-****
> > > > > <
> > > > > > >> http://www.infil00p.org/**introducing-cordova-3-0-0-for-**>
> > > > > > >>>>>>>> android/#comment-10694<http://**
> > > > www.infil00p.org/introducing-**
> > > > > <
> > > > > > http://www.infil00p.org/introducing-**>
> > > > > > >>>>>>>> cordova-3-0-0-for-android/#**comment-10694<
> > > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
> 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
> > > > > > >>>>>>>
> > > > > > >>>>>>>
> > > > > > >>>>> --
> > > > > > >>>>> GOFG - Get On Fat Guy
> > > > > > >>>>> http://www.gofg.at/ - powered by Cordova
> > > > > > >>>>>
> > > > > > >>>>
> > > > > > >>>>
> > > > > > >>>>
> > > > > > >>>> --
> > > > > > >>>> Carlos Santana
> > > > > > >>>> <cs...@gmail.com>>
> > > > > > >>>>
> > > > > > >>>
> > > > > > >>>
> > > > > > >>>
> > > > > > >>> --
> > > > > > >>> Carlos Santana
> > > > > > >>> <cs...@gmail.com>>
> > > > > > >>
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: config.xml discussion, we need to talk
Posted by Jesse <pu...@gmail.com>.
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 <st...@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 <mm...@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 <an...@gmail.com>
> wrote:
> >
> > > Erik that's great! Where can we download it?
> > > On Oct 18, 2013 8:01 AM, "Andrew Grieve" <ag...@chromium.org> wrote:
> > >
> > > > Awesome video!!
> > > >
> > > >
> > > > On Fri, Oct 18, 2013 at 3:43 AM, Erik Jan de Wit <ed...@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 <Ma...@somatic.fr> wrote:
> > > > >
> > > > > > Great Bryan
> > > > > > Totally agree !!!
> > > > > >
> > > > > > Cordialement.
> > > > > > -------------------------------
> > > > > > Maxime LUCE - Somatic
> > > > > > maxime.luce@somatic.fr
> > > > > > 06 28 60 72 34
> > > > > > ________________________________
> > > > > > De : Brian LeRoux<ma...@brian.io>
> > > > > > Envoyé : 18/10/2013 01:48
> > > > > > À : dev@cordova.apache.org<ma...@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 <
> > tommy@devgeeks.org
> > > > > <ma...@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.kadri@gmail.com<mailto:
> > > > > anis.kadri@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 <
> > > > csantana23@gmail.com
> > > > > <ma...@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 <
> > > > csantana23@gmail.com
> > > > > <ma...@gmail.com>
> > > > > >>> wrote:
> > > > > >>>
> > > > > >>>> ++1 "to install from a given directory instead of
> > .cordova/libs."
> > > > > >>>>
> > > > > >>>>
> > > > > >>>>
> > > > > >>>> On Thu, Oct 17, 2013 at 12:10 PM, Viras <
> > > > viras@users.sourceforge.net
> > > > > <ma...@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 <
> > > > > viras@users.sourceforge.net<ma...@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 <
> > > > mmocny@chromium.org
> > > > > <ma...@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-10731<htt**p://
> > > www.infil00p.org/config-**<
> > > > > http://www.infil00p.org/config-**>
> > > > > >>>>>>>> xml-changes-for-ios-and-**android/#comment-10731<
> > > > > >>
> > > > >
> > > >
> > >
> >
> 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-****
> > > > <
> > > > > >> http://www.infil00p.org/**introducing-cordova-3-0-0-for-**>
> > > > > >>>>>>>> android/#comment-10694<http://**
> > > www.infil00p.org/introducing-**
> > > > <
> > > > > http://www.infil00p.org/introducing-**>
> > > > > >>>>>>>> cordova-3-0-0-for-android/#**comment-10694<
> > > > > >>
> > > > >
> > > >
> > >
> >
> 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
> > > > > >>>>>>>
> > > > > >>>>>>>
> > > > > >>>>> --
> > > > > >>>>> GOFG - Get On Fat Guy
> > > > > >>>>> http://www.gofg.at/ - powered by Cordova
> > > > > >>>>>
> > > > > >>>>
> > > > > >>>>
> > > > > >>>>
> > > > > >>>> --
> > > > > >>>> Carlos Santana
> > > > > >>>> <cs...@gmail.com>>
> > > > > >>>>
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>> --
> > > > > >>> Carlos Santana
> > > > > >>> <cs...@gmail.com>>
> > > > > >>
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> >
>
Re: config.xml discussion, we need to talk
Posted by Michal Mocny <mm...@chromium.org>.
On Fri, Oct 18, 2013 at 2:28 PM, Steven Gill <st...@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 <mm...@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 <an...@gmail.com>
> wrote:
> >
> > > Erik that's great! Where can we download it?
> > > On Oct 18, 2013 8:01 AM, "Andrew Grieve" <ag...@chromium.org> wrote:
> > >
> > > > Awesome video!!
> > > >
> > > >
> > > > On Fri, Oct 18, 2013 at 3:43 AM, Erik Jan de Wit <ed...@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 <Ma...@somatic.fr> wrote:
> > > > >
> > > > > > Great Bryan
> > > > > > Totally agree !!!
> > > > > >
> > > > > > Cordialement.
> > > > > > -------------------------------
> > > > > > Maxime LUCE - Somatic
> > > > > > maxime.luce@somatic.fr
> > > > > > 06 28 60 72 34
> > > > > > ________________________________
> > > > > > De : Brian LeRoux<ma...@brian.io>
> > > > > > Envoyé : 18/10/2013 01:48
> > > > > > À : dev@cordova.apache.org<ma...@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 <
> > tommy@devgeeks.org
> > > > > <ma...@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.kadri@gmail.com<mailto:
> > > > > anis.kadri@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 <
> > > > csantana23@gmail.com
> > > > > <ma...@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 <
> > > > csantana23@gmail.com
> > > > > <ma...@gmail.com>
> > > > > >>> wrote:
> > > > > >>>
> > > > > >>>> ++1 "to install from a given directory instead of
> > .cordova/libs."
> > > > > >>>>
> > > > > >>>>
> > > > > >>>>
> > > > > >>>> On Thu, Oct 17, 2013 at 12:10 PM, Viras <
> > > > viras@users.sourceforge.net
> > > > > <ma...@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 <
> > > > > viras@users.sourceforge.net<ma...@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 <
> > > > mmocny@chromium.org
> > > > > <ma...@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-10731<htt**p://
> > > www.infil00p.org/config-**<
> > > > > http://www.infil00p.org/config-**>
> > > > > >>>>>>>> xml-changes-for-ios-and-**android/#comment-10731<
> > > > > >>
> > > > >
> > > >
> > >
> >
> 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-****
> > > > <
> > > > > >> http://www.infil00p.org/**introducing-cordova-3-0-0-for-**>
> > > > > >>>>>>>> android/#comment-10694<http://**
> > > www.infil00p.org/introducing-**
> > > > <
> > > > > http://www.infil00p.org/introducing-**>
> > > > > >>>>>>>> cordova-3-0-0-for-android/#**comment-10694<
> > > > > >>
> > > > >
> > > >
> > >
> >
> 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
> > > > > >>>>>>>
> > > > > >>>>>>>
> > > > > >>>>> --
> > > > > >>>>> GOFG - Get On Fat Guy
> > > > > >>>>> http://www.gofg.at/ - powered by Cordova
> > > > > >>>>>
> > > > > >>>>
> > > > > >>>>
> > > > > >>>>
> > > > > >>>> --
> > > > > >>>> Carlos Santana
> > > > > >>>> <cs...@gmail.com>>
> > > > > >>>>
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>> --
> > > > > >>> Carlos Santana
> > > > > >>> <cs...@gmail.com>>
> > > > > >>
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> >
>
Re: config.xml discussion, we need to talk
Posted by "Wargo, John" <jo...@sap.com>.
Steven, of course, that is what I meant.
Did you ever finish that review of my PhonegGap book? ;-) the next one will be out in a few weeks (hopefully).
John M. Wargo
> On Oct 18, 2013, at 2:29 PM, "Steven Gill" <st...@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 <mm...@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 <an...@gmail.com> wrote:
>>>
>>> Erik that's great! Where can we download it?
>>>> On Oct 18, 2013 8:01 AM, "Andrew Grieve" <ag...@chromium.org> wrote:
>>>>
>>>> Awesome video!!
>>>>
>>>>
>>>> On Fri, Oct 18, 2013 at 3:43 AM, Erik Jan de Wit <ed...@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 <Ma...@somatic.fr> wrote:
>>>>>>
>>>>>> Great Bryan
>>>>>> Totally agree !!!
>>>>>>
>>>>>> Cordialement.
>>>>>> -------------------------------
>>>>>> Maxime LUCE - Somatic
>>>>>> maxime.luce@somatic.fr
>>>>>> 06 28 60 72 34
>>>>>> ________________________________
>>>>>> De : Brian LeRoux<ma...@brian.io>
>>>>>> Envoyé : 18/10/2013 01:48
>>>>>> À : dev@cordova.apache.org<ma...@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 <
>> tommy@devgeeks.org
>>>>> <ma...@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.kadri@gmail.com<mailto:
>>>>>> anis.kadri@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 <
>>>> csantana23@gmail.com
>>>>> <ma...@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 <
>>>> csantana23@gmail.com
>>>>> <ma...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> ++1 "to install from a given directory instead of
>> .cordova/libs."
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, Oct 17, 2013 at 12:10 PM, Viras <
>>>> viras@users.sourceforge.net
>>>>> <ma...@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 <
>>>>> viras@users.sourceforge.net<ma...@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 <
>>>> mmocny@chromium.org
>>>>> <ma...@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-10731<htt**p://
>>> www.infil00p.org/config-**<
>>>>> http://www.infil00p.org/config-**>
>>>>>>>>>>>>> xml-changes-for-ios-and-**android/#comment-10731<
>> 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-****
>>>> <
>>>>>>> http://www.infil00p.org/**introducing-cordova-3-0-0-for-**>
>>>>>>>>>>>>> android/#comment-10694<http://**
>>> www.infil00p.org/introducing-**
>>>> <
>>>>> http://www.infil00p.org/introducing-**>
>>>>>>>>>>>>> cordova-3-0-0-for-android/#**comment-10694<
>> 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
>>>>>>>>>> --
>>>>>>>>>> GOFG - Get On Fat Guy
>>>>>>>>>> http://www.gofg.at/ - powered by Cordova
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Carlos Santana
>>>>>>>>> <cs...@gmail.com>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Carlos Santana
>>>>>>>> <cs...@gmail.com>>
>>
Re: config.xml discussion, we need to talk
Posted by Steven Gill <st...@gmail.com>.
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 <mm...@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 <an...@gmail.com> wrote:
>
> > Erik that's great! Where can we download it?
> > On Oct 18, 2013 8:01 AM, "Andrew Grieve" <ag...@chromium.org> wrote:
> >
> > > Awesome video!!
> > >
> > >
> > > On Fri, Oct 18, 2013 at 3:43 AM, Erik Jan de Wit <ed...@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 <Ma...@somatic.fr> wrote:
> > > >
> > > > > Great Bryan
> > > > > Totally agree !!!
> > > > >
> > > > > Cordialement.
> > > > > -------------------------------
> > > > > Maxime LUCE - Somatic
> > > > > maxime.luce@somatic.fr
> > > > > 06 28 60 72 34
> > > > > ________________________________
> > > > > De : Brian LeRoux<ma...@brian.io>
> > > > > Envoyé : 18/10/2013 01:48
> > > > > À : dev@cordova.apache.org<ma...@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 <
> tommy@devgeeks.org
> > > > <ma...@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.kadri@gmail.com<mailto:
> > > > anis.kadri@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 <
> > > csantana23@gmail.com
> > > > <ma...@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 <
> > > csantana23@gmail.com
> > > > <ma...@gmail.com>
> > > > >>> wrote:
> > > > >>>
> > > > >>>> ++1 "to install from a given directory instead of
> .cordova/libs."
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>> On Thu, Oct 17, 2013 at 12:10 PM, Viras <
> > > viras@users.sourceforge.net
> > > > <ma...@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 <
> > > > viras@users.sourceforge.net<ma...@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 <
> > > mmocny@chromium.org
> > > > <ma...@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-10731<htt**p://
> > www.infil00p.org/config-**<
> > > > http://www.infil00p.org/config-**>
> > > > >>>>>>>> xml-changes-for-ios-and-**android/#comment-10731<
> > > > >>
> > > >
> > >
> >
> 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-****
> > > <
> > > > >> http://www.infil00p.org/**introducing-cordova-3-0-0-for-**>
> > > > >>>>>>>> android/#comment-10694<http://**
> > www.infil00p.org/introducing-**
> > > <
> > > > http://www.infil00p.org/introducing-**>
> > > > >>>>>>>> cordova-3-0-0-for-android/#**comment-10694<
> > > > >>
> > > >
> > >
> >
> 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
> > > > >>>>>>>
> > > > >>>>>>>
> > > > >>>>> --
> > > > >>>>> GOFG - Get On Fat Guy
> > > > >>>>> http://www.gofg.at/ - powered by Cordova
> > > > >>>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>> --
> > > > >>>> Carlos Santana
> > > > >>>> <cs...@gmail.com>>
> > > > >>>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>> --
> > > > >>> Carlos Santana
> > > > >>> <cs...@gmail.com>>
> > > > >>
> > > > >
> > > >
> > > >
> > >
> >
>
Re: config.xml discussion, we need to talk
Posted by Michal Mocny <mm...@chromium.org>.
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 <an...@gmail.com> wrote:
> Erik that's great! Where can we download it?
> On Oct 18, 2013 8:01 AM, "Andrew Grieve" <ag...@chromium.org> wrote:
>
> > Awesome video!!
> >
> >
> > On Fri, Oct 18, 2013 at 3:43 AM, Erik Jan de Wit <ed...@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 <Ma...@somatic.fr> wrote:
> > >
> > > > Great Bryan
> > > > Totally agree !!!
> > > >
> > > > Cordialement.
> > > > -------------------------------
> > > > Maxime LUCE - Somatic
> > > > maxime.luce@somatic.fr
> > > > 06 28 60 72 34
> > > > ________________________________
> > > > De : Brian LeRoux<ma...@brian.io>
> > > > Envoyé : 18/10/2013 01:48
> > > > À : dev@cordova.apache.org<ma...@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 <tommy@devgeeks.org
> > > <ma...@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.kadri@gmail.com<mailto:
> > > anis.kadri@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 <
> > csantana23@gmail.com
> > > <ma...@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 <
> > csantana23@gmail.com
> > > <ma...@gmail.com>
> > > >>> wrote:
> > > >>>
> > > >>>> ++1 "to install from a given directory instead of .cordova/libs."
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>> On Thu, Oct 17, 2013 at 12:10 PM, Viras <
> > viras@users.sourceforge.net
> > > <ma...@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 <
> > > viras@users.sourceforge.net<ma...@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 <
> > mmocny@chromium.org
> > > <ma...@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-10731<htt**p://
> www.infil00p.org/config-**<
> > > http://www.infil00p.org/config-**>
> > > >>>>>>>> xml-changes-for-ios-and-**android/#comment-10731<
> > > >>
> > >
> >
> 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-****
> > <
> > > >> http://www.infil00p.org/**introducing-cordova-3-0-0-for-**>
> > > >>>>>>>> android/#comment-10694<http://**
> www.infil00p.org/introducing-**
> > <
> > > http://www.infil00p.org/introducing-**>
> > > >>>>>>>> cordova-3-0-0-for-android/#**comment-10694<
> > > >>
> > >
> >
> 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
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>> --
> > > >>>>> GOFG - Get On Fat Guy
> > > >>>>> http://www.gofg.at/ - powered by Cordova
> > > >>>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>> --
> > > >>>> Carlos Santana
> > > >>>> <cs...@gmail.com>>
> > > >>>>
> > > >>>
> > > >>>
> > > >>>
> > > >>> --
> > > >>> Carlos Santana
> > > >>> <cs...@gmail.com>>
> > > >>
> > > >
> > >
> > >
> >
>
Re: config.xml discussion, we need to talk
Posted by Anis KADRI <an...@gmail.com>.
Erik that's great! Where can we download it?
On Oct 18, 2013 8:01 AM, "Andrew Grieve" <ag...@chromium.org> wrote:
> Awesome video!!
>
>
> On Fri, Oct 18, 2013 at 3:43 AM, Erik Jan de Wit <ed...@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 <Ma...@somatic.fr> wrote:
> >
> > > Great Bryan
> > > Totally agree !!!
> > >
> > > Cordialement.
> > > -------------------------------
> > > Maxime LUCE - Somatic
> > > maxime.luce@somatic.fr
> > > 06 28 60 72 34
> > > ________________________________
> > > De : Brian LeRoux<ma...@brian.io>
> > > Envoyé : 18/10/2013 01:48
> > > À : dev@cordova.apache.org<ma...@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 <tommy@devgeeks.org
> > <ma...@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.kadri@gmail.com<mailto:
> > anis.kadri@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 <
> csantana23@gmail.com
> > <ma...@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 <
> csantana23@gmail.com
> > <ma...@gmail.com>
> > >>> wrote:
> > >>>
> > >>>> ++1 "to install from a given directory instead of .cordova/libs."
> > >>>>
> > >>>>
> > >>>>
> > >>>> On Thu, Oct 17, 2013 at 12:10 PM, Viras <
> viras@users.sourceforge.net
> > <ma...@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 <
> > viras@users.sourceforge.net<ma...@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 <
> mmocny@chromium.org
> > <ma...@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-10731<htt**p://www.infil00p.org/config-**<
> > http://www.infil00p.org/config-**>
> > >>>>>>>> xml-changes-for-ios-and-**android/#comment-10731<
> > >>
> >
> 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-****
> <
> > >> http://www.infil00p.org/**introducing-cordova-3-0-0-for-**>
> > >>>>>>>> android/#comment-10694<http://**www.infil00p.org/introducing-**
> <
> > http://www.infil00p.org/introducing-**>
> > >>>>>>>> cordova-3-0-0-for-android/#**comment-10694<
> > >>
> >
> 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
> > >>>>>>>
> > >>>>>>>
> > >>>>> --
> > >>>>> GOFG - Get On Fat Guy
> > >>>>> http://www.gofg.at/ - powered by Cordova
> > >>>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>> --
> > >>>> Carlos Santana
> > >>>> <cs...@gmail.com>>
> > >>>>
> > >>>
> > >>>
> > >>>
> > >>> --
> > >>> Carlos Santana
> > >>> <cs...@gmail.com>>
> > >>
> > >
> >
> >
>
Re: config.xml discussion, we need to talk
Posted by Andrew Grieve <ag...@chromium.org>.
Awesome video!!
On Fri, Oct 18, 2013 at 3:43 AM, Erik Jan de Wit <ed...@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 <Ma...@somatic.fr> wrote:
>
> > Great Bryan
> > Totally agree !!!
> >
> > Cordialement.
> > -------------------------------
> > Maxime LUCE - Somatic
> > maxime.luce@somatic.fr
> > 06 28 60 72 34
> > ________________________________
> > De : Brian LeRoux<ma...@brian.io>
> > Envoyé : 18/10/2013 01:48
> > À : dev@cordova.apache.org<ma...@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 <tommy@devgeeks.org
> <ma...@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.kadri@gmail.com<mailto:
> anis.kadri@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 <csantana23@gmail.com
> <ma...@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 <csantana23@gmail.com
> <ma...@gmail.com>
> >>> wrote:
> >>>
> >>>> ++1 "to install from a given directory instead of .cordova/libs."
> >>>>
> >>>>
> >>>>
> >>>> On Thu, Oct 17, 2013 at 12:10 PM, Viras <viras@users.sourceforge.net
> <ma...@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 <
> viras@users.sourceforge.net<ma...@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 <mmocny@chromium.org
> <ma...@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-10731<htt**p://www.infil00p.org/config-**<
> http://www.infil00p.org/config-**>
> >>>>>>>> xml-changes-for-ios-and-**android/#comment-10731<
> >>
> 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-****<
> >> http://www.infil00p.org/**introducing-cordova-3-0-0-for-**>
> >>>>>>>> android/#comment-10694<http://**www.infil00p.org/introducing-**<
> http://www.infil00p.org/introducing-**>
> >>>>>>>> cordova-3-0-0-for-android/#**comment-10694<
> >>
> 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
> >>>>>>>
> >>>>>>>
> >>>>> --
> >>>>> GOFG - Get On Fat Guy
> >>>>> http://www.gofg.at/ - powered by Cordova
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Carlos Santana
> >>>> <cs...@gmail.com>>
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Carlos Santana
> >>> <cs...@gmail.com>>
> >>
> >
>
>
Re: config.xml discussion, we need to talk
Posted by Erik Jan de Wit <ed...@redhat.com>.
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 <Ma...@somatic.fr> wrote:
> Great Bryan
> Totally agree !!!
>
> Cordialement.
> -------------------------------
> Maxime LUCE - Somatic
> maxime.luce@somatic.fr
> 06 28 60 72 34
> ________________________________
> De : Brian LeRoux<ma...@brian.io>
> Envoyé : 18/10/2013 01:48
> À : dev@cordova.apache.org<ma...@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>> 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" <an...@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 <cs...@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 <cs...@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 <mm...@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-10731<htt**p://www.infil00p.org/config-**<http://www.infil00p.org/config-**>
>>>>>>>> xml-changes-for-ios-and-**android/#comment-10731<
>> 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-****<
>> http://www.infil00p.org/**introducing-cordova-3-0-0-for-**>
>>>>>>>> android/#comment-10694<http://**www.infil00p.org/introducing-**<http://www.infil00p.org/introducing-**>
>>>>>>>> cordova-3-0-0-for-android/#**comment-10694<
>> 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
>>>>>>>
>>>>>>>
>>>>> --
>>>>> GOFG - Get On Fat Guy
>>>>> http://www.gofg.at/ - powered by Cordova
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Carlos Santana
>>>> <cs...@gmail.com>>
>>>>
>>>
>>>
>>>
>>> --
>>> Carlos Santana
>>> <cs...@gmail.com>>
>>
>
RE: config.xml discussion, we need to talk
Posted by Maxime LUCE <Ma...@somatic.fr>.
Great Bryan
Totally agree !!!
Cordialement.
-------------------------------
Maxime LUCE - Somatic
maxime.luce@somatic.fr
06 28 60 72 34
________________________________
De : Brian LeRoux<ma...@brian.io>
Envoyé : 18/10/2013 01:48
À : dev@cordova.apache.org<ma...@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>> 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" <an...@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 <cs...@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 <cs...@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 <mm...@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-10731<htt**p://www.infil00p.org/config-**<http://www.infil00p.org/config-**>
> >>>>>> xml-changes-for-ios-and-**android/#comment-10731<
> 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-****<
> http://www.infil00p.org/**introducing-cordova-3-0-0-for-**>
> >>>>>> android/#comment-10694<http://**www.infil00p.org/introducing-**<http://www.infil00p.org/introducing-**>
> >>>>>> cordova-3-0-0-for-android/#**comment-10694<
> 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
> >>>>>
> >>>>>
> >>> --
> >>> GOFG - Get On Fat Guy
> >>> http://www.gofg.at/ - powered by Cordova
> >>>
> >>
> >>
> >>
> >> --
> >> Carlos Santana
> >> <cs...@gmail.com>>
> >>
> >
> >
> >
> > --
> > Carlos Santana
> > <cs...@gmail.com>>
>
Re: config.xml discussion, we need to talk
Posted by Brian LeRoux <b...@brian.io>.
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" <an...@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 <cs...@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 <csantana23@gmail.com
> > >wrote:
> > >
> > >> ++1 "to install from a given directory instead of .cordova/libs."
> > >>
> > >>
> > >>
> > >> On Thu, Oct 17, 2013 at 12:10 PM, Viras <viras@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 <
> viras@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 <
> mmocny@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-10731<htt**p://www.infil00p.org/config-**
> > >>>>>> xml-changes-for-ios-and-**android/#comment-10731<
> >
> 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-****<
> > http://www.infil00p.org/**introducing-cordova-3-0-0-for-**>
> > >>>>>> android/#comment-10694<http://**www.infil00p.org/introducing-**
> > >>>>>> cordova-3-0-0-for-android/#**comment-10694<
> >
> 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
> > >>>>>
> > >>>>>
> > >>> --
> > >>> GOFG - Get On Fat Guy
> > >>> http://www.gofg.at/ - powered by Cordova
> > >>>
> > >>
> > >>
> > >>
> > >> --
> > >> Carlos Santana
> > >> <cs...@gmail.com>
> > >>
> > >
> > >
> > >
> > > --
> > > Carlos Santana
> > > <cs...@gmail.com>
> >
>
Re: config.xml discussion, we need to talk
Posted by Tommy Williams <to...@devgeeks.org>.
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" <an...@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 <cs...@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 <csantana23@gmail.com
> >wrote:
> >
> >> ++1 "to install from a given directory instead of .cordova/libs."
> >>
> >>
> >>
> >> On Thu, Oct 17, 2013 at 12:10 PM, Viras <viras@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 <mm...@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-10731<htt**p://www.infil00p.org/config-**
> >>>>>> xml-changes-for-ios-and-**android/#comment-10731<
> 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-****<
> http://www.infil00p.org/**introducing-cordova-3-0-0-for-**>
> >>>>>> android/#comment-10694<http://**www.infil00p.org/introducing-**
> >>>>>> cordova-3-0-0-for-android/#**comment-10694<
> 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
> >>>>>
> >>>>>
> >>> --
> >>> GOFG - Get On Fat Guy
> >>> http://www.gofg.at/ - powered by Cordova
> >>>
> >>
> >>
> >>
> >> --
> >> Carlos Santana
> >> <cs...@gmail.com>
> >>
> >
> >
> >
> > --
> > Carlos Santana
> > <cs...@gmail.com>
>
RE: config.xml discussion, we need to talk
Posted by "Wargo, John" <jo...@sap.com>.
I mean, can I help you with this. Not quite sure where that 'u' came from.
John M. Wargo
-----Original Message-----
From: Wargo, John [mailto:john.wargo@sap.com]
Sent: Friday, October 18, 2013 9:51 AM
To: dev@cordova.apache.org
Subject: RE: config.xml discussion, we need to talk
Mike,
Can UI help you with this?
John M. Wargo
Mobile Platform Product Management
SAP | Charlotte, NC | USA
Office: +1 704.321.0265 | Mobile: +1 704.249.7476
Email: john.wargo@sap.com
Twitter: @johnwargo
-----Original Message-----
From: Mike Billau [mailto:mike.billau@gmail.com]
Sent: Thursday, October 17, 2013 3:02 PM
To: dev@cordova.apache.org; bowserj@apache.org
Subject: Re: config.xml discussion, we need to talk
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 <bo...@gmail.com> wrote:
> On Thu, Oct 17, 2013 at 10:43 AM, Anis KADRI <an...@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
Posted by "Wargo, John" <jo...@sap.com>.
Mike,
Can UI help you with this?
John M. Wargo
Mobile Platform Product Management
SAP | Charlotte, NC | USA
Office: +1 704.321.0265 | Mobile: +1 704.249.7476
Email: john.wargo@sap.com
Twitter: @johnwargo
-----Original Message-----
From: Mike Billau [mailto:mike.billau@gmail.com]
Sent: Thursday, October 17, 2013 3:02 PM
To: dev@cordova.apache.org; bowserj@apache.org
Subject: Re: config.xml discussion, we need to talk
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 <bo...@gmail.com> wrote:
> On Thu, Oct 17, 2013 at 10:43 AM, Anis KADRI <an...@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
Posted by Mike Billau <mi...@gmail.com>.
Great, I filed https://issues.apache.org/jira/browse/CB-5122
On Thu, Oct 17, 2013 at 3:17 PM, Tyler Wilson <tw...@symbeeco.com> wrote:
> Sounds awesome to me.
>
> Thanks,
> Tyler
>
> On Oct 17, 2013, at 3:10 PM, Steven Gill <st...@gmail.com> wrote:
>
> > YES! We could really use this Mike!
> >
> >
> > On Thu, Oct 17, 2013 at 12:06 PM, Anis KADRI <an...@gmail.com>
> wrote:
> >
> >> That would be awesome Mike!
> >>
> >> On Thu, Oct 17, 2013 at 12:01 PM, Mike Billau <mi...@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 <bo...@gmail.com> wrote:
> >>>
> >>>> On Thu, Oct 17, 2013 at 10:43 AM, Anis KADRI <an...@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
Posted by Tyler Wilson <tw...@symbeeco.com>.
Sounds awesome to me.
Thanks,
Tyler
On Oct 17, 2013, at 3:10 PM, Steven Gill <st...@gmail.com> wrote:
> YES! We could really use this Mike!
>
>
> On Thu, Oct 17, 2013 at 12:06 PM, Anis KADRI <an...@gmail.com> wrote:
>
>> That would be awesome Mike!
>>
>> On Thu, Oct 17, 2013 at 12:01 PM, Mike Billau <mi...@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 <bo...@gmail.com> wrote:
>>>
>>>> On Thu, Oct 17, 2013 at 10:43 AM, Anis KADRI <an...@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
Posted by Steven Gill <st...@gmail.com>.
YES! We could really use this Mike!
On Thu, Oct 17, 2013 at 12:06 PM, Anis KADRI <an...@gmail.com> wrote:
> That would be awesome Mike!
>
> On Thu, Oct 17, 2013 at 12:01 PM, Mike Billau <mi...@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 <bo...@gmail.com> wrote:
> >
> >> On Thu, Oct 17, 2013 at 10:43 AM, Anis KADRI <an...@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
Posted by Anis KADRI <an...@gmail.com>.
That would be awesome Mike!
On Thu, Oct 17, 2013 at 12:01 PM, Mike Billau <mi...@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 <bo...@gmail.com> wrote:
>
>> On Thu, Oct 17, 2013 at 10:43 AM, Anis KADRI <an...@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
Posted by Mike Billau <mi...@gmail.com>.
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 <bo...@gmail.com> wrote:
> On Thu, Oct 17, 2013 at 10:43 AM, Anis KADRI <an...@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
Posted by Joe Bowser <bo...@gmail.com>.
On Thu, Oct 17, 2013 at 10:43 AM, Anis KADRI <an...@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
Posted by Anis KADRI <an...@gmail.com>.
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 <cs...@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 <cs...@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 <mm...@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-10731<htt**p://www.infil00p.org/config-**
>>>>>> xml-changes-for-ios-and-**android/#comment-10731<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-****<http://www.infil00p.org/**introducing-cordova-3-0-0-for-**>
>>>>>> android/#comment-10694<http://**www.infil00p.org/introducing-**
>>>>>> cordova-3-0-0-for-android/#**comment-10694<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
>>>>>
>>>>>
>>> --
>>> GOFG - Get On Fat Guy
>>> http://www.gofg.at/ - powered by Cordova
>>>
>>
>>
>>
>> --
>> Carlos Santana
>> <cs...@gmail.com>
>>
>
>
>
> --
> Carlos Santana
> <cs...@gmail.com>
Re: config.xml discussion, we need to talk
Posted by Carlos Santana <cs...@gmail.com>.
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 <cs...@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 <mm...@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-10731<htt**p://www.infil00p.org/config-**
>>>>> xml-changes-for-ios-and-**android/#comment-10731<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-****<http://www.infil00p.org/**introducing-cordova-3-0-0-for-**>
>>>>> android/#comment-10694<http://**www.infil00p.org/introducing-**
>>>>> cordova-3-0-0-for-android/#**comment-10694<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
>>>>
>>>>
>> --
>> GOFG - Get On Fat Guy
>> http://www.gofg.at/ - powered by Cordova
>>
>
>
>
> --
> Carlos Santana
> <cs...@gmail.com>
>
--
Carlos Santana
<cs...@gmail.com>
Re: config.xml discussion, we need to talk
Posted by Carlos Santana <cs...@gmail.com>.
++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 <mm...@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-10731<htt**p://www.infil00p.org/config-**
>>>> xml-changes-for-ios-and-**android/#comment-10731<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-****<http://www.infil00p.org/**introducing-cordova-3-0-0-for-**>
>>>> android/#comment-10694<http://**www.infil00p.org/introducing-**
>>>> cordova-3-0-0-for-android/#**comment-10694<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
>>>
>>>
> --
> GOFG - Get On Fat Guy
> http://www.gofg.at/ - powered by Cordova
>
--
Carlos Santana
<cs...@gmail.com>
Re: config.xml discussion, we need to talk
Posted by Viras <vi...@users.sourceforge.net>.
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 <mm...@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<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<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
>>
--
GOFG - Get On Fat Guy
http://www.gofg.at/ - powered by Cordova
Re: config.xml discussion, we need to talk
Posted by Michal Mocny <mm...@chromium.org>.
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 <mm...@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<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<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
Posted by Shazron <sh...@gmail.com>.
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 <br...@chromium.org>wrote:
> 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 <lholmqui@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 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 <mm...@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
Posted by Braden Shepherdson <br...@chromium.org>.
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 <lh...@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 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 <mm...@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
Posted by Lucas Holmquist <lh...@redhat.com>.
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 <mm...@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
Posted by Viras <vi...@users.sourceforge.net>.
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 <mm...@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
Posted by Joe Bowser <bo...@gmail.com>.
On Wed, Oct 16, 2013 at 1:37 PM, Michal Mocny <mm...@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
Posted by Steven Gill <st...@gmail.com>.
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 <mm...@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 <an...@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 <tw...@symbeeco.com>
> > wrote:
> > >
> > > On Oct 16, 2013, at 1:47 PM, Joe Bowser <bo...@gmail.com> wrote:
> > >
> > >> On Wed, Oct 16, 2013 at 10:13 AM, Wargo, John <jo...@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
Posted by Michal Mocny <mm...@chromium.org>.
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 <an...@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 <tw...@symbeeco.com>
> wrote:
> >
> > On Oct 16, 2013, at 1:47 PM, Joe Bowser <bo...@gmail.com> wrote:
> >
> >> On Wed, Oct 16, 2013 at 10:13 AM, Wargo, John <jo...@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
Posted by Anis KADRI <an...@gmail.com>.
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 <tw...@symbeeco.com> wrote:
>
> On Oct 16, 2013, at 1:47 PM, Joe Bowser <bo...@gmail.com> wrote:
>
>> On Wed, Oct 16, 2013 at 10:13 AM, Wargo, John <jo...@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
Posted by Tyler Wilson <tw...@symbeeco.com>.
On Oct 16, 2013, at 1:47 PM, Joe Bowser <bo...@gmail.com> wrote:
> On Wed, Oct 16, 2013 at 10:13 AM, Wargo, John <jo...@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
Posted by Joe Bowser <bo...@gmail.com>.
On Wed, Oct 16, 2013 at 10:13 AM, Wargo, John <jo...@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
Re: config.xml discussion, we need to talk
Posted by "Wargo, John" <jo...@sap.com>.
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" <bo...@gmail.com> wrote:
>
>> On Thu, Sep 26, 2013 at 8:53 AM, Lindsey Simon <el...@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
Posted by Carlos Santana <cs...@gmail.com>.
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 <pu...@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 <bo...@gmail.com> wrote:
>
> > On Thu, Sep 26, 2013 at 8:53 AM, Lindsey Simon <el...@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
<cs...@gmail.com>
Re: config.xml discussion, we need to talk
Posted by Jesse <pu...@gmail.com>.
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 <bo...@gmail.com> wrote:
> On Thu, Sep 26, 2013 at 8:53 AM, Lindsey Simon <el...@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
Posted by Joe Bowser <bo...@gmail.com>.
On Thu, Sep 26, 2013 at 8:53 AM, Lindsey Simon <el...@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
Posted by Lindsey Simon <el...@gmail.com>.
On Thu, Sep 26, 2013 at 8:32 AM, Carlos Santana <cs...@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?
> 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 <csantana23@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 <
> > bhiggins@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 <pu...@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 <
> > > > bhiggins@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 <
> purplecabbage@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]
> > > > > > > >
> > > > > > > >
> > > > > > > > > > > > > <http://risingj.com>
> > >
> > >
> > >
> > > --
> > > Carlos Santana
> > > <csantana23@gmail.com <javascript:;>>
> > >
> >
>
>
> --
> Carlos Santana
> <cs...@gmail.com>
>
RE: config.xml discussion, we need to talk
Posted by Jonathan Bond-Caron <jb...@gdesolutions.com>.
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
Posted by Carlos Santana <cs...@gmail.com>.
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 <csantana23@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 <
> bhiggins@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 <pu...@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 <
> > > bhiggins@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 <pu...@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]
> > > > > > >
> > > > > > >
> > > > > > > > > > > > <http://risingj.com>
> >
> >
> >
> > --
> > Carlos Santana
> > <csantana23@gmail.com <javascript:;>>
> >
>
--
Carlos Santana
<cs...@gmail.com>
Re: config.xml discussion, we need to talk
Posted by Carlos Santana <cs...@gmail.com>.
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 <
jbondc@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
<cs...@gmail.com>
Re: config.xml discussion, we need to talk
Posted by Carlos Santana <cs...@gmail.com>.
Branden
Yes I agree with you, I think we are on the same page.
Maybe I got confuse about "defaults.xml" and "A **totally different file**
with the same name is also generated by the
CLI"
my bad
On Thu, Sep 26, 2013 at 2:12 PM, Braden Shepherdson <br...@chromium.org>wrote:
> 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 <csantana23@gmail.com
> >wrote:
>
> > 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 <braden@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 <csantana23@gmail.com
> > > >wrote:
> > >
> > > > maybe a new file cordova.xml for CLI scenario?
> > > >
> > > >
> > > > On Thu, Sep 26, 2013 at 1:40 PM, Braden Shepherdson <
> > braden@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 <
> > > > > jbondc@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
> > > > <cs...@gmail.com>
> > > >
> > >
> >
> >
> >
> > --
> > Carlos Santana
> > <cs...@gmail.com>
> >
>
--
Carlos Santana
<cs...@gmail.com>
Re: config.xml discussion, we need to talk
Posted by Braden Shepherdson <br...@chromium.org>.
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 <cs...@gmail.com>wrote:
> 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 <braden@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 <csantana23@gmail.com
> > >wrote:
> >
> > > maybe a new file cordova.xml for CLI scenario?
> > >
> > >
> > > On Thu, Sep 26, 2013 at 1:40 PM, Braden Shepherdson <
> braden@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 <
> > > > jbondc@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
> > > <cs...@gmail.com>
> > >
> >
>
>
>
> --
> Carlos Santana
> <cs...@gmail.com>
>
Re: config.xml discussion, we need to talk
Posted by Carlos Santana <cs...@gmail.com>.
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 <br...@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 <csantana23@gmail.com
> >wrote:
>
> > maybe a new file cordova.xml for CLI scenario?
> >
> >
> > On Thu, Sep 26, 2013 at 1:40 PM, Braden Shepherdson <braden@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 <
> > > jbondc@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
> > <cs...@gmail.com>
> >
>
--
Carlos Santana
<cs...@gmail.com>
Re: config.xml discussion, we need to talk
Posted by Braden Shepherdson <br...@chromium.org>.
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 <cs...@gmail.com>wrote:
> maybe a new file cordova.xml for CLI scenario?
>
>
> On Thu, Sep 26, 2013 at 1:40 PM, Braden Shepherdson <braden@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 <
> > jbondc@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
> <cs...@gmail.com>
>
Re: config.xml discussion, we need to talk
Posted by Carlos Santana <cs...@gmail.com>.
maybe a new file cordova.xml for CLI scenario?
On Thu, Sep 26, 2013 at 1:40 PM, Braden Shepherdson <br...@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 <
> jbondc@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
<cs...@gmail.com>
RE: config.xml discussion, we need to talk
Posted by Michael Sierra <ms...@adobe.com>.
I'm about to try to better clarify current behavior in the doc. I understand when using the CLI to build, the `platforms/*/www/config.xml` files come from passively copying the web-assets source directory. (Excpetion: Android's ends up in `platforms/android/assets/www/config.xml`.) If you switch from CLI to an SDK workflow, you need to use these other files as source for iOS & Android:
platforms/ios/<APP_NAME>/config.xml
platforms/android/res/www/config.xml
Question: Do any other platforms' SDK-ready config.xml files live elsewhere than what's generated by the CLI in `platforms/*/www/config.xml`? And if so, where so they live? Thanks
--Mike S
________________________________________
From: braden@google.com [braden@google.com] On Behalf Of Braden Shepherdson [braden@chromium.org]
Sent: Thursday, September 26, 2013 1:40 PM
To: dev@cordova.apache.org
Subject: 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 <
jbondc@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
Posted by Braden Shepherdson <br...@chromium.org>.
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 <
jbondc@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
Posted by Jonathan Bond-Caron <jb...@gdesolutions.com>.
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
Posted by Jesse <pu...@gmail.com>.
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 <br...@chromium.org>wrote:
> On Thu, Sep 26, 2013 at 11:03 AM, Joe Bowser <bo...@gmail.com> wrote:
>
> > On Thu, Sep 26, 2013 at 7:18 AM, Braden Shepherdson <braden@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
Posted by Braden Shepherdson <br...@chromium.org>.
On Thu, Sep 26, 2013 at 11:03 AM, Joe Bowser <bo...@gmail.com> wrote:
> On Thu, Sep 26, 2013 at 7:18 AM, Braden Shepherdson <br...@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
Posted by Joe Bowser <bo...@gmail.com>.
On Thu, Sep 26, 2013 at 7:18 AM, Braden Shepherdson <br...@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
Posted by Braden Shepherdson <br...@chromium.org>.
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 <cs...@gmail.com>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 <bhiggins@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 <pu...@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 <
> > bhiggins@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 <pu...@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
> <cs...@gmail.com>
>
Re: config.xml discussion, we need to talk
Posted by Carlos Santana <cs...@gmail.com>.
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 <bhiggins@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 <pu...@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 <
> bhiggins@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 <pu...@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
<cs...@gmail.com>
Re: config.xml discussion, we need to talk
Posted by Braden Shepherdson <br...@chromium.org>.
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 <bh...@blackberry.com>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 <pu...@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 <bhiggins@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 <pu...@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
> > > > risingj.com
> > > >
> > >
> >
>
Re: config.xml discussion, we need to talk
Posted by Bryan Higgins <bh...@blackberry.com>.
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 <pu...@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 <bhiggins@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 <pu...@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
> > > risingj.com
> > >
> >
>
Re: config.xml discussion, we need to talk
Posted by Jesse <pu...@gmail.com>.
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 <bh...@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 <pu...@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
> > risingj.com
> >
>
Re: config.xml discussion, we need to talk
Posted by Bryan Higgins <bh...@blackberry.com>.
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 <pu...@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
> risingj.com
>