Re: [DISCUSS] CLI Templates

[Gorkem Ercan]

How about adding support for some more dynamic generation.
Can we add yeoman as an option something like $cordova create myApp 
--template=yo:m

to invoke the generator m ?
--
Gorkem

On 10 Nov 2015, at 19:52, Carlos Santana wrote:


Parashuram

I would say that if they have "platforms" and "plugins" it's not 
consider a
template, its consider a cordova project ready to be use no need to 
run

create on it.

As far as cp-from, it's doesn't copy much only www and config.xml, I 
didn't
want to change it's behavior for backwards compatibility. I think it 
will

be good to mark it deprecated for a certain period of time,



+1 for deprecating the copy-from.



On Tue, Nov 10, 2015 at 5:19 PM Parashuram N  
wrote:


Yes, they would. However, there could be cases where folks would like 
to

have templates that have changes stuff in platforms, or added custom
plugins or hooks. I think that instead of adding extra code to 
prevent all

these things, we keep things simple, and copy over everything. The
templates can then decide what they want to do, and most of them will 
not

bundle plugins or platforms.

-Original Message-
From: Steven Gill [mailto:stevengil...@gmail.com]
Sent: Tuesday, November 10, 2015 2:16 PM
To: dev@cordova.apache.org
Subject: Re: [DISCUSS] CLI Templates

If the plugins and platforms are listed in config.xml, wouldn't they 
just

get fetched on prepare?

On Tue, Nov 10, 2015 at 2:09 PM, Parashuram N 


wrote:


I think it should copy platform and plugins folders, if those are a
part of the template. I think the guidance should be that most
templates should not include a platform or a plugin folder, but if
they do - for reasons like custom plugins, etc, then we should let
that happen. The only enhancement from --copy-from would be that we 
also

support npm and git URLs.


-Original Message-
From: Carlos Santana [mailto:csantan...@gmail.com]
Sent: Tuesday, November 10, 2015 1:26 PM
To: dev@cordova.apache.org
Subject: Re: [DISCUSS] CLI Templates

Parashuram

The template doesn't any special structure, the current hello app in
npm is already a template

Will add comment in PR about having fixtures in tests for different
uses cases with different type of templates

The code copies everything except plugins and platforms directories,
maybe it needs some comments to make it more clear

It should copy dot files like .gitignore, .editorconfig, .bowerrc 
Very
important at least for me .gitignore, it helps when folks ask if 
they
should ignore platforms and plugins from source control and the 
answer
is always YES. If they are asking then it means they need the 
advise.



On Tue, Nov 10, 2015 at 3:27 PM Parashuram N 


wrote:


+1 to the proposal.

Is there a structure of a sample template ? Also, the code seems to
copy everything from npm or the gitURL, though in the proposal you
say that dot file and hooks/platforms should not be copies. Should
we talk about that in the proposal too ?

-Original Message-
From: Raymond Camden [mailto:raymondcam...@gmail.com]
Sent: Tuesday, November 10, 2015 12:01 PM
To: dev@cordova.apache.org
Subject: Re: [DISCUSS] CLI Templates

Yeah, nothing to add here but +1.

Oh, the only thing I'd add is that I wish there was a way to
*permanently* set a template. I hate the default Cordova template
(sorry
;) and would love to make the CLI always use my own particular

template.


On Tue, Nov 10, 2015 at 1:52 PM, Ryan J. Salva

wrote:

I love it!


rjs

Ryan J. Salva  |  Principal Program Manager Lead Visual Studio
Tools for Apache Cordova rsa...@microsoft.com
206 612 5079 mobile



-Original Message-
From: Carlos Santana [mailto:csantan...@gmail.com]
Sent: Tuesday, November 10, 2015 7:49 PM
To: dev@cordova.apache.org
Subject: [DISCUSS] CLI Templates

From the Face2Face meeting updating the cordova cli to work with
templates sounded like a good feature to add to the CLI

I finally got around to this and created the proposal and got
James

Dubee from our team to take a stab at implementation.


CLI-Template proposal [1]

[1]:
https://github.com/cordova/cordova-discuss/blob/master/proposals/C
LI
-T
https://na01.safelinks.protection.outlook.com/?url=emplates.md
a=
01%7c01%7cpanarasi%40microsoft.com%7ce586e8f64dae4418c1b708d2ea158
9e
d%7c72f988bf86f141af91ab2d7cd011db47%7c1=kctEUezjtECUIvZQcih
bu
uydWn7HfTJO8c7W0LTz98U%3d

--Carlos




--

== = Raymond Camden, Developer Advocate for MobileFirst at IBM

Email : raymondcam...@gmail.com
Blog :
https://na01.safelinks.protection.outlook.com/?url=www.raymondcamden
.c
om=01%7c01%7cpanarasi%40microsoft.com%7c92e5feab0e524d2dbc8008d
2e
a09af88%7c72f988bf86f141af91ab2d7cd011db47%7c1=xMtq2oC%2b%2b%2
fB
bNlOcIKlStSkgUUuiGDKbq7KuNMHLiVU%3d
Twitter: raymondcamden


- To 

Re: Is CPR going offline

[Gorkem Ercan]

+1
I also observe that people has taken their time to update.
I think it is helpful to keep CPR around until new year.
We can then send CPR away with a countdown on new year's day, instead of 
the viking funeral.

--
Gorkem

On 9 Oct 2015, at 18:04, Nikhil Khandelwal wrote:

I am in favor of keeping it running without making any updates. There 
is fairly high % of users using cordova cli version < cordova 5 (~25% 
based on survey responses). Since our survey is not yet broadly 
publicized, but only using twitter, this number is likely higher.


We should look at download numbers from CPR and when they become 
sufficiently low, then we should decide to take it offline.


Our switch to plugins.cordova.io use the new plugin search will likely 
push people to upgrade to the new CLI versions and phase out CPR - but 
it's going to take more time than another week (our initial phase out 
date).


-Nikhil

-Original Message-
From: Carlos Santana [mailto:csantan...@gmail.com]
Sent: Friday, October 9, 2015 2:49 PM
To: Cordova Dev <dev@cordova.apache.org>
Subject: Re: Is CPR going offline

If there is no reason to keep it alive, I was already handing out 
obituaries for CPR, it served a good purpose for his lifetime


On Fri, Oct 9, 2015 at 9:43 AM Gorkem Ercan <gorkem.er...@gmail.com> 
wrote:




Hi,
Our announced date Oct 15 is next week.
Will CPR be go offline as planned or do we see that we should give it
more time.
--
Gorkem

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Is CPR going offline

[Gorkem Ercan]

Hi,
Our announced date Oct 15 is next week.
Will CPR be go offline as planned or do we see that we should give it 
more time.

--
Gorkem

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: Announcing Tools for Apache Cordova (TACO) v1.0.0!

[Gorkem Ercan]

Congratulations on the release. Looks very useful.

Since this is already open source and seems complimentary to CLI,
What was your reason(s) for not doing this work as part of CLI.
--
Gorkem

On 1 Oct 2015, at 18:00, Subhag Oak wrote:


Hey all,

Today we releases the v1.0.0 of Tools for Apache Cordova (TACO).  
It’s available on npm and github.  TACO CLI is completely build on 
top of the Cordova CLI, so a BIG thank you to all of you! Here is how 
you can install it -

npm install –g taco-cli

Tools for Apache Cordova (TACO, for short) provides number of 
utilities for Mac and Windows users to develop with a set of platforms 
and plugins validated by our Visual Studio product team. Developers 
can also install the native Android and iOS (Mac-only) SDKs and build 
tools. This feature builds on top of the check-reqs command provided 
by the Cordova CLI. TACO also allows you to connect to the Mac remote 
build server straight from the command line on their Windows and Linux 
machines.


DOCS, SOURCE CODE AND NPM:
http://taco.tools
https://github.com/Microsoft/TACO
https://www.npmjs.com/package/taco-cli

If you run into any issues or have suggestions for new ones, please 
open an issue or better yet, send us a pull request. We would 
appreciate any feedback.


Subhag Oak
Senior Program Manager
TACO – Microsoft.

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: Announcing Tools for Apache Cordova (TACO) v1.0.0!

[Gorkem Ercan]

On 2 Oct 2015, at 18:22, Frederico Galvão wrote:

Although I see many benefits in the long run with such a tool (and 
thanks

for making it!) I agree with Gorkem's questioning.



Actually, I do not think all the features of TACO is a good fit to 
include in Cordova CLI
I was actually more interested to learn if the ways of the Apache 
Cordova project was a
factor on the decision. IMHO complimentary projects with a similar OS 
license that are not
built around a product may sometimes indicate a problem with the 
community. It sounds like

it is not and I would REALLY be surprised if it was.



Cordova already has too many names involved around itself (phonegap,
cordova, cli, platforms, plugman, ionic, to name a few), too much 
confusion
already lives in what does what. If TACO could live inside CLI, I 
think it

should.

2015-10-02 17:56 GMT-03:00 Subhag Oak <subhag@microsoft.com>:


Hey Gorkem, thank you for your wishes!

Honestly, as we were developing these tools, there was a continuous
discussion whether we should put this in the Cordova-CLI or have a 
separate

set of tools that complement Cordova. The decision was made to have a
separate package based on following –
•   We feel that Cordova-CLI is build-system, a run-time which 
enables
developers to write hybrid mobile applications using their web 
skills.
Rather than polluting it with extra tools, its best to keep it clean 
and
provide additional capabilities outside it. If there is a feature 
that is
core to the build system, we would definitely propose it for Cordova. 
For
example, we proposed a top-level ‘check-reqs’ command since the 
platforms
were already implicitly doing this. In TACO we have built a feature 
on top
of the ‘check-req’ and extended it to install build-dependencies 
for

individual platforms.
•   Another intention was to keep Cordova small and not 
encumber the
base Cordova-CLI with the ecosystem of tools around it.  
Statistically,
every company has few resources (/committers) allocated to the 
Cordova

open-source project and managing these kind of tools (not core to the
runtime) might get into ways of making fast & effective changes to 
Cordova

itself.

Does that make sense? I am open to suggestions and feedback.

Soak
Senior Program Manager
TACO – Microsoft


-Original Message-----
From: Gorkem Ercan [mailto:gorkem.er...@gmail.com]
Sent: Friday, October 2, 2015 10:05 AM
To: dev@cordova.apache.org
Subject: Re: Announcing Tools for Apache Cordova (TACO) v1.0.0!


Congratulations on the release. Looks very useful.

Since this is already open source and seems complimentary to CLI, 
What was

your reason(s) for not doing this work as part of CLI.
--
Gorkem

On 1 Oct 2015, at 18:00, Subhag Oak wrote:


Hey all,

Today we releases the v1.0.0 of Tools for Apache Cordova (TACO).
It’s available on npm and github.  TACO CLI is completely build on 
top
of the Cordova CLI, so a BIG thank you to all of you! Here is how 
you

can install it -
   npm install –g taco-cli

Tools for Apache Cordova (TACO, for short) provides number of
utilities for Mac and Windows users to develop with a set of 
platforms

and plugins validated by our Visual Studio product team. Developers
can also install the native Android and iOS (Mac-only) SDKs and 
build

tools. This feature builds on top of the check-reqs command provided
by the Cordova CLI. TACO also allows you to connect to the Mac 
remote
build server straight from the command line on their Windows and 
Linux

machines.

DOCS, SOURCE CODE AND NPM:
https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2ftaco.t
ools=01%7c01%7cSubhag.Oak%40microsoft.com%7ce3afffee29214d22271b0
8d2cb4ba500%7c72f988bf86f141af91ab2d7cd011db47%7c1=gVO75kqjP2Ak5
1NDrreZoLF8y3TFbHbfIYsNdlFJd7A%3d
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithu
b.com%2fMicrosoft%2fTACO=01%7c01%7cSubhag.Oak%40microsoft.com%7ce
3afffee29214d22271b08d2cb4ba500%7c72f988bf86f141af91ab2d7cd011db47%7c1
=9Xj7ZpSgo6GN7oj1PFO7Gg5hgccTcKeukdZv1kiHEsY%3d
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.n
pmjs.com%2fpackage%2ftaco-cli=01%7c01%7cSubhag.Oak%40microsoft.co
m%7ce3afffee29214d22271b08d2cb4ba500%7c72f988bf86f141af91ab2d7cd011db4
7%7c1=zlglwj67ATBpVFY9T1e%2fimuHvEXtjXw%2b3iEnskGpfZs%3d

If you run into any issues or have suggestions for new ones, please
open an issue or better yet, send us a pull request. We would
appreciate any feedback.

Subhag Oak
Senior Program Manager
TACO – Microsoft.

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org





--

*Frederico Galvão*

Diretor de Tecnologia

PontoGet Inovação Web


( +55(62)

Re: Will CPR BD be down?

[Gorkem Ercan]

Yes, the plan is to shut it down on Oct 15th. See the announcement in
http://cordova.apache.org/announcements/2015/04/21/plugins-release-and-move-to-npm.html

On 3 Jul 2015, at 11:24, Victor Sosa wrote:

With the move from CPR to NPM, will registry.cordova.io be down at 
some

point? My gut feeling is yes but wanted to confirm.

Thanks


-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: Best place to browse plugins

[Gorkem Ercan]

On 28 May 2015, at 19:41, Murat Sutunc wrote:

I had some free time today and started working on a plugin search 
prototype. Currently it doesn't offer much but it's very similar to 
what Gulp has.


GH: https://github.com/muratsu/cordova-plugin-search
Imgur (can't add images to mails :( ): http://imgur.com/sX8oFcJ

One problem I've run into is discoverability. Currently we're using 
the keyword `ecosystem:cordova` with all of the plugins. Ecosystem is 
a wider term than plugins and will most likely contain irrelevant 
search results.


It does, I use it and at least all the cordova-platforms appear on the 
results.



I was hoping that we switch to using `cordova-plugin` or 
`cordovaplugin` keyword going forward for better discoverability. Also 
for comparison, yeoman uses `yeoman-generator`, gulp uses `gulpplugin` 
and grunt uses `gruntplugin`. Thoughts?




+1.  I guess there is no way to add them for all the existing plugins 
though.




-Original Message-
From: Steven Gill [mailto:stevengil...@gmail.com]
Sent: Thursday, May 28, 2015 3:35 PM
To: dev@cordova.apache.org
Cc: Tommy-Carlos Williams
Subject: Re: Best place to browse plugins

npm does have a plan to improve their ecosystem + communities later 
this year. We will essentially get a portal for cordova on npmjs.


I also agree in turning plugins.cordova.io into a Gulp  Yeoman style 
search page. Probably won't be doing that until our current registry 
is shut down I imagine.


On Wed, May 27, 2015 at 7:42 AM, Kerri Shotts kerrisho...@gmail.com 
wrote:



+1

I've used both Gulp  Yeoman's search, and prefer both to NPM
(although it's not difficult to be better than NPM's search).

I also think close association with the brand and site are important.
For those users who don't know about Node  NPM yet, it's quickly
apparent that there's a large community creating plugins for Cordova,
and for everyone else, we have a URL that helps reinforce the Cordova
name. NPM would still be canonical, of course.

(Now if NPM improved their search and did some nice work around
ecosystems, perhaps the above wouldn't be necessary. But I'm not 
going

to hold my breath...)




On May 27, 2015 at 8:19:35 AM, Tommy-Carlos Williams
(to...@devgeeks.org)
wrote:

+1



On 26 May 2015, at 21:44, Carlos Santana csantan...@gmail.com 
wrote:


I would like to see plugin.cordova.io be a page easy to search and

filter

cordova plugins just like gulp [1], grunt [2], yeoman [3] and bower
[4]

[1]: http://gulpjs.com/plugins
[2]: http://gruntjs.com/plugins
[3]: http://yeoman.io/generators
[4]: http://bower.io/search



On Sat, May 2, 2015 at 3:57 PM Michael Brooks
mich...@michaelbrooks.ca
wrote:



The mirroring may not help for search, but my worry is that a lot
of

folks

would still be on 4.3.0 and when cordova plugins registry becomes
read only, they would not get bug fixes and other plugin updates.



My experience is this:

- A developer who is willing to upgrade a platform is also willing
to upgrading a plugin.
- A developer who is *not* willing to upgrade a platform is also
*not* willing in upgrading a plugin.

I think it's reasonable to offer a read-only state for the legacy
plugin registry. However, it would be helpful for the registry to
explain the minimum Cordova version required to support the npm 
registry.


Michael

On Fri, May 1, 2015 at 9:01 AM, Parashuram N (MS OPEN TECH) 
panar...@microsoft.com wrote:


The mirroring may not help for search, but my worry is that a lot
of

folks

would still be on 4.3.0 and when cordova plugins registry becomes
read only, they would not get bug fixes and other plugin updates.

-Original Message-
From: Victor Sosa [mailto:sosah.vic...@gmail.com]
Sent: Friday, May 1, 2015 8:59 AM
To: dev@cordova.apache.org
Subject: Re: Best place to browse plugins

I don't see a value on mirroring either. Instead I'd like to see a
good querying mechanism in NPM, but for that we have to wait :/

2015-05-01 10:55 GMT-05:00 Raymond Camden 
raymondcam...@gmail.com:



I don't know - if npm is the place, then having a mirror just
seems like noise. I'd say close it down and put a nice text
message up on the site explaining where it is at NPM and how to
search. (Link to npm with the search params included.)

Is there a benefit of having it mirrored?



On Fri, May 1, 2015 at 10:49 AM, Parashuram N (MS OPEN TECH)
panar...@microsoft.com wrote:

It would be even better (for backward compatibility reasons) if
we could

simply publish on npm, but keep plugins.cordova.io as a
mirror/redirector, based on the Cordova registry mapper.


-Original Message-
From: Gorkem Ercan [mailto:gorkem.er...@gmail.com]
Sent: Friday, May 1, 2015 8:31 AM
To: dev@cordova.apache.org
Subject: Re: Best place to browse plugins


What is the plan for plugins.cordova.io for after the CPR is 
closed?

Without knowing if there is a good way to retrieve the
list/details of

the cordova plugins from npm.
I would love it if we could keep it as it is with the data

Re: Also moving to a new team

[Gorkem Ercan]

Best of luck on your new project.
--
Gorkem

On 5 May 2015, at 11:15, Andrew Grieve wrote:

 As with Michal, you'll be seeing less of me around. My new full-time
 project will be on the Android port of Chrome.

 Just want to make it clear that us moving to new teams has nothing to do
 with a lack of faith in the project, but rather is due to needing a change
 of scenery and exciting new projects becoming available here.

 I'm super excited to see a new wave of committers joining the project! The
 momentum has certainly picked up:
 - Cordova-android 4.0.0 was huge
 - Plugins to npm was huge
 - Win10 and wkwebview will be massive launches as well!

 Great time for Cordova! (or a bad one... you know... if you're measuring
 against the goal of becoming obsolete :P)

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: Best place to browse plugins

[Gorkem Ercan]

What is the plan for plugins.cordova.io for after the CPR is closed?
Without knowing if there is a good way to retrieve the list/details of 
the cordova plugins from npm.

I would love it if we could keep it as it is with the data from npm.
--
Gorkem

On 29 Apr 2015, at 10:57, Raymond Camden wrote:

With plugins at npm now, what is the best place for users to browse 
plugins?


Is it at npm, using the search filter?
https://www.npmjs.com/browse/keyword/ecosystem:cordova

Is it plugins.cordova.io?

If it is npm, will there be text added to plugins.cordova.io to tell
folks to start using the npm site?

--
===
Raymond Camden, Developer Advocate for MobileFirst at IBM

Email : raymondcam...@gmail.com
Blog : www.raymondcamden.com
Twitter: raymondcamden

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: Apache Cordova 4 Programming book

[Gorkem Ercan]

Congratulations.
Thank you for including Eclipse Thym.
--
Gorkem

On 29 Apr 2015, at 7:26, John M. Wargo wrote:


Cordova Devs,

I wanted to let everyone know that Apache Cordova 4 Programming has 
been released and is available online: 
http://www.informit.com/store/apache-cordova-4-programming-9780134048192.


--
John M. Wargo
@johnwargo http://twitter.com/johnwargo
www.johnwargo.com http://www.johnwargo.com
--


-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: Question about plugin/platform --save: src vs version?

[Gorkem Ercan]

I am OK with spec.
I plan to review #202 today.
--
Gorkem

On 8 Apr 2015, at 5:12, Tim Barham wrote:

@gorkem - are you ok for this to be merged, or do you feel strongly we 
should stick with 'version'?


Thanks,

Tim

From: Tim Barham tim.bar...@microsoft.com
Sent: Tuesday, April 7, 2015 8:18 AM
To: dev@cordova.apache.org
Subject: Re: Question about plugin/platform --save: src vs version?

Thanks Jesse.

Well, according to semver standards, a bumped minor version means it 
is 100% backwards compatible, and I'm hoping semver at least complies 
with semver standards :). But I did look through all our uses of 
semver and everything seemed pretty basic - nothing to raise a concern 
with a minor version change.



From: Jesse purplecabb...@gmail.com
Sent: Tuesday, April 7, 2015 4:28 AM
To: dev@cordova.apache.org
Subject: Re: Question about plugin/platform --save: src vs version?

I'm okay with spec, the pr looks good.
Are there any side-effects updating the version of sem-ver?

@purplecabbage
risingj.com

On Mon, Apr 6, 2015 at 7:28 AM, Tim Barham tim.bar...@microsoft.com 
wrote:



Ok, so... Jesse's ok with 'spec', but prefers 'src'. Gorkem prefers
'version'. Glad we at least agree we need something :).

So, because I'd like to wrap this up and get this change in (in part
because along with this specific change I have a couple of fixes for
platform - save the version that was actually installed, and save it 
as a

tilde range), I've coded up all three.

When working on this, one benefit I found with using 'spec' was that 
I
think it makes the code clearer. That is, we have this value 'spec' 
that
can be a version or a source location, rather than a value 'version' 
that
actually might not be a version, or 'src' that actually might be a 
version.
I think that has the potential to get confusing quickly. Anyway, 
primarily

as a result of that, I created the PR for the change with the 'spec'
attribute [1]. But I also have branches for the 'version' [2] and 
'src' [3]

attributes.

Note that for clarity I've renamed variables as appropriate in the 
places

where I'm making the immediate change (version -- spec or src, for
example), but to keep the change as simple as possible, I haven't 
renamed
various secondary locations that get called by this code (like 
lazy_load,

for example).

[1] https://github.com/apache/cordova-lib/pull/202
[2]
https://github.com/apache/cordova-lib/compare/master...MSOpenTech:CB-8799-version
[3]
https://github.com/apache/cordova-lib/compare/master...MSOpenTech:CB-8799-src

Thanks,

Tim


From: Jesse purplecabb...@gmail.com
Sent: Thursday, April 2, 2015 7:01 AM
To: dev@cordova.apache.org
Subject: Re: Question about plugin/platform --save: src vs version?

I'm ok with 'spec'
However; I had always thought we would jam the new single attribute
into 'src' which is much more generic than 'version', and I think is
still close enough in meaning.

I have been looking at this more from the perspective of added
plugins, but I think even the engine tag having a src=^1.2.3 makes
sense.  It just means it comes from the 'default' location, at that
particular version.


On Apr 1, 2015, at 6:43 AM, Tim Barham tim.bar...@microsoft.com 
wrote:


Ahh.. the stages of config.xml discussions. Starts with rename 
things
continues to rename more and usually ends with let's change to 
JSON

:)


How boring would life be without constantly renaming things to give 
the

impression of progress? :)


It looks like single attribute is preferred, so instead of trying 
to

find a word that can mean source and version, we should settle on
version and change it for plugin.


I could live with that, however I have one final suggestion which
personally I'd much prefer (because I still cringe when I see the 
version
attribute with a filename or URL as its value)... I won't cry myself 
to
sleep if I can't get agreement on it, but I think it is where I'd 
cast my
vote... Npm internally uses the term spec for this value, and I 
think
that works pretty well - it's general enough to cover both scenarios, 
while

conveying the right sense:


engine name=windows spec=

https://github.com/apache/cordova-windows/tarball/master; /

engine name=windows spec=^1.2.3 /

Tim


From: Gorkem Ercan [gorkem.er...@gmail.com]
Sent: Wednesday, April 01, 2015 3:59 AM
To: dev@cordova.apache.org
Subject: Re: Question about plugin/platform --save: src vs version?


On 31 Mar 2015, at 8:44, Tim Barham wrote:

So... I agree that:

a) if we don't find it in the specified location, we should fail, 
and
b) storing the version is really superfluous when a source location 
is

specified (since we're gonna grab whatever is at the specified
location regardless of version).

And particularly since one of our goals with this was to move 
towards
being more npm'ish - 'npm install' doesn't save

Re: Question about plugin/platform --save: src vs version?

[Gorkem Ercan]

On 31 Mar 2015, at 8:44, Tim Barham wrote:


So... I agree that:

a) if we don't find it in the specified location, we should fail, and
b) storing the version is really superfluous when a source location is 
specified (since we're gonna grab whatever is at the specified 
location regardless of version).


And particularly since one of our goals with this was to move towards 
being more npm'ish - 'npm install' doesn't save the version when you 
specify a source location. For example:


 dependencies: {
 semver: https://github.com/npm/node-semver/tarball/master;
 }

Jesse - are you suggesting that rather than having a name and a 
?version attribute, we instead store them in a single attribute, 
something like the following?


 engine param=windows@^1.2.3  /
 engine param=windows@http://myplatforms/cordova-windows.tgz; /

(I'm not actually suggesting param BTW - just something for the sake 
of example)


That's a possibility, though it makes it harder to quickly look up 
something by name (that is, simply find the element that has a 'name' 
attribute that matches). So I'd prefer to keep the name ad the other 
bit in separate attributes, but use the same attribute name whether 
we're storing version or source. That, we go with:


 engine name=windows 
xxx=https://github.com/apache/cordova-windows/tarball/master; /

 engine name=windows xxx=^1.2.3 /

But where xxx is something other than version or src (something 
that works for both types of value). Any suggestions? Only thing that 
comes to my mind right now is at (because of the @):


 engine name=windows 
at=https://github.com/apache/cordova-windows/tarball/master; /

 engine name=windows at=^1.2.3 /

Any better ideas?


Ahh.. the stages of config.xml discussions. Starts with rename things 
continues to rename more and usually ends with let's change to JSON 
:)


It looks like single attribute is preferred, so instead of trying to 
find a word that can mean source and version, we should settle on 
version and change it for plugin.




Thanks!

Tim


From: Jesse [purplecabb...@gmail.com]
Sent: Tuesday, March 31, 2015 3:53 PM
To: dev@cordova.apache.org
Subject: Re: Question about plugin/platform --save: src vs version?

I agree with Andrew, fail loudly if we cannot find it.
And, jam all this into 1 attribute which may or may not have a version 
( or

a tag? )
Essentially just store whatever the parameter to 'cordova plugin add' 
was.







@purplecabbage
risingj.com

On Mon, Mar 30, 2015 at 5:36 PM, Andrew Grieve agri...@chromium.org 
wrote:


I don't think we'd want to try a fallback in this case. Better to 
fail

loudly if the plugin can't be found where it's expected to be.

I think since NPM uses only a single field (although theirs isn't 
labeled),

we should do likewise. Don't feel strongly about it though.

On Mon, Mar 30, 2015 at 4:04 PM, Edna Y Morales eymor...@us.ibm.com
wrote:

It could make sense to store both for the case where restoring from 
src
fails. For example, if the path to a local folder no longer exists, 
what

do
you use to restore? In that case you could use the version as a 
fallback?


Thanks,
Edna Morales

[image: Inactive hide details for Gorkem Ercan ---03/30/2015 
10:45:03

AM--- On 29 Mar 2015, at 23:11, Tim Barham wrote:]Gorkem Ercan
---03/30/2015 10:45:03 AM---On 29 Mar 2015, at 23:11, Tim Barham

wrote:


From: Gorkem Ercan gorkem.er...@gmail.com
To: dev ‎[dev@cordova.apache.org]‎ dev@cordova.apache.org
Date: 03/30/2015 10:45 AM
Subject: Re: Question about plugin/platform --save: src vs version?
--





On 29 Mar 2015, at 23:11, Tim Barham wrote:


Hi - I'm looking for input on this issue: For the plugin/platform
--save feature, there's currently an inconsistency between how we
store the information in config.xml for platforms vs plugins.



For platforms, we have a 'version' attribute where we store either 
the

source location or the version: if the platform was added by
specifying a specific location (git repository, local folder, 
package

file etc), we store that in the 'version' attribute. Otherwise we
store the actual version.



For plugins, these two values are stored separately - source 
location

in the 'src' attribute and version in the 'version' attribute. Note
however that when we restore a plugin, we ignore the 'version'
attribute if there is a 'src' attribute.


This comes from the history of the implementation ( as these things 
do).

In the old experimental save implementation, we had 3 parameters,
namely, version, url and installPath, and for every plugin we 
expected

one of them to exist. During the effort for npmizing the save
functionality the contribution for platforms and plugins were done
separately hence the unmatching attributes. So there is no real
technical reason for doing one way or the other and if you are 
willing

to unify them that is fantastic.




I'd like to make these consistent. My first thought

Re: Question about plugin/platform --save: src vs version?

[Gorkem Ercan]

On 29 Mar 2015, at 23:11, Tim Barham wrote:

Hi - I'm looking for input on this issue: For the plugin/platform 
--save feature, there's currently an inconsistency between how we 
store the information in config.xml for platforms vs plugins.




