cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Velecký <>
Subject Re: One platform development vs. Cordova CLI
Date Tue, 15 Jul 2014 06:12:32 GMT

Well, when I need something test quickly or check something with trial and 
error procedure, I don't like to use cordova run.

On Android, in most cases I need modificate androidmanifest.xml, rarely 
config.xml. Modifications of androidmanifest are, how I told, preserved, 
only formatting (and maybe only new lines) is destroyed. I do not change 
andoridmanifest through cross-platform config.xml, because this method is 
too complicated, to do it this way more changes in androidmanifest, so maybe
it is reason for that is changes in andoridmanifest preserved.

Well, I don't like to use cordova run for a reason. Cordova run/build 
compile perhaps every file everytime, so testing with this way is more 
likely waiting to build success, while Eclipse only compile changed files. 
For that reason I develop most time in Eclipse IDE. This is case for non-
assetss files.

When changing assets files (www), I must changed root www files, then run 
cordova run.

So I cannot switch to completely one platform development (which is 
preferred by me in this case), because refreshing project in Eclipse don't 
refresh assets, and then I must do long clean... I didn't try cordova 
executable inside android project, I'll try it.

But there is another one reason – plugins. In cordova executables in project
there are no parallel of cordova plugins add/remove, which there maybe 
should be too, so I need jump back to CLI. Yeah, I know about plugman, but 
it is so terrible to use it to add or remove plugins, I would rather do it 
manually, than with plugman.

I hope I explain it good.

Nice day,

Jan Velecký.


Sooo.. translation: 

“If you aren’t just making a test / example app…” 


Unless a lot has changed that I don’t know about, it is still impossible to 
make an app all the way to market without modifying those non-www files 
using the CLI. 

There are fantastic workarounds available (mostly hooks, etc) for the CLI 
until we get it to the point where the platforms/* and plugins/* folders are
build artefacts. 

- tommy 

On 15 July 2014 at 9:14:12, Anis KADRI ( wrote: 

If you're touching any non-www project files (that is *.xml, *.plist, *.m, *
.java etc...) or are using an IDE you should not be using cordova-cli and 
switch to single platform development. Browse the documentation and there is
always the equivalent platform command available to you. Example: cordova 
build becomes ./cordova/build etc...You can then modify all your files at 
will but will loose the benefit of a shared www/ across platforms. 

On Mon, Jul 14, 2014 at 5:49 PM, Frederico Galvão <>

I agree with the core message from Axel, but I'd refrase that last line as: 

"The bottom line is: either use Cordova CLI or not". 

Cordova can still be used without the CLI portion just as well, which should
suffice Jan for his needs. 

However, I'll add that you can still use Cordova with the CLI (and thus 
following the directory structure and rules the CLI gives you) and still be 
efficient even if it's only one target platform. What made you think that it
is "better to change platform project config.xml instead of whole project 
config.xml" should be clarified better if you can, so that the Cordova team 
can improve the tool. 

2014-07-14 5:35 GMT-03:00 Axel Nennker <>: 

My experience with Cordova (and other tools for that matter) is that it 
makes no sense to change tool generated files. If the tool is improved you 
do not benefit from this improvement because your modified files will be 
changed by the new version. If you change a tool generated file you are out.
When we started using Cordova me and other colleagues thought that our 
project "needs" to change Cordova generated files too. In each case this 
turned out to be wrong. Most of the times writing a Cordova plugin is the 

The bottom line is: either use Cordova or not. (or send a pull request to 
improve it) 


2014-07-13 22:18 GMT+02:00 Jan Velecký <>: 

Hello, there is serious backlog when using CLI in case one platform 
development. In this case is better to change platform project config.xml 
instead of whole project config.xml. Problem is what prepare should do, and 
what prepare actually do. (And prepare is also run if we do build.) At this 
moment, prepare in CLI does clean & copy... Also prepare does it in 
different way in Android, than in iOS. On Android, config.xml and 
androidmanifest.xml is probably recreated (destroy previous formatting, what
a feature...) and then probably add differences, so changes and new options 
are preserved, however nobody wanna read it... On iOS, config.xml is 
completely recreated, no any option is preserved... 

So, there are 2 questions... If is Android CLI too clever to do preserve 
changes created by user, 



ruins my formatting (new lines, maybe also tabulators)? Why is iOS CLI such 
a stupid? Why it is not able to do it like 



(at least)? 


*Frederico Galvão* 

Diretor de Tecnologia 

PontoGet Inovação Web 

( +55(62) 8131-5720 

* <> 

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