For platforms, we have a 'version' attribute where we store either the 
source location or the version: if the platform was added by 
specifying a specific location (git repository, local folder, package 
file etc), we store that in the 'version' attribute. Otherwise we 
store the actual version.




For plugins, these two values are stored separately - source location 
in the 'src' attribute and version in the 'version' attribute. Note 
however that when we restore a plugin, we ignore the 'version' 
attribute if there is a 'src' attribute.



This comes from the history of the implementation ( as these things do). 
In the old experimental save implementation, we had 3 parameters, 
namely, version, url and installPath, and for every plugin we expected 
one of them to exist. During the effort for npmizing the save 
functionality the contribution for platforms and plugins were done 
separately hence the unmatching attributes. So there is no real 
technical reason for doing one way or the other and if you are willing 
to unify them that is fantastic.





I'd like to make these consistent. My first thought was to support 
'version' and 'src' for platforms like we currently do for plugins. 
But since we always ignore the version if we have a src, I'm not sure 
we actually gain anything by doing that. Storing them in different 
attributes is perhaps clearer, but storing both implies we make use of 
both, which we don't. Also, the code ends up being simpler overall if 
we just store whichever we care about in the version attribute.




I personally prefer to clearly label data in case user needs to 
read/modify the config.xml, seeing a git url on the version attribute 
still puzzles me. But I am fine with either way. Whatever you decide 
please remember to support/migrate the current attributes so that we do 
not end up with stale entries on config.xml





Any thoughts either way?



Thanks!



Tim


-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: 'cordova plugin save' should also save plugin versions

[Gorkem Ercan]

On 24 Mar 2015, at 18:38, Tim Barham wrote:

+1 from me too (always save version, and allow automatic minor version 
upgrades).


I like Andrew's idea, my only concern is implementing only a portion of 
the semver syntax. I personally would assume full semver support after 
seeing ^1.2.3 notation on config.xml


Gorkem - I'm currently doing some work in this area - I'm happy to 
make this change while I'm there.



Sure, go ahead. I would not be able to get to it until next week.



From: Steven Gill [stevengil...@gmail.com]
Sent: Wednesday, March 25, 2015 7:20 AM
To: dev@cordova.apache.org
Subject: Re: 'cordova plugin save' should also save plugin versions

Definitely agree with alignment with npm's save! :D

On Tue, Mar 24, 2015 at 1:46 PM, Nikhil Khandelwal 
nikhi...@microsoft.com

wrote:


I'm in favor of alignment of 'plugin save' behavior with npm's as we
expect developers to already familiar with that and in future, we 
plan to

move to npm.

I liked Andrew's idea of adding a specific version with allowing 
minor

version upgrades to be automatic.

As for shrink wrapping, for npm this means locking down the version
numbers of all modules and their dependencies:
https://docs.npmjs.com/cli/shrinkwrap . It does not look our 
--shrinkwrap

option does that.

-Nikhil

-Original Message-
From: So, Byoungro [mailto:byoungro...@intel.com]
Sent: Tuesday, March 24, 2015 12:40 PM
To: dev@cordova.apache.org
Subject: Re: 'cordova plugin save' should also save plugin versions

+1 for making the shrinkwrap as the default for the save.
This makes sure the users will restore the same version they saved 
before.


Byoungro So
SSG / DPD / Mobile Computing and Compilers Intel Corporation






On 3/24/15, 12:31 PM, Gorkem Ercan gorkem.er...@gmail.com wrote:



I think the problem here is shrinkwrap behaviour is the expected
because platforms behave that way. I guess we could just make
shrinkwrap default and change the flag to --noshrinkwrap.
--
Gorkem

On 24 Mar 2015, at 13:58, Andrew Grieve wrote:


On Tue, Mar 24, 2015 at 11:49 AM, Gorkem Ercan
gorkem.er...@gmail.com
wrote:


They are related but not same.

CB-8594 asks to save the plugin version information during 
cordova

plugin add --save. Right now we do not save version unless the
command is cordova plugin add --save --shrinkwrap. This 
behaviour

allows plugins to be restored to the latest possible version
available if they are not explicitly shrinkwrapped.



How about doing what npm does, and always save the version, but 
save
it as ^1.0.3, so that you still get updates, but not major 
version

changes?





As for CB-8733, cordova plugin save command can not save the
version information even if it had wanted to because fetch.json is
missing that information. It is a bug.
--
Gorkem

On Tue, Mar 24, 2015 at 11:29 AM, Raymond Camden
raymondcam...@gmail.com
wrote:


Is that a dupe of https://issues.apache.org/jira/browse/CB-8594?

On Tue, Mar 24, 2015 at 10:19 AM, Edna Y Morales
eymor...@us.ibm.com
wrote:



Currently, version info is not saved for plugins in the 
fetch.json.

That

needs to be added so that plugin version can be saved in the

config.xml.

It
should follow what 'cordova platform save' does. I created a 
jira

item

for

this: https://issues.apache.org/jira/browse/CB-8733 and opened a
pull
request: https://github.com/apache/cordova-lib/pull/189. If
someone

could

review it and provide any feedback.

Thanks,
Edna Morales




--



=
===
===

Raymond Camden, Developer Advocate for MobileFirst at IBM

Email : raymondcam...@gmail.com
Blog : www.raymondcamden.com
Twitter: raymondcamden

---
-- To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org






-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: 'cordova plugin save' should also save plugin versions

[Gorkem Ercan]

They are related but not same.

CB-8594 asks to save the plugin version information during cordova plugin
add --save. Right now we do not save version unless the command is
cordova plugin add --save --shrinkwrap. This behaviour allows plugins to
be restored to the latest possible version available if they are not
explicitly shrinkwrapped.

As for CB-8733, cordova plugin save command can not save the version
information even if it had wanted to because fetch.json is missing that
information. It is a bug.
--
Gorkem

On Tue, Mar 24, 2015 at 11:29 AM, Raymond Camden raymondcam...@gmail.com
wrote:

 Is that a dupe of https://issues.apache.org/jira/browse/CB-8594?

 On Tue, Mar 24, 2015 at 10:19 AM, Edna Y Morales eymor...@us.ibm.com
 wrote:
 
 
  Currently, version info is not saved for plugins in the fetch.json. That
  needs to be added so that plugin version can be saved in the config.xml.
 It
  should follow what 'cordova platform save' does. I created a jira item
 for
  this: https://issues.apache.org/jira/browse/CB-8733 and opened a pull
  request: https://github.com/apache/cordova-lib/pull/189. If someone
 could
  review it and provide any feedback.
 
  Thanks,
  Edna Morales



 --
 ===
 Raymond Camden, Developer Advocate for MobileFirst at IBM

 Email : raymondcam...@gmail.com
 Blog : www.raymondcamden.com
 Twitter: raymondcamden

 -
 To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
 For additional commands, e-mail: dev-h...@cordova.apache.org

Re: 'cordova plugin save' should also save plugin versions

[Gorkem Ercan]

I think the problem here is shrinkwrap behaviour is the expected because
platforms behave that way. I guess we could just make shrinkwrap default
and change the flag to --noshrinkwrap.
--
Gorkem

On 24 Mar 2015, at 13:58, Andrew Grieve wrote:

On Tue, Mar 24, 2015 at 11:49 AM, Gorkem Ercan 
gorkem.er...@gmail.com

wrote:


They are related but not same.

CB-8594 asks to save the plugin version information during cordova 
plugin

add --save. Right now we do not save version unless the command is
cordova plugin add --save --shrinkwrap. This behaviour allows 
plugins to

be restored to the latest possible version available if they are not
explicitly shrinkwrapped.



How about doing what npm does, and always save the version, but save 
it as
^1.0.3, so that you still get updates, but not major version 
changes?






As for CB-8733, cordova plugin save command can not save the 
version
information even if it had wanted to because fetch.json is missing 
that

information. It is a bug.
--
Gorkem

On Tue, Mar 24, 2015 at 11:29 AM, Raymond Camden 
raymondcam...@gmail.com

wrote:


Is that a dupe of https://issues.apache.org/jira/browse/CB-8594?

On Tue, Mar 24, 2015 at 10:19 AM, Edna Y Morales 
eymor...@us.ibm.com

wrote:



Currently, version info is not saved for plugins in the fetch.json.

That

needs to be added so that plugin version can be saved in the

config.xml.

It
should follow what 'cordova platform save' does. I created a jira 
item

for
this: https://issues.apache.org/jira/browse/CB-8733 and opened a 
pull

request: https://github.com/apache/cordova-lib/pull/189. If someone

could

review it and provide any feedback.

Thanks,
Edna Morales




--


===

Raymond Camden, Developer Advocate for MobileFirst at IBM

Email : raymondcam...@gmail.com
Blog : www.raymondcamden.com
Twitter: raymondcamden

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org






-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: App Hello World with default plugin (plus status update)

[Gorkem Ercan]

On 20 Mar 2015, at 14:46, Andrew Grieve wrote:

First: just committed a change to add the whitelist plugin to the 
default

app template:

https://git1-us-west.apache.org/repos/asf?p=cordova-app-hello-world.git;a=commit;h=2e856b845a0134e7056bdc74f89cafcf483a379f

Perhaps a bit strange if projects don't use iOS / Android, but I'm not 
sure

there's a good alternative.


Second: Seems there were some started tasks that have fallen silent:

- Publishing app-hello-world to NPM (Steve - vote passed?)
- CLI (so that it obeys plugin within config.xml, and so that it can 
get

plugins from npm)


This is just waiting for a release.
The master of cordova-lib now works with plugin on config.xml. It 
still retains the ability to use feature tags but prints a warning 
about them. All new information is added as plugin tags.



Would like both of these things to happen (plus another 
app-hello-world

release to pick up change), so that:
- We can publish cordova-plugin-whitelist to NPM
- We can ship android@4.0


-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Deprecating the feature tag

[Gorkem Ercan]

I am about to deprecate the old feature tag use for saving plugin
information in favour of plugin tag. I have a PR[1] that I hope to soon
merge. The changes are backward compatible,  old feature syntax will
still be respected for read and remove operations but all new entries
will be done with the new syntax. Please review the changes and let me
know if you have any concerns, use cases that I am not aware of.

As a note, this change does not effect the feature tags that are
created on platform specific config.xml files. Platforms will still be
using the legacy feature tag.

[1] https://github.com/apache/cordova-lib/pull/182

--
Gorkem

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: Deprecating the feature tag

[Gorkem Ercan]

Here is an example

 plugin name=com.phonegap.plugins.facebookconnect
variable name=APP_ID value=someID /
variable name=APP_NAME value=valueee /
  /plugin


On 9 Mar 2015, at 19:22, Mefire O. wrote:


How do you specify variables with the new syntax ?

Thanks,
Mefire

-Original Message-
From: mmo...@google.com [mailto:mmo...@google.com] On Behalf Of Michal 
Mocny

Sent: Monday, March 9, 2015 2:50 PM
To: dev
Subject: Re: Deprecating the feature tag

Haven't looked at a patch, but +1 to plugin over feature

On Mon, Mar 9, 2015 at 4:41 PM, Gorkem Ercan gorkem.er...@gmail.com 
wrote:




I am about to deprecate the old feature tag use for saving plugin
information in favour of plugin tag. I have a PR[1] that I hope to
soon merge. The changes are backward compatible,  old feature syntax
will still be respected for read and remove operations but all new
entries will be done with the new syntax. Please review the changes
and let me know if you have any concerns, use cases that I am not 
aware of.


As a note, this change does not effect the feature tags that are
created on platform specific config.xml files. Platforms will still 
be

using the legacy feature tag.

[1] https://github.com/apache/cordova-lib/pull/182

--
Gorkem

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: Some thoughts/questions on the new --save feature

[Gorkem Ercan]

On 5 Mar 2015, at 12:01, Raymond Camden wrote:


just one way of doing things

This confuses me though. It seemed as if this new config (I mean new
to me) was a way to configure the CLI. Is there another way to
configure the CLI? With the example that was given (default to auto
save) being a preference for the tooling - can we accomplish that
another way?



That is the only way to enable auto save.
That preference is originally added for IDEs, build servers etc. that 
use CLI.
However I think it does provide a more natural flow at least for me. If 
we think we do not like config.json
then we should think about a more acceptable way to enable that 
functionality.


On Thu, Mar 5, 2015 at 10:50 AM, Andrew Grieve agri...@chromium.org 
wrote:
I don't think they are documented. There's really no settings in 
there
(besides this one) that anyone would ever need to use. So this would 
be the
time to add docs. However, I do think we should try and promote just 
one
way of doing things before branching pointing out there are hidden 
knobs.


On Thu, Mar 5, 2015 at 11:31 AM, Raymond Camden 
raymondcam...@gmail.com

wrote:


Heh, ok, so how about - for the typical Cordova user.

And I'd still like to know where/if the settings for this file are
documented?

On Thu, Mar 5, 2015 at 10:24 AM, Michal Mocny mmo...@chromium.org 
wrote:

Consensus is a strong word ;)

On Thu, Mar 5, 2015 at 11:02 AM, Raymond Camden 
raymondcam...@gmail.com


wrote:


Hmm. Ok... so... is there a consensus to *not* promote it?

On Thu, Mar 5, 2015 at 9:24 AM, Gorkem Ercan 
gorkem.er...@gmail.com

wrote:
config.son is not created by CLI by default anymore. You need to 
do

create

the file and add the key.
--
Gorkem


On 5 Mar 2015, at 7:33, Raymond Camden wrote:

Sorry - what file? I don't have that in my project. If you meant 
user

root, I don't have it there either.

On Tue, Mar 3, 2015 at 12:14 PM, Gorkem Ercan 

gorkem.er...@gmail.com

wrote:



You can enable auto save by adding auto_save_plugins to be true 
on

the

.cordova/config.json file. I think this helps with the case 1
--
Gorkem



On 3 Mar 2015, at 9:27, Raymond Camden wrote:

1) Is there any reason why --save isn't true by default? It 
would

seem

that in a majority of cases I'd want to save my plugins to the
configuration file. I definitely see times when I would *not* 
want

to

do so, but it seems like that would be the minority of cases.

2) This is probably an edge case, but...

One of the things I do when building Cordova examples is put 
up my

www
folder in a repo. My thinking is that my readers can grab the 
repo,
and then make a new project and use --copy-from to grab the 
folder.

This gives them my www crap and lets them go crazy.

For plugins, I've been using a readme file to tell users what 
to

do.


I'd like to make use of this new feature to persist plugins 
and

save
users at least one step. (In theory they would just need to 
add the

platform they want to test on.)

But in order to do so, I can't just ship the www folder, I 
have to
ship an entire Cordova project. That isn't a big deal per se, 
but

it

does mean they would need to copy a folder manually, possibly

modify

the app id, and then start working on the assets.

Given that I think my use case is probably pretty minor, is 
there

some
thought as to how one could distribute sample code and make 
use of

this feature?



--






===

Raymond Camden, Developer Advocate for MobileFirst at IBM

Email : raymondcam...@gmail.com
Blog : www.raymondcamden.com
Twitter: raymondcamden



-

To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org






-

To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org





--





===

Raymond Camden, Developer Advocate for MobileFirst at IBM

Email : raymondcam...@gmail.com
Blog : www.raymondcamden.com
Twitter: raymondcamden

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org





--


===

Raymond Camden, Developer Advocate for MobileFirst at IBM

Email : raymondcam...@gmail.com
Blog : www.raymondcamden.com
Twitter: raymondcamden

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org

Re: Some thoughts/questions on the new --save feature

[Gorkem Ercan]

config.son is not created by CLI by default anymore. You need to do 
create the file and add the key.

--
Gorkem

On 5 Mar 2015, at 7:33, Raymond Camden wrote:


Sorry - what file? I don't have that in my project. If you meant user
root, I don't have it there either.

On Tue, Mar 3, 2015 at 12:14 PM, Gorkem Ercan gorkem.er...@gmail.com 
wrote:


You can enable auto save by adding auto_save_plugins to be true on 
the

.cordova/config.json file. I think this helps with the case 1
--
Gorkem



On 3 Mar 2015, at 9:27, Raymond Camden wrote:

1) Is there any reason why --save isn't true by default? It would 
seem

that in a majority of cases I'd want to save my plugins to the
configuration file. I definitely see times when I would *not* want 
to

do so, but it seems like that would be the minority of cases.

2) This is probably an edge case, but...

One of the things I do when building Cordova examples is put up my 
www

folder in a repo. My thinking is that my readers can grab the repo,
and then make a new project and use --copy-from to grab the folder.
This gives them my www crap and lets them go crazy.

For plugins, I've been using a readme file to tell users what to do.

I'd like to make use of this new feature to persist plugins and save
users at least one step. (In theory they would just need to add the
platform they want to test on.)

But in order to do so, I can't just ship the www folder, I have to
ship an entire Cordova project. That isn't a big deal per se, but it
does mean they would need to copy a folder manually, possibly modify
the app id, and then start working on the assets.

Given that I think my use case is probably pretty minor, is there 
some

thought as to how one could distribute sample code and make use of
this feature?



--

===
Raymond Camden, Developer Advocate for MobileFirst at IBM

Email : raymondcam...@gmail.com
Blog : www.raymondcamden.com
Twitter: raymondcamden

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org





--
===
Raymond Camden, Developer Advocate for MobileFirst at IBM

Email : raymondcam...@gmail.com
Blog : www.raymondcamden.com
Twitter: raymondcamden

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: plugin install using old version with cordova 4.2

[Gorkem Ercan]

Do you have a version number specified on your config.xml for your 
plugin? Have you used the --save switch earlier for instance?

--
Gorkem

On 4 Mar 2015, at 23:22, Don Coleman wrote:


I published a new version of my plugin
http://plugins.cordova.io/#/package/com.megster.cordova.ble, but my 
local

machine keeps installing the old 0.1.3 version.

$ cordova -d plugin add com.megster.cordova.ble
Calling plugman.fetch on plugin com.megster.cordova.ble
Fetching plugin com.megster.cordova.ble via plugin registry
Copying plugin
/Users/don/.plugman/cache/com.megster.cordova.ble/0.1.3/package ...

cordova 4.2.0
plugman 0.23.0

If I upgrade to Cordova 4.3.0, the newer 0.1.4 version of the plugin 
is

installed
  npm install -g cordova
  cordova plugin rm com.megster.cordova.ble
  cordova plugin add com.megster.cordova.ble

If I downgrade back to Cordova 4.2.0, the older 0.1.3 version is 
installed

again
  cordova plugin rm com.megster.cordova.ble
  npm install -g cordova@4.2.0
  cordova plugin add com.megster.cordova.ble

I don't understand why this is happening. Any ideas why or how to fix 
it?


-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: Some thoughts/questions on the new --save feature

[Gorkem Ercan]

You can enable auto save by adding auto_save_plugins to be true on the 
.cordova/config.json file. I think this helps with the case 1

--
Gorkem


On 3 Mar 2015, at 9:27, Raymond Camden wrote:


1) Is there any reason why --save isn't true by default? It would seem
that in a majority of cases I'd want to save my plugins to the
configuration file. I definitely see times when I would *not* want to
do so, but it seems like that would be the minority of cases.

2) This is probably an edge case, but...

One of the things I do when building Cordova examples is put up my www
folder in a repo. My thinking is that my readers can grab the repo,
and then make a new project and use --copy-from to grab the folder.
This gives them my www crap and lets them go crazy.

For plugins, I've been using a readme file to tell users what to do.

I'd like to make use of this new feature to persist plugins and save
users at least one step. (In theory they would just need to add the
platform they want to test on.)

But in order to do so, I can't just ship the www folder, I have to
ship an entire Cordova project. That isn't a big deal per se, but it
does mean they would need to copy a folder manually, possibly modify
the app id, and then start working on the assets.

Given that I think my use case is probably pretty minor, is there some
thought as to how one could distribute sample code and make use of
this feature?



--
===
Raymond Camden, Developer Advocate for MobileFirst at IBM

Email : raymondcam...@gmail.com
Blog : www.raymondcamden.com
Twitter: raymondcamden

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [REVIEW] Tools Release Blog Post

[Gorkem Ercan]

On 27 Feb 2015, at 21:16, Michal Mocny wrote:


Looks good.  Few comments:

- You can manage plugin and platform versions using the --save 
command =
You can now save your list of installed plugins and platforms using 
the

--save command.


Should we also add Saved platforms and plugins are automagically 
restored during prepare



- (I don't think --save actually helps with management of versions)
- We are going to be doing a blog post soon about transitioning 
plugins to
npm = We are preparing to transition our plugin hosting over to 
npm.  We

will be doing a detailed blog post soon, stay tuned.

- I think cordova-lib needs a better README.md..
- I don't mind the long list of changes, but some people like to keep 
only

the important changes..

On Fri, Feb 27, 2015 at 8:30 PM, Steven Gill stevengil...@gmail.com 
wrote:



Still have some formatting to do of the changes.


https://github.com/cordova/apache-blog-posts/blob/master/2015-03-02-tools-release.md

Any other highlights I should mention?



-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [Vote] Tools Release February 27, 2015

[Gorkem Ercan]

On 27 Feb 2015, at 22:19, Mefire O. wrote:

I've spent some time testing, found two bugs and I vote -1 until we 
address those :

- https://issues.apache.org/jira/browse/CB-8577


I do not think this is a show stopper, probably not even a bug, I have 
not had time to change the old feature tags. Actually, it will make 
the migration harder if we fix it now.



- https://issues.apache.org/jira/browse/CB-8578
No idea about this one. I am still trying to figure out why this feature 
even exists.




I should be able to send pull requests to fix them shortly.

Thanks,
Mefire

-Original Message-
From: Mefire O. [mailto:ommen...@microsoft.com]
Sent: Friday, February 27, 2015 3:53 PM
To: dev@cordova.apache.org
Subject: RE: [Vote] Tools Release February 27, 2015

Steven, Thanks for initiating this.
I'll be performing some tests/checks and will then cast my vote 
accordingly.


Thanks,
Mefire

-Original Message-
From: Steven Gill [mailto:stevengil...@gmail.com]
Sent: Friday, February 27, 2015 1:21 PM
To: dev@cordova.apache.org
Subject: [Vote] Tools Release February 27, 2015

Please review and vote on this Tools Release.

Release issue: https://issues.apache.org/jira/browse/CB-8555

All the tools have been published to
dist/dev:https://dist.apache.org/repos/dist/dev/cordova/CB-8555/

All the tools have also been published to npm under the rc tag.
Feel free to test them with npm install -g cordova@rc

The packages were published from their corresponding git tags:

 cordova-js: 3.8.0 (5934b1b744)
 cordova-lib: 4.3.0 (c4fbb6a3e1)
 cordova-plugman: 0.23.0 (6ec4d1d006)
 cordova-cli: 4.3.0 (f0fed4ad5c)


Upon a successful vote I will upload the archives to dist/, publish 
them to NPM, and post the corresponding blog post.


Voting guidelines:
https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md

Voting will go on for a minimum of 48 hours.

I vote +1:
* Ran coho audit-license-headers over the relevant repos
* Ran coho check-license to ensure all dependencies and 
subdependencies have Apache-compatible licenses
* Ran npm test and built a hello world android cordova project with 
device plugin


-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [Discuss] Tools Release

[Gorkem Ercan]

On 25 Feb 2015, at 15:10, Steven Gill wrote:

 Newly Pinned:
 Android 3.7.1
 ios 3.8.0
 windows 3.8.0

cordova platform/plugin --save 
and auto-restore for plugins and platforms are also in. 

 Pre-req: iOS and Windows need to be published to npm.

 Before voting finishes, iOS and Windows need to publish their release blog
 posts.

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Schedule for npm transition

[Gorkem Ercan]

Is there a determined calendar for the npm move of the plugins?
I think the scheduling of the transition is crucial for those who are 
using the plugin registry directly.

--
Gorkem

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: Schedule for npm transition

[Gorkem Ercan]

On 11 Feb 2015, at 13:09, Steven Gill wrote:


We don't have one yet but we should pick dates soon.

How about:

CPR Switch to read only: Monday, May 18th
NPM fetch becomes default: Monday, May 18th
CPR offline: Monday, August 17th


I was hoping for a longer read-only period, 6 months would be grand.
Unfortunately getting users to switch versions takes time.


Based on the following proposal:
https://docs.google.com/document/d/12WAXJa6jfY3BnNHGieK9QOqvZ6cl3OXmP-9DpYkcmfs/edit?usp=sharing

- Need to start educating plugin developers to publish to npm as well 
as

CPR for next three months. (blog post)
- Need to educate users to install plugins via new names (if 
package-name

is different than id). Our core plugins are being renamed from
org.apache.cordova.device to cordova-plugin-device
- Inform devs who are working with registry directly to pull plugins 
from
npm instead of CPR. After 3 months, CPR plugins will start to become 
out of

date compared to npm versions.

Our next plugins release (after the one currently ongoing) will be
published to npm as well as cpr.



On Wed, Feb 11, 2015 at 9:10 AM, Gorkem Ercan gorkem.er...@gmail.com
wrote:



Is there a determined calendar for the npm move of the plugins?
I think the scheduling of the transition is crucial for those who are
using the plugin registry directly.
--
Gorkem

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: Schedule for npm transition

[Gorkem Ercan]

On 11 Feb 2015, at 15:50, Michal Mocny wrote:

Leo, restore will still work.  The only information stored in the 
saves
list is a set of plugin ids (and versions?).  Restoring will go 
through the

steps Steve outlines above, and either download from CPR or be mapped
automatically to the npm equivalent.  After the deprecation cutoff, 
plugins
that aren't in the mapper may fail to restore -- so we could improve 
the


Any ideas what that mapper will look like? part of CLI, online service?


rollout plan by starting to warn users adding plugins that still fetch 
from

CPR.

-Michal

On Wed, Feb 11, 2015 at 2:58 PM, Treggiari, Leo 
leo.treggi...@intel.com

wrote:


The proposal contains suggestions, alternatives and comments.




https://docs.google.com/document/d/12WAXJa6jfY3BnNHGieK9QOqvZ6cl3OXmP-9DpYkcmfs/edit?usp=sharing

When will there be a final version that is the official plan?

One other question:  Soon we will have optional 'save' of plugin 
metadata
in config.xml.  When CPR is turned off, there will be saved metadata 
which
is no longer valid - i.e. a restore will fail.  This is because the 
'name'
used to fetch a plugin (cordova-plugin-device) as well as the 
location will
change.   Is there anything that can be done to mitigate that?  Is 
the name

change really necessary - why can't we stick with the current names?

Thanks,
Leo

-Original Message-
From: Steven Gill [mailto:stevengil...@gmail.com]
Sent: Wednesday, February 11, 2015 11:40 AM
To: dev@cordova.apache.org
Subject: Re: Schedule for npm transition

Correct! For the first 3 months, all requests will hit CPR first, if 
CPR

fails, we will try to fetch from npm.

If users run cordova plugin add cordova-plugin-device, it would hit 
CPR,

fail, go to npm, succeed.

If we use the mapper module, cordova plugin add
org.apache.cordova.device would be converted to 
cordova-plugin-device, hit

CPR, fail, go to npm, succeed.

After 3 months, cordova plugin add cordova-plugin-device would hit 
npm

first and succeed.

We want to use these 3 months to get our developers to update their 
tools

and use the new names for plugins to install.

On Wed, Feb 11, 2015 at 10:36 AM, Michal Mocny mmo...@chromium.org
wrote:

Steve, npm fetch default only affects plugins that use same name in 
both

places, right?

If we create cordova-plugin-device today, and tell users to start 
using

cordova plugin add cordova-plugin-device, then we will get much user
feedback on npm fetching far before May 18th, right?

On Wed, Feb 11, 2015 at 1:09 PM, Steven Gill 
stevengil...@gmail.com

wrote:


We don't have one yet but we should pick dates soon.

How about:

CPR Switch to read only: Monday, May 18th
NPM fetch becomes default: Monday, May 18th
CPR offline: Monday, August 17th

Based on the following proposal:





https://docs.google.com/document/d/12WAXJa6jfY3BnNHGieK9QOqvZ6cl3OXmP-9DpYkcmfs/edit?usp=sharing


- Need to start educating plugin developers to publish to npm as 
well

as

CPR for next three months. (blog post)
- Need to educate users to install plugins via new names (if

package-name

is different than id). Our core plugins are being renamed from
org.apache.cordova.device to cordova-plugin-device
- Inform devs who are working with registry directly to pull 
plugins

from
npm instead of CPR. After 3 months, CPR plugins will start to 
become

out

of

date compared to npm versions.

Our next plugins release (after the one currently ongoing) will be
published to npm as well as cpr.



On Wed, Feb 11, 2015 at 9:10 AM, Gorkem Ercan 
gorkem.er...@gmail.com

wrote:



Is there a determined calendar for the npm move of the plugins?
I think the scheduling of the transition is crucial for those who 
are

using the plugin registry directly.
--
Gorkem

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org








-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: Plugin management ?

[Gorkem Ercan]

We have cordova save plugins and cordova restore plugins commmands that 
saves/restores from config.xml [1]. They are considered experimental but 
we are in the process of moving the functionality to their permanent 
locations.


[1] 
http://www.gorkem-ercan.com/2014/06/sharing-cordova-projects-becomes-easier.html


On 22 Jan 2015, at 5:36, Stéphane Wirtel wrote:


Hi all,

In my project, I use a lot of plugins.

So, is there a small tool or a config file where I can specify my 
dependencies (plugins) and just with a command line, install all my 
plugins ?


I think to grunt (Gruntfile.js), bower (bower.json) and npm 
(package.json)


Thank you,

Stephane
--
Stéphane Wirtel - http://wirtel.be - @matrixise

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: platforms/plugins save and restore from config.xml

[Gorkem Ercan]

The proposal(s) seems to only cover the platforms. Although the 
behaviours are very similar there will be details that should be 
addressed. For instance how to handle the search path for plugins

--
Gorkem

On 15 Jan 2015, at 19:33, Mefire O. wrote:

After  some suggestions to instead move to autosaving to config.xml, 
I've made modifications the document :  It now includes two proposals 
: --save vs autosave


Please review and make suggestions : 
https://docs.google.com/document/d/1qKjhzSf48ybGg2GFZPtjXP8dkF4Z5Jnc7FU41V3-jFc/edit



Thanks,
Mefire

-Original Message-
From: Mefire O. [mailto:ommen...@microsoft.com]
Sent: Wednesday, January 14, 2015 4:44 PM
To: dev@cordova.apache.org
Subject: RE: platforms/plugins save and restore from config.xml

All,
I have incorporated feedback into the Google docs as suggested by 
others. Please, cast another look.
For reviews/ comments/suggestions, please take a look at :  
https://docs.google.com/document/d/1qKjhzSf48ybGg2GFZPtjXP8dkF4Z5Jnc7FU41V3-jFc/edit


It seems to me like most people agree with the proposed behavior of 
--save. So, could anyone please review these pull requests that 
include that functionality ? :

- https://github.com/apache/cordova-lib/pull/144
- https://github.com/apache/cordova-cli/pull/203

Also, we have another related pull request that introduce git urls 
support to 'cordova platform add' :

- https://github.com/apache/cordova-lib/pull/148

Thanks for all the feedback so far !
I'll be creating JIRA issues for all the suggestions (those that have 
been agreed on). And start working on some of them...



Thanks,
Mefire


-Original Message-
From: Chuck Lantz [mailto:cla...@microsoft.com]
Sent: Wednesday, January 14, 2015 1:15 PM
To: dev@cordova.apache.org
Subject: RE: platforms/plugins save and restore from config.xml

For those joining the thread late - Here's the Google doc link that's 
trying to consolidate the conversation: 
https://docs.google.com/document/d/1qKjhzSf48ybGg2GFZPtjXP8dkF4Z5Jnc7FU41V3-jFc/edit


-Chuck

-Original Message-
From: Chuck Lantz [mailto:cla...@microsoft.com]
Sent: Wednesday, January 14, 2015 1:11 PM
To: dev@cordova.apache.org
Subject: RE: platforms/plugins save and restore from config.xml

You may also want to mention you tried to factor this conversation 
into the google doc and repoint them to it once you're done editing.


Before you do that, I'd also add our proposed plugin syntax in that 
section before you send it out.  Maybe use strikethrough on the XML 
section with the feature elements and add the plugin id=... 
syntax below it.


-Chuck

-Original Message-
From: Mefire O. [mailto:ommen...@microsoft.com]
Sent: Tuesday, January 13, 2015 4:12 PM
To: dev@cordova.apache.org
Subject: RE: platforms/plugins save and restore from config.xml

This PR adds support for git-urls to 'cordova platform add' : 
https://github.com/apache/cordova-lib/pull/148

Please, review.

Thanks,
Mefire

-Original Message-
From: Treggiari, Leo [mailto:leo.treggi...@intel.com]
Sent: Tuesday, January 13, 2015 8:18 AM
To: dev@cordova.apache.org
Subject: RE: platforms/plugins save and restore from config.xml

I agree with always saving and automatically re-fetching sources and 
platforms when needed.  With regards to the other conversation going 
on re: automatic add of a platform, I think the CLI should 
automatically do things when it is reasonably unambiguous what the 
user wants - e.g. if they explicitly say build for iOS then CLI adds 
the platform if it is needed.  If you are on Windows and you say build 
for iOS, you get an error, which you would even if CLI had allowed you 
to add the platform - e.g. for a cross platform, multi-developer 
scenario.


If save/restore are 'optional', then as others have pointed out, other 
problems cannot be solved unless the user has used the save and 
restore command/options.  I don't want my IDE to be saying:  didn't I 
tell you that you need to use the save/restore command options if you 
want to do any operations outside of the IDE!.


Leo

-Original Message-
From: agri...@google.com [mailto:agri...@google.com] On Behalf Of 
Andrew Grieve

Sent: Tuesday, January 13, 2015 6:57 AM
To: Gorkem Ercan
Cc: dev; Andrew Grieve; Michael Brooks
Subject: Re: platforms/plugins save and restore from config.xml

Saving all the time certainly would make this simpler. If we save all 
of the time, we can also make uninstall a part of prepare. E.g. If 
users edits their config.xml and removes a plugin, then prepare can 
detect that and plugman uninstall it before building. If we don't 
always save, then editing your config.xml wouldn't be that meaningful 
unless you delete  recreate platforms every time.


On Mon, Jan 12, 2015 at 10:29 PM, Gorkem Ercan 
gorkem.er...@gmail.com

wrote:




On 12 Jan 2015, at 22:09, Andrew Grieve wrote:

Related to this, but maybe can be discussed outside of the doc just 
fine:


https://issues.apache.org/jira/browse/CB-4275

Re: platforms/plugins save and restore from config.xml

[Gorkem Ercan]

On 12 Jan 2015, at 22:09, Andrew Grieve wrote:

Related to this, but maybe can be discussed outside of the doc just 
fine:


https://issues.apache.org/jira/browse/CB-4275

Right now when we add a new platform, we do a for-each on directories
within plugins/ and add them as well. This causes all plugins to wind 
up as

top-level plugins even when they are dependent plugins on existing
platforms.

Having plugins listed in config.xml, I think it would make sense to 
change
this logic to plugin add based on plugins within config.xml rather 
than
directories that exist within plugins. We could potentially still add 
all

of them if no plugins are listed in config.xml for backwards compat.



Related to that, I was looking at CB-8278[1] this bug not only causes 
the variables to be lost also it causes the top-level plugin info to 
vanish as well.
We could also fix this problem easier too if we are saving plugins to 
config.xml all the time. Which means no save command or --save.


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





On Mon, Jan 12, 2015 at 9:19 PM, Andrew Grieve agri...@chromium.org 
wrote:



Thanks for putting the doc together. Added some comments to it.

On Mon, Jan 12, 2015 at 5:39 PM, Mefire O. ommen...@microsoft.com 
wrote:



Google docs link :
https://docs.google.com/document/d/1qKjhzSf48ybGg2GFZPtjXP8dkF4Z5Jnc7FU41V3-jFc/edit

Thanks,
Mefire

-Original Message-
From: Mefire O. [mailto:ommen...@microsoft.com]
Sent: Monday, January 12, 2015 2:12 PM
To: dev@cordova.apache.org
Cc: Michael Brooks
Subject: RE: platforms/plugins save and restore from config.xml

Here's what I propose, let me know what you think :

'cordova platform add'
 * No -save flag, No 'autosave' setting in
project_dir/.cordova/config.json
 1. 'cordova platform add android' = restores the 
android
platform from config.xml. If config.xml doesn't have any android 
engine,

falls back to using the pinned CLI version.
 * With -save flag or 'autosave' setting in
project_dir/.cordova/config.json
 1. 'cordova platform add
https://github.com/apache/cordova-android.git -save' = clones the 
git
repo and adds the android platform to the project, then updates 
config.xml

and point its version to the specified git-url.
 2. 'cordova platform add android@
https://github.com/apache/cordova-android.git -save' = clones the 
git
repo and adds the android platform to the project, then updates 
config.xml

and point its version to the specified git-url.
 3. 'cordova platform add C:/path/to/android/platform
-save' = adds the android platform to the project, then updates 
config.xml

and point its version to the specified folder location.
 * --Save flag is used in CLI-based workflows, and 'autosave'
(project_dir/.cordova/config.json) is used in IDE-based workflows.

'cordova save platforms'
 In its current behavior, 'cordova save platforms' retrieves all
the platforms currently installed on the project, and saves them to
config.xml. However, unlike 'cordova save plugins', it does not save 
the
source of the platform (i.e: git-url, folder location), it only 
saves the

version. This behavior is different from the one that 'cordova save
plugins' implements.
 * 'cordova save platforms'  = it should retrieve the sources 
of
all the installed platforms from .fetch.json, and save them in 
config.xml.
This requires making changes to the way that 'cordova platform add' 
works,

it should always save the source in .fetch.json.
 * In case of conflict with the config.xml, 'cordova save
platforms' should error out. The -force option shall be used if we 
want it

to override config.xml content.

'cordova restore platforms'
 It reads the config.xml file and install all the platforms
specified there.

'cordova save'
 Saves all installed platforms and plugins into config.xml

'cordova restore'
 Restores all platforms and plugins from config.xml. similar to
'npm install'.

Here the link to the google docs :

Thanks,
Mefire

-Original Message-
From: Parashuram N (MS OPEN TECH) [mailto:panar...@microsoft.com]
Sent: Friday, January 9, 2015 1:09 PM
To: dev@cordova.apache.org
Cc: Michael Brooks
Subject: Re: platforms/plugins save and restore from config.xml

Regarding save - I think automatic save could be an issue for folks 
who
want to try out experimental platforms, or pick up platforms from 
git
URIs or master branches. What would happen in that case? May be 
that's is

why npm --save exists in the first place.

Where to save - For making progress, looks like we will also have to
finalize if it will be persisted in config.xml or in package.json. 
Most
IDEs will not use the --save option, but may choose to directly 
persist in

the required file when a platform is added using a GUI.

Regarding restore - automatic restore makes a lot of sense. Does 
mefire's

PR not cover that ?

From: Chuck Lantzmailto:cla...@microsoft.com
Sent: ?Friday?, ?January? ?9?, 

Re: platforms/plugins save and restore from config.xml

[Gorkem Ercan]

On 9 Jan 2015, at 13:35, Michal Mocny wrote:


-1 on removing experimental.

I love the concept behind this feature, and I applaud Gorkem for 
actually

working on pushing it forward,


Thanks just trying to help.


but I'm still concerned the current design
is not perfect.  Just today we were discussing storing the list of 
plugins

into a package.json if plugins move to npm.


discussing where ?


The current implementation
still saves all installed plugins including dependencies and not just 
what

was explicitly added.

Not anymore, that was the case with the initial implementation. [1] has 
changed that many months ago.


[1] 
https://github.com/apache/cordova-lib/commit/35a3059bbbe5fcabdb74ff30b8c2845d135dada7



If we add this outside experimental, and document  broadcast it, we 
will
have to support it going forward.  That will certainly influence 
future cli

designs.


I was not aware there was a future cli design discussion.


-Michal

On Fri, Jan 9, 2015 at 12:08 PM, Gorkem Ercan gorkem.er...@gmail.com
wrote:




On 9 Jan 2015, at 10:41, Andrew Grieve wrote:

Questions: Would ever not want to use --save? Why not just always 
update

config.xml with what plugins you have?

Eclipse Thym always updates the plugin  platform information to

config.xml, and no one complained about it so far.

Likewise, would you ever not want to have --shrinkwrap? I think you'd

always want the plugin/platform version listed in there.



I do not set the shrinkwrap for plugins usually, because without
shrinkwrap, the latest version is restored. I usually prefer the 
latest

with the stable plugins, such as the core plugins.
As a reference, Eclipse Thym does not shrinkwrap by default but has a
preference you can turn on.

With platforms shrinkwrap as default makes sense.

On Fri, Jan 9, 2015 at 1:46 AM, Mefire O. ommen...@microsoft.com 
wrote:


Also, I have Pull Requests that implements the --save flag as 
mentioned

earlier :

- https://github.com/apache/cordova-cli/pull/203
- https://github.com/apache/cordova-lib/pull/144


Thanks,
Mefire

-Original Message-
From: Mefire O. [mailto:ommen...@microsoft.com]
Sent: Thursday, January 8, 2015 10:27 PM
To: Cordova Dev
Subject: RE: platforms/plugins save and restore from config.xml

+1 on removing the --experimental flag after fixing the 'variables 
not

being saved' bug.

Thanks,
Mefire

-Original Message-
From: Josh Soref [mailto:jso...@blackberry.com]
Sent: Thursday, January 8, 2015 8:49 PM
To: Cordova Dev
Subject: Re: platforms/plugins save and restore from config.xml

Until adding plugins saves the variables provided, we really 
shouldn't /

can't make this non experimental.

Sent from my BlackBerry 10 smartphone.
‎



-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: platforms/plugins save and restore from config.xml

[Gorkem Ercan]

On 9 Jan 2015, at 10:41, Andrew Grieve wrote:

Questions: Would ever not want to use --save? Why not just always 
update

config.xml with what plugins you have?

Eclipse Thym always updates the plugin  platform information to 
config.xml, and no one complained about it so far.



Likewise, would you ever not want to have --shrinkwrap? I think you'd
always want the plugin/platform version listed in there.



I do not set the shrinkwrap for plugins usually, because without 
shrinkwrap, the latest version is restored. I usually prefer the latest 
with the stable plugins, such as the core plugins.
As a reference, Eclipse Thym does not shrinkwrap by default but has a 
preference you can turn on.


With platforms shrinkwrap as default makes sense.

On Fri, Jan 9, 2015 at 1:46 AM, Mefire O. ommen...@microsoft.com 
wrote:


Also, I have Pull Requests that implements the --save flag as 
mentioned

earlier :

- https://github.com/apache/cordova-cli/pull/203
- https://github.com/apache/cordova-lib/pull/144


Thanks,
Mefire

-Original Message-
From: Mefire O. [mailto:ommen...@microsoft.com]
Sent: Thursday, January 8, 2015 10:27 PM
To: Cordova Dev
Subject: RE: platforms/plugins save and restore from config.xml

+1 on removing the --experimental flag after fixing the 'variables 
not

being saved' bug.

Thanks,
Mefire

-Original Message-
From: Josh Soref [mailto:jso...@blackberry.com]
Sent: Thursday, January 8, 2015 8:49 PM
To: Cordova Dev
Subject: Re: platforms/plugins save and restore from config.xml

Until adding plugins saves the variables provided, we really 
shouldn't /

can't make this non experimental.

Sent from my BlackBerry 10 smartphone.
‎



-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: platforms/plugins save and restore from config.xml

[Gorkem Ercan]

This is not really an issue of the save/restore but rather will become 
obvious with the save and restore platforms. I think, save/restore 
plugins is irrelevant to this case.


A solution should not try to fix it in the context of save  restore 
platforms. The main issue is the plugin variables are platform agnostic 
but they are persisted to platform specific files which disappear with 
the platform. Eclipse Thym, which restores platforms continuously, does 
not run into this problem because it persists the variables on project 
level config.xml. I could send a PR to fix this one on the same lines 
but I am not sure if this would fit everyone.

--
Gorkem


On 8 Jan 2015, at 23:48, Josh Soref wrote:

Until adding plugins saves the variables provided, we really shouldn't 
/ can't make this non experimental.


Sent from my BlackBerry 10 smartphone.
‎

[smime.p7s]


-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: platforms/plugins save and restore from config.xml

[Gorkem Ercan]

On 9 Jan 2015, at 14:13, Treggiari, Leo wrote:

I had asked some questions about save and restore a while back, but 
have not been following the progress in detail - so ignore me if you 
feel it is appropriate.


One of my biggest questions was why would these commands be an option?


Ironically, the very first implementation did not introduce commands but 
rather hooked itself for plugin/platform add/rm and prepare, sort of 
like what [1] introduces with config.json preferences. However during 
the review it was suggested that these needs to be commands at least for 
a while.


[1] https://github.com/apache/cordova-lib/pull/143

What I'm looking for, as soon as possible, is that Cordova 'project' 
metadata is stored logically and consistently so that the CLI and 
multiple IDEs could simultaneously work on the same project and know 
about what each other have done wrt. adding/removing 
plugins/platforms/etc.




That is one of my motivations, right now too much depends on plugins and 
platforms folders being present.


Does removing experimental advance that goal or does it, as Michal 
says, put obstacles in the path of getting there by requiring long 
term support of an incomplete and possibly confusing (more options?) 
solution?




Removing experimental matters only if we want to keep save and restore 
as separate commands. Otherwise, it is a matter of agreeing on a goal.



Leo

-Original Message-
From: mmo...@google.com [mailto:mmo...@google.com] On Behalf Of Michal 
Mocny

Sent: Friday, January 09, 2015 10:35 AM
To: dev
Subject: Re: platforms/plugins save and restore from config.xml

-1 on removing experimental.

I love the concept behind this feature, and I applaud Gorkem for 
actually
working on pushing it forward, but I'm still concerned the current 
design
is not perfect.  Just today we were discussing storing the list of 
plugins
into a package.json if plugins move to npm.  The current 
implementation
still saves all installed plugins including dependencies and not just 
what

was explicitly added.

If we add this outside experimental, and document  broadcast it, we 
will
have to support it going forward.  That will certainly influence 
future cli

designs.

-Michal

On Fri, Jan 9, 2015 at 12:08 PM, Gorkem Ercan gorkem.er...@gmail.com
wrote:




On 9 Jan 2015, at 10:41, Andrew Grieve wrote:

Questions: Would ever not want to use --save? Why not just always 
update

config.xml with what plugins you have?

Eclipse Thym always updates the plugin  platform information to

config.xml, and no one complained about it so far.

Likewise, would you ever not want to have --shrinkwrap? I think you'd

always want the plugin/platform version listed in there.



I do not set the shrinkwrap for plugins usually, because without
shrinkwrap, the latest version is restored. I usually prefer the 
latest

with the stable plugins, such as the core plugins.
As a reference, Eclipse Thym does not shrinkwrap by default but has a
preference you can turn on.

With platforms shrinkwrap as default makes sense.

On Fri, Jan 9, 2015 at 1:46 AM, Mefire O. ommen...@microsoft.com 
wrote:


Also, I have Pull Requests that implements the --save flag as 
mentioned

earlier :

- https://github.com/apache/cordova-cli/pull/203
- https://github.com/apache/cordova-lib/pull/144


Thanks,
Mefire

-Original Message-
From: Mefire O. [mailto:ommen...@microsoft.com]
Sent: Thursday, January 8, 2015 10:27 PM
To: Cordova Dev
Subject: RE: platforms/plugins save and restore from config.xml

+1 on removing the --experimental flag after fixing the 'variables 
not

being saved' bug.

Thanks,
Mefire

-Original Message-
From: Josh Soref [mailto:jso...@blackberry.com]
Sent: Thursday, January 8, 2015 8:49 PM
To: Cordova Dev
Subject: Re: platforms/plugins save and restore from config.xml

Until adding plugins saves the variables provided, we really 
shouldn't /

can't make this non experimental.

Sent from my BlackBerry 10 smartphone.
‎



-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: platforms/plugins save and restore from config.xml

[Gorkem Ercan]

On 9 Jan 2015, at 14:48, Josh Soref wrote:

 Michal Mocny wrote:

 Automatic restore could just happen on prepare.
 We do this for CCA and its worked very well.

 Sounds good to me.

Already implemented on https://github.com/apache/cordova-lib/pull/143

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: platforms/plugins save and restore from config.xml

[Gorkem Ercan]

On 8 Jan 2015, at 17:29, Mefire O. wrote:


Hi all,

I am a big fan of the experimental save and restore features that 
are in the CLI and saw that Gorkem has also created another PR 
(https://github.com/apache/cordova-lib/pull/143 ) to have a setting to 
auto persist/restore plugin versions which is a really interesting 
idea.


Glad it helps someone. The current PR is for plugins and I will send a 
PR for platforms too. The ultimate goal is to be able to remove 
platforms and plugins folder completely.


On a related note, one issue I ran into with platform save/restore is 
when you need to involve multiple operating systems for a given 
project.  Ex: Targeting say iOS, Windows, and Ubuntu from the same 
project or simply have some team members on OSX or Linux while others 
are on Windows - you need to be able to save or restore only 
platforms that run on the OS you are currently using.


For the restore situation, it seems to make quite a bit of sense to 
use any version information in config.xml when you add a platform by 
default.  The fact the information in is in config.xml indicates the 
goal is consistency.


Here is a PR that adds this functionality for platforms: 
https://github.com/apache/cordova-lib/pull/140#issuecomment-68942932


This functionality makes a lot of sense especially if/when it supports 
git urls?


With that in mind, we could also follow that familiar pattern that 
exists with npm and package.json to help out when you want to quickly 
save the platform you added to config.xml.


Ex:

cordova platform add android --save



I think we should have support for --save on plugins add/remove as well. 
Ultimately, I think users of this functionality configure their projects 
to be auto restore and use this or the save/restore commands to specify 
what needs to be restored.


There is one catch with the implementation though. Save and restore are 
still called with --experimental, perhaps we need to remove 
--experimental before this can proceed.


...adds the latest android platform and updates config.xml with the 
version that was added. As always, you can always use the existing 
syntax to add a different version (cordova platform add 
android@4.0.0mailto:android@4.0.0). I'm planning on putting together 
a PR on that idea as well.  We could actually follow a similar model 
for plugins as well.


Thanks,
Mefire


-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: platforms/plugins save and restore from config.xml

[Gorkem Ercan]

cordova help
has a section for Experimental Commands they are listed there. Once 
the save and restore is graduated that section will be empty though.

--
Gorkem

On 8 Jan 2015, at 21:32, Brian LeRoux wrote:

Yes! Also quick q, are all experimental flags documented somewhere? 
(Other

than code)

On Thu, Jan 8, 2015, 6:29 PM Parashuram N (MS OPEN TECH) 
panar...@microsoft.com wrote:


+1 to graduating this out of experimental :)

On 1/8/15, 4:25 PM, Steven Gill stevengil...@gmail.com wrote:


+1 to remove --experimental

On Thu, Jan 8, 2015 at 4:13 PM, Gorkem Ercan 
gorkem.er...@gmail.com

wrote:




On 8 Jan 2015, at 17:29, Mefire O. wrote:

Hi all,


I am a big fan of the experimental save and restore features 
that

are
in the CLI and saw that Gorkem has also created another PR (
https://github.com/apache/cordova-lib/pull/143 ) to have a setting 
to

auto persist/restore plugin versions which is a really interesting
idea.



Glad it helps someone. The current PR is for plugins and I will 
send a

PR
for platforms too. The ultimate goal is to be able to remove 
platforms

and
plugins folder completely.

On a related note, one issue I ran into with platform save/restore 
is

when you need to involve multiple operating systems for a given
project.
Ex: Targeting say iOS, Windows, and Ubuntu from the same project 
or

simply
have some team members on OSX or Linux while others are on Windows 
-

you
need to be able to save or restore only platforms that run on 
the

OS
you are currently using.

For the restore situation, it seems to make quite a bit of sense 
to use

any version information in config.xml when you add a platform by
default.
The fact the information in is in config.xml indicates the goal is
consistency.

Here is a PR that adds this functionality for platforms:
https://github.com/apache/cordova-lib/pull/140#issuecomment-68942932

This functionality makes a lot of sense especially if/when it 
supports

git urls?

With that in mind, we could also follow that familiar pattern that
exists
with npm and package.json to help out when you want to quickly 
save the

platform you added to config.xml.

Ex:

cordova platform add android --save


I think we should have support for --save on plugins add/remove as 
well.

Ultimately, I think users of this functionality configure their
projects to
be auto restore and use this or the save/restore commands to 
specify

what
needs to be restored.

There is one catch with the implementation though. Save and restore 
are

still called with --experimental, perhaps we need to remove
--experimental
before this can proceed.

...adds the latest android platform and updates config.xml with the

version that was added. As always, you can always use the existing
syntax
to add a different version (cordova platform add 
android@4.0.0mailto:
android@4.0.0). I'm planning on putting together a PR on that 
idea as
well.  We could actually follow a similar model for plugins as 
well.


Thanks,
Mefire



-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org





-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: Plugins dependencies installation logic

[Gorkem Ercan]

Do you remember, whether a Jira was created for it?
--
Gorkem

On Wed, Oct 22, 2014 at 3:47 PM, Andrew Grieve agri...@chromium.org wrote:

 This was brought up (over a year ago at least), and was deemed a bug, but
 one that's hairy to fix.

 On Wed, Oct 22, 2014 at 8:07 AM, Bryan Higgins br...@bryanhiggins.net
 wrote:

  That is the design. CLI calls plugman.fetch and then plugman.install for
  each installed platform.
 
  The plugin won't get installed (and dependencies won't be resolved)
 until a
  platform is added.
 
  On Wed, Oct 22, 2014 at 5:15 AM, Sergey Grebnov (Akvelon) 
  v-seg...@microsoft.com wrote:
 
   Hi, while working on CB-7846 'Fix plugin deletion when dependency
 plugin
   does not exist' [1] I've found out that dependency plugins are not
   installed to plugins dir if you don't have any platform installed yet.
 Is
   it by design or something which should be further investigated?
  
   Related side effect is 'cordova plugins' report different list of
 plugins
   before and after you add a first platform
   λ cordova plugin add org.apache.cordova.file-transfer
  
   λ cordova plugins
   org.apache.cordova.file-transfer 0.4.7 File Transfer
  
   λ cordova platform add android
  
   λ cordova plugins
   org.apache.cordova.file 1.3.1 File
   org.apache.cordova.file-transfer 0.4.7 File Transfer
  
   [1] https://issues.apache.org/jira/browse/CB-7846
  
   Thx!
   Sergey
  
   -
   To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
   For additional commands, e-mail: dev-h...@cordova.apache.org
  
  
 

Re: adding push notifications to core plugins

[Gorkem Ercan]

On Thu, Oct 16, 2014 at 03:24:26PM -0700, Jesse wrote:
 Core, or no core, the plugin already exists:
 https://github.com/phonegap-build/PushPlugin/
 It works on iOS, Android, BB10, WP8, Windows8, and Amazon Fire OS.

 In my mind, the fact that every device uses it's own messaging service
 makes this a non-starter. At least for moving to core, and/or adding to the
 API.


What is the expected benefit of moving a plugin this much mature to
core plugins?



 @purplecabbage
 risingj.com

 On Thu, Oct 16, 2014 at 1:41 PM, Joe Bowser bows...@gmail.com wrote:

  I bet you that the Android Camera is more terrible than the iOS camera.
 
  The big problem with a lot of the plugins is that we make promises that we
  can't keep.  For example, the Android camera only supports JPG, but our
  docs say that you can take PNG photos, which not only makes very little
  sense, but isn't possible with the current code without a really big
  refactor. There's also the whole memory restriction problem that has
  creeped its ugly head with the Moto G and Moto E, which are lower end
  devices with a lot of users.  The Battery Spec is another example, where
  the current Android implemntation is unusable, and the W3C Proposal is
  absolute garbage and unimplementable.
 
  I don't want any more core plugins until we finally do our long promised,
  but forever pushed forward API audit.  I know that a push notifications
  plugin is super tempting, but this is like us adopting another puppy when
  we have a dead hamster, fish and turtle in our room stinking up the place.
 
  On Thu, Oct 16, 2014 at 1:35 PM, Shazron shaz...@gmail.com wrote:
 
   The Camera (esp iOS) is terrible IMO, we should replace with some
  standard
   API, like we've talked about before (not sure which spec).
  
   On Thu, Oct 16, 2014 at 1:33 PM, Brian LeRoux b...@brian.io wrote:
  
I'm all for code removal. Which plugins tho?
   
   
On Thu, Oct 16, 2014 at 1:23 PM, Joe Bowser bows...@gmail.com wrote:
   
 Do we need more core plugins? We're already pretty terrible at
   supporting
 what we have on our plate now.  I would rather we have less core
   plugins
 than more.

 On Thu, Oct 16, 2014 at 12:27 PM, Jesse purplecabb...@gmail.com
   wrote:

  This one supports everything:
 
  https://github.com/phonegap-build/PushPlugin/blob/master/plugin.xml
 
  and it is MIT
 
  @purplecabbage
  risingj.com
 
  On Thu, Oct 16, 2014 at 12:10 PM, Lorin Beer lorin.b...@gmail.com
  
 wrote:
 
   I've been asked about this from multiple sources over the last
  few
 weeks.
   Given how important push notifications are for mobile projects, a
core
  push
   notification plugin would be a great addition and another
  argument
for
  why
   you should use cordova.
  
   On Thu, Oct 16, 2014 at 11:58 AM, Brian LeRoux b...@brian.io
  wrote:
  
just was discussing w/ Shaz and Jesse…thoughts?
   
  
 

   
  
 

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: Adding ability to add any platform on any OS

[Gorkem Ercan]

On Sat, Oct 18, 2014 at 06:22:12AM +, Parashuram Narasimhan (MS
OPEN TECH) wrote:
 What about saving and restoring platforms?  Cordova platforms will not be 
 checked in, but we could do a cordova platform save. When I now do a cordova 
 platform restore on my Mac machine, will is try to restore the Windows 
 platform also and fail ?


cordova restore platforms will not be able to restore windows on a
Mac, it basically
delegates to cordova add which will fail. Unfortunately, it will stop
platform restoration after first failed platform which I think should
not be the case [1].

I think the ultimate goal with cordova restore is to make it part of the
prepare cycle and remove plugins and platforms folders. In such a
setting restoring platforms that we can not cater on a host OS will
probably cause more harm.

I can see some cases where this could be a useful feature but I do not think
they are part of the main flow. Perhaps a --force flag can be added for
this one?

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

 -Original Message-
 From: Josh Soref [mailto:jso...@blackberry.com]
 Sent: Friday, October 17, 2014 2:15 PM
 To: Jesse; dev@cordova.apache.org
 Subject: Re: Adding ability to add any platform on any OS

 cordova serve could still benefit from it...

 Although I haven't looked into it too much. ‎ Sent from my BlackBerry 10 
 smartphone.


 -
 To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
 For additional commands, e-mail: dev-h...@cordova.apache.org

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [GitHub] cordova-lib pull request: [CB-5989] - Default to $PROJECT_NAME-Inf...

[Gorkem Ercan]

Can you explain? This bug is not related to android, or use of project name
Unless iOS name defaults to the lowest order character, there is a chance
that a plist file brought in by a custom framework gets precedence and
fails the configuration update for plist.

On Mon, Sep 29, 2014 at 11:10 PM, Josh Soref jso...@blackberry.com wrote:

 -1. ‎We're in the process of fixing Android bugs related to using project
 names in file system artifacts.

PR for save/restore git local

[Gorkem Ercan]

Hi, 

I have a PR[1] waiting for some love  This one completes the
save and restore for git urls and local directories. I would appreciate
it if someone can take a look.

Thanks,

[1] https://github.com/apache/cordova-lib/pull/86

Re: Cordova-Create Module

[Gorkem Ercan]

Really cool!
If you have your own project template you could do most of this with the
cordova restore command. I have got a new PR[1] that will allow the
restore/save to support to local directories and git urls.

Platform restore list per host OS is interesting, I should look into that.

[1] https://github.com/apache/cordova-lib/pull/86
--
Gorkem

On Sun, Sep 14, 2014 at 10:00 AM, John M. Wargo jwarg...@gmail.com wrote:

 I recently created a node module called Cordova-create that takes care of
 the typical developer new project workflow.

 It makes calls to create, then adds a set of platforms and a set of
 plugins to the project.  I did this because I found myself performing the
 same steps over and over again and wanted a simpler way to do it. I made it
 configurable, so you can edit a cordova-create.json file in the home folder
 to specify the platforms and plugins to add.

 I published it to npm so others can use it, you can find it here:
 https://www.npmjs.org/package/cordova-create.

 Did I make a mistake by calling it cordova-create?  I don't want to
 confuse this module with the other cordova stuff, but I named it the way
 that made the most sense for me. Does anyone care that I named it that way?

Re: [DISCUSS] Plugins Release

[Gorkem Ercan]

Could you also take a look at this PR[1] and jira[2]  for the contacts
plugin
it is a simple typo but it is ruining one of our demos.

[1] https://github.com/apache/cordova-plugin-contacts/pull/45
[2] https://issues.apache.org/jira/browse/CB-7523
--
Gorkem

On Wed, Sep 10, 2014 at 6:10 PM, Shazron shaz...@gmail.com wrote:

 +1
 Esp for the iOS 8 fixes for Geolocation and Camera. I'll focus on those.

 On Tue, Sep 9, 2014 at 7:01 AM, Marcel Kinard cmarc...@gmail.com wrote:

  Then I would suggest that folks work on the outstanding pull requests for
  the plugins, such as merging in whatever they think is ready or closing
  requests that aren't appropriate or providing feedback on things in
 between.
 
  On Sep 9, 2014, at 2:45 AM, Sergey Grebnov (Akvelon) 
  v-seg...@microsoft.com wrote:
 
   +1, sounds great!
  
   -Sergey
   -Original Message-
   From: purplecabbage [mailto:purplecabb...@gmail.com]
   Sent: Tuesday, September 9, 2014 6:29 AM
   To: dev@cordova.apache.org
   Subject: Re: [DISCUSS] Plugins Release
  
   Sounds good to me!
  
   Sent from my iPhone
  
   On Sep 8, 2014, at 7:07 PM, Marcel Kinard cmarc...@gmail.com wrote:
  
   The last plugins release was about a month ago. There have been a lot
  of changes that have landed on master since then that fix bugs,
 especially
  around file and file-transfer. And the unified Windows platform is
 getting
  plugin fixes.
  
   How about doing a plugins release as soon as the 3.6.1 cadence release
  is finished?
 
 

Re: Remove VERSION file from repos

[Gorkem Ercan]

Is there a JIRA to follow up on this change?
--
Gorkem


On Fri, Aug 29, 2014 at 3:16 AM, Steven Gill stevengil...@gmail.com wrote:

 Just a quick update to this.

 Coho now updates the version script for the following platforms:
 Android
 Amazon-fireos
 Ubuntu
 Firefoxos
 Blackberry

 If coho is being used for releases, I think this is the way to go. iOS,
 windows and wp8 are the only remaining ones.

 Line to edit in coho:

 https://github.com/apache/cordova-coho/blob/master/src/cadance-release.js#L124
 Sample version script:

 https://github.com/apache/cordova-android/blob/master/bin/templates/cordova/version

 Let me know if you are going to make this change for your platforms. I will
 need to copy it over to my platform-release file which will replace cadence
 release after 3.6.0:

 https://github.com/stevengill/cordova-coho/blob/cb-7224/src/platform-release.js#L124




 On Thu, Aug 14, 2014 at 10:15 AM, purplecabbage purplecabb...@gmail.com
 wrote:

 
 
   On Aug 14, 2014, at 4:09 AM, Ian Clelland iclell...@chromium.org
  wrote:
  
   +1 -- there's little value in trying to derive something at runtime
 that
   should just be hard-coded. (And even if we didn't have coho, we could
 set
   it manually without too much effort. :) )
 
  If we remember to.
  +0
 
 
  
  
   On Wed, Aug 13, 2014 at 8:28 PM, Steven Gill stevengil...@gmail.com
  wrote:
  
   Using android's method of doing this doesn't seem so bad to me.
  
   Version script has hard coded value that coho sets when doing a
 release.
   Seems to be working fine as long as coho is used for releasing.
  
   Thoughts?
  
  
   On Wed, Aug 13, 2014 at 1:44 PM, Carlos Santana csantan...@gmail.com
 
   wrote:
  
   I think having the ios platform scripts in nodejs have a side benefit
  of
   being able to create ios platform on Linux and Windows.
  
   IBM Worklight customers use this use case, where they create ios
  cordova
   app, and in Windows or Linux they use it for preview with MBS a tool
   similar to Ripple, and generate a zip with the xcode project, they
 can
   use
   on a Mac with XCode for final build.
  
   The use case is also similar to create an ios platform app and
 preview
  in
   App Harness like PhoneGap Developer.
  
   just my two cents.
  
  
  
   On Tue, Aug 12, 2014 at 4:46 PM, Shazron shaz...@gmail.com wrote:
  
   Believe me, I want to go all node -- but all in for all scripts --
   which we don't have time to do yet (maybe 4.0?).
   But seeing that it's just replacing the contents of the current bash
   script with python code, it's the path of least resistance, and path
   of least potential conflict imo. No one will notice.
  
  
   On Tue, Aug 12, 2014 at 1:36 PM, Michal Mocny mmo...@chromium.org
   wrote:
   Shaz, that's technically true, but how many users actually use that
   path
   these days?
  
   I thought the last stats overwhelmingly suggest our users are
   drinking
   the
   kool-aid and using cli, node, etc.
  
  
   On Tue, Aug 12, 2014 at 4:19 PM, Shazron shaz...@gmail.com
 wrote:
  
   Not if they are installed manually. It's not worth having some
   dependency just to read a version, that's nuts.
  
   On Tue, Aug 12, 2014 at 1:15 PM, Jesse purplecabb...@gmail.com
   wrote:
   the non-cordova cli path depends on node to install/uninstall
   plugins
  
   @purplecabbage
   risingj.com
  
  
   On Tue, Aug 12, 2014 at 1:08 PM, Shazron shaz...@gmail.com
   wrote:
  
   Of course I considered nodejs, but no, this is for the
   non-cordova
   CLI
   path, which does not need another dependency.
  
   On Tue, Aug 12, 2014 at 11:52 AM, Jesse 
 purplecabb...@gmail.com
  
   wrote:
   Yeah, if you are going to replace bash, replace it with nodejs!
  
  
   @purplecabbage
   risingj.com
  
  
   On Tue, Aug 12, 2014 at 11:48 AM, Myles Borins my...@famo.us
   wrote:
  
   Have you considered writing a small node script to pass the
   json?
   This
   would make it as simple as requiring in the package json an
   piping
   the
   relevant info to stdout
   On Aug 12, 2014 11:47 AM, Shazron shaz...@gmail.com
   wrote:
  
   Yeah I value life and my sanity - I'll probably replace the
   bash
   script with python
  
   On Tue, Aug 12, 2014 at 11:40 AM, Lorin Beer 
   lorin.b...@gmail.com
  
   wrote:
   one source for version information is better
  
   although parsing json with bash scripts seems janky
  
  
   On Tue, Aug 12, 2014 at 11:31 AM, Jesse 
   purplecabb...@gmail.com
  
   wrote:
  
   I think it still needs to exist in an output project ...
   which
   is
   not
   (yet?) an npm project, and so does not have a
   package.json.
  
   The individual platform repos can get rid of it, they
   will
   just
   need
   to
   modify the way they `create` new projects to read the
   value
   from
   package.json and output it to NewProject/VERSION
  
  
  
  
   @purplecabbage
   risingj.com
  
  
   On Tue, Aug 12, 2014 at 11:25 AM, Shazron 
   shaz...@gmail.com
  
   wrote:
  
   For iOS, the only file I 

Re: cordova plugin save

[Gorkem Ercan]

 
 I’m still at a higher level question which is why save/restore at all?  It 
 seems like it would be better if the ‘plugin/platform add/remove’ commands 
 maintained their lists in config.xml.  There’s no need for a ‘save’ command 
 then.  ‘restore’ could be interesting if it can’t be done automatically – 
 i.e. if Cordova CLI knows the list of plugins from config.xml, then it could 
 automatically  fetch them if they are missing from the plugins directory.
 

My first implementation did not have the save/restore commands and the
functionality was part of add/remove and prepare commands as you have
described. I guess once the functionality is mature enough we will reach
an agreement to integrate them back. 


 As an IDE developer, my overall goal would be to make it such that Cordova 
 CLI and an IDE could be used seamlessly on the same application.  E.g. 
 support a user who likes to use both at different times, and teams where some 
 users want to use the CLI and other users want to use an IDE.
 
 Leo
 
 From: mmo...@google.com [mailto:mmo...@google.com] On Behalf Of Michal Mocny
 Sent: Thursday, August 14, 2014 5:53 AM
 To: dev
 Cc: Treggiari, Leo
 Subject: Re: cordova plugin save
 
 Summarizing / simplifying since this thread has run away:
 
 Run-time Platform-specific config:
   - Automatically created on prepare from a combination of initial 
 application template and many project properties
   - Currently, this is the cordova platform config.xml, but also the 
 various platform metadata files like AndroidManifest.xml and App.plist etc
 
 Build-time Platform-generic App config:
   - Settings *every* developer would agree with.
   - Goes into VC, required to build the project.
   - Currently, this is /config.xml
 
 Project config:
   - Settings local to a given developers machine / project instance.
   - Currently, this is /.cordova/config.json
   - Can also have a global version that applies to all projects, but the 
 content is the same as per-project, conceptually the same.
  - and ~/.cordova/config.json
   - [I've been calling Project config the Workspace config.  I think both 
 terms are overloaded and confusing.  Perhaps we should just call it the 
 Local config?]
 
 
 I think the point of this thread was to figure out if the list of 
 platform/plugins to restore from should go.  With the above descriptions, 
 here are my 2c:
 - The list of plugin id / url and optional version go into the App config.  
 Every developer I believe will agree with the list itself being a requirement 
 to build the app.
 - Local settings such as searchpaths go in the local config, since I may have 
 cloned my repos differently than you have.
 - I should be able to override the list of version requirements easily, these 
 are just suggestions to help simplify sharing, not rules.
 - Ditto for platforms.
 
 Does that make sense?
 
 If we don't like the current app/local config, lets bring that up in a 
 different thread!
 
 -Michal
 
 On Thu, Aug 14, 2014 at 4:15 AM, Gorkem Ercan 
 gorkem.er...@gmail.commailto:gorkem.er...@gmail.com wrote:
 
 The goal with the save/restore work is to make it as convenient as
 possible to share cordova projects, so Chuck was right on the money. We
 also have an accompanying save/restore platforms command. Once the
 work is complete CLI should be able to restore plugins and platforms
 folders of a shared project with the plugins installed and platforms
 that was worked on.
 
 I actually think of config.xml as an app metadata file. Another of my
 ramblings has been to have a single config.xml and remove the
 need for platform specific ones. So I would prefer to avoid putting data that
 is not relevant at runtime to config.xml.
 
 For instance, Eclipse Thym [1] ,that I work on, uses config.json to save
 the engine information. I tend to think it is a more proper place for
 it.
 
 Answers to some of your questions.
 
  -  Where does 'save' find the definitive list of plugins that it should 
  save?  There may be some plugins specified in config.xml and there are 
  other metadata (platform.json)  files that believe they know the list.
   The list of plugins is simply a list of directories under the plugins folder
  -  What does it save and where?  Does it save the argument that was passed 
  to 'corodva platform add xxx'?  Does it save the id, (and possibly 
  additional information) from the sources that were actually fetched?
   It saves the id and if shrinkwrap flag is set also the installed
   version to the config.xml. It does not use the information passed to
   cordova platform add. The plan is to add git url information to be saved
   when appropriate  so that plugins that were installed using git can be
   restored too.
  -  Can 'restore' be guaranteed to fetch the same exact sources that were in 
  the project that was 'save'd?  Does it need to?
   If shrinkwrap is set then restore will restore the exact version of
   the plugin from the registry. Otherwise it will get

Re: cordova plugin save

[Gorkem Ercan]

The goal with the save/restore work is to make it as convenient as
possible to share cordova projects, so Chuck was right on the money. We
also have an accompanying save/restore platforms command. Once the
work is complete CLI should be able to restore plugins and platforms
folders of a shared project with the plugins installed and platforms
that was worked on.

I actually think of config.xml as an app metadata file. Another of my
ramblings has been to have a single config.xml and remove the
need for platform specific ones. So I would prefer to avoid putting data that
is not relevant at runtime to config.xml.

For instance, Eclipse Thym [1] ,that I work on, uses config.json to save 
the engine information. I tend to think it is a more proper place for
it.

Answers to some of your questions. 

 -  Where does 'save' find the definitive list of plugins that it should save? 
  There may be some plugins specified in config.xml and there are other 
 metadata (platform.json)  files that believe they know the list.
  The list of plugins is simply a list of directories under the plugins folder
 -  What does it save and where?  Does it save the argument that was passed to 
 'corodva platform add xxx'?  Does it save the id, (and possibly additional 
 information) from the sources that were actually fetched?
  It saves the id and if shrinkwrap flag is set also the installed
  version to the config.xml. It does not use the information passed to
  cordova platform add. The plan is to add git url information to be saved
  when appropriate  so that plugins that were installed using git can be
  restored too. 
 -  Can 'restore' be guaranteed to fetch the same exact sources that were in 
 the project that was 'save'd?  Does it need to?
  If shrinkwrap is set then restore will restore the exact version of
  the plugin from the registry. Otherwise it will get the latest
  available. In case of git URL it will be whatever that URL points to.

[1] http://www.eclipse.org/thym

--
Gorkem

On Thu, Aug 14, 2014 at 02:14:32AM +, Chuck Lantz wrote:
 Yeah I guess what I'm getting at is it is more of an app descriptor. It 
 describes things about the app that are immutable across the native 
 underlying projects used to build the app, different IDEs, or project 
 structures. If there was a way to import and export Cordova apps across any 
 number of IDEs or products and services (PhoneGap Build, WorkLight, Intel, 
 Telerik, etc) there are a set of things about the app that wouldn't change. A 
 transformed version of config.xml lands in underlying native projects in the 
 platforms folder as well.
 
 Another example, lets say that Gulp becomes the build system instead of the 
 CLI (not saying that will happen - just jumping to an extreme). We need a 
 place to keep the things that would not change.
 
 Speaking for VS, I would never put typescript compilation settings, build 
 configs, and other IDE settings that pertain to the app project in 
 config.xml. That's specific to the VS world and belongs in the VS project. 
 Similarly I would not force a project structure on another IDE let alone 
 someone hand editing config.xml in sublime text. Most likely will not change 
 from the CLI structure anyway.
 
 Now, how that is presented to the developer is a completely different story.
 
 Whether config.xml is the right long term place for what I describe is 
 another topic entirely.  It's pretty engrained. I do think it will be 
 important to easily separate the concepts, however.
 
 On the other questions - hop on that thread. I didn't make the PR so I can 
 only speak to the code verses the exact intent. :) The issue is that there is 
 no single definitive list of plugins or platforms to install today (plugins 
 pull in dependencies for specific platforms so the contents of the plugins 
 folder is actually not the definitive list).  That's what it was trying to 
 fix.
 
 From: Treggiari, Leomailto:leo.treggi...@intel.com
 Sent: ‎8/‎13/‎2014 6:48 PM
 To: Chuck Lantzmailto:cla...@microsoft.com; 
 dev@cordova.apache.orgmailto:dev@cordova.apache.org
 Cc: Treggiari, Leomailto:leo.treggi...@intel.com
 Subject: RE: cordova plugin save
 
 Hi Chuck,
 
 Thanks for adding the other 'app metadata file' (like AndroidManifest.xml or 
 package.appxmanifest.xml.) to the conversation.  It's important to consider 
 that as well.  Those are somewhat different because they contain information 
 that is not built into the app executable, but rather handled by an installer 
 or loader.  Does that make those settings somehow different to the app 
 developer?  I'm not sure.  But I'm sure you're right that items in the 
 existing set of metadata files affect all of the app executable, the 
 accompanying app 'manifest' file, and the accompanying cordova.js file.
 
 To start, I'm not sure that it makes sense to add any new metadata to the app 
 config.xml file.  I'm not sure that, because of its history, it fits cleanly 
 into 

Re: Feedback on cordova plugin save friends

[Gorkem Ercan]

On Tue, Aug 12, 2014 at 09:36:34PM -0400, Andrew Grieve wrote:
 On Tue, Aug 12, 2014 at 6:43 PM, Gorkem Ercan gorkem.er...@gmail.com
 wrote:
 
 
  Just returning from PTO, great timing :)
 
 :)
 
 
  On Tue, Aug 12, 2014 at 04:06:14PM -0400, Andrew Grieve wrote:
   Played around with it and it's pretty clear to me that the ability to
   record your plugins  platforms in config.xml is a big step up.
  
   I do have some specific comments about the current design though:
  
   - Right now the plugin save saves all plugins to config.xml rather than
   just explicitly-installed plugins.
 
  I agree, it should only save the explicitly installed plugins but I could
  not see an easy way to extract that info and did not want to spend too
  much time on it at the beginning.
 
 
 I know that the info is stored in the android.json, ios.json, etc files,
 but I don't know how the exact details of finding it.
 @kamrik - do you know?
 
 
 
 - For the shrinkwrap use-case, you actually do want to record dependent
   plugins and their versions though, so it's still important for this case.
 
  agreed.
 
   - Plugin restore doesn't work for locally installed plugins. e.g. try it
   with mobilespec. It won't remember to look in the right spot for plugins.
   - Really don't like that feature is used, since that could be confused
  by
   the tools with the runtime config.xml's feature tag. Instead, I think
  the
   syntax PGBuild uses would be better (minus the gap:)
   http://docs.build.phonegap.com/en_US/configuring_plugins.md.html
 - Note there's a PR for adding param (CB-7142)
  
 
  feature tag looks off place because CLI generates platforms specific
  config.xml files. If CLI adopted a single config.xml file that is just
  copied over instead of being modified during platform builds, the
  benefit of the feature tag would be more visible.
 
  Below is what is generated by Eclipse Thym for Device plugin when it is
  installed on config.xml, all the info for the plugin is
  under one tag, which makes it easier to manage for humans and tools.
 
  feature name=Device
  param name=firefoxos-package value=Device /
  param name=android-package value=org.apache.cordova.device.Device /
  param name=ios-package value=CDVDevice /
  param name=wp-package value=Device /
  param name=id value=org.apache.cordova.device /
  param name=version value=0.2.11 /
  /feature
 
 
 The issue I have with feature, is that the name= attribute is used as
 an exec() bridge detail, and it's set by plugin.xml. Plugins can have
 multiple features, or no features at all, and there's no way to know
 the name= before looking at the plugin.xml and inferring it. Even if CLI
 did use a shared config.xml, I think I'd still want to use plugin
 separate from feature (keep the parts that users shouldn't touch separate
 from the parts they can touch).
 
 Plus... feature... what the heck is a feature? I know what a plugin is,
 and a platform, but feature (as well as dependency), are generic terms
 that I don't think make obvious what they do. E.g. are platforms a
 feature/dependency? platform and plugin are more self-explanatory I
 think.
 

I agree.. feature is a horrible name to define plugins. I can
easily change the saved info to be in cdv:plugin tags, it makes little
difference and this is a convinient time to do it. I still prefer
everything related to a plugin collected under one tag perhaps we should retire
the feature tag and use the new one on the platform runtimes too.


 
 
 
   When I was playing with it, I found that I wished that is would just run
   every time I added a plugin, rather than having to run the command
   explicitly afterwards. Maybe we could add an environment variable that
  will
   enable it while we're still experimenting? Then, too, we could make
   platform / plugin restore a part of `prepare`.
 
  Initial implementation was actually part of the plugin add and
  prepare. We did not have explicit save and restore commands at all.
  Michal suggested that it was early for this feature so I came up with
  the save and restore commands.
 
  On Eclipse Thym, I have it implemented so that every plugin installation
  is saved to config.xml and plugins are auto restored when they are
  detected
  on config.xml. I am actually keeping plugins folder at this point just
  to be compatible but I hope that we can get CLI to the same stage and
  make the plugins folder a temporarily generated one that is not visible
  to anyone.
 
 
 Cool! How to you handle assets if you don't actually use the plugins/
 directory? CLI has to copy them from plugins/ - platforms on each prepare
 when constructing the www/.

The plugins directory may still exist but not as part of the project
tree because now config.xml carries all the info needed for it to be
generated. On CLI it can probably be implemented on prepare by generating 
(or updating) a plugins folder on a temp folder as a build time artifact 
and used from there.

 
 
 
  
   Don't have

Re: Feedback on cordova plugin save friends

[Gorkem Ercan]

On Tue, Aug 12, 2014 at 09:21:10PM -0400, Andrew Grieve wrote:
 On Tue, Aug 12, 2014 at 6:58 PM, Gorkem Ercan gorkem.er...@gmail.com
 wrote:
 
  On Tue, Aug 12, 2014 at 08:40:25PM +, Chuck Lantz wrote:
   +1
  
   That same pattern could be applied to platforms actually with an
  additional version attribute:
  
   platform name=android version=3.5.1
 ... things like icons, splaschreens, and maybe even packaging
  details go here ...
   /platform
  
   We could also follow a similar model if we wanted to say what top level
  cordova version was used to create the project by using the engine element
  from plugin.xml
  
   engine name=cordova version=3.5.0 /
 
  Already had a PR [1] for saving and restoring platforms, that is MIA. Is
  there a specific reason why you want engines stated expilicitly,
  wouldn't platforms be sufficient.
 
  [1] https://github.com/apache/cordova-lib/pull/18
 
 
 This was merged (I did it :P)
 
 cordova save platforms --experimental
 Results in:
 cdv:engine id=android version=3.6.0-dev /

Great, thanks.. This is why we need PTOs:. :)

 
 
 
 
 
  
   -Chuck
  
   -Original Message-
   From: mmo...@google.com [mailto:mmo...@google.com] On Behalf Of Michal
  Mocny
   Sent: Tuesday, August 12, 2014 1:34 PM
   To: dev
   Cc: Gorkem Ercan
   Subject: Re: Feedback on cordova plugin save  friends
  
   plugin is nice, but why not just dependency as plugin.xml already
  uses?
config.xml and plugin.xml share lots of tags already, why fork here?
  
   -Michal
  
  
   On Tue, Aug 12, 2014 at 4:06 PM, Andrew Grieve agri...@google.com
  wrote:
  
Played around with it and it's pretty clear to me that the ability to
record your plugins  platforms in config.xml is a big step up.
   
I do have some specific comments about the current design though:
   
- Right now the plugin save saves all plugins to config.xml rather
than just explicitly-installed plugins.
  - For the shrinkwrap use-case, you actually do want to record
dependent plugins and their versions though, so it's still important
  for this case.
- Plugin restore doesn't work for locally installed plugins. e.g. try
it with mobilespec. It won't remember to look in the right spot for
  plugins.
- Really don't like that feature is used, since that could be
confused by the tools with the runtime config.xml's feature tag.
Instead, I think the syntax PGBuild uses would be better (minus the
gap:) http://docs.build.phonegap.com/en_US/configuring_plugins.md.html
  - Note there's a PR for adding param (CB-7142)
   
When I was playing with it, I found that I wished that is would just
run every time I added a plugin, rather than having to run the command
explicitly afterwards. Maybe we could add an environment variable that
will enable it while we're still experimenting? Then, too, we could
make platform / plugin restore a part of `prepare`.
   
Don't have the intention of picking up work on this in the near term,
but wanted to at least share the feedback since I did play around with
  it.
   
 

Re: Feedback on cordova plugin save friends

[Gorkem Ercan]

On Wed, Aug 13, 2014 at 01:21:24AM +, Chuck Lantz wrote:
 Yes, good point - Took a look at the PR with platforms - seems like a similar 
 concept but using the engine element which as I think about it would probably 
 be better anyway.
 
 engines
 engine name=cordova-android version=3.5.1/
 engine name=cordova-ios version=3.5.0/
 /engines
 
 More consistent with the existing plugin.xml
 
 Would we need / want to support restoring from git repos or other 
 non-official sources?  My off-hand reaction is that is more useful for 
 platform development than end-users. As long as platforms implementations are 
 cached somewhere outside of the project itself as they are now it doesn't 
 strike me that restoring from the local filesystem is needed as a perf 
 measure either.

git repos is a good idea. Right now both plugins and engines are
missing it. For the non-official sources we are bound with what CLI can
support. 

 
 -Chuck
 
 -Original Message-
 From: Parashuram Narasimhan (MS OPEN TECH) 
 Sent: Tuesday, August 12, 2014 4:05 PM
 To: dev@cordova.apache.org; Chuck Lantz
 Subject: RE: Feedback on cordova plugin save  friends
 
 Given that we are looking at decoupling engine and platform releases, there 
 should be ways to specify them separately, right ? In this case, I am 
 assuming it is basically version of cordova-cli/cordova-lib and the platform, 
 assuming that cordova-cli can work with older platform versions. 
 
 -Original Message-
 From: Gorkem Ercan [mailto:gorkem.er...@gmail.com]
 Sent: Tuesday, August 12, 2014 3:59 PM
 To: Chuck Lantz
 Cc: dev@cordova.apache.org
 Subject: Re: Feedback on cordova plugin save  friends
 
 On Tue, Aug 12, 2014 at 08:40:25PM +, Chuck Lantz wrote:
  +1
  
  That same pattern could be applied to platforms actually with an additional 
  version attribute:
  
  platform name=android version=3.5.1
  ... things like icons, splaschreens, and maybe even packaging details 
  go here ...
  /platform
  
  We could also follow a similar model if we wanted to say what top 
  level cordova version was used to create the project by using the 
  engine element from plugin.xml
  
  engine name=cordova version=3.5.0 /
 
 Already had a PR [1] for saving and restoring platforms, that is MIA. Is 
 there a specific reason why you want engines stated expilicitly, wouldn't 
 platforms be sufficient.
 
 [1] https://github.com/apache/cordova-lib/pull/18
 
 
  
  -Chuck
  
  -Original Message-
  From: mmo...@google.com [mailto:mmo...@google.com] On Behalf Of Michal 
  Mocny
  Sent: Tuesday, August 12, 2014 1:34 PM
  To: dev
  Cc: Gorkem Ercan
  Subject: Re: Feedback on cordova plugin save  friends
  
  plugin is nice, but why not just dependency as plugin.xml already uses?
   config.xml and plugin.xml share lots of tags already, why fork here?
  
  -Michal
  
  
  On Tue, Aug 12, 2014 at 4:06 PM, Andrew Grieve agri...@google.com wrote:
  
   Played around with it and it's pretty clear to me that the ability 
   to record your plugins  platforms in config.xml is a big step up.
  
   I do have some specific comments about the current design though:
  
   - Right now the plugin save saves all plugins to config.xml rather 
   than just explicitly-installed plugins.
 - For the shrinkwrap use-case, you actually do want to record 
   dependent plugins and their versions though, so it's still important for 
   this case.
   - Plugin restore doesn't work for locally installed plugins. e.g. 
   try it with mobilespec. It won't remember to look in the right spot for 
   plugins.
   - Really don't like that feature is used, since that could be 
   confused by the tools with the runtime config.xml's feature tag.
   Instead, I think the syntax PGBuild uses would be better (minus the
   gap:) http://docs.build.phonegap.com/en_US/configuring_plugins.md.html
 - Note there's a PR for adding param (CB-7142)
  
   When I was playing with it, I found that I wished that is would just 
   run every time I added a plugin, rather than having to run the 
   command explicitly afterwards. Maybe we could add an environment 
   variable that will enable it while we're still experimenting? Then, 
   too, we could make platform / plugin restore a part of `prepare`.
  
   Don't have the intention of picking up work on this in the near 
   term, but wanted to at least share the feedback since I did play around 
   with it.
  

Re: Feedback on cordova plugin save friends

[Gorkem Ercan]

Just returning from PTO, great timing :) 

On Tue, Aug 12, 2014 at 04:06:14PM -0400, Andrew Grieve wrote:
 Played around with it and it's pretty clear to me that the ability to
 record your plugins  platforms in config.xml is a big step up.
 
 I do have some specific comments about the current design though:
 
 - Right now the plugin save saves all plugins to config.xml rather than
 just explicitly-installed plugins.

I agree, it should only save the explicitly installed plugins but I could
not see an easy way to extract that info and did not want to spend too
much time on it at the beginning.

   - For the shrinkwrap use-case, you actually do want to record dependent
 plugins and their versions though, so it's still important for this case.

agreed. 

 - Plugin restore doesn't work for locally installed plugins. e.g. try it
 with mobilespec. It won't remember to look in the right spot for plugins.
 - Really don't like that feature is used, since that could be confused by
 the tools with the runtime config.xml's feature tag. Instead, I think the
 syntax PGBuild uses would be better (minus the gap:)
 http://docs.build.phonegap.com/en_US/configuring_plugins.md.html
   - Note there's a PR for adding param (CB-7142)
 

feature tag looks off place because CLI generates platforms specific
config.xml files. If CLI adopted a single config.xml file that is just
copied over instead of being modified during platform builds, the
benefit of the feature tag would be more visible.  

Below is what is generated by Eclipse Thym for Device plugin when it is
installed on config.xml, all the info for the plugin is
under one tag, which makes it easier to manage for humans and tools.

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

 When I was playing with it, I found that I wished that is would just run
 every time I added a plugin, rather than having to run the command
 explicitly afterwards. Maybe we could add an environment variable that will
 enable it while we're still experimenting? Then, too, we could make
 platform / plugin restore a part of `prepare`.

Initial implementation was actually part of the plugin add and
prepare. We did not have explicit save and restore commands at all.
Michal suggested that it was early for this feature so I came up with
the save and restore commands. 

On Eclipse Thym, I have it implemented so that every plugin installation
is saved to config.xml and plugins are auto restored when they are detected
on config.xml. I am actually keeping plugins folder at this point just
to be compatible but I hope that we can get CLI to the same stage and
make the plugins folder a temporarily generated one that is not visible
to anyone.

 
 Don't have the intention of picking up work on this in the near term, but
 wanted to at least share the feedback since I did play around with it.

No worries, as long as somebody takes time to review and merge PRs, I
can keep the ball rolling. 

--
Gorkem

Re: Feedback on cordova plugin save friends

[Gorkem Ercan]

On Tue, Aug 12, 2014 at 08:40:25PM +, Chuck Lantz wrote:
 +1
 
 That same pattern could be applied to platforms actually with an additional 
 version attribute:
 
 platform name=android version=3.5.1
   ... things like icons, splaschreens, and maybe even packaging details 
 go here ...
 /platform
 
 We could also follow a similar model if we wanted to say what top level 
 cordova version was used to create the project by using the engine element 
 from plugin.xml 
 
 engine name=cordova version=3.5.0 /

Already had a PR [1] for saving and restoring platforms, that is MIA. Is
there a specific reason why you want engines stated expilicitly,
wouldn't platforms be sufficient.

[1] https://github.com/apache/cordova-lib/pull/18


 
 -Chuck
 
 -Original Message-
 From: mmo...@google.com [mailto:mmo...@google.com] On Behalf Of Michal Mocny
 Sent: Tuesday, August 12, 2014 1:34 PM
 To: dev
 Cc: Gorkem Ercan
 Subject: Re: Feedback on cordova plugin save  friends
 
 plugin is nice, but why not just dependency as plugin.xml already uses?
  config.xml and plugin.xml share lots of tags already, why fork here?
 
 -Michal
 
 
 On Tue, Aug 12, 2014 at 4:06 PM, Andrew Grieve agri...@google.com wrote:
 
  Played around with it and it's pretty clear to me that the ability to 
  record your plugins  platforms in config.xml is a big step up.
 
  I do have some specific comments about the current design though:
 
  - Right now the plugin save saves all plugins to config.xml rather 
  than just explicitly-installed plugins.
- For the shrinkwrap use-case, you actually do want to record 
  dependent plugins and their versions though, so it's still important for 
  this case.
  - Plugin restore doesn't work for locally installed plugins. e.g. try 
  it with mobilespec. It won't remember to look in the right spot for plugins.
  - Really don't like that feature is used, since that could be 
  confused by the tools with the runtime config.xml's feature tag. 
  Instead, I think the syntax PGBuild uses would be better (minus the 
  gap:) http://docs.build.phonegap.com/en_US/configuring_plugins.md.html
- Note there's a PR for adding param (CB-7142)
 
  When I was playing with it, I found that I wished that is would just 
  run every time I added a plugin, rather than having to run the command 
  explicitly afterwards. Maybe we could add an environment variable that 
  will enable it while we're still experimenting? Then, too, we could 
  make platform / plugin restore a part of `prepare`.
 
  Don't have the intention of picking up work on this in the near term, 
  but wanted to at least share the feedback since I did play around with it.
 

Re: What's Stopping us From Independent Platform Releases

[Gorkem Ercan]

This has been discussed long enough and even for those downstream
distros and tools who will have to adjust, it is better to finalize it. 

Overall I like the plan, my major concern was with cadence releaeses gone, the 
lack of a
name/tag/version number for Cordova, and a description of its contents. Now, 
this is 
addressed with CLI and package.json file.

My +1 for this. 


On Fri, Jul 25, 2014 at 05:25:28PM -0400, Andrew Grieve wrote:
 Wanted to start a thread for everyone to share what concrete changes they'd
 like to see happen before we start having platforms being released in an
 unsynchronized fashion.
 
 I'll start :)
 
 cordova-js:
  - cordova.version returns a value computed from the cordova-js git tag.
- Let's deprecate this field
- And create cordova.platformVersion
- And update our release process to have the version set based on the
 platform's version rather than the tag within cordova-js.

What will be the value for cordova.version during deprecation period?

 
 Cordova-docs:
  - Most of the docs are not actually affected by platform versions.
  - Mainly though, it's the platform guides that are.
  - Two options that I see:
- 1) Set default version to edge  always annotate with added in
 X.X.X, removed in X.X.X
- 2) Move guides to live in platform repos and link to them from docs.
 
 cordova-cli:
   - Set version to 4.0.0 just to make it so that it doesn't map to any
 existing platform versions

Not sure if this matters. Platforms will catch up to 4.0.0 soon enough.

 
 Release Process:
   - Tag cordova-js for each platform release with PLATFORM-VERSION
   - Rewrite
 https://github.com/apache/cordova-coho/blob/master/docs/cadence-release-process.md
 as platforms-release-process

Re: When is .cordova created?

[Gorkem Ercan]

Eclipse Thym searches for config.xml and www to identify cordova
projects. config.xml can be either on the root of the project or in the
www folder.
--
Gorkem

On Mon, Jul 21, 2014 at 07:00:48PM +, Ray Camden wrote:
 Thanks all for the replies. For now, I'm simply going to look for the common 
 subdirectories (hook, plugins, platforms, and www) as a means of sniffing if 
 the project is a Cordova project.
 
 From: mmo...@google.com mmo...@google.com on behalf of Michal Mocny 
 mmo...@chromium.org
 Sent: Monday, July 21, 2014 1:42 PM
 To: dev
 Subject: Re: When is .cordova created?
 
 That directory is optional.  It will only exist if you have non standard
 config options.  When using --link-to and --copy-from, we set the config
 option { lib: { www: { uri: ..., link: true/false } } }.  We also set
 config settings for e.g. Custom platform paths and plugin search paths.

Re: [Discuss] The Future of Ripple as a Top Level ASF Project

[Gorkem Ercan]

Did this discussion concluded? What was the conclusion?

I would like to see Ripple to have a healthy future and if having it as a
sub-project on Cordova ensures it, I would like to help with that.
I think we can have one or two people from Red Hat assisting on the
maintenance of Ripple. This probably is not enough for a
top-level project but may be enough to continue as a sub-project.

Also, I know there are tools (folks from MSFT, I am looking at you) that
use ripple, they may also be ultimately interested on the well being
of the project.
--
Gorkem




On Tue, Apr 22, 2014 at 10:30 AM, Brent Lintner brent.lint...@gmail.com
wrote:

 Hey All,

 Since becoming an incubator project (being donated graciously by
 BlackBerry), Ripple has seen positive contributions.

 However, it is also apparent that the community does not seem large enough
 to sustain a project like this as a top level project (let alone an
 individual PMC).

 Three of the original contributors/creators of Ripple are now fully
 involved in a new technology startup in an unrelated field and therefore we
 no longer have the resources to support Ripple in ASF. Also, BlackBerry has
 given no resources to help since donating Ripple to the ASF (this might be
 due to a change in their internal priorities).

 Given this, I would like to propose:

 1. We find more community members willing to lead committership of the
 project, and see how that goes.

 2. We also consider the eventuality of folding Ripple into another ASF
 project, if possible. If so, it would seem Cordova is a candidate for this,
 especially given the project being one of Ripple's main focus and support.
 If the community votes for this, we should involve the Cordova community to
 gage their interests as well (I've CC'd their mailing list in this email).

 3. If the above does not work out, I would then suggest we consider the
 most unfortunate (put perhaps prudent) eventuality, which is to fail
 Ripple as an incubator project. fail is this case, not being negative.

 And, if it does fail incubation- what does ASF normally do with the
 project?

 Does it get donated back to the original party? Does it get moved to an
 open source project outside of ASF (under a different license)?

 Any insight would be appreciated!

 --
 Brent Lintner

Re: Verified Plugins Marketplace

[Gorkem Ercan]

On Fri, Jul 11, 2014 at 08:12:08AM -0700, Brian LeRoux wrote:
 this would be a good time to talk about the federation capabilities in
 Plugman and the Cordova/CLI then =)
 
 time for:
 
 `cordova registry add telerik http://plugins.telerik.com/  cordova set
 registry telerik`
 
 (or something like that)

I second that and would help with its implementation. It requires a bit
of agreement though, Cordova CLI has the logic to support npmjs based repos at
this time. It would probably be better, if we can just define a set of REST
APIs for registries to provide and always do the installation through
git. 

 
 
 
 On Fri, Jul 11, 2014 at 7:51 AM, Rob Lauer rob.la...@telerik.com wrote:
 
  Hi Cordova Team,
 
  My name is Rob Lauer and I'm the Product Manager for AppBuilder here at
  Telerik. I'm writing to let you know that we just released our brand new
  Verified Plugins Marketplace for custom Cordova plugins. It's available
  today, for free of course, at plugins.telerik.com
  http://plugins.telerik.com/.
 
  This site is meant to serve as a curated list of high value Cordova
  plugins that we have tested, verified, documented, and used to create
  simple sample apps (with Kendo UI) for hybrid developers. Our primary goal
  for this site is to ease some of the pain developers experience when
  choosing and implementing custom plugins - and thereby boosting the profile
  of hybrid development in general. We are not trying to compete with
  plugins.cordova.io or other existing plugin catalogs - we expect to
  maintain a smaller, maintainable, set of plugins. There is more information
  available at this blog post
  http://blogs.telerik.com/blogs/14-07-11/verified-plugins-marketplace-your-source-for-verified-cordova-phonegap-plugins
  if you are curious.
 
  We also have a UserVoice portal
  http://telerik-verified-plugins.uservoice.com/ to solicit opinions on
  which plugins we should include next. Please try it all out and let me know
  what you think!
 
  Thanks,
  Rob Lauer | Product Manager at Telerik
  @rdlauerhttp://twitter.com/rdlauer
 
 

Re: Directory Structure - CLI directory config proposal

[Gorkem Ercan]

On Tue, Jul 08, 2014 at 09:02:03AM -0400, Michal Mocny wrote:
 Lets see what Lisa had in mind, but I always assumed it fit into
 .cordova/config.json.
 

Do you consider the contents of .cordova/config.json to be shared among
developers of a project.


 
 On Tue, Jul 8, 2014 at 8:46 AM, Andrew Grieve agri...@chromium.org wrote:
 
  Wondering what this will look like. config.xml settings?
  .cordova/config.json? A new config file?
 
 
  On Mon, Jul 7, 2014 at 2:43 PM, Parashuram Narasimhan (MS OPEN TECH) 
  panar...@microsoft.com wrote:
 
   +1 to this proposal. If we are able to agree on a proposal, we can
   contribute with code too.
  
   -Original Message-
   From: mmo...@google.com [mailto:mmo...@google.com] On Behalf Of Michal
   Mocny
   Sent: Monday, July 7, 2014 7:52 AM
   To: dev
   Subject: Re: Directory Structure - CLI directory config proposal
  
   I'd like to see this happen.
  
   Specifically, I would like to see support for a directory structure like
   this:
  
   MyApp/
 cordova_components/
   platforms/
   plugins/
 bower_components/...
 node_modules/...
 ...Rest of contents of MyApp are basically www/
  
   And this cannot use a symlink from MyApp/cordova_components/www/ to MyApp
   for obvious reasons.
  
   Basically, this would allow adding cordova to an existing project, as
   opposed to creating a new cordova workspace.  It also plays nicer will
  all
   the other tools.
  
   -Michal
  
  
   On Mon, Jul 7, 2014 at 10:41 AM, Lisa Seacat DeLuca ldel...@us.ibm.com
   wrote:
  
I wanted to start a discussion on this dev list about potentially
adding a config setting for the CLI that defines the directory
structure to use for creating and building cordova projects.  There
are many products that are built on top of Cordova that have different
directory structures than Cordova.  This can be scary to the product
teams when it comes to migration as there is no guarantee that the
directory structure for Cordova isn't going to drastically change.
   
Is anyone aware of any semantic issues that would cause problems by
creating the proposed config setting?
   
   
Lisa
   
Lisa Seacat DeLuca
Mobile Engineer | t: +415.787.4589 | *ldel...@apache.org*
ldel...@apache.org | | *ldel...@us.ibm.com* ldel...@us.ibm.com |
*lisaseacat.com* http://www.lisaseacat.com/ | [image: follow
@LisaSeacat on twitter] http://www.twitter.com/LisaSeacat| [image:
follow Lisa Seacat DeLuca on linkedin]
http://www.linkedin.com/in/lisaseacat
  
 

usenpm and old versions

[Gorkem Ercan]

Hi All,
Is there a plan to provide the older Cordova versions of the platforms on
npm. At the moment only version 3.5.0 is available, I think one of the
value adds with usenpm is the ability to use older versions.
--
Gorkem

Re: usenpm and old versions

[Gorkem Ercan]

I imagine versions greater than 3.0.0 would be the target. I have doubts
that CLI can support earlier versions (may even choke on some of the 3.0.0
versions).

I am OK with uploading only the latest patched versions so that we would
have to do less.
--
Gorkem

On Fri, Jun 27, 2014 at 9:06 AM, Ian Clelland iclell...@chromium.org
wrote:

 I don't think it's been discussed at all on this list, so no, I don't think
 there's a plan.

 If someone wanted to take the time to package them up, then I don't think
 they would be blocked at all. It was all released previously, so it's a
 matter of repackaging now.

 One topic of discussion for this list, though, would be which versions to
 make available? It might be considered poor form to add, say, any release
 which has unpatched reported security vulnerabilities. (But should be fine
 to add the version that includes the patch instead)


 On Fri, Jun 27, 2014 at 8:43 AM, Gorkem Ercan gorkem.er...@gmail.com
 wrote:

  Hi All,
  Is there a plan to provide the older Cordova versions of the platforms on
  npm. At the moment only version 3.5.0 is available, I think one of the
  value adds with usenpm is the ability to use older versions.
  --
  Gorkem
 

Re: usenpm and old versions

[Gorkem Ercan]

On Fri, Jun 27, 2014 at 09:53:20AM -0400, Mark Koudritsky wrote:
 Is it really worth it?

Cordova packages are consumed in different ways. This will create the
inconvinience of changing retrieval logic with versions for things like
CI tools, and IDEs. It is just a matter of being kind to those folks.

 git clone --branch=your favorite tag platform-repo
 cordova platform add /dir/where/it/cloned
 is not much longer and gives you full control at what version exactly you
 are getting. In addition it provides an indication that this is not the
 most recommended way and one should know what he is doing when explicitly
 asking for an older version.

Which raises the question why do we have download logic as part of the
CLI at all? 
--
Gorkem

Re: How to initialize a Cordova project using CLI if I only have the www directory of the project?

[Gorkem Ercan]

see
http://stackoverflow.com/questions/24196703/create-a-project-using-my-app-as-a-starter-in-phonegap


On Wed, Jun 25, 2014 at 10:47 AM, German Viscuso germanvisc...@gmail.com
wrote:

 Ok thanks. But that's exactly what I don't know how to do (can you
 point me to a doc or something?).
 That's my fork of your project, remember I asked permission via Twitter? :)
 Best.
 German

 On Tue, Jun 24, 2014 at 9:58 PM, Ray Camden rayca...@adobe.com wrote:
  The CLI allows you to copy from a folder to 'seed' a new project. I'd
 use that.
 
  Interesting - CowTipLine is my app - but that's not my repo. :)
 
  
  From: German Viscuso germanvisc...@gmail.com
  Sent: Tuesday, June 24, 2014 12:23 PM
  To: dev@cordova.apache.org
  Subject: How to initialize a Cordova project using CLI if I only have
 the www directory of the project?
 
  I'm new to Phonegap/Cordova and I installed the latest Cordova CLI via
  npm. I have a couple of projects that I want to build/run but the root
  dir seems to be only what you'd find on a www directory of a Cordova
  project:
 
  https://github.com/phonegap/phonegap-app-anyconference (Phonegap 2.9)
 
  https://github.com/germanviscuso/CowTipLine (Phonegap 2.0)
 
  How can I initialize/upgrade a Cordova project with these projects? I
  just want to be able to build and run these project using the latest
  Cordova CLI. Note that the 2nd project runs on a rather old version of
  Phonegap.
 
  I tried phonegap local run android when in the
  phonegap-app-anyconference directory and it doesn't work.
 
  Best! Thx a lot.

Re: CLI implementation for the save and restore plugins

[Gorkem Ercan]

I was planning to add it when I got the restore/save platforms in but I
can send an early PR.
--
Gorkem


On Wed, May 21, 2014 at 9:47 AM, Brian LeRoux b...@brian.io wrote:

 yes: pls!


 On Wed, May 21, 2014 at 4:40 AM, Marcel Kinard cmarc...@gmail.com wrote:

  Should experimental commands be listed in cordova-cli/doc/help.txt? I’m
  tempted to say yes if they are there for people to use, as long as they
 are
  marked experimental. I’d say no if they are meant to be hidden from
 users.
 
  Begin forwarded message:
 
   From: mmo...@apache.org
   Subject: git commit: CLI implementation for the save and restore
 plugins
   Date: May 20, 2014 at 11:06:05 AM EDT
   To: comm...@cordova.apache.org
   Reply-To: dev@cordova.apache.org
  
   Repository: cordova-cli
   Updated Branches:
refs/heads/master ee34eeefc - 6613b47d9
  
  
   CLI implementation for the save and restore plugins
  
   Adds a new save command to CLI which persists the currently added
  plugins to config.xml. There
   is also an accompanying restore command which scans the config.xml and
   restores the missing plugins that are listed.
 
 

Re: CLI implementation for the save and restore plugins

[Gorkem Ercan]

PR sent..
https://github.com/apache/cordova-cli/pull/177


On Wed, May 21, 2014 at 11:29 AM, Brian LeRoux b...@brian.io wrote:

 Mark em as experimental so ppl know we'll change them. Fairly common
 practice in frontend dev frameworks and Node.


They are marked experimental both on CLI and docs




 On Wed, May 21, 2014 at 9:35 AM, Michal Mocny mmo...@chromium.org wrote:

  Fair enough.  I guess I expected for you to run across this experiment
 via
  an outlet such as: Hey guys, check out ___. You use it as such.. (docs
  inline), and not by casually reading the CLI docs some day.
 
  But anyway, Gorkem has volunteered to document it, and I guess having a
  central place to update instructions as things change is good, so thats
  that.
 
  -Michal
 
 
  On Wed, May 21, 2014 at 10:28 AM, Ray Camden rayca...@adobe.com wrote:
 
   If the intent is for us to test them, then they should be documented.
 If
  I
   run across something and _don't_ see a doc, I get more upset about that
   then anything else. Just make it clear it is an experiment and it may
   change in the future.
   
   From: mmo...@google.com mmo...@google.com on behalf of Michal Mocny
 
   mmo...@chromium.org
   Sent: Wednesday, May 21, 2014 9:24 AM
   To: dev
   Subject: Re: CLI implementation for the save and restore plugins
  
   In theory, but I think the point for now was that we aren't sure about
  the
   syntax and semantics.  We should probably reach out using various
  channels
   to get users to try it and chime in, but its really early to start
   documenting lest users get upset when it breaks.
  
  
   On Wed, May 21, 2014 at 10:16 AM, Gorkem Ercan gorkem.er...@gmail.com
   wrote:
  
I was planning to add it when I got the restore/save platforms in
  but I
can send an early PR.
--
Gorkem
  
  
 

Re: [GitHub] cordova-cli pull request: CB-6469 - Restore plugins from config.xm...

[Gorkem Ercan]

 distributed under the License is distributed on an
  +AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
  +KIND, either express or implied.  See the License for the
  +specific language governing permissions and limitations
  +under the License.
  +*/
  +
  +var cordova_util= require('./util'),
  +ConfigParser = require('./ConfigParser'),
  +path = require('path'),
  +xml  = require('../util/xml-helpers')
  +Q= require('q'),
  +events   = require('./events');
  +
  +module.exports = function save(target){
  +  var projectHome = cordova_util.cdProjectRoot();
  +  var configPath = cordova_util.projectConfig(projectHome);
  +  var configXml = new ConfigParser(configPath);
  +  var pluginsPath = path.join(projectHome, 'plugins');
  +  var plugins = cordova_util.findPlugins(pluginsPath);
  +  var features =
  configXml.doc.findall('./feature/param[@name=id]/..');
  +  //clear obsolete features with id params.
  +  for(var i=0; ifeatures.length; i++){
  + //somehow elementtree remove fails on me
   + var childs = configXml.doc.getroot().getchildren();
  + var idx = childs.indexOf(features[i]);
  + if(idx  -1){
  +childs.splice(idx,1);
  +  }
  +  }
  +  // persist the removed features here if there are no plugins
  +  // to be added to config.xml otherwise we can delay the
  +  // persist to add feature
  +  if((!plugins || plugins.length1) 
  +(features  features.length)){
  +  configXml.write();
  +  }
  +
  +  return Q.all(plugins.map(function(plugin){
  +var currentPluginPath = path.join(pluginsPath,plugin);
  +var name = readPluginName(currentPluginPath);
  +var id = plugin;
  +var version = readPluginVersion(currentPluginPath);
  +var params = [{name:id, value:id},{name:version, value:
  version}];
  +configXml.addFeature(name,params);
  +configXml.write();
  +events.emit('results', 'Saved plugin info for '+plugin+' to
  config.xml');
  +return Q();
  +  }));
  +}
  +
  +function readPluginName(pluginPath){
  +var xml_path = path.join(pluginPath, 'plugin.xml');
  +var et = xml.parseElementtreeSync(xml_path);
  +var el = et.getroot().find('name');
  +if(el  el.text){
  +   return el.text.trim();
  +}
  +return ;
  +}
  +
  +function readPluginVersion(pluginPath){
  +var xml_path = path.join(pluginPath, 'plugin.xml');
  +var et = xml.parseElementtreeSync(xml_path);
  +var version = et.getroot().attrib.version;
  +return version;
  +}
 
 
 
   On Tue, May 6, 2014 at 11:20 AM, Gorkem Ercan gorkem.er...@gmail.com
 wrote:
 
  Any updates for me?
  --
  Gorkem
 
 
  On Fri, Apr 18, 2014 at 10:21 PM, Michal Mocny mmo...@chromium.org
  wrote:
 
   On Fri, Apr 18, 2014 at 4:11 PM, Gorkem Ercan 
 gorkem.er...@gmail.com
   wrote:
  
On Thu, Apr 17, 2014 at 3:46 PM, Michal Mocny 
 mmo...@chromium.org
   wrote:
   
 Took a quick glance.  General questions:
 - why the need for save?  Why not just alter the list on each
  cordova
 plugin add/rm?

   
I do not want to force this workflow. Calling save does not bring
  much
overhead, considering plugin list does not probably change
  constantly.
   
  
   If you are going to make this choice, then I would not like to
   automatically install on prepare.  There should be an explicit
 load
   command.  (those names are wrong, but you get the point).
  
   Either we automatically manage plugin installs, or explicitly manage
  them.
I'm happy to start with explicit and support opt-in to automatic
  handling
   later once we have confidence in the feature.
  
  
   
   
 - wouldn't cordova plugin rm foo  cordova prepare re-install
  that
 plugin right now?

   
This workflow would require an explicit update to config.xml if a
  plugin
   is
persisted in there. This is a good point, I shall update plugins
 rm
  to
print a warning about it.
  
  
   
 - why the name feature and not dependency ?  I think this
functionality
 should overlap with the plugin.xml spec.


feature tag lives in the w3c widget spec which has advantages for
  those
(like myself)  who does provide tools for editing config,xml.
   
  
   We are no longer using that spec, and I as we move more
 functionality
  from
   plugins.xml into config.xml we should strive to keep them in line.
   It also
   makes our docs easier.
  
  
   
   
   
 I haven't put the PR through testing yet.


 On Thu, Apr 17, 2014 at 5:54 PM, Jesse purplecabb...@gmail.com
 
   wrote:

  Yeah, that looks weird.
 
  @purplecabbage
  risingj.com
 
 
  On Thu, Apr 17, 2014 at 2:46 PM, kamrik g...@git.apache.org
  wrote:
 
   Github user kamrik commented on a diff in the pull request:
  
  

  https://github.com/apache/cordova-cli/pull/165#discussion_r11755812
  
   --- Diff

Re: [GitHub] cordova-cli pull request: CB-6469 - Restore plugins from config.xm...

[Gorkem Ercan]

New PRs created

https://github.com/apache/cordova-lib/pull/6
https://github.com/apache/cordova-cli/pull/176


On Tue, May 13, 2014 at 9:07 PM, gorkem g...@git.apache.org wrote:

 Github user gorkem closed the pull request at:

 https://github.com/apache/cordova-cli/pull/165


 ---
 If your project is set up for it, you can reply to this email and have your
 reply appear on GitHub as well. If your project does not have this feature
 enabled and wishes so, or if the feature is enabled but not working, please
 contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
 with INFRA.
 ---

Re: [GitHub] cordova-cli pull request: CB-6469 - Restore plugins from config.xm...

[Gorkem Ercan]

Any updates for me?
--
Gorkem


On Fri, Apr 18, 2014 at 10:21 PM, Michal Mocny mmo...@chromium.org wrote:

 On Fri, Apr 18, 2014 at 4:11 PM, Gorkem Ercan gorkem.er...@gmail.com
 wrote:

  On Thu, Apr 17, 2014 at 3:46 PM, Michal Mocny mmo...@chromium.org
 wrote:
 
   Took a quick glance.  General questions:
   - why the need for save?  Why not just alter the list on each cordova
   plugin add/rm?
  
 
  I do not want to force this workflow. Calling save does not bring much
  overhead, considering plugin list does not probably change constantly.
 

 If you are going to make this choice, then I would not like to
 automatically install on prepare.  There should be an explicit load
 command.  (those names are wrong, but you get the point).

 Either we automatically manage plugin installs, or explicitly manage them.
  I'm happy to start with explicit and support opt-in to automatic handling
 later once we have confidence in the feature.


 
 
   - wouldn't cordova plugin rm foo  cordova prepare re-install that
   plugin right now?
  
 
  This workflow would require an explicit update to config.xml if a plugin
 is
  persisted in there. This is a good point, I shall update plugins rm to
  print a warning about it.


 
   - why the name feature and not dependency ?  I think this
  functionality
   should overlap with the plugin.xml spec.
  
  
  feature tag lives in the w3c widget spec which has advantages for those
  (like myself)  who does provide tools for editing config,xml.
 

 We are no longer using that spec, and I as we move more functionality from
 plugins.xml into config.xml we should strive to keep them in line.  It also
 makes our docs easier.


 
 
 
   I haven't put the PR through testing yet.
  
  
   On Thu, Apr 17, 2014 at 5:54 PM, Jesse purplecabb...@gmail.com
 wrote:
  
Yeah, that looks weird.
   
@purplecabbage
risingj.com
   
   
On Thu, Apr 17, 2014 at 2:46 PM, kamrik g...@git.apache.org wrote:
   
 Github user kamrik commented on a diff in the pull request:


   https://github.com/apache/cordova-cli/pull/165#discussion_r11755812

 --- Diff: src/save.js ---
 @@ -0,0 +1,71 @@
 +/**
 +Licensed to the Apache Software Foundation (ASF) under one
 +or more contributor license agreements.  See the NOTICE
 file
 +distributed with this work for additional information
 +regarding copyright ownership.  The ASF licenses this file
 +to you under the Apache License, Version 2.0 (the
 +License); you may not use this file except in compliance
 +with the License.  You may obtain a copy of the License at
 +
 +http://www.apache.org/licenses/LICENSE-2.0
 +
 +Unless required by applicable law or agreed to in writing,
 +software distributed under the License is distributed on
 an
 +AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
 +KIND, either express or implied.  See the License for the
 +specific language governing permissions and limitations
 +under the License.
 +*/
 +
 +var cordova_util = require('./util'),
 +ConfigParser = require('./ConfigParser'),
 +path = require('path'),
 +xml  =require('./xml-helpers')
 +Q= require('q'),
 +events   = require('./events');
 +
 +;
 +
 +
 +module.exports = function save(target){
 +  var projectHome = cordova_util.cdProjectRoot();
 +  var configPath = cordova_util.projectConfig(projectHome);
 +  var configXml = new ConfigParser(configPath);
 +  var pluginsPath = path.join(projectHome, 'plugins');
 +  var plugins = cordova_util.findPlugins(pluginsPath);
 +
 +  return Q.all(plugins.map(function(plugin){
 +var currentPluginPath = path.join(pluginsPath,plugin);
 +var name = readPluginName(currentPluginPath);
 +var id = plugin;
 +var version = readPluginVersion(currentPluginPath);
 +var features = configXml.doc.findall('feature');
 +  for(var i=0; ifeatures.length; i++){
 +if(features[i].attrib.name === name){
 +  events.emit('results', 'An entry for '+ plugin+ '
already
 exists');
 +  return Q();
 +}
 +  }
 +configXml.addFeature(name, JSON.parse('[{name:id,
 value:'+id+'},{name:version, value:'+version+'}]'));
 --- End diff --

 I might be missing something, but why JSON.parse() rather than
  just
 literal array of objects?


 ---
 If your project is set up for it, you can reply to this email and
  have
your
 reply appear on GitHub as well. If your project does not have this
feature

Re: [GitHub] cordova-cli pull request: CB-6469 - Restore plugins from config.xm...

[Gorkem Ercan]

I would appreciate it if someone can have a final look and get this in.. I
have doc updates to follow.
Thanks
--
Gorkem


On Fri, Apr 25, 2014 at 4:37 PM, Gorkem Ercan gorkem.er...@gmail.comwrote:

 FYI. Just updated the PR with separated save  restore commands.
 --
 Gorkem


 On Thu, Apr 24, 2014 at 7:21 PM, Gorkem Ercan gorkem.er...@gmail.comwrote:

 I guess this is essentially moving save command as a flag to cordova
 plugin * commands and restore becomes harder to discover. We need to
 consider the platforms too since next stop is implementing cordova
 save/restore platforms
 --
 Gorkem


 On Thu, Apr 24, 2014 at 5:05 PM, Michal Mocny mmo...@chromium.orgwrote:

 Gorkem,

 I also found an old JIRA duplicate issue for this which had listed an old
 suggestion I think is interesting:
 https://issues.apache.org/jira/browse/CB-4624

 Specifically, instead of introducing save/restore commands, we could
 mirror
 npm install and its use of --save:
 - npm install - cordova plugin add
   - restores deps
 - npm install foo - cordova plugin add foo
   - install foo, but don't add it to deps
 - npm install foo --save - cordova plugin add foo --save
   - install foo, and do add it to deps
 - npm install --save - cordova plugin add --save
   - don't install anything, just save the current installed plugins into
 deps

 Just something to consider.

 (note, just tried it again and npm install --save doesn't actually do
 what
 I want.. wonder if its supported..)

 -Michal


 On Wed, Apr 23, 2014 at 11:39 PM, Michal Mocny mmo...@chromium.org
 wrote:

  Gorkem, as an orthogonal issue to the syntax we use, I think there is
  another small problem with this patch as-is.
 
  cordova plugin add org.apache.cordova.file-transfer  cordova plugin
  save would have my application explicitly depend on
  org.apache.cordova.file.  If in the future the dependency is
  removed/moved/renamed, my app would explicitly try to install it when
  running cordova plugin restore.
 
  As a first version I think this is acceptable, but I think we may want
 a
  better solution eventually.
 
 
  On Tue, Apr 22, 2014 at 1:18 PM, Michal Mocny mmo...@chromium.org
 wrote:
 
 
 
 
  On Tue, Apr 22, 2014 at 11:37 AM, Gorkem Ercan 
 gorkem.er...@gmail.comwrote:
 
  On Fri, Apr 18, 2014 at 7:21 PM, Michal Mocny mmo...@chromium.org
  wrote:
 
   On Fri, Apr 18, 2014 at 4:11 PM, Gorkem Ercan 
 gorkem.er...@gmail.com
   wrote:
  
On Thu, Apr 17, 2014 at 3:46 PM, Michal Mocny 
 mmo...@chromium.org
   wrote:
   
 Took a quick glance.  General questions:
 - why the need for save?  Why not just alter the list on each
  cordova
 plugin add/rm?

   
I do not want to force this workflow. Calling save does not bring
  much
overhead, considering plugin list does not probably change
  constantly.
   
  
   If you are going to make this choice, then I would not like to
   automatically install on prepare.  There should be an explicit
 load
   command.  (those names are wrong, but you get the point).
  
   Either we automatically manage plugin installs, or explicitly
 manage
  them.
I'm happy to start with explicit and support opt-in to automatic
  handling
   later once we have confidence in the feature.
  
 
  Makes sense... adding a 'restore' command and removing from prepare.
 We
  can
  add an auto-restore config in the next iteration.
 
 
  Excellent, thanks.
 
 
 
 
  
  
   
   
 - wouldn't cordova plugin rm foo  cordova prepare
 re-install
  that
 plugin right now?

   
This workflow would require an explicit update to config.xml if a
  plugin
   is
persisted in there. This is a good point, I shall update plugins
 rm
  to
print a warning about it.
  
  
   
 - why the name feature and not dependency ?  I think this
functionality
 should overlap with the plugin.xml spec.


feature tag lives in the w3c widget spec which has advantages for
  those
(like myself)  who does provide tools for editing config,xml.
   
  
   We are no longer using that spec, and I as we move more
 functionality
  from
   plugins.xml into config.xml we should strive to keep them in line.
  It
  also
   makes our docs easier.
  
  
  Tools developers are people too :) I think plugin.xml and config.xml
 has
  two different audiences, I think there is a comparatively small
  intersection of developers who are interested on both. At the
 moment, we
  are pretty much within the w3c spec with the top-level config.xml
 and I
  do
  not see the benefit of breaking it.
 
 
  Actually, I am thinking about tools devs.  Namely, our tools devs who
  should be using the same config parsing and handlers for dependency
  management, etc.
 
  Anyway.  You are putting in the sweat and blood on this feature, so
 you
  get double the voting power on this as far as I'm concerned.  Still, I
  think we should bring this to the attention of the list to see how
 everyone
  feels.  Sound fair?  I'll start a quick thread

Re: [GitHub] cordova-cli pull request: CB-6469 - Restore plugins from config.xm...

[Gorkem Ercan]

FYI. Just updated the PR with separated save  restore commands.
--
Gorkem


On Thu, Apr 24, 2014 at 7:21 PM, Gorkem Ercan gorkem.er...@gmail.comwrote:

 I guess this is essentially moving save command as a flag to cordova
 plugin * commands and restore becomes harder to discover. We need to
 consider the platforms too since next stop is implementing cordova
 save/restore platforms
 --
 Gorkem


 On Thu, Apr 24, 2014 at 5:05 PM, Michal Mocny mmo...@chromium.org wrote:

 Gorkem,

 I also found an old JIRA duplicate issue for this which had listed an old
 suggestion I think is interesting:
 https://issues.apache.org/jira/browse/CB-4624

 Specifically, instead of introducing save/restore commands, we could
 mirror
 npm install and its use of --save:
 - npm install - cordova plugin add
   - restores deps
 - npm install foo - cordova plugin add foo
   - install foo, but don't add it to deps
 - npm install foo --save - cordova plugin add foo --save
   - install foo, and do add it to deps
 - npm install --save - cordova plugin add --save
   - don't install anything, just save the current installed plugins into
 deps

 Just something to consider.

 (note, just tried it again and npm install --save doesn't actually do what
 I want.. wonder if its supported..)

 -Michal


 On Wed, Apr 23, 2014 at 11:39 PM, Michal Mocny mmo...@chromium.org
 wrote:

  Gorkem, as an orthogonal issue to the syntax we use, I think there is
  another small problem with this patch as-is.
 
  cordova plugin add org.apache.cordova.file-transfer  cordova plugin
  save would have my application explicitly depend on
  org.apache.cordova.file.  If in the future the dependency is
  removed/moved/renamed, my app would explicitly try to install it when
  running cordova plugin restore.
 
  As a first version I think this is acceptable, but I think we may want a
  better solution eventually.
 
 
  On Tue, Apr 22, 2014 at 1:18 PM, Michal Mocny mmo...@chromium.org
 wrote:
 
 
 
 
  On Tue, Apr 22, 2014 at 11:37 AM, Gorkem Ercan gorkem.er...@gmail.com
 wrote:
 
  On Fri, Apr 18, 2014 at 7:21 PM, Michal Mocny mmo...@chromium.org
  wrote:
 
   On Fri, Apr 18, 2014 at 4:11 PM, Gorkem Ercan 
 gorkem.er...@gmail.com
   wrote:
  
On Thu, Apr 17, 2014 at 3:46 PM, Michal Mocny 
 mmo...@chromium.org
   wrote:
   
 Took a quick glance.  General questions:
 - why the need for save?  Why not just alter the list on each
  cordova
 plugin add/rm?

   
I do not want to force this workflow. Calling save does not bring
  much
overhead, considering plugin list does not probably change
  constantly.
   
  
   If you are going to make this choice, then I would not like to
   automatically install on prepare.  There should be an explicit
 load
   command.  (those names are wrong, but you get the point).
  
   Either we automatically manage plugin installs, or explicitly manage
  them.
I'm happy to start with explicit and support opt-in to automatic
  handling
   later once we have confidence in the feature.
  
 
  Makes sense... adding a 'restore' command and removing from prepare.
 We
  can
  add an auto-restore config in the next iteration.
 
 
  Excellent, thanks.
 
 
 
 
  
  
   
   
 - wouldn't cordova plugin rm foo  cordova prepare re-install
  that
 plugin right now?

   
This workflow would require an explicit update to config.xml if a
  plugin
   is
persisted in there. This is a good point, I shall update plugins
 rm
  to
print a warning about it.
  
  
   
 - why the name feature and not dependency ?  I think this
functionality
 should overlap with the plugin.xml spec.


feature tag lives in the w3c widget spec which has advantages for
  those
(like myself)  who does provide tools for editing config,xml.
   
  
   We are no longer using that spec, and I as we move more
 functionality
  from
   plugins.xml into config.xml we should strive to keep them in line.
  It
  also
   makes our docs easier.
  
  
  Tools developers are people too :) I think plugin.xml and config.xml
 has
  two different audiences, I think there is a comparatively small
  intersection of developers who are interested on both. At the moment,
 we
  are pretty much within the w3c spec with the top-level config.xml and
 I
  do
  not see the benefit of breaking it.
 
 
  Actually, I am thinking about tools devs.  Namely, our tools devs who
  should be using the same config parsing and handlers for dependency
  management, etc.
 
  Anyway.  You are putting in the sweat and blood on this feature, so you
  get double the voting power on this as far as I'm concerned.  Still, I
  think we should bring this to the attention of the list to see how
 everyone
  feels.  Sound fair?  I'll start a quick thread.
 
 
 
 
  
   
   
   
 I haven't put the PR through testing yet.


 On Thu, Apr 17, 2014 at 5:54 PM, Jesse purplecabb...@gmail.com
 
   wrote:

  Yeah, that looks weird

Re: [GitHub] cordova-cli pull request: CB-6469 - Restore plugins from config.xm...

[Gorkem Ercan]

My plan is to add a warning to cordova plugin rm that will remind to
explicitly call cordova save plugins to refresh the  plugin dependencies.
In a future iteration we can add a keep my dependencies always restorable
flag so that cordova plugin rm/add also do the save. (and prepare does the
auto restore)
--
Gorkem


On Wed, Apr 23, 2014 at 11:39 PM, Michal Mocny mmo...@chromium.org wrote:

 Gorkem, as an orthogonal issue to the syntax we use, I think there is
 another small problem with this patch as-is.

 cordova plugin add org.apache.cordova.file-transfer  cordova plugin
 save would have my application explicitly depend on
 org.apache.cordova.file.  If in the future the dependency is
 removed/moved/renamed, my app would explicitly try to install it when
 running cordova plugin restore.

 As a first version I think this is acceptable, but I think we may want a
 better solution eventually.


 On Tue, Apr 22, 2014 at 1:18 PM, Michal Mocny mmo...@chromium.org wrote:

 
 
 
  On Tue, Apr 22, 2014 at 11:37 AM, Gorkem Ercan gorkem.er...@gmail.com
 wrote:
 
  On Fri, Apr 18, 2014 at 7:21 PM, Michal Mocny mmo...@chromium.org
  wrote:
 
   On Fri, Apr 18, 2014 at 4:11 PM, Gorkem Ercan gorkem.er...@gmail.com
   wrote:
  
On Thu, Apr 17, 2014 at 3:46 PM, Michal Mocny mmo...@chromium.org
   wrote:
   
 Took a quick glance.  General questions:
 - why the need for save?  Why not just alter the list on each
  cordova
 plugin add/rm?

   
I do not want to force this workflow. Calling save does not bring
 much
overhead, considering plugin list does not probably change
 constantly.
   
  
   If you are going to make this choice, then I would not like to
   automatically install on prepare.  There should be an explicit load
   command.  (those names are wrong, but you get the point).
  
   Either we automatically manage plugin installs, or explicitly manage
  them.
I'm happy to start with explicit and support opt-in to automatic
  handling
   later once we have confidence in the feature.
  
 
  Makes sense... adding a 'restore' command and removing from prepare. We
  can
  add an auto-restore config in the next iteration.
 
 
  Excellent, thanks.
 
 
 
 
  
  
   
   
 - wouldn't cordova plugin rm foo  cordova prepare re-install
  that
 plugin right now?

   
This workflow would require an explicit update to config.xml if a
  plugin
   is
persisted in there. This is a good point, I shall update plugins rm
 to
print a warning about it.
  
  
   
 - why the name feature and not dependency ?  I think this
functionality
 should overlap with the plugin.xml spec.


feature tag lives in the w3c widget spec which has advantages for
  those
(like myself)  who does provide tools for editing config,xml.
   
  
   We are no longer using that spec, and I as we move more functionality
  from
   plugins.xml into config.xml we should strive to keep them in line.  It
  also
   makes our docs easier.
  
  
  Tools developers are people too :) I think plugin.xml and config.xml has
  two different audiences, I think there is a comparatively small
  intersection of developers who are interested on both. At the moment, we
  are pretty much within the w3c spec with the top-level config.xml and I
 do
  not see the benefit of breaking it.
 
 
  Actually, I am thinking about tools devs.  Namely, our tools devs who
  should be using the same config parsing and handlers for dependency
  management, etc.
 
  Anyway.  You are putting in the sweat and blood on this feature, so you
  get double the voting power on this as far as I'm concerned.  Still, I
  think we should bring this to the attention of the list to see how
 everyone
  feels.  Sound fair?  I'll start a quick thread.
 
 
 
 
  
   
   
   
 I haven't put the PR through testing yet.


 On Thu, Apr 17, 2014 at 5:54 PM, Jesse purplecabb...@gmail.com
   wrote:

  Yeah, that looks weird.
 
  @purplecabbage
  risingj.com
 
 
  On Thu, Apr 17, 2014 at 2:46 PM, kamrik g...@git.apache.org
  wrote:
 
   Github user kamrik commented on a diff in the pull request:
  
  

 https://github.com/apache/cordova-cli/pull/165#discussion_r11755812
  
   --- Diff: src/save.js ---
   @@ -0,0 +1,71 @@
   +/**
   +Licensed to the Apache Software Foundation (ASF)
 under
  one
   +or more contributor license agreements.  See the
 NOTICE
   file
   +distributed with this work for additional information
   +regarding copyright ownership.  The ASF licenses this
  file
   +to you under the Apache License, Version 2.0 (the
   +License); you may not use this file except in
  compliance
   +with the License.  You may obtain a copy of the
  License at
   +
   +http://www.apache.org/licenses/LICENSE-2.0
   +
   +Unless required

Re: [GitHub] cordova-cli pull request: CB-6469 - Restore plugins from config.xm...

[Gorkem Ercan]

I guess this is essentially moving save command as a flag to cordova plugin
* commands and restore becomes harder to discover. We need to consider the
platforms too since next stop is implementing cordova save/restore
platforms
--
Gorkem


On Thu, Apr 24, 2014 at 5:05 PM, Michal Mocny mmo...@chromium.org wrote:

 Gorkem,

 I also found an old JIRA duplicate issue for this which had listed an old
 suggestion I think is interesting:
 https://issues.apache.org/jira/browse/CB-4624

 Specifically, instead of introducing save/restore commands, we could mirror
 npm install and its use of --save:
 - npm install - cordova plugin add
   - restores deps
 - npm install foo - cordova plugin add foo
   - install foo, but don't add it to deps
 - npm install foo --save - cordova plugin add foo --save
   - install foo, and do add it to deps
 - npm install --save - cordova plugin add --save
   - don't install anything, just save the current installed plugins into
 deps

 Just something to consider.

 (note, just tried it again and npm install --save doesn't actually do what
 I want.. wonder if its supported..)

 -Michal


 On Wed, Apr 23, 2014 at 11:39 PM, Michal Mocny mmo...@chromium.org
 wrote:

  Gorkem, as an orthogonal issue to the syntax we use, I think there is
  another small problem with this patch as-is.
 
  cordova plugin add org.apache.cordova.file-transfer  cordova plugin
  save would have my application explicitly depend on
  org.apache.cordova.file.  If in the future the dependency is
  removed/moved/renamed, my app would explicitly try to install it when
  running cordova plugin restore.
 
  As a first version I think this is acceptable, but I think we may want a
  better solution eventually.
 
 
  On Tue, Apr 22, 2014 at 1:18 PM, Michal Mocny mmo...@chromium.org
 wrote:
 
 
 
 
  On Tue, Apr 22, 2014 at 11:37 AM, Gorkem Ercan gorkem.er...@gmail.com
 wrote:
 
  On Fri, Apr 18, 2014 at 7:21 PM, Michal Mocny mmo...@chromium.org
  wrote:
 
   On Fri, Apr 18, 2014 at 4:11 PM, Gorkem Ercan 
 gorkem.er...@gmail.com
   wrote:
  
On Thu, Apr 17, 2014 at 3:46 PM, Michal Mocny mmo...@chromium.org
 
   wrote:
   
 Took a quick glance.  General questions:
 - why the need for save?  Why not just alter the list on each
  cordova
 plugin add/rm?

   
I do not want to force this workflow. Calling save does not bring
  much
overhead, considering plugin list does not probably change
  constantly.
   
  
   If you are going to make this choice, then I would not like to
   automatically install on prepare.  There should be an explicit load
   command.  (those names are wrong, but you get the point).
  
   Either we automatically manage plugin installs, or explicitly manage
  them.
I'm happy to start with explicit and support opt-in to automatic
  handling
   later once we have confidence in the feature.
  
 
  Makes sense... adding a 'restore' command and removing from prepare. We
  can
  add an auto-restore config in the next iteration.
 
 
  Excellent, thanks.
 
 
 
 
  
  
   
   
 - wouldn't cordova plugin rm foo  cordova prepare re-install
  that
 plugin right now?

   
This workflow would require an explicit update to config.xml if a
  plugin
   is
persisted in there. This is a good point, I shall update plugins rm
  to
print a warning about it.
  
  
   
 - why the name feature and not dependency ?  I think this
functionality
 should overlap with the plugin.xml spec.


feature tag lives in the w3c widget spec which has advantages for
  those
(like myself)  who does provide tools for editing config,xml.
   
  
   We are no longer using that spec, and I as we move more functionality
  from
   plugins.xml into config.xml we should strive to keep them in line.
  It
  also
   makes our docs easier.
  
  
  Tools developers are people too :) I think plugin.xml and config.xml
 has
  two different audiences, I think there is a comparatively small
  intersection of developers who are interested on both. At the moment,
 we
  are pretty much within the w3c spec with the top-level config.xml and I
  do
  not see the benefit of breaking it.
 
 
  Actually, I am thinking about tools devs.  Namely, our tools devs who
  should be using the same config parsing and handlers for dependency
  management, etc.
 
  Anyway.  You are putting in the sweat and blood on this feature, so you
  get double the voting power on this as far as I'm concerned.  Still, I
  think we should bring this to the attention of the list to see how
 everyone
  feels.  Sound fair?  I'll start a quick thread.
 
 
 
 
  
   
   
   
 I haven't put the PR through testing yet.


 On Thu, Apr 17, 2014 at 5:54 PM, Jesse purplecabb...@gmail.com
   wrote:

  Yeah, that looks weird.
 
  @purplecabbage
  risingj.com
 
 
  On Thu, Apr 17, 2014 at 2:46 PM, kamrik g...@git.apache.org
  wrote:
 
   Github user kamrik commented on a diff

Re: Looking for input on syntax to use for specifying plugin deps in config.xml

[Gorkem Ercan]

On Wed, Apr 23, 2014 at 1:26 PM, Michal Mocny mmo...@chromium.org wrote:

 Gorkem has an initial implementation posted here:
 https://github.com/apache/cordova-cli/pull/165 -- but its missing a change
 previously discussed to support explicit cordova restore instead of
 auto-restore-on-prepare.  He also made us a video:
 https://www.youtube.com/watch?v=bc60WAQdOjE

 The syntax for deps in that patch currently uses feature tags and looks
 like this:

 feature name=“Console”
   param name=“id” value=“org.apache.cordova.console” /
   param name=“version” value=“0.2.7” /
 /feature

 Whereas plugin.xml dependency tags look like:

 dependency id=org.apache.cordova.file version=1.0.1 /

 And the current platform config.xml feature tags look like: (note the
 caveat Andrew mentions that these are intended to solve a different
 problem)

 feature name=“Console”
   param name=ios-package value=CDVConsole /
 /feature


One could merge the params as below, if one day we actually have a single
config.xml file. Although id and version are planned to be used at the
build time at the moment I think something like app harness could
appreciate their existence at the runtime.

feature name=“Console”
  param name=ios-package value=CDVConsole /
  param name=“id” value=“org.apache.cordova.console” /
  param name=“version” value=“0.2.7” /
/feature



 Food for thought.

 -Michal

 On Wed, Apr 23, 2014 at 12:19 PM, purplecabbage purplecabb...@gmail.com
 wrote:

  Can we see a mock version of what this all would like in either case?
  I also withdraw my previous +1 for feature/ after Michal's
 clarification.
 
  Sent from my iPhone
 
   On Apr 23, 2014, at 9:03 AM, Michal Mocny mmo...@google.com wrote:
  
   Actually I don't think of platforms as dependencies. Your app doesn't
  need
   android to run on iOS. It needs plugins. Plugin deps may be specific to
   certain platforms, but platforms are targets.
  
   So I think dependency is not ambiguous with platforms.. Though your app
  may
   have more deps than just Cordova plugins.
   On 23 Apr 2014 10:08, Andrew Grieve agri...@chromium.org wrote:
  
   I like the param name=registry idea!
  
   The main thing I don't like about feature, is that it already means
   something different in platform config.xml:
  feature name=LocalStorage
  param name=ios-package value=CDVLocalStorage /
  /feature
  
   This means that when JS makes an exec() for LocalStorage, route it
   to CDVLocalStorage. JS-only plugins don't inject feature, and
   feature does not contain plugin IDs. If a plugin has multiple exec()
   targets, then it *must* inject multiple feature tags.
  
  
   dependency is much closer, but the meaning is not as clear in
   config.xml (e.g. apps depend on platforms as well).
  
   So, how about using cdv:plugin? Name is quite clear :).
  
  
  
  
   On Wed, Apr 23, 2014 at 12:35 AM, purplecabbage 
  purplecabb...@gmail.com
   wrote:
   I think consistency with input and output config.xml files makes more
   sense than consistency with plugin.xml. So +1 feature/
  
   Sent from my iPhone
  
   On Apr 22, 2014, at 8:06 PM, Gorkem Ercan gorkem.er...@gmail.com
   wrote:
  
   On Tue, Apr 22, 2014 at 8:44 PM, Andrew Grieve 
 agri...@chromium.org
  
   wrote:
  
   Anis - Gorkem wants feature since it works with his IDE. *Why* do
   you prefer feature?
   Just to be clear I am not trying to push for feature because it
  works
   on
   the JBoss/Eclipse IDE now. I do not mind ripping it apart and
   implementing
   a new editor if there is a good benefit. However I favor feature
   because
   it allows validation and content assist due to its XSD (I think we
  have
   discussed about this earlier) which is probably the only benefit of
  the
   xml
   markup on a configuration file these days.
  
   If we use dependency for defining the plugins to be restored it does
  not
   mean that feature magically disappears. It is still used by the
   platform
   runtimes and therefore the CLI generated config.xml files. I guess
  that
   would mean we still need to keep the documentation etc for it
 around.
  
   Also one thing that I have noticed when implementing the restore for
   plugins because all the information is given as params under
 feature
   it
   is very easily extendible. For instance if someday we want to
 support
   enterprise plugin registries, we could just add param
 name=registry
   value=http://registry.acme.corp; / and use the value on the
   implementation. Same could be done to dependency by adding another
   attribute which would break the validations etc.
  
  
  
   On Tue, Apr 22, 2014 at 6:56 PM, Anis KADRI anis.ka...@gmail.com
 
   wrote:
   I prefer feature.
  
  
   On Tue, Apr 22, 2014 at 11:41 AM, Mark Koudritsky 
  kam...@google.com
  
   wrote:
  
   I prefer the dependency syntax. It's shorter, more intuitive
 and
   consistent with plugin.xml. I don't see much value in _partial_
   compliance
   with the w3c spec.
  
  
   On Tue, Apr

Re: [GitHub] cordova-cli pull request: CB-6469 - Restore plugins from config.xm...

[Gorkem Ercan]

On Fri, Apr 18, 2014 at 7:21 PM, Michal Mocny mmo...@chromium.org wrote:

 On Fri, Apr 18, 2014 at 4:11 PM, Gorkem Ercan gorkem.er...@gmail.com
 wrote:

  On Thu, Apr 17, 2014 at 3:46 PM, Michal Mocny mmo...@chromium.org
 wrote:
 
   Took a quick glance.  General questions:
   - why the need for save?  Why not just alter the list on each cordova
   plugin add/rm?
  
 
  I do not want to force this workflow. Calling save does not bring much
  overhead, considering plugin list does not probably change constantly.
 

 If you are going to make this choice, then I would not like to
 automatically install on prepare.  There should be an explicit load
 command.  (those names are wrong, but you get the point).

 Either we automatically manage plugin installs, or explicitly manage them.
  I'm happy to start with explicit and support opt-in to automatic handling
 later once we have confidence in the feature.


Makes sense... adding a 'restore' command and removing from prepare. We can
add an auto-restore config in the next iteration.




 
 
   - wouldn't cordova plugin rm foo  cordova prepare re-install that
   plugin right now?
  
 
  This workflow would require an explicit update to config.xml if a plugin
 is
  persisted in there. This is a good point, I shall update plugins rm to
  print a warning about it.


 
   - why the name feature and not dependency ?  I think this
  functionality
   should overlap with the plugin.xml spec.
  
  
  feature tag lives in the w3c widget spec which has advantages for those
  (like myself)  who does provide tools for editing config,xml.
 

 We are no longer using that spec, and I as we move more functionality from
 plugins.xml into config.xml we should strive to keep them in line.  It also
 makes our docs easier.


Tools developers are people too :) I think plugin.xml and config.xml has
two different audiences, I think there is a comparatively small
intersection of developers who are interested on both. At the moment, we
are pretty much within the w3c spec with the top-level config.xml and I do
not see the benefit of breaking it.



 
 
 
   I haven't put the PR through testing yet.
  
  
   On Thu, Apr 17, 2014 at 5:54 PM, Jesse purplecabb...@gmail.com
 wrote:
  
Yeah, that looks weird.
   
@purplecabbage
risingj.com
   
   
On Thu, Apr 17, 2014 at 2:46 PM, kamrik g...@git.apache.org wrote:
   
 Github user kamrik commented on a diff in the pull request:


   https://github.com/apache/cordova-cli/pull/165#discussion_r11755812

 --- Diff: src/save.js ---
 @@ -0,0 +1,71 @@
 +/**
 +Licensed to the Apache Software Foundation (ASF) under one
 +or more contributor license agreements.  See the NOTICE
 file
 +distributed with this work for additional information
 +regarding copyright ownership.  The ASF licenses this file
 +to you under the Apache License, Version 2.0 (the
 +License); you may not use this file except in compliance
 +with the License.  You may obtain a copy of the License at
 +
 +http://www.apache.org/licenses/LICENSE-2.0
 +
 +Unless required by applicable law or agreed to in writing,
 +software distributed under the License is distributed on
 an
 +AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
 +KIND, either express or implied.  See the License for the
 +specific language governing permissions and limitations
 +under the License.
 +*/
 +
 +var cordova_util = require('./util'),
 +ConfigParser = require('./ConfigParser'),
 +path = require('path'),
 +xml  =require('./xml-helpers')
 +Q= require('q'),
 +events   = require('./events');
 +
 +;
 +
 +
 +module.exports = function save(target){
 +  var projectHome = cordova_util.cdProjectRoot();
 +  var configPath = cordova_util.projectConfig(projectHome);
 +  var configXml = new ConfigParser(configPath);
 +  var pluginsPath = path.join(projectHome, 'plugins');
 +  var plugins = cordova_util.findPlugins(pluginsPath);
 +
 +  return Q.all(plugins.map(function(plugin){
 +var currentPluginPath = path.join(pluginsPath,plugin);
 +var name = readPluginName(currentPluginPath);
 +var id = plugin;
 +var version = readPluginVersion(currentPluginPath);
 +var features = configXml.doc.findall('feature');
 +  for(var i=0; ifeatures.length; i++){
 +if(features[i].attrib.name === name){
 +  events.emit('results', 'An entry for '+ plugin+ '
already
 exists');
 +  return Q();
 +}
 +  }
 +configXml.addFeature

Re: [Discuss] The Future of Ripple as a Top Level ASF Project

[Gorkem Ercan]

+1 for moving to Cordova...

JBoss IDE uses base Ripple and with some extensions to it. I will ping Red
Hat committers if we can contribute some of that to Ripple.
--
Gorkem


On Tuesday, April 22, 2014, Shazron shaz...@gmail.com wrote:

 +1 on absorbing Ripple


 On Tue, Apr 22, 2014 at 8:16 AM, Joe Bowser bows...@gmail.comjavascript:;
 wrote:

  On Tue, Apr 22, 2014 at 7:30 AM, Brent Lintner 
  brent.lint...@gmail.comjavascript:;
 
  wrote:
   Hey All,
  
   Since becoming an incubator project (being donated graciously by
   BlackBerry), Ripple has seen positive contributions.
  
   However, it is also apparent that the community does not seem large
  enough
   to sustain a project like this as a top level project (let alone an
   individual PMC).
  
   Three of the original contributors/creators of Ripple are now fully
   involved in a new technology startup in an unrelated field and
 therefore
  we
   no longer have the resources to support Ripple in ASF. Also, BlackBerry
  has
   given no resources to help since donating Ripple to the ASF (this might
  be
   due to a change in their internal priorities).
  
   Given this, I would like to propose:
  
   1. We find more community members willing to lead committership of the
   project, and see how that goes.
  
   2. We also consider the eventuality of folding Ripple into another ASF
   project, if possible. If so, it would seem Cordova is a candidate for
  this,
   especially given the project being one of Ripple's main focus and
  support.
   If the community votes for this, we should involve the Cordova
 community
  to
   gage their interests as well (I've CC'd their mailing list in this
  email).
 
  I'd +1 this.  I'd like to see Ripple live on in some form if people
  are still using it, even though I don't use it personally.
 
  
   3. If the above does not work out, I would then suggest we consider the
   most unfortunate (put perhaps prudent) eventuality, which is to fail
   Ripple as an incubator project. fail is this case, not being
 negative.
  
 
  So, Incubator projects can't go into the Attic? That's what the ASF
  does with projects that become inactive after they leave incubator.
  I'm sure the ASF doesn't want to get into the habit of taking
  abandoned projects and shoving everything into the attic, so I'd
  rather see it get included in Cordova as one of the less active
  repositories.
 

Re: Looking for input on syntax to use for specifying plugin deps in config.xml

[Gorkem Ercan]

On Tue, Apr 22, 2014 at 8:44 PM, Andrew Grieve agri...@chromium.org wrote:

 Anis - Gorkem wants feature since it works with his IDE. *Why* do
 you prefer feature?


Just to be clear I am not trying to push for feature because it works on
the JBoss/Eclipse IDE now. I do not mind ripping it apart and implementing
a new editor if there is a good benefit. However I favor feature because
it allows validation and content assist due to its XSD (I think we have
discussed about this earlier) which is probably the only benefit of the xml
markup on a configuration file these days.

If we use dependency for defining the plugins to be restored it does not
mean that feature magically disappears. It is still used by the platform
runtimes and therefore the CLI generated config.xml files. I guess that
would mean we still need to keep the documentation etc for it around.

Also one thing that I have noticed when implementing the restore for
plugins because all the information is given as params under feature it
is very easily extendible. For instance if someday we want to support
enterprise plugin registries, we could just add param name=registry
value=http://registry.acme.corp; / and use the value on the
implementation. Same could be done to dependency by adding another
attribute which would break the validations etc.



 On Tue, Apr 22, 2014 at 6:56 PM, Anis KADRI anis.ka...@gmail.com wrote:
  I prefer feature.
 
 
  On Tue, Apr 22, 2014 at 11:41 AM, Mark Koudritsky kam...@google.com
 wrote:
 
  I prefer the dependency syntax. It's shorter, more intuitive and
  consistent with plugin.xml. I don't see much value in _partial_
 compliance
  with the w3c spec.
 
 
  On Tue, Apr 22, 2014 at 1:31 PM, Michal Mocny mmo...@google.com
 wrote:
 
   Gorkem is adding awesome feature to restore plugins/platforms your app
   depends on.  There is some debate on the correct syntax to use in the
   config.xml file: do we use (a) plugin.xml style dependency tags, or
 (b)
   w3c widget spec feature tags?
  
   Gorkem votes (b), arguing that using widget spec helps his tools with
   editing config.xml (existing gui editor, I assume?), and has
 implemented
  a
   PR for it (https://github.com/apache/cordova-cli/pull/165).
  
   I vote (a), arguing that we already don't match widget spec, and
 already
   have established syntax for for specifying plugin urls  versions in
   plugin.xml (with docs and examples), and its better for our CLI
   implementation to use existing plugin deps handlers.
  
   What do you think?
  
   Background: read full thread titled [GitHub] cordova-cli pull
 request:
   CB-6469
  
 

Re: [GitHub] cordova-cli pull request: CB-6469 - Restore plugins from config.xm...

[Gorkem Ercan]

On Thu, Apr 17, 2014 at 3:46 PM, Michal Mocny mmo...@chromium.org wrote:

 Took a quick glance.  General questions:
 - why the need for save?  Why not just alter the list on each cordova
 plugin add/rm?


I do not want to force this workflow. Calling save does not bring much
overhead, considering plugin list does not probably change constantly.


 - wouldn't cordova plugin rm foo  cordova prepare re-install that
 plugin right now?


This workflow would require an explicit update to config.xml if a plugin is
persisted in there. This is a good point, I shall update plugins rm to
print a warning about it.


 - why the name feature and not dependency ?  I think this functionality
 should overlap with the plugin.xml spec.


feature tag lives in the w3c widget spec which has advantages for those
(like myself)  who does provide tools for editing config,xml.



 I haven't put the PR through testing yet.


 On Thu, Apr 17, 2014 at 5:54 PM, Jesse purplecabb...@gmail.com wrote:

  Yeah, that looks weird.
 
  @purplecabbage
  risingj.com
 
 
  On Thu, Apr 17, 2014 at 2:46 PM, kamrik g...@git.apache.org wrote:
 
   Github user kamrik commented on a diff in the pull request:
  
  
 https://github.com/apache/cordova-cli/pull/165#discussion_r11755812
  
   --- Diff: src/save.js ---
   @@ -0,0 +1,71 @@
   +/**
   +Licensed to the Apache Software Foundation (ASF) under one
   +or more contributor license agreements.  See the NOTICE file
   +distributed with this work for additional information
   +regarding copyright ownership.  The ASF licenses this file
   +to you under the Apache License, Version 2.0 (the
   +License); you may not use this file except in compliance
   +with the License.  You may obtain a copy of the License at
   +
   +http://www.apache.org/licenses/LICENSE-2.0
   +
   +Unless required by applicable law or agreed to in writing,
   +software distributed under the License is distributed on an
   +AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
   +KIND, either express or implied.  See the License for the
   +specific language governing permissions and limitations
   +under the License.
   +*/
   +
   +var cordova_util = require('./util'),
   +ConfigParser = require('./ConfigParser'),
   +path = require('path'),
   +xml  =require('./xml-helpers')
   +Q= require('q'),
   +events   = require('./events');
   +
   +;
   +
   +
   +module.exports = function save(target){
   +  var projectHome = cordova_util.cdProjectRoot();
   +  var configPath = cordova_util.projectConfig(projectHome);
   +  var configXml = new ConfigParser(configPath);
   +  var pluginsPath = path.join(projectHome, 'plugins');
   +  var plugins = cordova_util.findPlugins(pluginsPath);
   +
   +  return Q.all(plugins.map(function(plugin){
   +var currentPluginPath = path.join(pluginsPath,plugin);
   +var name = readPluginName(currentPluginPath);
   +var id = plugin;
   +var version = readPluginVersion(currentPluginPath);
   +var features = configXml.doc.findall('feature');
   +  for(var i=0; ifeatures.length; i++){
   +if(features[i].attrib.name === name){
   +  events.emit('results', 'An entry for '+ plugin+ '
  already
   exists');
   +  return Q();
   +}
   +  }
   +configXml.addFeature(name, JSON.parse('[{name:id,
   value:'+id+'},{name:version, value:'+version+'}]'));
   --- End diff --
  
   I might be missing something, but why JSON.parse() rather than just
   literal array of objects?
  
  
   ---
   If your project is set up for it, you can reply to this email and have
  your
   reply appear on GitHub as well. If your project does not have this
  feature
   enabled and wishes so, or if the feature is enabled but not working,
  please
   contact infrastructure at infrastruct...@apache.org or file a JIRA
  ticket
   with INFRA.
   ---
  
 

Re: engines and plugins on config.xml

[Gorkem Ercan]

Just opened [1] for restoring the plugins. There is also a PR attached to
the Jira. I would appreciate if someone could take a look. I also have
minor changes to plugman that will follow.

If you would like a sneak preview of the feature
https://www.youtube.com/watch?v=bc60WAQdOjE

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

--
Gorkem


On Wed, Apr 9, 2014 at 2:25 PM, Gorkem Ercan gorkem.er...@gmail.com wrote:


 Agreed, I was thinking about making the version attribute optional which
 would basically signal CLI to create platforms with the latestgreatest
 platforms releases.
 --
 Gorkem


 On Wed, Apr 9, 2014 at 12:45 PM, Michal Mocny mmo...@chromium.org wrote:

 This would be a great contribution.

 We should consider using the dependency tag for plugins, which I think
 maps well to existing specifications for urls and versions.

 For platforms, I'm fine with engine, though I don't like tieing to
 specific versions by default.  I think we should support it, but my usual
 reason for project re-creation is a trivial way to upgrade everything.

 Thanks for signing up!

 -Michal


 On Wed, Apr 9, 2014 at 12:45 PM, Andrew Grieve agri...@chromium.org
 wrote:

  Gorkem - if you implement this you'll be my hero!
 
  engine vs platform is a bit weird, because platform is already a
  thing that exists right now that is meant to mean tags within it apply
 only
  to the platform is lists. E..g
  platform name=android
preference name=foo value=3 /
  /platform
 
 
  On one hand, you could throw a version in there, but given that you can
  have multiple platform tags, it's a bit weird. I can also see the
  use-case of wanting: platform name=android|ios.
 
  So... wanted to point this out for consideration, but think that
 engine
  might be better because if this reason.
 
 
  I think the argument is more compelling to have plugins use cdv:plugin
  rather than feature. I think we'd only want:
  cdv:plugin name= version= /
  And not have end-users need to add in the param name=package-name/,
  since that's up to the plugin.xml to add in.
 
 
 
 
  On Wed, Apr 9, 2014 at 8:09 AM, Gorkem Ercan gorkem.er...@gmail.com
  wrote:
 
   I guess it could be platform as well. I put engine because that is
 what
   plugin.xml uses for its dependencies.
   --
   Gorkem
  
  
   On Wed, Apr 9, 2014 at 10:01 AM, Sebastien Blanc scm.bl...@gmail.com
   wrote:
  
I had the same idea and I really love it
but why not platform instead of engine ?
   
   
   
On Wed, Apr 9, 2014 at 5:58 PM, Gorkem Ercan 
 gorkem.er...@gmail.com
wrote:
   
 Hi,
 I would like to propose a couple of enhancements to the top level
 config.xml that would enable us to recreate a project easily.

 (Note: the examples below assumes a cdv namespace on config.xml)

 1. engines tag :

 cdv:engine id=org.apache.cordova.android version=3.5.1 /
 cdv:engine id=org.apache.cordova.ios version=3.7.0 /

 CLI could use this tag the reconstruct the platforms hence the
   platforms
 folder would really become a build artifact. I believe phonegap
 and
  the
 JBoss IDE is already using a similiar thing on the
  .cordova/config.json

 2. plugins

 feature name=Console cdv:id=org.apache.cordova.core.console
 cdv:version=0.2.8
param name=ios-package value=ConsolePlugin /
 /feature

 Alternately

 feature name=Console
  param name=id value=org.apache.cordova.core.console /
 param name=version value=0.2.8 /
  param name=ios-package value=ConsolePlugin /
 /feature

 This is reutilizing the existing feature tag. ID is the only
 missing
piece
 of information for CLI to reinstall the plugins to a project is
 the
plugin
 id and version. This would also eliminate the need to share
 plugins
folder
 with the Cordova projects. The plugins folder can still be
 utilized
  for
 plugins that were not available from plugin registry. Also if the
 id
  is
 missing on a feature tag CLI would skip restoring that plugin for
 the
 project.

 On top of this I am volunteering myself to do the work. I guess it
  will
 require a good amount of changes to CLI prepare.

 ---
 Gorkem

   
  
 

engines and plugins on config.xml

[Gorkem Ercan]

Hi,
I would like to propose a couple of enhancements to the top level
config.xml that would enable us to recreate a project easily.

(Note: the examples below assumes a cdv namespace on config.xml)

1. engines tag :

cdv:engine id=org.apache.cordova.android version=3.5.1 /
cdv:engine id=org.apache.cordova.ios version=3.7.0 /

CLI could use this tag the reconstruct the platforms hence the platforms
folder would really become a build artifact. I believe phonegap and the
JBoss IDE is already using a similiar thing on the .cordova/config.json

2. plugins

feature name=Console cdv:id=org.apache.cordova.core.console
cdv:version=0.2.8
   param name=ios-package value=ConsolePlugin /
/feature

Alternately

feature name=Console
 param name=id value=org.apache.cordova.core.console /
param name=version value=0.2.8 /
 param name=ios-package value=ConsolePlugin /
/feature

This is reutilizing the existing feature tag. ID is the only missing piece
of information for CLI to reinstall the plugins to a project is the plugin
id and version. This would also eliminate the need to share plugins folder
with the Cordova projects. The plugins folder can still be utilized for
plugins that were not available from plugin registry. Also if the id is
missing on a feature tag CLI would skip restoring that plugin for the
project.

On top of this I am volunteering myself to do the work. I guess it will
require a good amount of changes to CLI prepare.

---
Gorkem

Re: engines and plugins on config.xml

[Gorkem Ercan]

I guess it could be platform as well. I put engine because that is what
plugin.xml uses for its dependencies.
--
Gorkem


On Wed, Apr 9, 2014 at 10:01 AM, Sebastien Blanc scm.bl...@gmail.comwrote:

 I had the same idea and I really love it
 but why not platform instead of engine ?



 On Wed, Apr 9, 2014 at 5:58 PM, Gorkem Ercan gorkem.er...@gmail.com
 wrote:

  Hi,
  I would like to propose a couple of enhancements to the top level
  config.xml that would enable us to recreate a project easily.
 
  (Note: the examples below assumes a cdv namespace on config.xml)
 
  1. engines tag :
 
  cdv:engine id=org.apache.cordova.android version=3.5.1 /
  cdv:engine id=org.apache.cordova.ios version=3.7.0 /
 
  CLI could use this tag the reconstruct the platforms hence the platforms
  folder would really become a build artifact. I believe phonegap and the
  JBoss IDE is already using a similiar thing on the .cordova/config.json
 
  2. plugins
 
  feature name=Console cdv:id=org.apache.cordova.core.console
  cdv:version=0.2.8
 param name=ios-package value=ConsolePlugin /
  /feature
 
  Alternately
 
  feature name=Console
   param name=id value=org.apache.cordova.core.console /
  param name=version value=0.2.8 /
   param name=ios-package value=ConsolePlugin /
  /feature
 
  This is reutilizing the existing feature tag. ID is the only missing
 piece
  of information for CLI to reinstall the plugins to a project is the
 plugin
  id and version. This would also eliminate the need to share plugins
 folder
  with the Cordova projects. The plugins folder can still be utilized for
  plugins that were not available from plugin registry. Also if the id is
  missing on a feature tag CLI would skip restoring that plugin for the
  project.
 
  On top of this I am volunteering myself to do the work. I guess it will
  require a good amount of changes to CLI prepare.
 
  ---
  Gorkem
 

Re: engines and plugins on config.xml

[Gorkem Ercan]

Agreed, I was thinking about making the version attribute optional which
would basically signal CLI to create platforms with the latestgreatest
platforms releases.
--
Gorkem


On Wed, Apr 9, 2014 at 12:45 PM, Michal Mocny mmo...@chromium.org wrote:

 This would be a great contribution.

 We should consider using the dependency tag for plugins, which I think
 maps well to existing specifications for urls and versions.

 For platforms, I'm fine with engine, though I don't like tieing to
 specific versions by default.  I think we should support it, but my usual
 reason for project re-creation is a trivial way to upgrade everything.

 Thanks for signing up!

 -Michal


 On Wed, Apr 9, 2014 at 12:45 PM, Andrew Grieve agri...@chromium.org
 wrote:

  Gorkem - if you implement this you'll be my hero!
 
  engine vs platform is a bit weird, because platform is already a
  thing that exists right now that is meant to mean tags within it apply
 only
  to the platform is lists. E..g
  platform name=android
preference name=foo value=3 /
  /platform
 
 
  On one hand, you could throw a version in there, but given that you can
  have multiple platform tags, it's a bit weird. I can also see the
  use-case of wanting: platform name=android|ios.
 
  So... wanted to point this out for consideration, but think that engine
  might be better because if this reason.
 
 
  I think the argument is more compelling to have plugins use cdv:plugin
  rather than feature. I think we'd only want:
  cdv:plugin name= version= /
  And not have end-users need to add in the param name=package-name/,
  since that's up to the plugin.xml to add in.
 
 
 
 
  On Wed, Apr 9, 2014 at 8:09 AM, Gorkem Ercan gorkem.er...@gmail.com
  wrote:
 
   I guess it could be platform as well. I put engine because that is what
   plugin.xml uses for its dependencies.
   --
   Gorkem
  
  
   On Wed, Apr 9, 2014 at 10:01 AM, Sebastien Blanc scm.bl...@gmail.com
   wrote:
  
I had the same idea and I really love it
but why not platform instead of engine ?
   
   
   
On Wed, Apr 9, 2014 at 5:58 PM, Gorkem Ercan gorkem.er...@gmail.com
 
wrote:
   
 Hi,
 I would like to propose a couple of enhancements to the top level
 config.xml that would enable us to recreate a project easily.

 (Note: the examples below assumes a cdv namespace on config.xml)

 1. engines tag :

 cdv:engine id=org.apache.cordova.android version=3.5.1 /
 cdv:engine id=org.apache.cordova.ios version=3.7.0 /

 CLI could use this tag the reconstruct the platforms hence the
   platforms
 folder would really become a build artifact. I believe phonegap and
  the
 JBoss IDE is already using a similiar thing on the
  .cordova/config.json

 2. plugins

 feature name=Console cdv:id=org.apache.cordova.core.console
 cdv:version=0.2.8
param name=ios-package value=ConsolePlugin /
 /feature

 Alternately

 feature name=Console
  param name=id value=org.apache.cordova.core.console /
 param name=version value=0.2.8 /
  param name=ios-package value=ConsolePlugin /
 /feature

 This is reutilizing the existing feature tag. ID is the only
 missing
piece
 of information for CLI to reinstall the plugins to a project is the
plugin
 id and version. This would also eliminate the need to share plugins
folder
 with the Cordova projects. The plugins folder can still be utilized
  for
 plugins that were not available from plugin registry. Also if the
 id
  is
 missing on a feature tag CLI would skip restoring that plugin for
 the
 project.

 On top of this I am volunteering myself to do the work. I guess it
  will
 require a good amount of changes to CLI prepare.

 ---
 Gorkem

   
  
 

Re: Suggestions for a problem

[Gorkem Ercan]

I think a tool can just go through all tagged version of the CLI's
platforms.js and create the version map. I guess this effectively makes CLI
versions the Cordova version.

I was looking at the phonegap announcement[1], which got me thinking, I
think independent releases may create complications beyond the problems
like the one I had. For instance take a moment and try to imagine how one
would need to write the same announcement for an independent release.

By the way, I keep hearing that independent platform releases has not
happened yet but since iOS has a 3.4.1 release while all other platforms
are 3.4.0 and CLI is getting ready for a release that picks up iOS 3.4.1
what else is missing for it to happen?

[1] https://twitter.com/PhoneGapBuild/status/453271589803405313

--
Gorkem



On Mon, Apr 7, 2014 at 7:24 PM, Michal Mocny mmo...@chromium.org wrote:

 On Mon, Apr 7, 2014 at 7:56 PM, Shazron shaz...@gmail.com wrote:

  Looks like you will have to generate this yourself for now. But correct
 me
  if I'm wrong, if the CLI is at version X.Y.Z, wouldn't the platform
  versions be at least X.Y.Z themselves? At least for the main platforms
 

 I don't think thats what the proposal was, but as Joe says, this hasn't
 happened yet and so is still up in the air.

 Strictly speaking, if we chose to version everything with semver, the
 version numbers would diverge over time.  The specific x.y.z of one
 artifact would be meaningless when compared to other artifacts, but in
 exchange potentially more useful when compared to other versions of the
 same artifact.

 Implicitly, each release happens on a date, and CLI releases on a given
 date depend on the latest releases of each platform.  So, if you have any
 single artifact, you can get the release date, then the corresponding CLI
 release, and finally use that to map backwards to specific semver versions
 of all platforms.

 Personally, though, I'm not sure that we are using Semver to good effect at
 all, and its just hurting us.  I'd suggest we consider switching to
 versioning by date (aka the Ubuntu / Chromium / etc model).


  (android, ios, bb) this would be true I suppose, at least until 3.5.0
 (not
  sure when we are diverging).
 
  Since the CLI is tied to certain platform versions, I don't see why the
 map
  can't be auto generated.
 
 
 
 
  On Mon, Apr 7, 2014 at 4:44 PM, Gorkem Ercan gorkem.er...@gmail.com
  wrote:
 
   Would package.json carry the historical data? At the moment, my plan is
  to
   have a json file that maps CLI versions to platform version but for
 every
   version  3.0.0. It would be great if such a file is updated as part of
  the
   release of CLI though.
   --
   Gorkem
  
  
   On Mon, Apr 7, 2014 at 5:07 PM, Brian LeRoux b...@brian.io wrote:
  
Moving to independent platform releases doesn't change things other
  than
   a
mostly arbitrary number we use for issue tracking. This is the way it
   works
today:
   
CLI@X.X.X
'- cordova@X.X.X
|-ios@X.X.X
'-android@X.X.X
   
This is how it would work in the new world order:
   
CLI@X.X.X
|- ios@X.X.X
'-android@X.X.X
   
This means other tool that depends on the version locked convenience
 of
   the
Cordova release basically will want to track whatever we do with the
  CLI
instead. Convienantly we will having this in the Cordova package.json
  so,
hypothetically, this is super easy.
   
   
   
   
   
On Tue, Apr 8, 2014 at 10:24 AM, Marcel Kinard cmarc...@gmail.com
   wrote:
   
 The way I would summarize this is that enterprises need a way to
   recreate
 a specific environment. This includes our platforms, plugins,
  tooling,
and
 dependencies. Many enterprises do not desire to live on head,
 instead
they
 want to live at a known reproductable state. Before 3.0, this was
   pretty
 straightforward. After 3.0, and additionally potentially releasing
 platforms separately, our definition of a Cordova version has
   basically
 fallen apart (separate timing for plugins and tools,
  non-shrinkwrapped
npm
 dependencies, etc)

 Perhaps one way to solve this would be a Cordova version
 identifier
that
 is a map to the individual versions of all the components, similar
 to
   how
 cordova-cli/platforms.js has a version property for each platform,
  but
 include tools and even plugins. How often would it make sense to
  update
 that version-map and bump the Cordova version? There are probably
arguments
 for both a cadence schedule as well as
 anytime-any-component-changes.

 On Apr 7, 2014, at 5:00 PM, Gorkem Ercan gorkem.er...@gmail.com
   wrote:

  Hi,
  With the independent platforms releases I have started to run
 into
  a
  problem with my Eclipse tools that I am looking for some
  suggestions.
 
  In the past, Cordova X.Y.Z meant all platforms would be tagged
 and
 released
  with X.Y.Z. so

Suggestions for a problem

[Gorkem Ercan]

Hi,
With the independent platforms releases I have started to run into a
problem with my Eclipse tools that I am looking for some suggestions.

In the past, Cordova X.Y.Z meant all platforms would be tagged and released
with X.Y.Z. so if Eclipse tools needed to download Cordova version X.Y.Z,
it could just do so by using the X.Y.Z git tag. Now that platforms can do
independent releases the X.Y.Z tag for may not exist for a release for a
platform. So I actually need a way to determine what platform versions go
together. CLI actually captures that information on platforms.js for the
release but this is not enough for Eclipse tools as it does not capture the
data for older releases and Eclipse tools can be download and use older
versions.

Is there a place where I can extract this sort of platform version
information?
Also in the past, plugins could define engine compatibility as below
engine name=cordova version=1.7.0 /
How does plugman act with the independent releases now?
--
Gorkem

Re: Suggestions for a problem

[Gorkem Ercan]

 3.4.1 release exists for only iOS and CLI platforms.js is updated to
accordingly so at least it does feel like it is happening.
--
Gorkem


On Mon, Apr 7, 2014 at 3:07 PM, Anis KADRI anis.ka...@gmail.com wrote:

 Have we actually decided to move along with the plan? I thought we were
 only discussing it.


 On Mon, Apr 7, 2014 at 2:04 PM, Joe Bowser bows...@gmail.com wrote:

  We don't know yet because we're still figuring this out.
 
  On Mon, Apr 7, 2014 at 2:00 PM, Gorkem Ercan gorkem.er...@gmail.com
  wrote:
   Hi,
   With the independent platforms releases I have started to run into a
   problem with my Eclipse tools that I am looking for some suggestions.
  
   In the past, Cordova X.Y.Z meant all platforms would be tagged and
  released
   with X.Y.Z. so if Eclipse tools needed to download Cordova version
 X.Y.Z,
   it could just do so by using the X.Y.Z git tag. Now that platforms can
 do
   independent releases the X.Y.Z tag for may not exist for a release for
 a
   platform. So I actually need a way to determine what platform versions
 go
   together. CLI actually captures that information on platforms.js for
 the
   release but this is not enough for Eclipse tools as it does not capture
  the
   data for older releases and Eclipse tools can be download and use older
   versions.
  
   Is there a place where I can extract this sort of platform version
   information?
   Also in the past, plugins could define engine compatibility as below
   engine name=cordova version=1.7.0 /
   How does plugman act with the independent releases now?
   --
   Gorkem
 

Re: Suggestions for a problem

[Gorkem Ercan]

Would package.json carry the historical data? At the moment, my plan is to
have a json file that maps CLI versions to platform version but for every
version  3.0.0. It would be great if such a file is updated as part of the
release of CLI though.
--
Gorkem


On Mon, Apr 7, 2014 at 5:07 PM, Brian LeRoux b...@brian.io wrote:

 Moving to independent platform releases doesn't change things other than a
 mostly arbitrary number we use for issue tracking. This is the way it works
 today:

 CLI@X.X.X
 '- cordova@X.X.X
 |-ios@X.X.X
 '-android@X.X.X

 This is how it would work in the new world order:

 CLI@X.X.X
 |- ios@X.X.X
 '-android@X.X.X

 This means other tool that depends on the version locked convenience of the
 Cordova release basically will want to track whatever we do with the CLI
 instead. Convienantly we will having this in the Cordova package.json so,
 hypothetically, this is super easy.





 On Tue, Apr 8, 2014 at 10:24 AM, Marcel Kinard cmarc...@gmail.com wrote:

  The way I would summarize this is that enterprises need a way to recreate
  a specific environment. This includes our platforms, plugins, tooling,
 and
  dependencies. Many enterprises do not desire to live on head, instead
 they
  want to live at a known reproductable state. Before 3.0, this was pretty
  straightforward. After 3.0, and additionally potentially releasing
  platforms separately, our definition of a Cordova version has basically
  fallen apart (separate timing for plugins and tools, non-shrinkwrapped
 npm
  dependencies, etc)
 
  Perhaps one way to solve this would be a Cordova version identifier
 that
  is a map to the individual versions of all the components, similar to how
  cordova-cli/platforms.js has a version property for each platform, but
  include tools and even plugins. How often would it make sense to update
  that version-map and bump the Cordova version? There are probably
 arguments
  for both a cadence schedule as well as anytime-any-component-changes.
 
  On Apr 7, 2014, at 5:00 PM, Gorkem Ercan gorkem.er...@gmail.com wrote:
 
   Hi,
   With the independent platforms releases I have started to run into a
   problem with my Eclipse tools that I am looking for some suggestions.
  
   In the past, Cordova X.Y.Z meant all platforms would be tagged and
  released
   with X.Y.Z. so if Eclipse tools needed to download Cordova version
 X.Y.Z,
   it could just do so by using the X.Y.Z git tag. Now that platforms can
 do
   independent releases the X.Y.Z tag for may not exist for a release for
 a
   platform. So I actually need a way to determine what platform versions
 go
   together. CLI actually captures that information on platforms.js for
 the
   release but this is not enough for Eclipse tools as it does not capture
  the
   data for older releases and Eclipse tools can be download and use older
   versions.
  
   Is there a place where I can extract this sort of platform version
   information?
   Also in the past, plugins could define engine compatibility as below
   engine name=cordova version=1.7.0 /
   How does plugman act with the independent releases now?
   --
   Gorkem
 
 

Re: Blackberry copyright in js files

[Gorkem Ercan]

According to [1]. they should be removed by copyright owner.

[1] https://www.apache.org/legal/src-headers.html#headers


On Fri, Apr 4, 2014 at 4:40 PM, Bryan Higgins br...@bryanhiggins.netwrote:

 The files are all Apache 2.0 licensed.

 The 2012 headers came from code donated by RIM which was previously hosted
 on GitHub. The recent one is probably a copy/paste mistake by Josh.

 I *think* they can all be removed.


 On Fri, Apr 4, 2014 at 4:26 PM, Martin Gonzalez Glez 
 martin.c.glez.g...@gmail.com wrote:

  Hi everyone, in some blackberry files, I have noticed some blackberry
  copyright statements:
 
 
 
 https://github.com/blackberry/cordova-blackberry/blob/cb_6398/blackberry10/bin/templates/project/cordova/lib/params.js#L2
 
 
 
 https://github.com/blackberry/cordova-blackberry/blob/cb_6398/blackberry10/bin/templates/project/cordova/lib/params.js#L2
 
 
 
 https://github.com/blackberry/cordova-blackberry/blob/cb_6398/blackberry10/bin/templates/project/cordova/lib/debugtoken-helper.js#L2
 
  Something like:
 
  Copyright 2014 BlackBerry Limited.
 
  Copyright 2012 Research In Motion Limited.
 
 
  Is not supposed to all files should be under Apache License, Version
 2.0?.
 
  Just asking if this is normal?
 

Re: registry.cordova.io is down

[Gorkem Ercan]

Seems to be back to normal.
Thanks.


On Fri, Apr 4, 2014 at 8:55 PM, Anis KADRI anis.ka...@gmail.com wrote:

 Somebody (Steve maybe ?) deleted the database but there is a copy of it so
 I pointed the domain to it. Works now right ?


 On Fri, Apr 4, 2014 at 5:37 PM, Gorkem Ercan gorkem.er...@gmail.com
 wrote:

  Hi,
  couchdb responds to all doc requests as not_found deleted.
 
  CLI and plugins.cordova.io ( and others)  is broken as a result. Any
 idea
  what may be wrong?
  --
  Gorkem
 

Re: Consolidating the Distribution of Platforms Plugins

[Gorkem Ercan]

Great idea..  I especially don't like the git archive download. It does not
really allow us to track some sort of statistics reliably. I think its
replacement should allow collection of download statistics. The plugins
stats from plugman seems OK. I am not sure if npm would allow such stats.

Not that important to this discussion but I think plugman has a cache in
.plugman/cache

--
Gorkem


On Thu, Mar 13, 2014 at 11:25 AM, Andrew Grieve agri...@chromium.orgwrote:

 Right now, CLI downloads  caches platforms  plugins using two different
 mechanisms, with totally independent code paths.

 plugman uses the request library, with proxy settings in .plugman/config.
 It downloads the tars directly from registry.cordova.io. It does not cache
 them.

 CLI uses the request library as well, with proxy settings from .npmrc. It
 downloads tars directly from our git server's archive endpoint. It caches
 them in ~/.cordova.


 I'd like to propose that we unify them. Specifically:

 1. Store platforms on registry.cordova.io
   - This would allow CLI to easily see what versions of platforms are
 available, and be able to choose between them.
   - This (I'm sure), INFRA would be much happier about than our current
 fetch-from-git approach

 2. Unify CLI  Plugman's downloading logic
   - Use the same code-path for both.
   - Have them use the same caching logic.

 3. Use npm's cache logic instead of our own:
   - Just type npm help cache to see what it does
   - Would allow for: cordova cache clean

 I would *not* want to lose our support for --searchpath, as I think it's
 really handy. I don't see a problem with this though.

 This would also enable CLI to answer queries like what platform versions
 are available, and make it trivial to do install cordova-android@3.0.0

 This isn't something I have time to work on in the near future, but wanted
 to see if everyone would be onboard with the change. I'll end up just
 filing bugs for the changes if it sounds good... but if anyone else wants
 to work on it... :)

Re: 3.4.0 iOS projects under Xcode 5.1

[Gorkem Ercan]

Not sure how far away 3.5 release but I was actually thinking about a
release to pick up the fixed templates.
--
Gorkem


On Tue, Mar 11, 2014 at 5:14 PM, Shazron shaz...@gmail.com wrote:

 You will need to manually upgrade by playing around with Build Settings.
 Joy.

 See:
 https://issues.apache.org/jira/browse/CB-6223

 I think I already fixed these issues in the 3.5.0 template however...

Re: New project proposal on Eclipse.org

[Gorkem Ercan]

I guess it is close to a downstream.

From runtimes perspective it is plain Cordova. IDE actually gets the
Cordova runtime directly from Apache repos just like CLI does. You can
Bring Your Own Cordova too but if a distribution is too different from an
Apache distribution a plugin that tells where required files should come
from is needed.

For the tools, it depends on the same artifacts as plugman and CLI. Like
the plugin.xml, config.xml, registry, directory structures etc. however
does not use the CLI/plugman implementation but rather have its own
implementation.
--
Gorkem


On Mon, Mar 10, 2014 at 3:38 PM, Brian LeRoux b...@brian.io wrote:

 very cool! would you consider this downstream of Cordova or a flat out
 fork? (neither is bad, I know sometimes the word 'fork' sounds nasty but I
 view it as a healthy sign personally)


 On Fri, Mar 7, 2014 at 3:29 PM, Gorkem Ercan gorkem.er...@gmail.com
 wrote:

  Hi,
 
  Some of you have seen the cordova development tools that are part of the
  JBoss tools in the past.
  If you have not, here is a quick overview [1]. Today, we (Red Hat) have
 put
  out a proposal[2]
  to move most of the functionality to Eclipse foundation and continue its
  development under
  an Eclipse project named Thym.
 
  Some of you have expressed interest in the project and such a project in
  the past and
  Eclipse proposals do have section to list interested parties. This
 section
  only implies that
  this is a project that is interesting for you [3] and nothing more but it
  will help the proposal.
  If you are interested and would not mind getting listed on the proposal,
  please let me know.
 
  If you have any questions regarding the project or the proposal the stage
  is yours.
 
  [1] http://www.youtube.com/watch?v=hbZ-wZCJ7Xs
  [2] https://projects.eclipse.org/proposals/thym
  [3]
 
 
 http://waynebeaton.wordpress.com/2013/10/10/interested-parties-on-eclipse-project-proposals/
 
  Many thanks,
  Gorkem
 

New project proposal on Eclipse.org

[Gorkem Ercan]

Hi,

Some of you have seen the cordova development tools that are part of the
JBoss tools in the past.
If you have not, here is a quick overview [1]. Today, we (Red Hat) have put
out a proposal[2]
to move most of the functionality to Eclipse foundation and continue its
development under
an Eclipse project named Thym.

Some of you have expressed interest in the project and such a project in
the past and
Eclipse proposals do have section to list interested parties. This section
only implies that
this is a project that is interesting for you [3] and nothing more but it
will help the proposal.
If you are interested and would not mind getting listed on the proposal,
please let me know.

If you have any questions regarding the project or the proposal the stage
is yours.

[1] http://www.youtube.com/watch?v=hbZ-wZCJ7Xs
[2] https://projects.eclipse.org/proposals/thym
[3]
http://waynebeaton.wordpress.com/2013/10/10/interested-parties-on-eclipse-project-proposals/

Many thanks,
Gorkem

Re: ApacheCon attendees and talks

[Gorkem Ercan]

will be there... I have a talk named Developing Cordova Applications with
Eclipse IDE
--
Gorkem


On Wed, Feb 19, 2014 at 11:46 PM, Don Coleman don.cole...@gmail.com wrote:

 That's a good idea to meet up.

 One of my talks was accepted - Connecting Arduino and Phones with Bluetooth
 and Cordova
 And they also accepted a lab - Hands on with NFC and Apache Cordova




 On Wed, Feb 19, 2014 at 3:44 PM, Andrew Grieve agri...@chromium.org
 wrote:

  Yep, I'll be there.
 
 
  On Wed, Feb 19, 2014 at 10:36 AM, Lisa Seacat DeLuca ldel...@us.ibm.com
  wrote:
 
   Taking a poll to see who all is planning on attending ApacheCon and the
   titles of your talks.  It'd like to get some time to meetup with other
   Cordova committers while we're there.
  
   Here are the two I planned on presenting:
   Crowd Sourcing Translations - A Look at How Apache Cordova's
   Documentation is Available in Multiple Languages
   Using Modern Web Technologies to Rapid Develop an Apache Cordova
 Mobile
   App
  
   Last i saw on our mailing list attendees from our group are:
   Andrew Grieve
   talk: The Cordova Development Lifecycle (how we manage 50 repos
   and not go insane) lightning talk: Cordova's Sweet Spot (e.g. what kind
  of
   apps are good fits for hybrid)
   Steve Gill
   Don Coleman
   Presentation - Connecting Arduino and Phones with Bluetooth and
   Cordova Presentation - Writing NFC applications with Apache Cordova
   Lab - Hands on with NFC and Apache Cordova
  
   Do we get 30 minutes or an hour for the talks?  I didn't see that
   information on the submission page.
  
  
   Lisa
  
   Lisa Seacat DeLuca
   Mobile Engineer | t: +415.787.4589 | *ldel...@apache.org*
  ldel...@apache.org| |
   *ldel...@us.ibm.com* ldel...@us.ibm.com | *lisaseacat.com*
  http://www.lisaseacat.com/| [image:
   follow @LisaSeacat on twitter] http://www.twitter.com/LisaSeacat|
  [image:
   follow Lisa Seacat DeLuca on linkedin]
  http://www.linkedin.com/in/lisaseacat
  
  
  
  
 

Re: XML Namespaces

[Gorkem Ercan]

I am not liking it.
JBoss tools actually maintains a w3c xsd and maps the 
http://www.w3.org/ns/widgets; namespace to that XSD. Through this mapping
tools can provide content assist, validation etc. When this namespace
disappears we loose all the benefits. I would be OK with a planned
replacement of the namespace as suggested on B as long as we can maintain
an XSD for it.

Validation against an XSD is probably the main benefit of using xml on
config.xml at least for me.


On Wed, Feb 12, 2014 at 5:00 PM, Andrew Grieve agri...@chromium.org wrote:

 Maybe I'm crazy, but I can't stand them. I don't think they add any value,
 and are a cause of confusion.

 So... I'd like to:
 A: Remove  xmlns=http://www.w3.org/ns/widgets; from our config.xml
 template
 B: Change xmlns:cdv=http://cordova.apache.org/ns/1.0; - xmlns=
 http://cordova.apache.org/ns/1.0;
 C: Revert the commit that enforces the namespace to exist.

 This will allow us to add new tags  attributes to cordova.xml without
 violating XML namespace rules.

 Does anyone hate this idea?

Re: XML Namespaces

[Gorkem Ercan]

On Wed, Feb 12, 2014 at 10:42 PM, Andrew Grieve agri...@chromium.orgwrote:

 Sounds good to leave them in then.

 Why I ask now is for the icon and splashscreen discussions / pull
 requests going on right now.

 We can call them:
 cdv:icon cdv:splashscreen


There is also an icon element on the w3c specification (the default
namespace). You may want to reuse that one



 And then start thinking about moving to JSON.


I would not mind.




 On Wed, Feb 12, 2014 at 6:12 PM, Brian LeRoux b...@brian.io wrote:

  Ya I think my ambivalence stems from the same thinking Josh points out.
 I'd
  love to move us to package.json personally. I think all agreed last
 meeting
  that was solving problems we don't really have.
 
  And ultimately MANY downstreams are relying on both XML and namespaces so
  removing them will have be a noisy MAJOR update sort of thing.
 
 
  On Wed, Feb 12, 2014 at 2:54 PM, Josh Soref jso...@blackberry.com
 wrote:
 
   Andrew wrote:
Maybe I'm crazy, but I can't stand them.
  
   Most people can't
  
I don't think they add any value,
  
   They allow other products which are frozen (released to an audience)
 to
   interoperate in a defined manner with your software. And vice versa.
  
   If you don't care about that, then there isn't much reason to use XML
   (it's a horrible language).
  
   For the most part, I'd say that Cordova pretty much by definition
 doesn't
   care about this. Moving the file from www/ to www/../ broke existing
   software (amusingly including cordova serve). Cordova's view is
 basically
   that people will update their tools to work with the new version. And
   that's fine, but it isn't really a match for the promise of XML.
  
and are a cause of confusion.
  
   Absolutely
  
So... I'd like to:
A: Remove xmlns=http://www.w3.org/ns/widgets; from our config.xml
   template
B: Change xmlns:cdv=http://cordova.apache.org/ns/1.0; - xmlns=
   http://cordova.apache.org/ns/1.0;
C: Revert the commit that enforces the namespace to exist.
  
Does anyone hate this idea?
  
   I'm pretty sure we (BlackBerry) will have to do some work in response
 to
   this, but that isn't a big deal.
  
   If you're going to depart from the file format, why not switch to JSON?
  
  
 
 http://blogs.msdn.com/b/visualstudioalm/archive/2014/02/06/json-debugger-visualizer-in-visual-studio-2013.aspxevenMicrosoftis
  offering editors for it.
  
   Is there any value that you see in Cordova using XML?
  
  
  
 

Engines and plugins

[Gorkem Ercan]

JBoss Tools have recently added the capability to switch between
Cordova engines. See [1] for details. While implementing checks for
plug-in compatibility I found the engine definitions on the plug-in 
specification to
be more complex than needed to be. 

I think there are too many default engines defined. 
for instance 
  engine name=cordova-android version==1.8.0 /
is essentially the same as 
  engine name=cordova version==1.8.0 platform=android /

Could someone remind the reason for having platform specific default engine 
names? If
they exist for a historic reason can we remove it from the documentation
and guide people to use the platform attribute? I can provide a doc patch for 
this purpose.
I think this is making the implementation on plugman more complex also. 

And specifying custom Apache Cordova-based frameworks is a different
beast altogether. It actually gives the responsibility to integrate a
custom engine with plugman to the plug-ins with the scriptSrc attribute.
I do not think this will scale considering that the engine and plug-in
ideally have a different life cycle. I think plugman should actually
provide a way for custom engines to provide this information. 

I guess there is some merit to engines such as apple-xcode but I have
yet not been able to find a plug-in that uses those. I must also admit
the use of engine definitions is also very limited.

[1] http://www.gorkem-ercan.com/2014/01/multiple-cordova-engines-on-jboss.html

Re: Engines and plugins

[Gorkem Ercan]

On Mon, Jan 13, 2014 at 04:32:20PM -0500, Andrew Grieve wrote:
 FYI to others - the docs for this is found here (seems to have some
 incorrectly formatted markdown too :( ) :
 http://cordova.apache.org/docs/en/3.3.0/plugin_ref_spec.md.html#Plugin%20Specification
 
 My understanding was that:
 engine name=cordova-android version==1.8.0 /
 is the same as:
 engine name=cordova-android version==1.8.0 platform=android /
 not:
 engine name=cordova version==1.8.0 platform=android /

What is actually different here? I know the implementation assumes all
platforms when it sees cordova but it does not have to, it could just
look take platform attribute into account. I am just
trying to understand the reasons for the cordova-${platform} engine
names.

 
 
 I think this is definitely open for discussion. As you say - usage of
 the tags are very limited right now.
 
 Other concerns with it I have:
 - scriptSrc allows plugins to run code on the host machine upon
 install... Seems like a security concern.
 I *think* the answer to your question is that we want to be able to specify:
 engine name=cordova-android version==1.8.0 /
 engine name=cordova-ios version==1.9.0 /
 
 And don't want cordova-ios checked when you don't have the android
 platform. And the syntax is more concise than:

I think this is a bit strict and makes life harder if iOS is not really
targeted by the application. Perhaps missing one of those engines should
be a warning and missing all of them a fail.

 engine name=cordova-android version==1.8.0 platform=android /
 
 
 On Mon, Jan 13, 2014 at 2:33 PM, Gorkem Ercan gorkem.er...@gmail.com wrote:
  JBoss Tools have recently added the capability to switch between
  Cordova engines. See [1] for details. While implementing checks for
  plug-in compatibility I found the engine definitions on the plug-in 
  specification to
  be more complex than needed to be.
 
  I think there are too many default engines defined.
  for instance
engine name=cordova-android version==1.8.0 /
  is essentially the same as
engine name=cordova version==1.8.0 platform=android /
 
  Could someone remind the reason for having platform specific default engine 
  names? If
  they exist for a historic reason can we remove it from the documentation
  and guide people to use the platform attribute? I can provide a doc patch 
  for this purpose.
  I think this is making the implementation on plugman more complex also.
 
  And specifying custom Apache Cordova-based frameworks is a different
  beast altogether. It actually gives the responsibility to integrate a
  custom engine with plugman to the plug-ins with the scriptSrc attribute.
  I do not think this will scale considering that the engine and plug-in
  ideally have a different life cycle. I think plugman should actually
  provide a way for custom engines to provide this information.
 
  I guess there is some merit to engines such as apple-xcode but I have
  yet not been able to find a plug-in that uses those. I must also admit
  the use of engine definitions is also very limited.
 
  [1] 
  http://www.gorkem-ercan.com/2014/01/multiple-cordova-engines-on-jboss.html

Re: Moving .cordova/config.json - cordova.json

[Gorkem Ercan]

Are the platform locations set by Cordova CLI already? I know phonegap does
it and I actually wish to add it to Cordova CLI as well [1] but I thought
it was not implemented on CLI.

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

In any case, engine info can go into cordova.xml.
--
Gorkem


On Thu, Jan 2, 2014 at 10:22 AM, Andrew Grieve agri...@chromium.org wrote:

 What cordova.json has that config.xml doesn't, is that you can set the
 location of platforms with it through:

 {
   id:org.apache.mobilespec,
   name:mobilespec,
   lib: {
 android: {
   uri: /Users/agrieve/git/cordova/cordova-android,
   version: dev,
   id: cordova-android-dev
 },
 ios: {
   uri: /Users/agrieve/git/cordova/cordova-ios,
   version: dev,
   id: cordova-ios-dev
 }
   }
 }


 We're also planning on adding plugin search paths in there in
 https://issues.apache.org/jira/browse/CB-5006.

 That said, I like your idea of having one top-level config file instead of
 two. I don't see why we couldn't just put these same settings into a
 cordova.xml.



 On Wed, Jan 1, 2014 at 5:05 PM, Gorkem Ercan gorkem.er...@gmail.com
 wrote:

  There is also another proposal to move config.xml out of www. Can we
 merge
  this two moves and
  1. remove .cordova
  2. remove config.json
  3. move config.xml to root
  4. rename config.xml to cordova.xml
 
  AFAIK config,json does not carry any information that is not already
  available on the config.xml. Since .cordova is basically a marker for CLI
  for the root of an app I think renaming config.xml should provide the
 same
  functionality.
  --
  Gorkem
 
 
 
 
  On Tue, Dec 31, 2013 at 1:19 PM, Andrew Grieve agri...@chromium.org
  wrote:
 
   Thanks for the feedback!
  
   I don't think we should move files around automatically because it
 could
   mess with people's source control.
  
   I think using old versions of CLI with newer projects can't be
 supported,
   but we can certainly (and I think have been) supporting using newer
   versions of CLI with older projects.
  
   Searching up until you find a cordova.json (or .cordova) sounds like a
  good
   way to find the root.
  
  
  
   On Mon, Dec 30, 2013 at 5:46 PM, Dick Van den Brink 
   d_vandenbr...@outlook.com wrote:
  
CLI searches for the .cordova folder from the current working
 directory
   up
to the root. What will be the new approach? Searching for the
   cordova.json
and .cordova for compatibility?
   
   
While I do agree on the change I don't really like the if folder
 exists
   or
config exists approach thingy, can't we do something with the upgrade
command to move the files around where we want them and just force
 the
   new
way? Not sure if this is an ideal approach.. but yeah…
   
   
I know this makes it really important to use the right cli version on
  the
projects but I don't believe a new cli with old project structure or
  the
old cli with new platform versions work now because of the
 differences
where Cordova.js is stored for example.. So I don't think that's a
 real
issue.
   
   
What do you guys think? Or am I talking nonsense right now?
   
   
   
   
   
Verzonden met Windows Mail
   
   
   
   
   
Van: Andrew Grieve
Verzonden: maandag 30 december 2013 22:08
Aan: dev@cordova.apache.org
   
   
   
   
   
Proposal:
For CLI projects:
- Use ./cordova.json if it exists, otherwise use .cordova/config.json
- Use ./hooks/* if it exists, otherwise use .cordova/hooks/*
- Change the project template to use ./cordova.json instead of
.cordova/config.json
   
   
Reasons:
- We want users to put .cordova into source control, so shouldn't
 hide
  it
- We didn't make plugins/ and platforms/ hidden, so shouldn't hide
.cordova/
   
   
Sound good? If so I'll make an issue and work on this. Since it's
   holidays,
will wait until next week Tuesday (Jan 7) to proceed.
   
  
 

Re: Moving .cordova/config.json - cordova.json

[Gorkem Ercan]

I think what I will describe here is more that what CLI provides today.

An engine/lib has a version, id and a uri. On most cases, you only care about 
the 
id and uri and assume that the tools that you work with already knows how to 
resolve the id and version to a location. In the case of CLI an engine with id: 
cordova 
and version:3.1.0 should be resolved to ~/.cordova/lib/ios/cordova/3.1.0 . If 
we have a 
uri defined that actually means we want to overwrite the default location for 
the engine. 
I think this redirection should be per engine not per project and should be 
located as part of 
CLI's configuration 
--
Gorkem

On Thu, Jan 02, 2014 at 01:28:12PM -0500, Andrew Grieve wrote:
 Hmm, good point about absolute paths.
 
 I think if you're using an override there though, that you could set it to
 a relative path for shared projects. Same thing with plugin search paths.
 
 I think it'll be confusing to have a cordova.xml as well as a
 cordova.json file right in the root.
 
 WDYT? Other options?
 
 
 On Thu, Jan 2, 2014 at 1:06 PM, Ian Clelland iclell...@chromium.org wrote:
 
  On Thu, Jan 2, 2014 at 10:22 AM, Andrew Grieve agri...@chromium.org
  wrote:
 
   What cordova.json has that config.xml doesn't, is that you can set the
   location of platforms with it through:
  
  
 
  
   That said, I like your idea of having one top-level config file instead
  of
   two. I don't see why we couldn't just put these same settings into a
   cordova.xml.
  
 
  Wouldn't this make it impossible to share project configuration between
  developers? If your /Users/agrieve/.../ paths are in your config xml,
  you're going to have a bad time putting that in version control.
 
  -1 on having a single file to manage both application config and
  build-environment config.
 
  +1 to the way I read Gorkem's original suggestion, which was to coordinate
  the move of the two files into a single issue and take care of it all at
  once.
 
 
  
  
   On Wed, Jan 1, 2014 at 5:05 PM, Gorkem Ercan gorkem.er...@gmail.com
   wrote:
  
There is also another proposal to move config.xml out of www. Can we
   merge
this two moves and
1. remove .cordova
2. remove config.json
3. move config.xml to root
4. rename config.xml to cordova.xml
   
AFAIK config,json does not carry any information that is not already
available on the config.xml. Since .cordova is basically a marker for
  CLI
for the root of an app I think renaming config.xml should provide the
   same
functionality.
--
Gorkem
   
   
  
 

Re: Moving .cordova/config.json - cordova.json

[Gorkem Ercan]

Reducing the number of configuration files is actually the goal here. 

The abstraction is not a new one. It already exists and it is part of the 
$PROJECT/.cordova/config.json. 
I am suggesting to move it to $HOME/.cordova/config.json so that we no longer 
need the 
$PROJECT/.cordova/config.json and have only the cordova.xml to carry project 
specific
properties.
--
Gorkem


On Thu, Jan 02, 2014 at 12:16:57PM -0800, Brian LeRoux wrote:
 Considering http://wiki.apache.org/cordova/ConfigurationFiles I'm not sure
 we want more config either.
 
 Perhaps we need to think more comprehensively rather than proposing more
 abstractions.
 
 
 On Thu, Jan 2, 2014 at 11:15 AM, Gorkem Ercan gorkem.er...@gmail.comwrote:
 
 
  I think what I will describe here is more that what CLI provides today.
 
  An engine/lib has a version, id and a uri. On most cases, you only care
  about the
  id and uri and assume that the tools that you work with already knows how
  to
  resolve the id and version to a location. In the case of CLI an engine
  with id: cordova
  and version:3.1.0 should be resolved to ~/.cordova/lib/ios/cordova/3.1.0 .
  If we have a
  uri defined that actually means we want to overwrite the default location
  for the engine.
  I think this redirection should be per engine not per project and should
  be located as part of
  CLI's configuration
  --
  Gorkem
 
  On Thu, Jan 02, 2014 at 01:28:12PM -0500, Andrew Grieve wrote:
   Hmm, good point about absolute paths.
  
   I think if you're using an override there though, that you could set it
  to
   a relative path for shared projects. Same thing with plugin search paths.
  
   I think it'll be confusing to have a cordova.xml as well as a
   cordova.json file right in the root.
  
   WDYT? Other options?
  
  
   On Thu, Jan 2, 2014 at 1:06 PM, Ian Clelland iclell...@chromium.org
  wrote:
  
On Thu, Jan 2, 2014 at 10:22 AM, Andrew Grieve agri...@chromium.org
wrote:
   
 What cordova.json has that config.xml doesn't, is that you can set
  the
 location of platforms with it through:


   

 That said, I like your idea of having one top-level config file
  instead
of
 two. I don't see why we couldn't just put these same settings into a
 cordova.xml.

   
Wouldn't this make it impossible to share project configuration between
developers? If your /Users/agrieve/.../ paths are in your config xml,
you're going to have a bad time putting that in version control.
   
-1 on having a single file to manage both application config and
build-environment config.
   
+1 to the way I read Gorkem's original suggestion, which was to
  coordinate
the move of the two files into a single issue and take care of it all
  at
once.
   
   


 On Wed, Jan 1, 2014 at 5:05 PM, Gorkem Ercan gorkem.er...@gmail.com
  
 wrote:

  There is also another proposal to move config.xml out of www. Can
  we
 merge
  this two moves and
  1. remove .cordova
  2. remove config.json
  3. move config.xml to root
  4. rename config.xml to cordova.xml
 
  AFAIK config,json does not carry any information that is not
  already
  available on the config.xml. Since .cordova is basically a marker
  for
CLI
  for the root of an app I think renaming config.xml should provide
  the
 same
  functionality.
  --
  Gorkem
 
 

   
 

Re: Moving .cordova/config.json - cordova.json

[Gorkem Ercan]

There is also another proposal to move config.xml out of www. Can we merge
this two moves and
1. remove .cordova
2. remove config.json
3. move config.xml to root
4. rename config.xml to cordova.xml

AFAIK config,json does not carry any information that is not already
available on the config.xml. Since .cordova is basically a marker for CLI
for the root of an app I think renaming config.xml should provide the same
functionality.
--
Gorkem




On Tue, Dec 31, 2013 at 1:19 PM, Andrew Grieve agri...@chromium.org wrote:

 Thanks for the feedback!

 I don't think we should move files around automatically because it could
 mess with people's source control.

 I think using old versions of CLI with newer projects can't be supported,
 but we can certainly (and I think have been) supporting using newer
 versions of CLI with older projects.

 Searching up until you find a cordova.json (or .cordova) sounds like a good
 way to find the root.



 On Mon, Dec 30, 2013 at 5:46 PM, Dick Van den Brink 
 d_vandenbr...@outlook.com wrote:

  CLI searches for the .cordova folder from the current working directory
 up
  to the root. What will be the new approach? Searching for the
 cordova.json
  and .cordova for compatibility?
 
 
  While I do agree on the change I don't really like the if folder exists
 or
  config exists approach thingy, can't we do something with the upgrade
  command to move the files around where we want them and just force the
 new
  way? Not sure if this is an ideal approach.. but yeah…
 
 
  I know this makes it really important to use the right cli version on the
  projects but I don't believe a new cli with old project structure or the
  old cli with new platform versions work now because of the differences
  where Cordova.js is stored for example.. So I don't think that's a real
  issue.
 
 
  What do you guys think? Or am I talking nonsense right now?
 
 
 
 
 
  Verzonden met Windows Mail
 
 
 
 
 
  Van: Andrew Grieve
  Verzonden: maandag 30 december 2013 22:08
  Aan: dev@cordova.apache.org
 
 
 
 
 
  Proposal:
  For CLI projects:
  - Use ./cordova.json if it exists, otherwise use .cordova/config.json
  - Use ./hooks/* if it exists, otherwise use .cordova/hooks/*
  - Change the project template to use ./cordova.json instead of
  .cordova/config.json
 
 
  Reasons:
  - We want users to put .cordova into source control, so shouldn't hide it
  - We didn't make plugins/ and platforms/ hidden, so shouldn't hide
  .cordova/
 
 
  Sound good? If so I'll make an issue and work on this. Since it's
 holidays,
  will wait until next week Tuesday (Jan 7) to proceed.