CLI bug triage complete!

[Andrew Grieve]

Got CLI component down to 91 issues.

Can you believe this is JIRA's link to the component!?

https://issues.apache.org/jira/browse/CB-5494?jql=project%20%3D%20CB%20AND%20resolution%20%3D%20Unresolved%20AND%20component%20%3D%20CLI%20ORDER%20BY%20priority%20DESC

Re: Get customized feature parameter value from config.xml

[Carlos Santana]

Shaz do we have a jira item for this limitation?

Maybe something that can be address short term via plugin dev docs, and
long term maybe with new config.xml/json :-)



On Mon, Apr 14, 2014 at 4:29 PM, Li, Jonathan  wrote:

> That works. Thanks.
>
> On 4/14/14 4:26 PM, "Shazron"  wrote:
>
> >Yes, that is the known limitation. My suggestion is to prefix the
> >preference name with your plugin name, or whatever you prefer.
> >
> >
> >On Mon, Apr 14, 2014 at 1:12 PM, Li, Jonathan 
> wrote:
> >
> >> Although the preference can be defined in plugin.xml on per platform and
> >> plugin level, but when the information is used to generate config.xml,
> >>the
> >> related preference element will be generated under the root "widget"
> >> element, and so shared by all plugins. This may cause conflict if the
> >>same
> >> preference name is used by multiple plugins.
> >>
> >>
> >>
> >> On 4/14/14 3:48 PM, "Shazron"  wrote:
> >>
> >> >per platform in the platform tag - yes.
> >> >plugin level  - yes.
> >> >
> >> >
> >> >On Mon, Apr 14, 2014 at 11:34 AM, Li, Jonathan 
> >> >wrote:
> >> >
> >> >> Does "preference" can be set on per platform and plugin level?
> >> >>
> >> >> On 4/14/14 2:27 PM, "Shazron"  wrote:
> >> >>
> >> >> >Will a   tag not suffice?
> >> >> >
> >> >> >
> >> >> >On Mon, Apr 14, 2014 at 11:23 AM, Li, Jonathan  >
> >> >> >wrote:
> >> >> >
> >> >> >> Hi,
> >> >> >> In the following sample plugin.xml and config.xml , the parameter
> >> >> >> "enable-redirect" can be configured by app developers when they
> >>add
> >> >>the
> >> >> >> plugin to cordova project. However, currently only "ios-package"
> >>and
> >> >> >> "onload" parameters are parsed and stored by config.xml's settings
> >> >> >>parser,
> >> >> >> other parameters (like "enable-redirect") are ignored by the
> >>settings
> >> >> >> parser, so plugin developer has to parse the config.xml again by
> >> >> >>themselves
> >> >> >> in order to get the other parameters' value.
> >> >> >>
> >> >> >> Just wonder it maybe a good idea to parse all parameters under
> >> >>feature
> >> >> >> element, and return it as a "param" dictionary, so as to make it
> >> >>ready
> >> >> >>to
> >> >> >> use by developers within plugin's native code.
> >> >> >>
> >> >> >> Plugin.xml:
> >> >> >>   
> >> >> >> 
> >> >> >> 
> >> >> >> 
> >> >> >> 
> >> >> >> 
> >> >> >> 
> >> >> >> 
> >> >> >> 
> >> >> >> 
> >> >> >>
> >> >> >> Config.xml
> >> >> >> 
> >> >> >> 
> >> >> >> 
> >> >> >> 
> >> >> >> 
> >> >> >>
> >> >> >> Thanks
> >> >> >> Jonathan
> >> >> >>
> >> >>
> >> >>
> >>
> >>
>
>


-- 
Carlos Santana

Re: Introducing myself

[Carlos Santana]

Welcome Victor !

As new contributor, if find the introduction docs are missing information
or can be improved will appreciate the feedback


On Mon, Apr 14, 2014 at 4:49 PM, Victor Sosa  wrote:

> Hello everybody.
>
> Thanks for the warming welcome, feels good being in a community that is so
> active and that worries about the people in it.
> I'll check the links you kindly provided.
> Also, I've sent the signed ICLA to Apache foundation.
>
>
> 2014-04-14 13:48 GMT-05:00 Marcel Kinard :
>
> > Welcome! Besides the page that Brian referenced, the wiki overall has
> good
> > information for developers, so browse around it.
> > http://wiki.apache.org/cordova
> >
> > If you plan on making contributions, start by getting an ICLA signed, as
> > described in ContributorWorkflow.
> >
> > On Apr 14, 2014, at 2:08 PM, Brian LeRoux  wrote:
> >
> > > Welcome Victor!
> > >
> > > You can find more goodies to get started on the wiki:
> > > http://wiki.apache.org/cordova/ContributorWorkflow
> > >
> > >
> > > On Mon, Apr 14, 2014 at 9:51 AM, Victor Sosa 
> > wrote:
> > >
> > >> Hello Apache Cordova Community.
> > >>
> > >> My Name is Victor Sosa. Really excited to start contributing to this
> > >> project.
> > >> My background is as Java developer focused on Eclipse tools, but
> lately
> > >> I've been doing some mobile development and that's how I discovered
> > >> Cordova.
> > >> I also have some background on other areas, like Web development,
> Cloud
> > >> computing and scripting languages (I am a Linux user ;-).
> > >>
> > >> Cheers!
> > >>
> >
> >
>
>
> --
> Victor Adrian Sosa Herrera
> IBM Software Engineer
> Guadalajara, Jalisco
>



-- 
Carlos Santana

Re: Sharing code between plugman and cordova-cli

[Carlos Santana]

You don't need git install for npm to resolved the dependency, npm handles
the fetching of the git url or simple url to tarball [1]

Another way is when is time to publish you can put these common node
modules as Bundle Dependencies [2] and send them to npm when publishing
plugman and cordova-cli

I understand that the problem is the common code to be separated and into a
common component.

I just want to point out that there is more than one way of accomplish our
goals, and that npm has a lot capabilities of accomplishing the same thing
with different approaches.

1: https://www.npmjs.org/doc/json.html#URLs-as-Dependencies
2: https://www.npmjs.org/doc/json.html#bundledDependencies

--Carlos




On Tue, Apr 15, 2014 at 9:32 PM, Andrew Grieve  wrote:

> We found out the hard way that having any git-based dependencies
> causes install to fail if the user doesn't have git installed. For
> this reason, if something's going to be an npm modules that's depended
> on, it must be published to npm, and thus go through the proper
> release process.
>
> Note though that the release process isn't the motivator for this,
> rather, it's the pain of co-ordinating changes to multiple
> repositories that depend on each other.
>
>
>
> On Tue, Apr 15, 2014 at 5:21 PM, Carlos Santana 
> wrote:
> > On Tue, Apr 15, 2014 at 9:07 PM, Carlos Santana  >wrote:
> >
> >> I agree that braking things into small node modules with clear scope and
> >> function is good and then be shared across other modules that declare
> them
> >> ad dependencies.
> >>
> >> These common node modules...:
> >> 1. don't have to be publish to npm or release as a apache/cordova dist
> >> asset.
> >> 2. can live in their own git repos
> >> 3. can be specified as dependencies using git url, manage during dev
> with
> >> npm link or git submodules to do test integration while doing dev
> >> 4. can be treated as common source code to the cordova tools, and not a
> >> standalone general purpose tool
> >> 5. what actually gets publish to npm and release as a apache/cordova
> dist
> >> asset continue to be plugman and cordova-cli
> >>
> >> --Carlos
> >>
> >>
> > This was just things to consider not necessary a proposal.
> > But wanted to point out that things can be broken up into modules, and
> not
> > necessary add overhead on npm and release process/voting, and just
> treated
> > as a SCM exercise.
>



-- 
Carlos Santana

Re: [iOS] CB-6441 System frameworks issue

[Mark Koudritsky]

The cache in ConfigKeeper is meant to make cordova prepare faster.
The second cache on the line linked to by Anis was done for faster plugin
add.
But as the comment above that line says (added it myself in Feb), since the
linked pull request added the functionality to pass a list of plugins to
install, that cache shouldn't be helpful any longer.

Re: hangout / discussion for smaller modules in cordova

[Andrew Grieve]

bah - turns out there's three threads about this one subject.

Created a doodle for Wed/Thurs. Add yourself if you'd like to
participate in the discussion.

http://doodle.com/uvyr9454pvepz3a3

Shouldn't take more than a 30 minutes time slice. The point of the
hangout is to speed this along, if we can't find a time this week I
think we should just continue via the doc Mark sent out (thanks for
this Mark!).




On Tue, Apr 15, 2014 at 5:18 PM, Brian LeRoux  wrote:
> well, a Google Hangout
>
> this week is sort of a mess for me but next is better
>
>
> On Tue, Apr 15, 2014 at 6:09 PM, Naik, Archana  wrote:
>
>> In person discussion? Where & when?
>>
>> On 4/15/14 5:01 PM, "Brian LeRoux"  wrote:
>>
>> >So we all want to break up the beast that is the CLI: good. How we get
>> >there appears to be confusing.
>> >
>> >Discussion for this in person probably easier and will require more than
>> >an
>> >hour. Thoughts?
>>
>>

Re: Sharing code between plugman and cordova-cli

[Brian LeRoux]

I realize now that is all we're talking about.

/cordova-the-one-repo-to-rule-them-all
|- cli
|  '- package.json
|- plugman
|  '- package.json
|- etc..

The benefit being it will be faster to rip things into module packages from
one directly I guess if your text editor struggles with many directories
(Is this th problem?) I completely do not follow the reasoning. Commit
history is in one place is a benefit though I personally don't find myself
rewinding time very often (and when I do I find such exercises easier in
small modules.)



On Tue, Apr 15, 2014 at 6:21 PM, Carlos Santana wrote:

> On Tue, Apr 15, 2014 at 9:07 PM, Carlos Santana  >wrote:
>
> > I agree that braking things into small node modules with clear scope and
> > function is good and then be shared across other modules that declare
> them
> > ad dependencies.
> >
> > These common node modules...:
> > 1. don't have to be publish to npm or release as a apache/cordova dist
> > asset.
> > 2. can live in their own git repos
> > 3. can be specified as dependencies using git url, manage during dev with
> > npm link or git submodules to do test integration while doing dev
> > 4. can be treated as common source code to the cordova tools, and not a
> > standalone general purpose tool
> > 5. what actually gets publish to npm and release as a apache/cordova dist
> > asset continue to be plugman and cordova-cli
> >
> > --Carlos
> >
> >
> This was just things to consider not necessary a proposal.
> But wanted to point out that things can be broken up into modules, and not
> necessary add overhead on npm and release process/voting, and just treated
> as a SCM exercise.
>

Re: Sharing code between plugman and cordova-cli

[Andrew Grieve]

We found out the hard way that having any git-based dependencies
causes install to fail if the user doesn't have git installed. For
this reason, if something's going to be an npm modules that's depended
on, it must be published to npm, and thus go through the proper
release process.

Note though that the release process isn't the motivator for this,
rather, it's the pain of co-ordinating changes to multiple
repositories that depend on each other.



On Tue, Apr 15, 2014 at 5:21 PM, Carlos Santana  wrote:
> On Tue, Apr 15, 2014 at 9:07 PM, Carlos Santana wrote:
>
>> I agree that braking things into small node modules with clear scope and
>> function is good and then be shared across other modules that declare them
>> ad dependencies.
>>
>> These common node modules...:
>> 1. don't have to be publish to npm or release as a apache/cordova dist
>> asset.
>> 2. can live in their own git repos
>> 3. can be specified as dependencies using git url, manage during dev with
>> npm link or git submodules to do test integration while doing dev
>> 4. can be treated as common source code to the cordova tools, and not a
>> standalone general purpose tool
>> 5. what actually gets publish to npm and release as a apache/cordova dist
>> asset continue to be plugman and cordova-cli
>>
>> --Carlos
>>
>>
> This was just things to consider not necessary a proposal.
> But wanted to point out that things can be broken up into modules, and not
> necessary add overhead on npm and release process/voting, and just treated
> as a SCM exercise.

Re: Proposal for cli and plugman code rearrangement

[Andrew Grieve]

We didn't have time to cover this today, but I think it's better off
as its own hangout anyways.

Created a doodle for Wed/Thurs. Add yourself if you'd like to
participate in the discussion.

http://doodle.com/uvyr9454pvepz3a3

On Tue, Apr 15, 2014 at 11:19 AM, Mark Koudritsky  wrote:
> A short 
> proposal
> for
> how to rearrange cli and plugman code. Let's discuss it during the hangout
> today. Feel free to comment.

Re: Sharing code between plugman and cordova-cli

[Carlos Santana]

On Tue, Apr 15, 2014 at 9:07 PM, Carlos Santana wrote:

> I agree that braking things into small node modules with clear scope and
> function is good and then be shared across other modules that declare them
> ad dependencies.
>
> These common node modules...:
> 1. don't have to be publish to npm or release as a apache/cordova dist
> asset.
> 2. can live in their own git repos
> 3. can be specified as dependencies using git url, manage during dev with
> npm link or git submodules to do test integration while doing dev
> 4. can be treated as common source code to the cordova tools, and not a
> standalone general purpose tool
> 5. what actually gets publish to npm and release as a apache/cordova dist
> asset continue to be plugman and cordova-cli
>
> --Carlos
>
>
This was just things to consider not necessary a proposal.
But wanted to point out that things can be broken up into modules, and not
necessary add overhead on npm and release process/voting, and just treated
as a SCM exercise.

Re: hangout / discussion for smaller modules in cordova

[Brian LeRoux]

well, a Google Hangout

this week is sort of a mess for me but next is better


On Tue, Apr 15, 2014 at 6:09 PM, Naik, Archana  wrote:

> In person discussion? Where & when?
>
> On 4/15/14 5:01 PM, "Brian LeRoux"  wrote:
>
> >So we all want to break up the beast that is the CLI: good. How we get
> >there appears to be confusing.
> >
> >Discussion for this in person probably easier and will require more than
> >an
> >hour. Thoughts?
>
>

Re: hangout / discussion for smaller modules in cordova

[Naik, Archana]

In person discussion? Where & when?

On 4/15/14 5:01 PM, "Brian LeRoux"  wrote:

>So we all want to break up the beast that is the CLI: good. How we get
>there appears to be confusing.
>
>Discussion for this in person probably easier and will require more than
>an
>hour. Thoughts?

Re: Sharing code between plugman and cordova-cli

[Carlos Santana]

I agree that braking things into small node modules with clear scope and
function is good and then be shared across other modules that declare them
ad dependencies.

These common node modules...:
1. don't have to be publish to npm or release as a apache/cordova dist
asset.
2. can live in their own git repos
3. can be specified as dependencies using git url, manage during dev with
npm link or git submodules to do test integration while doing dev
4. can be treated as common source code to the cordova tools, and not a
standalone general purpose tool
5. what actually gets publish to npm and release as a apache/cordova dist
asset continue to be plugman and cordova-cli

--Carlos




On Tue, Apr 15, 2014 at 5:52 PM, Brian LeRoux  wrote:

> I really hope we don't have to vote on this. Its the wrong path guys and I
> am really hoping we can find consensus to follow Node practices in a Node
> project. I recognize that Google is used to working with a single large
> repo but this is not Google.
>
>
> On Wed, Apr 16, 2014 at 9:41 AM, Michal Mocny  wrote:
>
> > I should have updated this email thread.  That proposal is old news, Mark
> > has done a writeup:
> >
> >
> https://docs.google.com/document/d/1GVtG6BD266dqRURKaS-GEDefb0tBYt56acxrJEKAfmE/edit
> >
> >
> > (I know you have commented on it already, but for others)
> >
> > On Tue, Apr 15, 2014 at 4:20 PM, Brian LeRoux  wrote:
> >
> > > >
> > > > I think everyone is on board with the idea that modules should be
> used
> > to
> > > > enable sharing code, and for code organization.
> > > >
> > >
> > > Cool.
> > >
> > >
> > > > Two problems that are happening in practice:
> > > > - Multiple pull requests (plugman and CLI) to make a change
> > > > - Code duplication between the repositories
> > > >
> > > > Both of these are solved by moving all common code into the same git
> > > > repository.
> > > >
> > >
> > > Nope. Multiple pull requests to make a single functional change could
> be
> > > achieved by pulling a common module out. I respect you have a single
> repo
> > > at Google but this is not the solution to everything!
> > >
> > >
> > >
> > >
> > > > I think whether to make additional npm packages should happen as a
> > > > follow-up, and as concrete proposals (e.g. Let's publish CordovaError
> > > into
> > > > an npm package)
> > > >
> > >
> > > Sure
> > >
> > >
> > > It's a bit weird that a lot of cordova's CLI is in a module called
> > > > "cordova", but you need to install "plugman" to publish to the
> > registry.
> > > >
> > >
> > > Nope. The choice to make the CLI the entry point for developers of
> > cordova
> > > makes perfect sense. To have a separate tool for publishing also makes
> > > sense. Exposing that tool from Cordova was always the idea.
> > >
> > >
> > >
> > > > How about folding the functionality of plugman into cordova?
> > > >
> > >
> > > Right. This doesn't mean they have to be in the same git repo. In
> Cordova
> > > you can use package.json to include Plugman and expose functionality.
> > This
> > > way you win versioning which is the point dependency management…not
> SCM.
> > >
> > >
> > > > For users that are accustomed to using plugman directly, we could
> make
> > > > plugman depend on CLI to have it continue working.
> > > >
> > >
> > > What?! Why!
> > >
> >
>



-- 
Carlos Santana

Re: [iOS] CB-6441 System frameworks issue

[Shazron]

I can confirm this problem occurs too frequently on the Google Groups.
Users install plugins and they get linker errors, or compile errors,
because some files/frameworks do not exist in the Xcode project after
installing a plugin. Often the fix is to uninstall and re-install, thus the
problem seems to be in the CLI and not the plugin structure itself.

I would opt for 100% reliability versus speed in this case, since
installing plugins is a one-time thing usually for a project.


On Tue, Apr 15, 2014 at 5:42 PM, Anis KADRI  wrote:

> There are currently a lot people reporting this issue on the google groups.
>
> iOS frameworks don't get added when plugin with dependencies gets
> installed. It's a big problem because projects don't compile.
>
> A great example of this is: mobile-spec/dependencies-plugin/. It seems like
> the double caching of pbxproject file in plugman (platforms,
> config-changes) is causing this and deleting this line [1] fixes it.
>
> this would have been easier for me to figure out if everything
> was broken out into shorter discreet modules. Instead it took me several
> hours.
>
> The change was introduced with this pull request it seems:
> https://github.com/apache/cordova-plugman/pull/45/files
>
> I am not sure what the proper fix is. I love performance but I love
> reliability even more. I think ideally we'd have one cache shared across
> modules but we need an immediate fix for this so unless someone thinks they
> can implement it before the next release I propose that we don't use the
> cache for the time being.
>
> Thoughts ?
>
> [1]
>
> https://git-wip-us.apache.org/repos/asf?p=cordova-plugman.git;a=blob;f=src/platforms/ios.js;h=9631e6450c4481def593a8043519d2e55a9e69f2;hb=HEAD#l156
>

[iOS] CB-6441 System frameworks issue

[Anis KADRI]

There are currently a lot people reporting this issue on the google groups.

iOS frameworks don't get added when plugin with dependencies gets
installed. It's a big problem because projects don't compile.

A great example of this is: mobile-spec/dependencies-plugin/. It seems like
the double caching of pbxproject file in plugman (platforms,
config-changes) is causing this and deleting this line [1] fixes it.

this would have been easier for me to figure out if everything
was broken out into shorter discreet modules. Instead it took me several
hours.

The change was introduced with this pull request it seems:
https://github.com/apache/cordova-plugman/pull/45/files

I am not sure what the proper fix is. I love performance but I love
reliability even more. I think ideally we'd have one cache shared across
modules but we need an immediate fix for this so unless someone thinks they
can implement it before the next release I propose that we don't use the
cache for the time being.

Thoughts ?

[1]
https://git-wip-us.apache.org/repos/asf?p=cordova-plugman.git;a=blob;f=src/platforms/ios.js;h=9631e6450c4481def593a8043519d2e55a9e69f2;hb=HEAD#l156

[GitHub] cordova-registry-web pull request: CB-6285

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/cordova-registry-web/pull/3


---
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.
---

hangout / discussion for smaller modules in cordova

[Brian LeRoux]

So we all want to break up the beast that is the CLI: good. How we get
there appears to be confusing.

Discussion for this in person probably easier and will require more than an
hour. Thoughts?

RE: Icons and Splash Screens (bug?)

[Sergey Grebnov (Akvelon)]

All  icons related instructions and docs are for PG Build only. We are working 
on core support right now. 

More info here[1] and here[2]

[1] https://github.com/apache/cordova-cli/pull/126
[2] https://github.com/apache/cordova-docs/pull/201/files

Thx!
Sergey
-Original Message-
From: Axel Nennker [mailto:ignisvul...@gmail.com] 
Sent: Monday, April 14, 2014 11:54 PM
To: dev
Subject: Re: Icons and Splash Screens (bug?)

There is a pull request related to cb-2606 for cordoava-docs. Sorry can't find 
the link to it on my phone. Sergey knows more I think.

Axel
https://github.com/apache/cordova-cli/pull/126
 Am 14.04.2014 20:35 schrieb "Brian LeRoux" :

> Hey Jeremy: ah now I get you! I've cc'd the Cordova list to see if 
> this is known (and we'll add a bug either way to fix).
>
> Thanks mang!
>
>
> On Mon, Apr 14, 2014 at 9:58 AM, Jeremy Battle  wrote:
>
> > Brian,
> >
> > This is @complexcarb from Twitter, sorry for moving to e-mail but 
> > 140 characters is difficult to manage sometimes.
> >
> > The issue I am having is that in the 3.4 docs (
> >
> http://cordova.apache.org/docs/en/3.4.0/config_ref_images.md.html#Icon
> s%20and%20Splash%20Screens
> )
> > they state that when a new project is created the folder 
> > www/res/icons
> and
> > www/res/screens will be created for icons and splash screen images 
> > respectively. However, when I create a new project using Cordova 3.4 
> > that structure is not created. Which is fine, I created them myself 
> > based on
> how
> > Phonegap 3.4 creates the folder structure. But even in doing so 
> > neither
> the
> > assets in www/res/icons or www/res/screens are used in any way 
> > during a
> run
> > or build of the application.
> >
> > Now I can just create a grunt/gulp task to go ahead and move my 
> > icons
> into
> > the appropriate platforms/android/res/drawable* folder (which I've 
> > done
> and
> > works), that's not really a big issue, but the docs make this 
> > extremely confusing referring to folder structure that isn't 
> > created, and then
> doing
> > nothing with the contents when that structure is used.
> >
> > So this is probably just incorrect documentation and not a bug in
> Cordova.
> > I should have originally tweeted that the Cordova CLI does not do 
> > what
> I'd
> > expect based on the documentation.
> >
> > Does this make a bit more sense?
> >
> > -Jeremy
> >
>

Re: Sharing code between plugman and cordova-cli

[Brian LeRoux]

I really hope we don't have to vote on this. Its the wrong path guys and I
am really hoping we can find consensus to follow Node practices in a Node
project. I recognize that Google is used to working with a single large
repo but this is not Google.


On Wed, Apr 16, 2014 at 9:41 AM, Michal Mocny  wrote:

> I should have updated this email thread.  That proposal is old news, Mark
> has done a writeup:
>
> https://docs.google.com/document/d/1GVtG6BD266dqRURKaS-GEDefb0tBYt56acxrJEKAfmE/edit
>
>
> (I know you have commented on it already, but for others)
>
> On Tue, Apr 15, 2014 at 4:20 PM, Brian LeRoux  wrote:
>
> > >
> > > I think everyone is on board with the idea that modules should be used
> to
> > > enable sharing code, and for code organization.
> > >
> >
> > Cool.
> >
> >
> > > Two problems that are happening in practice:
> > > - Multiple pull requests (plugman and CLI) to make a change
> > > - Code duplication between the repositories
> > >
> > > Both of these are solved by moving all common code into the same git
> > > repository.
> > >
> >
> > Nope. Multiple pull requests to make a single functional change could be
> > achieved by pulling a common module out. I respect you have a single repo
> > at Google but this is not the solution to everything!
> >
> >
> >
> >
> > > I think whether to make additional npm packages should happen as a
> > > follow-up, and as concrete proposals (e.g. Let's publish CordovaError
> > into
> > > an npm package)
> > >
> >
> > Sure
> >
> >
> > It's a bit weird that a lot of cordova's CLI is in a module called
> > > "cordova", but you need to install "plugman" to publish to the
> registry.
> > >
> >
> > Nope. The choice to make the CLI the entry point for developers of
> cordova
> > makes perfect sense. To have a separate tool for publishing also makes
> > sense. Exposing that tool from Cordova was always the idea.
> >
> >
> >
> > > How about folding the functionality of plugman into cordova?
> > >
> >
> > Right. This doesn't mean they have to be in the same git repo. In Cordova
> > you can use package.json to include Plugman and expose functionality.
> This
> > way you win versioning which is the point dependency management…not SCM.
> >
> >
> > > For users that are accustomed to using plugman directly, we could make
> > > plugman depend on CLI to have it continue working.
> > >
> >
> > What?! Why!
> >
>

Re: Sharing code between plugman and cordova-cli

[Michal Mocny]

I should have updated this email thread.  That proposal is old news, Mark
has done a writeup:
https://docs.google.com/document/d/1GVtG6BD266dqRURKaS-GEDefb0tBYt56acxrJEKAfmE/edit


(I know you have commented on it already, but for others)

On Tue, Apr 15, 2014 at 4:20 PM, Brian LeRoux  wrote:

> >
> > I think everyone is on board with the idea that modules should be used to
> > enable sharing code, and for code organization.
> >
>
> Cool.
>
>
> > Two problems that are happening in practice:
> > - Multiple pull requests (plugman and CLI) to make a change
> > - Code duplication between the repositories
> >
> > Both of these are solved by moving all common code into the same git
> > repository.
> >
>
> Nope. Multiple pull requests to make a single functional change could be
> achieved by pulling a common module out. I respect you have a single repo
> at Google but this is not the solution to everything!
>
>
>
>
> > I think whether to make additional npm packages should happen as a
> > follow-up, and as concrete proposals (e.g. Let's publish CordovaError
> into
> > an npm package)
> >
>
> Sure
>
>
> It's a bit weird that a lot of cordova's CLI is in a module called
> > "cordova", but you need to install "plugman" to publish to the registry.
> >
>
> Nope. The choice to make the CLI the entry point for developers of cordova
> makes perfect sense. To have a separate tool for publishing also makes
> sense. Exposing that tool from Cordova was always the idea.
>
>
>
> > How about folding the functionality of plugman into cordova?
> >
>
> Right. This doesn't mean they have to be in the same git repo. In Cordova
> you can use package.json to include Plugman and expose functionality. This
> way you win versioning which is the point dependency management…not SCM.
>
>
> > For users that are accustomed to using plugman directly, we could make
> > plugman depend on CLI to have it continue working.
> >
>
> What?! Why!
>

Re: Google Team's short-term roadmap

[Brian LeRoux]

ServiceWorker would be rad but geez I wish there was a better name.


On Tue, Apr 15, 2014 at 12:54 PM, Andrew Grieve wrote:

> Each quarter we write up our goals for the next three months. Figured
> I'd share these with the broader team :)
>
> - cordova-android /w CrossWalk    iclelland
>  - Working demo
>  - Solidify Plugin API boundary
>  - Enumerate loose ends (multi-apk generation, etc)
>
> - Chrome ADT (cordova-app-harness)--- drkemp
>  - Able to build an .apk
>  - LiveReload
>  - Blog post worthy
>
> - Better Unit Testing  --- mmocny, maxw
>  - Move all plugin-specific tests into plugin repos
>  - Tooling to easily create a mobile-spec project based on list of plugins
>
> - Intents --- maxw
>  - Android should fire intents
>  - iOS & Android should handle intents
>
> - Figure out if ServiceWorker is a workable model for Cordova --- agrieve
>  - See if Android WebView works in a Service
>  - Evaluate list of SW APIs
>
> - CLI Tools  --- kamrik & braden
>  - Improve code maintainability
>  - Better handling of plugin versions
>  - platforms via npm
>  - All fetches via "npm cache add"
>  - Support for Icons & Splashscreens
>  - Support for versionCode, bundleVersion
>
> - Independent Platform Releases  --- agrieve
>
> - Plugins  ---maxw
>   - org.chromium.gcm
>   - org.chromium.identity (v2)
>   - Bugfixing
>
> - Unbundle cca plugins from cca's npm package
>

Re: Sharing code between plugman and cordova-cli

[Brian LeRoux]

>
> I think everyone is on board with the idea that modules should be used to
> enable sharing code, and for code organization.
>

Cool.


> Two problems that are happening in practice:
> - Multiple pull requests (plugman and CLI) to make a change
> - Code duplication between the repositories
>
> Both of these are solved by moving all common code into the same git
> repository.
>

Nope. Multiple pull requests to make a single functional change could be
achieved by pulling a common module out. I respect you have a single repo
at Google but this is not the solution to everything!




> I think whether to make additional npm packages should happen as a
> follow-up, and as concrete proposals (e.g. Let's publish CordovaError into
> an npm package)
>

Sure


It's a bit weird that a lot of cordova's CLI is in a module called
> "cordova", but you need to install "plugman" to publish to the registry.
>

Nope. The choice to make the CLI the entry point for developers of cordova
makes perfect sense. To have a separate tool for publishing also makes
sense. Exposing that tool from Cordova was always the idea.



> How about folding the functionality of plugman into cordova?
>

Right. This doesn't mean they have to be in the same git repo. In Cordova
you can use package.json to include Plugman and expose functionality. This
way you win versioning which is the point dependency management…not SCM.


> For users that are accustomed to using plugman directly, we could make
> plugman depend on CLI to have it continue working.
>

What?! Why!

[GitHub] cordova-windows pull request: CB-6435 ./VERSION & /template/VERSIO...

[purplecabbage]

Github user purplecabbage commented on the pull request:

https://github.com/apache/cordova-windows/pull/25#issuecomment-40528015
  
Closed, thank you.


---
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.
---

[GitHub] cordova-windows pull request: CB-6435 ./VERSION & /template/VERSIO...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/cordova-windows/pull/25


---
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: Hangout Today @ 4:00 EST

[Andrew Grieve]

View-only: http://youtu.be/5lR1a8V_po0

On Tue, Apr 15, 2014 at 12:01 PM, Andrew Grieve  wrote:
> Link to join if you want to talk:
> https://plus.google.com/hangouts/_/hoaevent/AP36tYciQ2qhQzBbNbvbX-G0tKN9YleIV754KNT2CULwdybs72KN9w?authuser=0&hl=en-GB
>
> View-only link will come in a moment.
>
> On Tue, Apr 15, 2014 at 8:28 AM, Andrew Grieve  wrote:
>> Just wanted to remind & to start a thread for organizing the hangout today.
>>
>> I'll post the join & view links here later today.
>>
>> Really want to focus on productive discussion & not going too long (say, 1
>> hour plus some setup time).
>>
>> To that end:
>> - I'd like to *not* add to the agenda once the meeting has started. If
>> there's something you'd like to discuss, add it to the agenda beforehand.
>> This will give everyone time to think about each item beforehand, and also
>> determine whether or not they'd like to attend.
>>
>> - Each item should have an owner. Owners are responsible for introducing the
>> topic, and ideally presenting a doc of prioritized list of discussion
>> points.
>>
>>
>> I've moved the agenda from the wiki to a Google Doc, so that:
>> - People can comment on the agenda beforehand
>> - It can be used to take notes during the meeting
>>
>> I've update the link to it from:
>> https://wiki.apache.org/cordova/Google%20Hangout%20Discussion%20Notes#preview
>>
>> Direct link here:
>> https://docs.google.com/document/d/1rHo-LXNNBnYVqEmLrZ35aEEmrcxVQX0TDWgoQGY2Jt4/edit#
>>
>> Andrew

Re: Hangout Today @ 4:00 EST

[Andrew Grieve]

Link to join if you want to talk:
https://plus.google.com/hangouts/_/hoaevent/AP36tYciQ2qhQzBbNbvbX-G0tKN9YleIV754KNT2CULwdybs72KN9w?authuser=0&hl=en-GB

View-only link will come in a moment.

On Tue, Apr 15, 2014 at 8:28 AM, Andrew Grieve  wrote:
> Just wanted to remind & to start a thread for organizing the hangout today.
>
> I'll post the join & view links here later today.
>
> Really want to focus on productive discussion & not going too long (say, 1
> hour plus some setup time).
>
> To that end:
> - I'd like to *not* add to the agenda once the meeting has started. If
> there's something you'd like to discuss, add it to the agenda beforehand.
> This will give everyone time to think about each item beforehand, and also
> determine whether or not they'd like to attend.
>
> - Each item should have an owner. Owners are responsible for introducing the
> topic, and ideally presenting a doc of prioritized list of discussion
> points.
>
>
> I've moved the agenda from the wiki to a Google Doc, so that:
> - People can comment on the agenda beforehand
> - It can be used to take notes during the meeting
>
> I've update the link to it from:
> https://wiki.apache.org/cordova/Google%20Hangout%20Discussion%20Notes#preview
>
> Direct link here:
> https://docs.google.com/document/d/1rHo-LXNNBnYVqEmLrZ35aEEmrcxVQX0TDWgoQGY2Jt4/edit#
>
> Andrew

[GitHub] cordova-windows pull request: CB-6435 ./VERSION & /template/VERSIO...

[martincgg]

Github user martincgg commented on the pull request:

https://github.com/apache/cordova-windows/pull/25#issuecomment-40526960
  
Well, there's the files 3.5.0-dev set.
If want to merge them, or fix it by your own, it would be great.
Thanks a lot @clelland for taking the time.


---
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: Proposal for independent platform releases

[Steven Gill]

Shoot! Fixed


On Tue, Apr 15, 2014 at 12:53 PM, Bryan Higgins wrote:

> I don't have permission to edit or add comments to this
>
>
> On Tue, Apr 15, 2014 at 3:22 PM, Steven Gill 
> wrote:
>
> >
> >
> https://docs.google.com/document/d/1OmK_fezEiv-LIPIw242kAdKhThqfD39xbSfvjWFOmjM/edit?usp=sharing
> >
> > Very much a work in progress. I would love some more info on both option
> 1
> > and option 2 for people who are interested. Add your comments and changes
> > to the doc!
> >
>

Re: [VOTE] cordoav-cli@3.4.1-0.1.0, cordova-plugman@0.21.0 and cordova-ios@3.4.1

[Carlos Santana]

Deleting shrinkwrap.json to do testing is a bad practice.

One of the main reasons for testing with shrinkwrap.json is to make sure
everyone test the same dependencies version for the whole dependency graph.
and users get what we tested.

I think it's OK to manually edit the package.json and shrinkwrap.json to
update only the plugman version to a different one or local one, but do not
delete the shrinkwrap.json so the other dependencies get tested as intended
to be release.

This was the agreement from the discussion here:
http://markmail.org/thread/j6bv5bk5ndlokobj

--Carlos


On Tue, Apr 8, 2014 at 3:51 PM, Steven Gill  wrote:

> This vote has failed and has been broken into separate vote threads.
>
>
> On Sun, Apr 6, 2014 at 10:44 PM, Steven Gill 
> wrote:
>
> > Just chatted with Ian at the bar about this.
> >
> > I think the best way to move forward is to vote on plugman first, release
> > it and then make sure cli has proper references and vote on that.
> >
> > I'll send out a thread now
> >
> >
> > On Sun, Apr 6, 2014 at 9:39 PM, Shazron  wrote:
> >
> >> Hi Steve,
> >> Not sure what the next steps are -- are the -1s being resolved so we can
> >> get this out? Let me know how I can help.
> >>
> >>
> >> On Fri, Apr 4, 2014 at 10:45 AM, Steven Gill 
> >> wrote:
> >>
> >> > Sorry, didn't mean to hit send on that last message quite so quickly.
> >> >
> >> > We could add release branches but it would require us to change our
> >> release
> >> > process for them.
> >> >
> >> > Isn't master only broken until we release. If the process is completed
> >> > within 24hours, is having master broken a huge deal? Most people will
> >> use
> >> > npm to install cordova anyways.
> >> >
> >> >
> >> >
> >> > On Fri, Apr 4, 2014 at 10:43 AM, Steven Gill 
> >> > wrote:
> >> >
> >> > > We don't have release branches for CLI + Plugman.
> >> > >
> >> > >
> >> > > On Fri, Apr 4, 2014 at 10:40 AM, Bryan Higgins <
> >> br...@bryanhiggins.net
> >> > >wrote:
> >> > >
> >> > >> SGTM
> >> > >>
> >> > >>
> >> > >> On Fri, Apr 4, 2014 at 1:38 PM, Ian Clelland <
> iclell...@chromium.org
> >> >
> >> > >> wrote:
> >> > >>
> >> > >> > What about only adding the shrinkwrap file to git just before
> >> release,
> >> > >> on
> >> > >> > the release branch? Then only published releases on npm (and on
> >> > >> > dist.apache.org) will include that file, and the only people who
> >> have
> >> > >> to
> >> > >> > delete it manually are those people testing the release
> candidate.
> >> > >> Anyone
> >> > >> > getting master from git will not have that file.
> >> > >> >
> >> > >> >
> >> > >> > On Fri, Apr 4, 2014 at 1:25 PM, Bryan Higgins <
> >> br...@bryanhiggins.net
> >> > >> > >wrote:
> >> > >> >
> >> > >> > > Right, but someone outside of this group stumbling upon the
> repo
> >> on
> >> > >> > GitHub
> >> > >> > > won't be able to use it unless they know to delete the
> shrinkwrap
> >> > >> file.
> >> > >> > I'd
> >> > >> > > rather the process be a bit more cumbersome for us and preserve
> >> the
> >> > >> > > integrity of repo.
> >> > >> > >
> >> > >> > >
> >> > >> > > On Fri, Apr 4, 2014 at 1:11 PM, David Kemp <
> drk...@chromium.org>
> >> > >> wrote:
> >> > >> > >
> >> > >> > > > If we make the proposed change to the CLI package.json
> (change
> >> the
> >> > >> > > plugman
> >> > >> > > > dependency to ">=0.21.0-rc"),
> >> > >> > > > then all that is required for testing is to delete the
> >> shrinkwrap
> >> > >> file.
> >> > >> > > >
> >> > >> > > > That means a little less hackery to test the package that is
> >> being
> >> > >> > voted
> >> > >> > > > on.
> >> > >> > > >
> >> > >> > > > We have currently made those changes on the fly in the CI to
> >> get
> >> > it
> >> > >> > > working
> >> > >> > > > again.
> >> > >> > > >
> >> > >> > > >
> >> > >> > > >
> >> > >> > > > On Fri, Apr 4, 2014 at 12:57 PM, Bryan Higgins <
> >> > >> br...@bryanhiggins.net
> >> > >> > > > >wrote:
> >> > >> > > >
> >> > >> > > > > The other problem we face is the actual repo being unusable
> >> for
> >> > a
> >> > >> > > period
> >> > >> > > > of
> >> > >> > > > > time unless you know how to fiddle with package.json /
> >> > >> > > > npm-shrinkwrap.json.
> >> > >> > > > >
> >> > >> > > > > At the very least this should be pointed out on the README,
> >> but
> >> > >> even
> >> > >> > > that
> >> > >> > > > > doesn't seem friendly to potential contributors.
> >> > >> > > > >
> >> > >> > > > > I'm in favour of bumping the version number in CLI after
> the
> >> > vote
> >> > >> for
> >> > >> > > > cases
> >> > >> > > > > like this where we're releasing tools together. Those
> testing
> >> > the
> >> > >> CLI
> >> > >> > > for
> >> > >> > > > > release can bump up the plugman version locally.
> >> > >> > > > >
> >> > >> > > > > Otherwise we should vote on plugman first, then update CLI
> >> and
> >> > >> vote
> >> > >> > on
> >> > >> > > > > that...
> >> > >> > > > >
> >> > >> > > > >
> >> > >> > > > > On Fri, Apr 4, 2014 at 12:33 PM, Parashuram Narasimhan 

Google Team's short-term roadmap

[Andrew Grieve]

Each quarter we write up our goals for the next three months. Figured
I'd share these with the broader team :)

- cordova-android /w CrossWalk    iclelland
 - Working demo
 - Solidify Plugin API boundary
 - Enumerate loose ends (multi-apk generation, etc)

- Chrome ADT (cordova-app-harness)--- drkemp
 - Able to build an .apk
 - LiveReload
 - Blog post worthy

- Better Unit Testing  --- mmocny, maxw
 - Move all plugin-specific tests into plugin repos
 - Tooling to easily create a mobile-spec project based on list of plugins

- Intents --- maxw
 - Android should fire intents
 - iOS & Android should handle intents

- Figure out if ServiceWorker is a workable model for Cordova --- agrieve
 - See if Android WebView works in a Service
 - Evaluate list of SW APIs

- CLI Tools  --- kamrik & braden
 - Improve code maintainability
 - Better handling of plugin versions
 - platforms via npm
 - All fetches via "npm cache add"
 - Support for Icons & Splashscreens
 - Support for versionCode, bundleVersion

- Independent Platform Releases  --- agrieve

- Plugins  ---maxw
  - org.chromium.gcm
  - org.chromium.identity (v2)
  - Bugfixing

- Unbundle cca plugins from cca's npm package

Re: Proposal for independent platform releases

[Bryan Higgins]

I don't have permission to edit or add comments to this


On Tue, Apr 15, 2014 at 3:22 PM, Steven Gill  wrote:

>
> https://docs.google.com/document/d/1OmK_fezEiv-LIPIw242kAdKhThqfD39xbSfvjWFOmjM/edit?usp=sharing
>
> Very much a work in progress. I would love some more info on both option 1
> and option 2 for people who are interested. Add your comments and changes
> to the doc!
>

[GitHub] cordova-windows pull request: CB-6435 ./VERSION & /template/VERSIO...

[clelland]

Github user clelland commented on the pull request:

https://github.com/apache/cordova-windows/pull/25#issuecomment-40526123
  
I think that we should change version to 3.5.0-dev, like the other 
platforms (since 3.4.0 is released already, development should now be on 
3.5.0-dev), and then we'll make sure that it gets fixed to 3.5.0 when that gets 
released.


---
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.
---

Proposal for independent platform releases

[Steven Gill]

https://docs.google.com/document/d/1OmK_fezEiv-LIPIw242kAdKhThqfD39xbSfvjWFOmjM/edit?usp=sharing

Very much a work in progress. I would love some more info on both option 1
and option 2 for people who are interested. Add your comments and changes
to the doc!

Proposal for cli and plugman code rearrangement

[Mark Koudritsky]

A short 
proposal
for
how to rearrange cli and plugman code. Let's discuss it during the hangout
today. Feel free to comment.

Re: [DISCUSS] Plugin release this week / early next

[Michal Mocny]

We should write a coho script for that (*ducks*).


On Tue, Apr 15, 2014 at 2:14 PM, Ian Clelland  wrote:

> A little bit of both :)
>
> Versions from
> coho foreach "grep -o 'version=\".*\"' plugin.xml | head -n 2 | tail -n 1"
> -r plugins
>
> Commit counts from
> coho foreach "git log origin/master..origin/dev --oneline | grep -v
> 'Incremented plugin version' | grep -v 'Merge branch' | wc -l" -r plugins
>
> and then I collated it manually.
>
>
> On Tue, Apr 15, 2014 at 2:10 PM, Shazron  wrote:
>
> > +1
> > Ian, what tool did you use to generate that list? Was it manual or.. coho
> > ;)
> >
> >
> > On Tue, Apr 15, 2014 at 9:50 AM, Bryan Higgins  > >wrote:
> >
> > > +1
> > >
> > >
> > > On Tue, Apr 15, 2014 at 12:24 PM, Jesse MacFadyen
> > > wrote:
> > >
> > > > Yes. We need this to happen way more frequently.
> > > >
> > > > Sent from my Windows PhoneFrom: James Jong
> > > > Sent: ‎4/‎15/‎2014 9:17 AM
> > > > To: dev@cordova.apache.org
> > > > Subject: Re: [DISCUSS] Plugin release this week / early next
> > > > SGTM.  It has been awhile since our last plugins release.
> > > > -James Jong
> > > >
> > > > On Apr 15, 2014, at 11:53 AM, Ian Clelland 
> > > wrote:
> > > >
> > > > > It's been a while since we did a plugin release, and I have a
> number
> > of
> > > > > changes to File / Media that I'd like to make public. It looks
> every
> > > > plugin
> > > > > has had at least one commit since the last release, though, so
> maybe
> > we
> > > > > want to do a release of the full suite.
> > > > >
> > > > > (The one minimum commit for each appears to be an "Added NOTICE
> > file",
> > > so
> > > > > it might be good from an ASF-compliance POV)
> > > > >
> > > > > From what I can see this morning:
> > > > >
> > > > > cordova-plugin-battery-status: release 0.2.8, 1 commit
> > > > > cordova-plugin-camera: release 0.2.9, 12 commits
> > > > > cordova-plugin-console: release 0.2.8, 1 commit
> > > > > cordova-plugin-contacts: release 0.2.10, 5 commits
> > > > > cordova-plugin-device: release 0.2.9, 3 commits
> > > > > cordova-plugin-device-motion: release 0.2.7, 2 commits
> > > > > cordova-plugin-device-orientation: release 0.3.6, 3 commits
> > > > > cordova-plugin-dialogs: release 0.2.7, 5 commits
> > > > > cordova-plugin-file: release 1.0.2, 25 commits
> > > > > cordova-plugin-file-transfer: release 0.4.3, 7 commits
> > > > > cordova-plugin-geolocation: release 0.3.7, 4 commits
> > > > > cordova-plugin-globalization: release 0.2.7, 4 commits
> > > > > cordova-plugin-inappbrowser: release 0.3.4, 12 commits
> > > > > cordova-plugin-media: release 0.2.10, 4 commits
> > > > > cordova-plugin-media-capture: release 0.2.9, 8 commits
> > > > > cordova-plugin-network-information: release 0.2.8, 3 commits
> > > > > cordova-plugin-splashscreen: release 0.2.8, 3 commits
> > > > > cordova-plugin-statusbar: release 0.1.5, 4 commits
> > > > > cordova-plugin-vibration: release 0.3.8, 1 commit
> > > > >
> > > > >
> > > > > I have a couple of changes that I want to get in to media-capture
> > > today,
> > > > > but after that I'm happy with the state of the file-related
> plugins.
> > > > >
> > > > > Thoughts? We could start a vote thread tomorrow or Thursday, and
> > > release
> > > > on
> > > > > Monday if it passes.
> > > > >
> > > > > Ian
> > > >
> > >
> >
>

Re: support on phonegap/cordova?

[Michal Mocny]

Stack Overflow has the ability to subscribe to a tag, and you can change
the frequency with which the digest is delivered.


On Tue, Apr 15, 2014 at 1:41 PM, Terence M. Bandoian wrote:

> One nice thing about a mailing list is that it is delivered.  The digest
> form provides an uncluttered, passive means to stay aware of issues and
> contribute when appropriate.
>
> I'm still new to this list but would like to listen in to the hangout if
> that's possible.  How would I find it on Google Hangout?
>
> -Terence Bandoian
>
>
>
> On 4/15/2014 9:31 AM, Lisa Seacat DeLuca wrote:
>
>> Michal +1.
>>
>> 1. Create a user@ group that we use to encourage users to post questions
>> on SO.
>> 2. Update website to remove reference to PhoneGap Google Group and
>> include reference to the user@ mailing list
>> 3. remove the IRC #phonegap reference as well
>>
>> Is everyone in agreement on this?  Do we need to add an item to our
>> hangout agenda today to discuss further?
>>
>>
>>
>> Lisa Seacat DeLuca
>> Mobile Engineer | t: +415.787.4589 | _ldeluca@apache.org_ > ldel...@apache.org>| | _ldel...@us.ibm.com_ |
>> _lisaseacat.com_ | follow @LisaSeacat on
>> twitter | follow Lisa Seacat DeLuca on
>> linkedin 
>>
>>
>>
>>
>>
>>
>> From: Michal Mocny 
>> To: dev 
>> Date: 04/15/2014 09:50 AM
>> Subject: Re: support on phonegap/cordova?
>> Sent by: mmo...@google.com
>> 
>>
>>
>>
>>
>> So first: we don't *have* have to have users@ list.  This isn't about
>> "apache way" at all, this is in response to several user inquiries asking
>> for a user list to point them to.
>>
>> Seems no one is looking forward to more email, but I'd be satisfied to
>> have
>> a users@ list from which we direct people over to SO, since some people
>> don't yet know about SO and/or expect a mailing list when they go looking.
>>
>> The most important action item I think is to update the website, since
>> right now we only list the dev, commits, and issues mailing lists listed,
>> and a small note about the phonegap forum for user questions (and that was
>> hard to find without grep-ing).
>>
>> -Michal
>>
>>
>>
>>
>> On Tue, Apr 15, 2014 at 8:06 AM, Mike Billau 
>> wrote:
>>
>> > I think that between a users@ mailing list, a google group, an IRC
>> room,
>> > and StackOverflow, the best medium we can use to support our users is
>> > StackOverflow. Joe makes great points about the benefits that
>> StackOverflow
>> > gives us that I don't see the other mediums providing. Sure the GG may
>> be
>> > searchable but not nearly as well as SO. Also, there are already a lot
>> of
>> > Cordova users helping each other out on SO (only 4 of the top 20
>> > "answerers" are on this list [1]) SO also will automatically switch
>> > "phonegap" to "cordova" tag but still allow things like
>> "phonegap-build" or
>> > "phonegap-enterprise" or whatever - nothing against phonegap, this just
>> > seems to be more inline with the "Apache Way" and would help Adobe
>> support
>> > find relevant issues to them while letting the the overall community
>> work
>> > on the more general support questions.
>> >
>> > If we have to have a users@, so be it, but we should make it a point to
>> > answer all questions there with a link to the relevant Stack Overflow
>> > answer. I think we should also be doing this on the google group too,
>> but
>> > I'll be the first to admit that I haven't been.
>> >
>> > Finally I know there is a lot of push back about "getting rid of /
>> > encouraging less use of" the google group because a lot of people use it
>> > and apparently get a lot of their issues fixed, however it seems like
>> > either the majority of the questions never get answered, or they get
>> > answered by a few users. We should maybe reach out to these power users
>> and
>> > explain to them the motivation behind trying to move all support off
>> the GG
>> > and into SO and encourage them to help with this transition.
>> >
>> > [1] http://stackoverflow.com/tags/cordova/topusers
>> >
>> >
>> > On Mon, Apr 14, 2014 at 5:03 PM, Joe Bowser  wrote:
>> >
>> > > The reasons I prefer stack overflow to users lists are as follows:
>> > >
>> > > 1. Most of our users aren't skilled enough to get on or off of a users
>> > list
>> > > 2. Stack Overflow's structure keeps things more professional than the
>> > > mailing list.  Personal attacks get downvoted on SO
>> > > 3. Stack Overflow has better searchibility than a users list.
>> > >
>> > > If we have to have one because of the much loathed "Apache Way", so be
>> > > it, but I don't see it being nearly as helpful as SO.
>> > >
>> > > On Mon, Apr 14, 2014 at 1:15 PM, Andrew Grieve 
>> > > wrote:
>> > > > Most Apache projects have a users@ list for this purpose. Although
>> SO
>> > > often
>> > > > yields better answers, I don't think it would hurt to have a
>> > users@list.
>> > > >
>> > 

Re: Change id.apache.org password

[Michal Mocny]

Seems I did not have to do this after changing my password.


On Tue, Apr 15, 2014 at 1:35 PM, Andrew Grieve  wrote:

> We all had to do this thanks to <3 bleed. Just wanted to share a tip I
> needed to do to make git on osx work afterwards. You need to clear your
> cached credentials:
>
> $ git remote -v
> origin https://git-wip-us.apache.org/repos/asf/cordova-coho.git (fetch)
> origin https://git-wip-us.apache.org/repos/asf/cordova-coho.git (push)
> $ git credential-osxkeychain erase
> host=origin
> 
> 
>

Re: support on phonegap/cordova?

[Shazron]

+1 to Michael Brook's proposal.
Definitely I'm all for SO vs a users@ mailing list


On Tue, Apr 15, 2014 at 11:21 AM, Michael Brooks
wrote:

> I agree, PhoneGap references do not belong in Apache Cordova.
>
> I think it's safe to remove website links to:
> - the PhoneGap Google Groups
> - the PhoneGap IRC channel
>
> We should update the Cordova website with links to:
> - StackOverflow Cordova tag
> - #cordova IRC channel
>
> Do not:
> - do not keep the PhoneGap Google Groups link for old solutions - Google
> has this indexed for anyone searching.
> - do not create a users@ mailing list - make it earn it's place;
> StackOverflow has already done this.
>
> Michael
>
>
>
> On Tue, Apr 15, 2014 at 10:52 AM, Andrew Grieve  >wrote:
>
> > stay tuned on the ML thread with subject "Hangout Today @ 4:00 EST". I
> > will post the link there once we're set up.
> >
> > On Tue, Apr 15, 2014 at 9:41 AM, Terence M. Bandoian 
> > wrote:
> > > One nice thing about a mailing list is that it is delivered.  The
> digest
> > > form provides an uncluttered, passive means to stay aware of issues and
> > > contribute when appropriate.
> > >
> > > I'm still new to this list but would like to listen in to the hangout
> if
> > > that's possible.  How would I find it on Google Hangout?
> > >
> > > -Terence Bandoian
> > >
> > >
> > >
> > > On 4/15/2014 9:31 AM, Lisa Seacat DeLuca wrote:
> > >>
> > >> Michal +1.
> > >>
> > >> 1. Create a user@ group that we use to encourage users to post
> > questions
> > >> on SO.
> > >> 2. Update website to remove reference to PhoneGap Google Group and
> > include
> > >> reference to the user@ mailing list
> > >> 3. remove the IRC #phonegap reference as well
> > >>
> > >> Is everyone in agreement on this?  Do we need to add an item to our
> > >> hangout agenda today to discuss further?
> > >>
> > >>
> > >>
> > >> Lisa Seacat DeLuca
> > >> Mobile Engineer | t: +415.787.4589 | _ldeluca@apache.org_
> > >> | | _ldel...@us.ibm.com_
> > >> | _lisaseacat.com_ <
> > http://www.lisaseacat.com/>|
> > >> follow @LisaSeacat on twitter | follow
> Lisa
> > >> Seacat DeLuca on linkedin 
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> From: Michal Mocny 
> > >> To: dev 
> > >> Date: 04/15/2014 09:50 AM
> > >> Subject: Re: support on phonegap/cordova?
> > >> Sent by: mmo...@google.com
> > >>
> 
> > >>
> > >>
> > >>
> > >>
> > >> So first: we don't *have* have to have users@ list.  This isn't about
> > >> "apache way" at all, this is in response to several user inquiries
> > asking
> > >> for a user list to point them to.
> > >>
> > >> Seems no one is looking forward to more email, but I'd be satisfied to
> > >> have
> > >> a users@ list from which we direct people over to SO, since some
> people
> > >> don't yet know about SO and/or expect a mailing list when they go
> > looking.
> > >>
> > >> The most important action item I think is to update the website, since
> > >> right now we only list the dev, commits, and issues mailing lists
> > listed,
> > >> and a small note about the phonegap forum for user questions (and that
> > was
> > >> hard to find without grep-ing).
> > >>
> > >> -Michal
> > >>
> > >>
> > >>
> > >>
> > >> On Tue, Apr 15, 2014 at 8:06 AM, Mike Billau 
> > >> wrote:
> > >>
> > >> > I think that between a users@ mailing list, a google group, an IRC
> > room,
> > >> > and StackOverflow, the best medium we can use to support our users
> is
> > >> > StackOverflow. Joe makes great points about the benefits that
> > >> > StackOverflow
> > >> > gives us that I don't see the other mediums providing. Sure the GG
> may
> > >> > be
> > >> > searchable but not nearly as well as SO. Also, there are already a
> lot
> > >> > of
> > >> > Cordova users helping each other out on SO (only 4 of the top 20
> > >> > "answerers" are on this list [1]) SO also will automatically switch
> > >> > "phonegap" to "cordova" tag but still allow things like
> > "phonegap-build"
> > >> > or
> > >> > "phonegap-enterprise" or whatever - nothing against phonegap, this
> > just
> > >> > seems to be more inline with the "Apache Way" and would help Adobe
> > >> > support
> > >> > find relevant issues to them while letting the the overall community
> > >> > work
> > >> > on the more general support questions.
> > >> >
> > >> > If we have to have a users@, so be it, but we should make it a
> point
> > to
> > >> > answer all questions there with a link to the relevant Stack
> Overflow
> > >> > answer. I think we should also be doing this on the google group
> too,
> > >> > but
> > >> > I'll be the first to admit that I haven't been.
> > >> >
> > >> > Finally I know there is a lot of push back about "getting rid of /
> > >> > encouraging less use of" the google group because a lot of people
> use
> > it
> > >> > and apparently get a lot of their issues fixed, however it seems
> 

Draft Proposal for Docs

[Steven Gill]

https://docs.google.com/document/d/1qwpypH7sH0wH9Sbesmg8JZow-l8IqdZtF1BtLUZb1As/edit

Work in progress. Feel free to contribute! I'm hoping to do a quick chat
about this at the hangout today.

-Steve

Re: support on phonegap/cordova?

[Michael Brooks]

I agree, PhoneGap references do not belong in Apache Cordova.

I think it's safe to remove website links to:
- the PhoneGap Google Groups
- the PhoneGap IRC channel

We should update the Cordova website with links to:
- StackOverflow Cordova tag
- #cordova IRC channel

Do not:
- do not keep the PhoneGap Google Groups link for old solutions - Google
has this indexed for anyone searching.
- do not create a users@ mailing list - make it earn it's place;
StackOverflow has already done this.

Michael



On Tue, Apr 15, 2014 at 10:52 AM, Andrew Grieve wrote:

> stay tuned on the ML thread with subject "Hangout Today @ 4:00 EST". I
> will post the link there once we're set up.
>
> On Tue, Apr 15, 2014 at 9:41 AM, Terence M. Bandoian 
> wrote:
> > One nice thing about a mailing list is that it is delivered.  The digest
> > form provides an uncluttered, passive means to stay aware of issues and
> > contribute when appropriate.
> >
> > I'm still new to this list but would like to listen in to the hangout if
> > that's possible.  How would I find it on Google Hangout?
> >
> > -Terence Bandoian
> >
> >
> >
> > On 4/15/2014 9:31 AM, Lisa Seacat DeLuca wrote:
> >>
> >> Michal +1.
> >>
> >> 1. Create a user@ group that we use to encourage users to post
> questions
> >> on SO.
> >> 2. Update website to remove reference to PhoneGap Google Group and
> include
> >> reference to the user@ mailing list
> >> 3. remove the IRC #phonegap reference as well
> >>
> >> Is everyone in agreement on this?  Do we need to add an item to our
> >> hangout agenda today to discuss further?
> >>
> >>
> >>
> >> Lisa Seacat DeLuca
> >> Mobile Engineer | t: +415.787.4589 | _ldeluca@apache.org_
> >> | | _ldel...@us.ibm.com_
> >> | _lisaseacat.com_ <
> http://www.lisaseacat.com/>|
> >> follow @LisaSeacat on twitter | follow Lisa
> >> Seacat DeLuca on linkedin 
> >>
> >>
> >>
> >>
> >>
> >>
> >> From: Michal Mocny 
> >> To: dev 
> >> Date: 04/15/2014 09:50 AM
> >> Subject: Re: support on phonegap/cordova?
> >> Sent by: mmo...@google.com
> >> 
> >>
> >>
> >>
> >>
> >> So first: we don't *have* have to have users@ list.  This isn't about
> >> "apache way" at all, this is in response to several user inquiries
> asking
> >> for a user list to point them to.
> >>
> >> Seems no one is looking forward to more email, but I'd be satisfied to
> >> have
> >> a users@ list from which we direct people over to SO, since some people
> >> don't yet know about SO and/or expect a mailing list when they go
> looking.
> >>
> >> The most important action item I think is to update the website, since
> >> right now we only list the dev, commits, and issues mailing lists
> listed,
> >> and a small note about the phonegap forum for user questions (and that
> was
> >> hard to find without grep-ing).
> >>
> >> -Michal
> >>
> >>
> >>
> >>
> >> On Tue, Apr 15, 2014 at 8:06 AM, Mike Billau 
> >> wrote:
> >>
> >> > I think that between a users@ mailing list, a google group, an IRC
> room,
> >> > and StackOverflow, the best medium we can use to support our users is
> >> > StackOverflow. Joe makes great points about the benefits that
> >> > StackOverflow
> >> > gives us that I don't see the other mediums providing. Sure the GG may
> >> > be
> >> > searchable but not nearly as well as SO. Also, there are already a lot
> >> > of
> >> > Cordova users helping each other out on SO (only 4 of the top 20
> >> > "answerers" are on this list [1]) SO also will automatically switch
> >> > "phonegap" to "cordova" tag but still allow things like
> "phonegap-build"
> >> > or
> >> > "phonegap-enterprise" or whatever - nothing against phonegap, this
> just
> >> > seems to be more inline with the "Apache Way" and would help Adobe
> >> > support
> >> > find relevant issues to them while letting the the overall community
> >> > work
> >> > on the more general support questions.
> >> >
> >> > If we have to have a users@, so be it, but we should make it a point
> to
> >> > answer all questions there with a link to the relevant Stack Overflow
> >> > answer. I think we should also be doing this on the google group too,
> >> > but
> >> > I'll be the first to admit that I haven't been.
> >> >
> >> > Finally I know there is a lot of push back about "getting rid of /
> >> > encouraging less use of" the google group because a lot of people use
> it
> >> > and apparently get a lot of their issues fixed, however it seems like
> >> > either the majority of the questions never get answered, or they get
> >> > answered by a few users. We should maybe reach out to these power
> users
> >> > and
> >> > explain to them the motivation behind trying to move all support off
> the
> >> > GG
> >> > and into SO and encourage them to help with this transition.
> >> >
> >> > [1] http://stackoverflow.com/tags/cordova/topusers
> >> >
> >> >
> >> > On Mon, Apr 14, 2

Re: [DISCUSS] Plugin release this week / early next

[Ian Clelland]

A little bit of both :)

Versions from
coho foreach "grep -o 'version=\".*\"' plugin.xml | head -n 2 | tail -n 1"
-r plugins

Commit counts from
coho foreach "git log origin/master..origin/dev --oneline | grep -v
'Incremented plugin version' | grep -v 'Merge branch' | wc -l" -r plugins

and then I collated it manually.


On Tue, Apr 15, 2014 at 2:10 PM, Shazron  wrote:

> +1
> Ian, what tool did you use to generate that list? Was it manual or.. coho
> ;)
>
>
> On Tue, Apr 15, 2014 at 9:50 AM, Bryan Higgins  >wrote:
>
> > +1
> >
> >
> > On Tue, Apr 15, 2014 at 12:24 PM, Jesse MacFadyen
> > wrote:
> >
> > > Yes. We need this to happen way more frequently.
> > >
> > > Sent from my Windows PhoneFrom: James Jong
> > > Sent: ‎4/‎15/‎2014 9:17 AM
> > > To: dev@cordova.apache.org
> > > Subject: Re: [DISCUSS] Plugin release this week / early next
> > > SGTM.  It has been awhile since our last plugins release.
> > > -James Jong
> > >
> > > On Apr 15, 2014, at 11:53 AM, Ian Clelland 
> > wrote:
> > >
> > > > It's been a while since we did a plugin release, and I have a number
> of
> > > > changes to File / Media that I'd like to make public. It looks every
> > > plugin
> > > > has had at least one commit since the last release, though, so maybe
> we
> > > > want to do a release of the full suite.
> > > >
> > > > (The one minimum commit for each appears to be an "Added NOTICE
> file",
> > so
> > > > it might be good from an ASF-compliance POV)
> > > >
> > > > From what I can see this morning:
> > > >
> > > > cordova-plugin-battery-status: release 0.2.8, 1 commit
> > > > cordova-plugin-camera: release 0.2.9, 12 commits
> > > > cordova-plugin-console: release 0.2.8, 1 commit
> > > > cordova-plugin-contacts: release 0.2.10, 5 commits
> > > > cordova-plugin-device: release 0.2.9, 3 commits
> > > > cordova-plugin-device-motion: release 0.2.7, 2 commits
> > > > cordova-plugin-device-orientation: release 0.3.6, 3 commits
> > > > cordova-plugin-dialogs: release 0.2.7, 5 commits
> > > > cordova-plugin-file: release 1.0.2, 25 commits
> > > > cordova-plugin-file-transfer: release 0.4.3, 7 commits
> > > > cordova-plugin-geolocation: release 0.3.7, 4 commits
> > > > cordova-plugin-globalization: release 0.2.7, 4 commits
> > > > cordova-plugin-inappbrowser: release 0.3.4, 12 commits
> > > > cordova-plugin-media: release 0.2.10, 4 commits
> > > > cordova-plugin-media-capture: release 0.2.9, 8 commits
> > > > cordova-plugin-network-information: release 0.2.8, 3 commits
> > > > cordova-plugin-splashscreen: release 0.2.8, 3 commits
> > > > cordova-plugin-statusbar: release 0.1.5, 4 commits
> > > > cordova-plugin-vibration: release 0.3.8, 1 commit
> > > >
> > > >
> > > > I have a couple of changes that I want to get in to media-capture
> > today,
> > > > but after that I'm happy with the state of the file-related plugins.
> > > >
> > > > Thoughts? We could start a vote thread tomorrow or Thursday, and
> > release
> > > on
> > > > Monday if it passes.
> > > >
> > > > Ian
> > >
> >
>

Re: [DISCUSS] Plugin release this week / early next

[Shazron]

+1
Ian, what tool did you use to generate that list? Was it manual or.. coho ;)


On Tue, Apr 15, 2014 at 9:50 AM, Bryan Higgins wrote:

> +1
>
>
> On Tue, Apr 15, 2014 at 12:24 PM, Jesse MacFadyen
> wrote:
>
> > Yes. We need this to happen way more frequently.
> >
> > Sent from my Windows PhoneFrom: James Jong
> > Sent: ‎4/‎15/‎2014 9:17 AM
> > To: dev@cordova.apache.org
> > Subject: Re: [DISCUSS] Plugin release this week / early next
> > SGTM.  It has been awhile since our last plugins release.
> > -James Jong
> >
> > On Apr 15, 2014, at 11:53 AM, Ian Clelland 
> wrote:
> >
> > > It's been a while since we did a plugin release, and I have a number of
> > > changes to File / Media that I'd like to make public. It looks every
> > plugin
> > > has had at least one commit since the last release, though, so maybe we
> > > want to do a release of the full suite.
> > >
> > > (The one minimum commit for each appears to be an "Added NOTICE file",
> so
> > > it might be good from an ASF-compliance POV)
> > >
> > > From what I can see this morning:
> > >
> > > cordova-plugin-battery-status: release 0.2.8, 1 commit
> > > cordova-plugin-camera: release 0.2.9, 12 commits
> > > cordova-plugin-console: release 0.2.8, 1 commit
> > > cordova-plugin-contacts: release 0.2.10, 5 commits
> > > cordova-plugin-device: release 0.2.9, 3 commits
> > > cordova-plugin-device-motion: release 0.2.7, 2 commits
> > > cordova-plugin-device-orientation: release 0.3.6, 3 commits
> > > cordova-plugin-dialogs: release 0.2.7, 5 commits
> > > cordova-plugin-file: release 1.0.2, 25 commits
> > > cordova-plugin-file-transfer: release 0.4.3, 7 commits
> > > cordova-plugin-geolocation: release 0.3.7, 4 commits
> > > cordova-plugin-globalization: release 0.2.7, 4 commits
> > > cordova-plugin-inappbrowser: release 0.3.4, 12 commits
> > > cordova-plugin-media: release 0.2.10, 4 commits
> > > cordova-plugin-media-capture: release 0.2.9, 8 commits
> > > cordova-plugin-network-information: release 0.2.8, 3 commits
> > > cordova-plugin-splashscreen: release 0.2.8, 3 commits
> > > cordova-plugin-statusbar: release 0.1.5, 4 commits
> > > cordova-plugin-vibration: release 0.3.8, 1 commit
> > >
> > >
> > > I have a couple of changes that I want to get in to media-capture
> today,
> > > but after that I'm happy with the state of the file-related plugins.
> > >
> > > Thoughts? We could start a vote thread tomorrow or Thursday, and
> release
> > on
> > > Monday if it passes.
> > >
> > > Ian
> >
>

RE: Sharing code between plugman and cordova-cli

[Jonathan Bond-Caron]

On Tue Apr 15 09:36 AM, Andrew Grieve wrote:
> I think everyone is on board with the idea that modules should be used to 
> enable
> sharing code, and for code organization.
> 
> Two problems that are happening in practice:
> - Multiple pull requests (plugman and CLI) to make a change
> - Code duplication between the repositories
> 

+1, from a new contributor's perspective, learning about git & coordinating 
pull requests to 2+ repos was quite challenging. Probably equally challenging 
to review :) 

> - Only one tool for devs to install (aptly named "cordova")
>- "cordova --help" as one entry-point to what's available

Like this, with cordova-lib or cordova-common being a reasonable transition to 
help clarify how or if plugman should be merged. 

Re: support on phonegap/cordova?

[Andrew Grieve]

stay tuned on the ML thread with subject "Hangout Today @ 4:00 EST". I
will post the link there once we're set up.

On Tue, Apr 15, 2014 at 9:41 AM, Terence M. Bandoian  wrote:
> One nice thing about a mailing list is that it is delivered.  The digest
> form provides an uncluttered, passive means to stay aware of issues and
> contribute when appropriate.
>
> I'm still new to this list but would like to listen in to the hangout if
> that's possible.  How would I find it on Google Hangout?
>
> -Terence Bandoian
>
>
>
> On 4/15/2014 9:31 AM, Lisa Seacat DeLuca wrote:
>>
>> Michal +1.
>>
>> 1. Create a user@ group that we use to encourage users to post questions
>> on SO.
>> 2. Update website to remove reference to PhoneGap Google Group and include
>> reference to the user@ mailing list
>> 3. remove the IRC #phonegap reference as well
>>
>> Is everyone in agreement on this?  Do we need to add an item to our
>> hangout agenda today to discuss further?
>>
>>
>>
>> Lisa Seacat DeLuca
>> Mobile Engineer | t: +415.787.4589 | _ldeluca@apache.org_
>> | | _ldel...@us.ibm.com_
>> | _lisaseacat.com_ |
>> follow @LisaSeacat on twitter | follow Lisa
>> Seacat DeLuca on linkedin 
>>
>>
>>
>>
>>
>>
>> From: Michal Mocny 
>> To: dev 
>> Date: 04/15/2014 09:50 AM
>> Subject: Re: support on phonegap/cordova?
>> Sent by: mmo...@google.com
>> 
>>
>>
>>
>>
>> So first: we don't *have* have to have users@ list.  This isn't about
>> "apache way" at all, this is in response to several user inquiries asking
>> for a user list to point them to.
>>
>> Seems no one is looking forward to more email, but I'd be satisfied to
>> have
>> a users@ list from which we direct people over to SO, since some people
>> don't yet know about SO and/or expect a mailing list when they go looking.
>>
>> The most important action item I think is to update the website, since
>> right now we only list the dev, commits, and issues mailing lists listed,
>> and a small note about the phonegap forum for user questions (and that was
>> hard to find without grep-ing).
>>
>> -Michal
>>
>>
>>
>>
>> On Tue, Apr 15, 2014 at 8:06 AM, Mike Billau 
>> wrote:
>>
>> > I think that between a users@ mailing list, a google group, an IRC room,
>> > and StackOverflow, the best medium we can use to support our users is
>> > StackOverflow. Joe makes great points about the benefits that
>> > StackOverflow
>> > gives us that I don't see the other mediums providing. Sure the GG may
>> > be
>> > searchable but not nearly as well as SO. Also, there are already a lot
>> > of
>> > Cordova users helping each other out on SO (only 4 of the top 20
>> > "answerers" are on this list [1]) SO also will automatically switch
>> > "phonegap" to "cordova" tag but still allow things like "phonegap-build"
>> > or
>> > "phonegap-enterprise" or whatever - nothing against phonegap, this just
>> > seems to be more inline with the "Apache Way" and would help Adobe
>> > support
>> > find relevant issues to them while letting the the overall community
>> > work
>> > on the more general support questions.
>> >
>> > If we have to have a users@, so be it, but we should make it a point to
>> > answer all questions there with a link to the relevant Stack Overflow
>> > answer. I think we should also be doing this on the google group too,
>> > but
>> > I'll be the first to admit that I haven't been.
>> >
>> > Finally I know there is a lot of push back about "getting rid of /
>> > encouraging less use of" the google group because a lot of people use it
>> > and apparently get a lot of their issues fixed, however it seems like
>> > either the majority of the questions never get answered, or they get
>> > answered by a few users. We should maybe reach out to these power users
>> > and
>> > explain to them the motivation behind trying to move all support off the
>> > GG
>> > and into SO and encourage them to help with this transition.
>> >
>> > [1] http://stackoverflow.com/tags/cordova/topusers
>> >
>> >
>> > On Mon, Apr 14, 2014 at 5:03 PM, Joe Bowser  wrote:
>> >
>> > > The reasons I prefer stack overflow to users lists are as follows:
>> > >
>> > > 1. Most of our users aren't skilled enough to get on or off of a users
>> > list
>> > > 2. Stack Overflow's structure keeps things more professional than the
>> > > mailing list.  Personal attacks get downvoted on SO
>> > > 3. Stack Overflow has better searchibility than a users list.
>> > >
>> > > If we have to have one because of the much loathed "Apache Way", so be
>> > > it, but I don't see it being nearly as helpful as SO.
>> > >
>> > > On Mon, Apr 14, 2014 at 1:15 PM, Andrew Grieve 
>> > > wrote:
>> > > > Most Apache projects have a users@ list for this purpose. Although
>> > > > SO
>> > > often
>> > > > yields better answers, I don't think it would hurt to have a
>> > user

Re: support on phonegap/cordova?

[Terence M. Bandoian]

One nice thing about a mailing list is that it is delivered.  The digest 
form provides an uncluttered, passive means to stay aware of issues and 
contribute when appropriate.


I'm still new to this list but would like to listen in to the hangout if 
that's possible.  How would I find it on Google Hangout?


-Terence Bandoian


On 4/15/2014 9:31 AM, Lisa Seacat DeLuca wrote:

Michal +1.

1. Create a user@ group that we use to encourage users to post 
questions on SO.
2. Update website to remove reference to PhoneGap Google Group and 
include reference to the user@ mailing list

3. remove the IRC #phonegap reference as well

Is everyone in agreement on this?  Do we need to add an item to our 
hangout agenda today to discuss further?




Lisa Seacat DeLuca
Mobile Engineer | t: +415.787.4589 | _ldeluca@apache.org_ 
| | _ldel...@us.ibm.com_ 
| _lisaseacat.com_ 
| follow @LisaSeacat on twitter 
| follow Lisa Seacat DeLuca on linkedin 







From: Michal Mocny 
To: dev 
Date: 04/15/2014 09:50 AM
Subject: Re: support on phonegap/cordova?
Sent by: mmo...@google.com




So first: we don't *have* have to have users@ list.  This isn't about
"apache way" at all, this is in response to several user inquiries asking
for a user list to point them to.

Seems no one is looking forward to more email, but I'd be satisfied to 
have

a users@ list from which we direct people over to SO, since some people
don't yet know about SO and/or expect a mailing list when they go looking.

The most important action item I think is to update the website, since
right now we only list the dev, commits, and issues mailing lists listed,
and a small note about the phonegap forum for user questions (and that was
hard to find without grep-ing).

-Michal




On Tue, Apr 15, 2014 at 8:06 AM, Mike Billau  
wrote:


> I think that between a users@ mailing list, a google group, an IRC room,
> and StackOverflow, the best medium we can use to support our users is
> StackOverflow. Joe makes great points about the benefits that 
StackOverflow
> gives us that I don't see the other mediums providing. Sure the GG 
may be
> searchable but not nearly as well as SO. Also, there are already a 
lot of

> Cordova users helping each other out on SO (only 4 of the top 20
> "answerers" are on this list [1]) SO also will automatically switch
> "phonegap" to "cordova" tag but still allow things like 
"phonegap-build" or

> "phonegap-enterprise" or whatever - nothing against phonegap, this just
> seems to be more inline with the "Apache Way" and would help Adobe 
support
> find relevant issues to them while letting the the overall community 
work

> on the more general support questions.
>
> If we have to have a users@, so be it, but we should make it a point to
> answer all questions there with a link to the relevant Stack Overflow
> answer. I think we should also be doing this on the google group 
too, but

> I'll be the first to admit that I haven't been.
>
> Finally I know there is a lot of push back about "getting rid of /
> encouraging less use of" the google group because a lot of people use it
> and apparently get a lot of their issues fixed, however it seems like
> either the majority of the questions never get answered, or they get
> answered by a few users. We should maybe reach out to these power 
users and
> explain to them the motivation behind trying to move all support off 
the GG

> and into SO and encourage them to help with this transition.
>
> [1] http://stackoverflow.com/tags/cordova/topusers
>
>
> On Mon, Apr 14, 2014 at 5:03 PM, Joe Bowser  wrote:
>
> > The reasons I prefer stack overflow to users lists are as follows:
> >
> > 1. Most of our users aren't skilled enough to get on or off of a users
> list
> > 2. Stack Overflow's structure keeps things more professional than the
> > mailing list.  Personal attacks get downvoted on SO
> > 3. Stack Overflow has better searchibility than a users list.
> >
> > If we have to have one because of the much loathed "Apache Way", so be
> > it, but I don't see it being nearly as helpful as SO.
> >
> > On Mon, Apr 14, 2014 at 1:15 PM, Andrew Grieve 
> > wrote:
> > > Most Apache projects have a users@ list for this purpose. 
Although SO

> > often
> > > yields better answers, I don't think it would hurt to have a
> users@list.
> > >
> > >
> > > On Fri, Apr 11, 2014 at 9:09 AM, Joe Bowser  
wrote:

> > >
> > >> This is a dev list, not a support list. I would recommend
> StackOverflow.
> > >>  On Apr 9, 2014 3:16 PM, "Andrew Grieve" 
> wrote:
> > >>
> > >> > StackOverflow works really well as well. If it's a possible 
but in

> the
> > >> > framework or an Apache plugin though, this is the list :)
> > >> >
> > >> >
> > >> > On Wed, Apr 9, 2014 at 6:21 AM, Ray Camden 
> > wrote:
> > >> >
> > >> > > I'd use the Google Group:

Change id.apache.org password

[Andrew Grieve]

We all had to do this thanks to <3 bleed. Just wanted to share a tip I
needed to do to make git on osx work afterwards. You need to clear your
cached credentials:

$ git remote -v
origin https://git-wip-us.apache.org/repos/asf/cordova-coho.git (fetch)
origin https://git-wip-us.apache.org/repos/asf/cordova-coho.git (push)
$ git credential-osxkeychain erase
host=origin

Re: [jira] [Commented] (CB-5194) Camera.getPicture with sourceType: PHOTOLIBRARY doesn't respect correctOrientation unless targetWidth/Height also specified

[Роман]

stop it

Пользователь "Clément Vollet (JIRA)"  писал:

>
>[ 
> https://issues.apache.org/jira/browse/CB-5194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13969781#comment-13969781
>  ] 
>
>Clément Vollet commented on CB-5194:
>
>
>[~bowserj] I'd say 
>https://github.com/apache/cordova-plugin-camera/commit/4ae4414856762e9250f5579c7052315d62733032
> (dunno why the commit message has been modified). The problem was that the 
>image was rotated, but not saved if no targetHeight or targetWidth were set.
>
>> Camera.getPicture with sourceType: PHOTOLIBRARY doesn't respect 
>> correctOrientation unless targetWidth/Height also specified
>> ---
>>
>> Key: CB-5194
>> URL: https://issues.apache.org/jira/browse/CB-5194
>> Project: Apache Cordova
>>  Issue Type: Bug
>>  Components: Android, Plugin Camera
>>Affects Versions: 2.6.0
>> Environment: Galaxy S4
>>Reporter: Andre Asselin
>>Priority: Minor
>>
>> Use Camera.getPicture() with sourceType: PHOTOLIBRARY to retrieve a picture 
>> from the library.  The correctOrientation option will be ignored unless you 
>> also specify targetWidth/Height as options.  The documentation doesn't state 
>> there is a dependency.
>
>
>
>--
>This message was sent by Atlassian JIRA
>(v6.2#6252)

Re: [DISCUSS] Plugin release this week / early next

[Bryan Higgins]

+1


On Tue, Apr 15, 2014 at 12:24 PM, Jesse MacFadyen
wrote:

> Yes. We need this to happen way more frequently.
>
> Sent from my Windows PhoneFrom: James Jong
> Sent: ‎4/‎15/‎2014 9:17 AM
> To: dev@cordova.apache.org
> Subject: Re: [DISCUSS] Plugin release this week / early next
> SGTM.  It has been awhile since our last plugins release.
> -James Jong
>
> On Apr 15, 2014, at 11:53 AM, Ian Clelland  wrote:
>
> > It's been a while since we did a plugin release, and I have a number of
> > changes to File / Media that I'd like to make public. It looks every
> plugin
> > has had at least one commit since the last release, though, so maybe we
> > want to do a release of the full suite.
> >
> > (The one minimum commit for each appears to be an "Added NOTICE file", so
> > it might be good from an ASF-compliance POV)
> >
> > From what I can see this morning:
> >
> > cordova-plugin-battery-status: release 0.2.8, 1 commit
> > cordova-plugin-camera: release 0.2.9, 12 commits
> > cordova-plugin-console: release 0.2.8, 1 commit
> > cordova-plugin-contacts: release 0.2.10, 5 commits
> > cordova-plugin-device: release 0.2.9, 3 commits
> > cordova-plugin-device-motion: release 0.2.7, 2 commits
> > cordova-plugin-device-orientation: release 0.3.6, 3 commits
> > cordova-plugin-dialogs: release 0.2.7, 5 commits
> > cordova-plugin-file: release 1.0.2, 25 commits
> > cordova-plugin-file-transfer: release 0.4.3, 7 commits
> > cordova-plugin-geolocation: release 0.3.7, 4 commits
> > cordova-plugin-globalization: release 0.2.7, 4 commits
> > cordova-plugin-inappbrowser: release 0.3.4, 12 commits
> > cordova-plugin-media: release 0.2.10, 4 commits
> > cordova-plugin-media-capture: release 0.2.9, 8 commits
> > cordova-plugin-network-information: release 0.2.8, 3 commits
> > cordova-plugin-splashscreen: release 0.2.8, 3 commits
> > cordova-plugin-statusbar: release 0.1.5, 4 commits
> > cordova-plugin-vibration: release 0.3.8, 1 commit
> >
> >
> > I have a couple of changes that I want to get in to media-capture today,
> > but after that I'm happy with the state of the file-related plugins.
> >
> > Thoughts? We could start a vote thread tomorrow or Thursday, and release
> on
> > Monday if it passes.
> >
> > Ian
>

[GitHub] cordova-mobile-spec pull request: CB-6437[Improvements & support f...

[martincgg]

Github user martincgg commented on a diff in the pull request:

https://github.com/apache/cordova-mobile-spec/pull/55#discussion_r11643737
  
--- Diff: createmobilespec/createmobilespec.js ---
@@ -17,99 +16,215 @@
 KIND, either express or implied.  See the License for the
 specific language governing permissions and limitations
 under the License.
-*/
+ */
 
 var fs = require('fs'),
 path = require('path'),
-shelljs,
-optimist;
+child_process = require('child_process'),
+shelljs;
+
+// Dependencies requirements check
 try {
 shelljs = require('shelljs');
-optimist = require('optimist');
 } catch (e) {
 console.error('Missing module. Please run "npm install" from this 
directory:\n\t' +
-   path.dirname(__dirname));
+path.dirname(__dirname));
 process.exit(2);
 }
 
-var tokens = process.argv.slice(2);
-var argv = optimist(tokens)
-   .default('android', false)
-   .default('ios', false)
-   .usage('Usage: $0 [--android] [--ios]\nDefault is to use 
Android and iOS.')
-   .argv;
-// preserve the original behavior when there are no args
-if (tokens.length === 0) {
-argv.android = true;
-argv.ios = true;
+console.log('Creating mobilespec project. If you have any errors, it may 
be from missing repositories.');
+console.log('To clone needed repositories:');
+console.log('  ./cordova-coho/coho repo-clone -r plugins -r mobile-spec -r 
android -r ios -r cli');
+console.log('To update all repositories:');
+console.log('  ./cordova-coho/coho repo-update');
+
+// Setting up vars, folders and libraries, to ensure full compatibility 
cross platform, absolute paths are used instead of relative paths
+var mainModDir = process.cwd(),
+// Cordova Coho dir, it should contain all libraries and required 
repositories
+// [cordova-cli, cordova-android, cordova-blackberry, cordova-ios, 
cordova-windows, cordova-windows8, all plugins libraries, cordova-mobile-spec, 
cordova-js]
+// searchDir function it was added, to look for cordova-coho folder 
backwards, for cases like absolute/path/cordova-coho/cordova-coho/...All 
libraries
+// This is to make sure that cordova-coho exists and it's the right one.
+coho_dir = searchDir(mainModDir, 'cordova-coho'),
+cordova_cli = path.join(coho_dir, 'cordova-cli', 'bin', 'cordova'),
+cordova_ms = (path.join(coho_dir, 'cordova-mobile-spec')),
+cordova_js = (path.join(coho_dir, 'cordova-js')),
+ms_project_dir = (path.join(mainModDir, 'mobilespec'));
+
+// Main libraries and path's requirements check
+if (!fs.existsSync(coho_dir)) {
+console.log('Please run this script from the directory that contains 
cordova-coho');
+shelljs.exit(1);
 }
-var platforms = [];
-if (argv.android) { platforms.push('android'); }
-if (argv.ios) { platforms.push('ios'); }
 
-if (!fs.existsSync('cordova-mobile-spec')) {
+if (!fs.existsSync(cordova_ms)) {
 console.log('Please run this script from the directory that contains 
cordova-mobile-spec');
 shelljs.exit(1);
 }
 
-if (fs.existsSync('mobilespec')) {
-console.log('Directory "mobilespec" already exists. Delete it first 
then re-run.');
+if (!fs.existsSync(cordova_js)) {
+console.log('Please run this script from the directory that contains 
cordova-js');
 shelljs.exit(1);
 }
 
-console.log('Creating mobilespec project. If you have any errors, it may 
be from missing repositories.');
-console.log('To clone needed repositories:');
-console.log("  ./cordova-coho/coho repo-clone -r plugins -r mobile-spec -r 
cli -r " + platforms.join(' -r '));
-console.log('To update all repositories:');
-console.log('  ./cordova-coho/coho repo-update');
+//Determine which platforms are available
+// Default platforms [Android, Blackberry], both platforms works under 
Windows, Linux and Mac OS
+cordovaPlatforms = ['android', 'blackberry10'];
--- End diff --

It makes perfect sense, I understand the point, and I'm agree, if a parent 
script uses createmobilespec, interactions will become in a problem, I'll 
change the source to use optimist to get args, and of course it would be better 
if we let to the cordova manage the errors.
I'll make the changes and commit them soon.
Thanks for the feedback.


---
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.
---

[GitHub] cordova-mobile-spec pull request: CB-6437[Improvements & support f...

[martincgg]

Github user martincgg commented on a diff in the pull request:

https://github.com/apache/cordova-mobile-spec/pull/55#discussion_r11643490
  
--- Diff: createmobilespec/createmobilespec.js ---
@@ -17,99 +16,215 @@
 KIND, either express or implied.  See the License for the
 specific language governing permissions and limitations
 under the License.
-*/
+ */
 
 var fs = require('fs'),
 path = require('path'),
-shelljs,
-optimist;
+child_process = require('child_process'),
+shelljs;
+
+// Dependencies requirements check
 try {
 shelljs = require('shelljs');
-optimist = require('optimist');
 } catch (e) {
 console.error('Missing module. Please run "npm install" from this 
directory:\n\t' +
-   path.dirname(__dirname));
+path.dirname(__dirname));
 process.exit(2);
 }
 
-var tokens = process.argv.slice(2);
-var argv = optimist(tokens)
-   .default('android', false)
-   .default('ios', false)
-   .usage('Usage: $0 [--android] [--ios]\nDefault is to use 
Android and iOS.')
-   .argv;
-// preserve the original behavior when there are no args
-if (tokens.length === 0) {
-argv.android = true;
-argv.ios = true;
+console.log('Creating mobilespec project. If you have any errors, it may 
be from missing repositories.');
+console.log('To clone needed repositories:');
+console.log('  ./cordova-coho/coho repo-clone -r plugins -r mobile-spec -r 
android -r ios -r cli');
+console.log('To update all repositories:');
+console.log('  ./cordova-coho/coho repo-update');
+
+// Setting up vars, folders and libraries, to ensure full compatibility 
cross platform, absolute paths are used instead of relative paths
+var mainModDir = process.cwd(),
+// Cordova Coho dir, it should contain all libraries and required 
repositories
+// [cordova-cli, cordova-android, cordova-blackberry, cordova-ios, 
cordova-windows, cordova-windows8, all plugins libraries, cordova-mobile-spec, 
cordova-js]
+// searchDir function it was added, to look for cordova-coho folder 
backwards, for cases like absolute/path/cordova-coho/cordova-coho/...All 
libraries
+// This is to make sure that cordova-coho exists and it's the right one.
+coho_dir = searchDir(mainModDir, 'cordova-coho'),
+cordova_cli = path.join(coho_dir, 'cordova-cli', 'bin', 'cordova'),
+cordova_ms = (path.join(coho_dir, 'cordova-mobile-spec')),
+cordova_js = (path.join(coho_dir, 'cordova-js')),
+ms_project_dir = (path.join(mainModDir, 'mobilespec'));
+
+// Main libraries and path's requirements check
+if (!fs.existsSync(coho_dir)) {
+console.log('Please run this script from the directory that contains 
cordova-coho');
+shelljs.exit(1);
 }
-var platforms = [];
-if (argv.android) { platforms.push('android'); }
-if (argv.ios) { platforms.push('ios'); }
 
-if (!fs.existsSync('cordova-mobile-spec')) {
+if (!fs.existsSync(cordova_ms)) {
 console.log('Please run this script from the directory that contains 
cordova-mobile-spec');
 shelljs.exit(1);
 }
 
-if (fs.existsSync('mobilespec')) {
-console.log('Directory "mobilespec" already exists. Delete it first 
then re-run.');
+if (!fs.existsSync(cordova_js)) {
+console.log('Please run this script from the directory that contains 
cordova-js');
 shelljs.exit(1);
 }
 
-console.log('Creating mobilespec project. If you have any errors, it may 
be from missing repositories.');
-console.log('To clone needed repositories:');
-console.log("  ./cordova-coho/coho repo-clone -r plugins -r mobile-spec -r 
cli -r " + platforms.join(' -r '));
-console.log('To update all repositories:');
-console.log('  ./cordova-coho/coho repo-update');
+//Determine which platforms are available
+// Default platforms [Android, Blackberry], both platforms works under 
Windows, Linux and Mac OS
+cordovaPlatforms = ['android', 'blackberry10'];
+if (/^win/.test(process.platform)) {
+//Determine windows 8 platform
+child_process.exec('wmic os get caption', function (error, stdout, 
stderr) {
+if (error !== null) {
+callback = 'Error performing command: ' + error + "\n" + 
stderr;
+} else {
+// If Windows 8, add Windows Phone 8 and Windows8 platform to 
the array
+if ((/.*(Windows 8).*/gi).test(((stdout.replace(/\r\r\n/i, ': 
')).replace(/\s\s+/g, '')).replace((/\n|\r/gi), ''))) {
+cordovaPlatforms.push('wp8', 'windows8');
+}
+}
+});
+} else {
+//If Mac Os, add iOS platform
+if (/^darwin/.test(process.platform))
+cordovaPlatforms.push('ios');

Hangout Today @ 4:00 EST

[Andrew Grieve]

Just wanted to remind & to start a thread for organizing the hangout today.

I'll post the join & view links here later today.

Really want to focus on productive discussion & not going too long (say, 1
hour plus some setup time).

To that end:
- I'd like to *not* add to the agenda once the meeting has started. If
there's something you'd like to discuss, add it to the agenda beforehand.
This will give everyone time to think about each item beforehand, and also
determine whether or not they'd like to attend.

- Each item should have an owner. Owners are responsible for introducing
the topic, and ideally presenting a doc of prioritized list of discussion
points.


I've moved the agenda from the wiki to a Google Doc, so that:
- People can comment on the agenda beforehand
- It can be used to take notes during the meeting

I've update the link to it from:
https://wiki.apache.org/cordova/Google%20Hangout%20Discussion%20Notes#preview

Direct link here:
https://docs.google.com/document/d/1rHo-LXNNBnYVqEmLrZ35aEEmrcxVQX0TDWgoQGY2Jt4/edit#

Andrew

RE: [DISCUSS] Plugin release this week / early next

[Jesse MacFadyen]

Yes. We need this to happen way more frequently.

Sent from my Windows PhoneFrom: James Jong
Sent: ‎4/‎15/‎2014 9:17 AM
To: dev@cordova.apache.org
Subject: Re: [DISCUSS] Plugin release this week / early next
SGTM.  It has been awhile since our last plugins release.
-James Jong

On Apr 15, 2014, at 11:53 AM, Ian Clelland  wrote:

> It's been a while since we did a plugin release, and I have a number of
> changes to File / Media that I'd like to make public. It looks every plugin
> has had at least one commit since the last release, though, so maybe we
> want to do a release of the full suite.
>
> (The one minimum commit for each appears to be an "Added NOTICE file", so
> it might be good from an ASF-compliance POV)
>
> From what I can see this morning:
>
> cordova-plugin-battery-status: release 0.2.8, 1 commit
> cordova-plugin-camera: release 0.2.9, 12 commits
> cordova-plugin-console: release 0.2.8, 1 commit
> cordova-plugin-contacts: release 0.2.10, 5 commits
> cordova-plugin-device: release 0.2.9, 3 commits
> cordova-plugin-device-motion: release 0.2.7, 2 commits
> cordova-plugin-device-orientation: release 0.3.6, 3 commits
> cordova-plugin-dialogs: release 0.2.7, 5 commits
> cordova-plugin-file: release 1.0.2, 25 commits
> cordova-plugin-file-transfer: release 0.4.3, 7 commits
> cordova-plugin-geolocation: release 0.3.7, 4 commits
> cordova-plugin-globalization: release 0.2.7, 4 commits
> cordova-plugin-inappbrowser: release 0.3.4, 12 commits
> cordova-plugin-media: release 0.2.10, 4 commits
> cordova-plugin-media-capture: release 0.2.9, 8 commits
> cordova-plugin-network-information: release 0.2.8, 3 commits
> cordova-plugin-splashscreen: release 0.2.8, 3 commits
> cordova-plugin-statusbar: release 0.1.5, 4 commits
> cordova-plugin-vibration: release 0.3.8, 1 commit
>
>
> I have a couple of changes that I want to get in to media-capture today,
> but after that I'm happy with the state of the file-related plugins.
>
> Thoughts? We could start a vote thread tomorrow or Thursday, and release on
> Monday if it passes.
>
> Ian

Re: [DISCUSS] Plugin release this week / early next

[James Jong]

SGTM.  It has been awhile since our last plugins release.
-James Jong

On Apr 15, 2014, at 11:53 AM, Ian Clelland  wrote:

> It's been a while since we did a plugin release, and I have a number of
> changes to File / Media that I'd like to make public. It looks every plugin
> has had at least one commit since the last release, though, so maybe we
> want to do a release of the full suite.
> 
> (The one minimum commit for each appears to be an "Added NOTICE file", so
> it might be good from an ASF-compliance POV)
> 
> From what I can see this morning:
> 
> cordova-plugin-battery-status: release 0.2.8, 1 commit
> cordova-plugin-camera: release 0.2.9, 12 commits
> cordova-plugin-console: release 0.2.8, 1 commit
> cordova-plugin-contacts: release 0.2.10, 5 commits
> cordova-plugin-device: release 0.2.9, 3 commits
> cordova-plugin-device-motion: release 0.2.7, 2 commits
> cordova-plugin-device-orientation: release 0.3.6, 3 commits
> cordova-plugin-dialogs: release 0.2.7, 5 commits
> cordova-plugin-file: release 1.0.2, 25 commits
> cordova-plugin-file-transfer: release 0.4.3, 7 commits
> cordova-plugin-geolocation: release 0.3.7, 4 commits
> cordova-plugin-globalization: release 0.2.7, 4 commits
> cordova-plugin-inappbrowser: release 0.3.4, 12 commits
> cordova-plugin-media: release 0.2.10, 4 commits
> cordova-plugin-media-capture: release 0.2.9, 8 commits
> cordova-plugin-network-information: release 0.2.8, 3 commits
> cordova-plugin-splashscreen: release 0.2.8, 3 commits
> cordova-plugin-statusbar: release 0.1.5, 4 commits
> cordova-plugin-vibration: release 0.3.8, 1 commit
> 
> 
> I have a couple of changes that I want to get in to media-capture today,
> but after that I'm happy with the state of the file-related plugins.
> 
> Thoughts? We could start a vote thread tomorrow or Thursday, and release on
> Monday if it passes.
> 
> Ian

[GitHub] cordova-mobile-spec pull request: CB-6437[Improvements & support f...

[cmarcelk]

Github user cmarcelk commented on a diff in the pull request:

https://github.com/apache/cordova-mobile-spec/pull/55#discussion_r11641446
  
--- Diff: createmobilespec/createmobilespec.js ---
@@ -17,99 +16,215 @@
 KIND, either express or implied.  See the License for the
 specific language governing permissions and limitations
 under the License.
-*/
+ */
 
 var fs = require('fs'),
 path = require('path'),
-shelljs,
-optimist;
+child_process = require('child_process'),
+shelljs;
+
+// Dependencies requirements check
 try {
 shelljs = require('shelljs');
-optimist = require('optimist');
 } catch (e) {
 console.error('Missing module. Please run "npm install" from this 
directory:\n\t' +
-   path.dirname(__dirname));
+path.dirname(__dirname));
 process.exit(2);
 }
 
-var tokens = process.argv.slice(2);
-var argv = optimist(tokens)
-   .default('android', false)
-   .default('ios', false)
-   .usage('Usage: $0 [--android] [--ios]\nDefault is to use 
Android and iOS.')
-   .argv;
-// preserve the original behavior when there are no args
-if (tokens.length === 0) {
-argv.android = true;
-argv.ios = true;
+console.log('Creating mobilespec project. If you have any errors, it may 
be from missing repositories.');
+console.log('To clone needed repositories:');
+console.log('  ./cordova-coho/coho repo-clone -r plugins -r mobile-spec -r 
android -r ios -r cli');
+console.log('To update all repositories:');
+console.log('  ./cordova-coho/coho repo-update');
+
+// Setting up vars, folders and libraries, to ensure full compatibility 
cross platform, absolute paths are used instead of relative paths
+var mainModDir = process.cwd(),
+// Cordova Coho dir, it should contain all libraries and required 
repositories
+// [cordova-cli, cordova-android, cordova-blackberry, cordova-ios, 
cordova-windows, cordova-windows8, all plugins libraries, cordova-mobile-spec, 
cordova-js]
+// searchDir function it was added, to look for cordova-coho folder 
backwards, for cases like absolute/path/cordova-coho/cordova-coho/...All 
libraries
+// This is to make sure that cordova-coho exists and it's the right one.
+coho_dir = searchDir(mainModDir, 'cordova-coho'),
+cordova_cli = path.join(coho_dir, 'cordova-cli', 'bin', 'cordova'),
+cordova_ms = (path.join(coho_dir, 'cordova-mobile-spec')),
+cordova_js = (path.join(coho_dir, 'cordova-js')),
+ms_project_dir = (path.join(mainModDir, 'mobilespec'));
+
+// Main libraries and path's requirements check
+if (!fs.existsSync(coho_dir)) {
+console.log('Please run this script from the directory that contains 
cordova-coho');
+shelljs.exit(1);
 }
-var platforms = [];
-if (argv.android) { platforms.push('android'); }
-if (argv.ios) { platforms.push('ios'); }
 
-if (!fs.existsSync('cordova-mobile-spec')) {
+if (!fs.existsSync(cordova_ms)) {
 console.log('Please run this script from the directory that contains 
cordova-mobile-spec');
 shelljs.exit(1);
 }
 
-if (fs.existsSync('mobilespec')) {
-console.log('Directory "mobilespec" already exists. Delete it first 
then re-run.');
+if (!fs.existsSync(cordova_js)) {
+console.log('Please run this script from the directory that contains 
cordova-js');
 shelljs.exit(1);
 }
 
-console.log('Creating mobilespec project. If you have any errors, it may 
be from missing repositories.');
-console.log('To clone needed repositories:');
-console.log("  ./cordova-coho/coho repo-clone -r plugins -r mobile-spec -r 
cli -r " + platforms.join(' -r '));
-console.log('To update all repositories:');
-console.log('  ./cordova-coho/coho repo-update');
+//Determine which platforms are available
+// Default platforms [Android, Blackberry], both platforms works under 
Windows, Linux and Mac OS
+cordovaPlatforms = ['android', 'blackberry10'];
+if (/^win/.test(process.platform)) {
+//Determine windows 8 platform
+child_process.exec('wmic os get caption', function (error, stdout, 
stderr) {
+if (error !== null) {
+callback = 'Error performing command: ' + error + "\n" + 
stderr;
+} else {
+// If Windows 8, add Windows Phone 8 and Windows8 platform to 
the array
+if ((/.*(Windows 8).*/gi).test(((stdout.replace(/\r\r\n/i, ': 
')).replace(/\s\s+/g, '')).replace((/\n|\r/gi), ''))) {
+cordovaPlatforms.push('wp8', 'windows8');
+}
+}
+});
+} else {
+//If Mac Os, add iOS platform
+if (/^darwin/.test(process.platform))
+cordovaPlatforms.push('ios');

[DISCUSS] Plugin release this week / early next

[Ian Clelland]

It's been a while since we did a plugin release, and I have a number of
changes to File / Media that I'd like to make public. It looks every plugin
has had at least one commit since the last release, though, so maybe we
want to do a release of the full suite.

(The one minimum commit for each appears to be an "Added NOTICE file", so
it might be good from an ASF-compliance POV)

>From what I can see this morning:

cordova-plugin-battery-status: release 0.2.8, 1 commit
cordova-plugin-camera: release 0.2.9, 12 commits
cordova-plugin-console: release 0.2.8, 1 commit
cordova-plugin-contacts: release 0.2.10, 5 commits
cordova-plugin-device: release 0.2.9, 3 commits
cordova-plugin-device-motion: release 0.2.7, 2 commits
cordova-plugin-device-orientation: release 0.3.6, 3 commits
cordova-plugin-dialogs: release 0.2.7, 5 commits
cordova-plugin-file: release 1.0.2, 25 commits
cordova-plugin-file-transfer: release 0.4.3, 7 commits
cordova-plugin-geolocation: release 0.3.7, 4 commits
cordova-plugin-globalization: release 0.2.7, 4 commits
cordova-plugin-inappbrowser: release 0.3.4, 12 commits
cordova-plugin-media: release 0.2.10, 4 commits
cordova-plugin-media-capture: release 0.2.9, 8 commits
cordova-plugin-network-information: release 0.2.8, 3 commits
cordova-plugin-splashscreen: release 0.2.8, 3 commits
cordova-plugin-statusbar: release 0.1.5, 4 commits
cordova-plugin-vibration: release 0.3.8, 1 commit


I have a couple of changes that I want to get in to media-capture today,
but after that I'm happy with the state of the file-related plugins.

Thoughts? We could start a vote thread tomorrow or Thursday, and release on
Monday if it passes.

Ian

[GitHub] cordova-mobile-spec pull request: CB-6437[Improvements & support f...

[cmarcelk]

Github user cmarcelk commented on a diff in the pull request:

https://github.com/apache/cordova-mobile-spec/pull/55#discussion_r11640926
  
--- Diff: createmobilespec/createmobilespec.js ---
@@ -17,99 +16,215 @@
 KIND, either express or implied.  See the License for the
 specific language governing permissions and limitations
 under the License.
-*/
+ */
 
 var fs = require('fs'),
 path = require('path'),
-shelljs,
-optimist;
+child_process = require('child_process'),
+shelljs;
+
+// Dependencies requirements check
 try {
 shelljs = require('shelljs');
-optimist = require('optimist');
 } catch (e) {
 console.error('Missing module. Please run "npm install" from this 
directory:\n\t' +
-   path.dirname(__dirname));
+path.dirname(__dirname));
 process.exit(2);
 }
 
-var tokens = process.argv.slice(2);
-var argv = optimist(tokens)
-   .default('android', false)
-   .default('ios', false)
-   .usage('Usage: $0 [--android] [--ios]\nDefault is to use 
Android and iOS.')
-   .argv;
-// preserve the original behavior when there are no args
-if (tokens.length === 0) {
-argv.android = true;
-argv.ios = true;
+console.log('Creating mobilespec project. If you have any errors, it may 
be from missing repositories.');
+console.log('To clone needed repositories:');
+console.log('  ./cordova-coho/coho repo-clone -r plugins -r mobile-spec -r 
android -r ios -r cli');
+console.log('To update all repositories:');
+console.log('  ./cordova-coho/coho repo-update');
+
+// Setting up vars, folders and libraries, to ensure full compatibility 
cross platform, absolute paths are used instead of relative paths
+var mainModDir = process.cwd(),
+// Cordova Coho dir, it should contain all libraries and required 
repositories
+// [cordova-cli, cordova-android, cordova-blackberry, cordova-ios, 
cordova-windows, cordova-windows8, all plugins libraries, cordova-mobile-spec, 
cordova-js]
+// searchDir function it was added, to look for cordova-coho folder 
backwards, for cases like absolute/path/cordova-coho/cordova-coho/...All 
libraries
+// This is to make sure that cordova-coho exists and it's the right one.
+coho_dir = searchDir(mainModDir, 'cordova-coho'),
+cordova_cli = path.join(coho_dir, 'cordova-cli', 'bin', 'cordova'),
+cordova_ms = (path.join(coho_dir, 'cordova-mobile-spec')),
+cordova_js = (path.join(coho_dir, 'cordova-js')),
+ms_project_dir = (path.join(mainModDir, 'mobilespec'));
+
+// Main libraries and path's requirements check
+if (!fs.existsSync(coho_dir)) {
+console.log('Please run this script from the directory that contains 
cordova-coho');
+shelljs.exit(1);
 }
-var platforms = [];
-if (argv.android) { platforms.push('android'); }
-if (argv.ios) { platforms.push('ios'); }
 
-if (!fs.existsSync('cordova-mobile-spec')) {
+if (!fs.existsSync(cordova_ms)) {
 console.log('Please run this script from the directory that contains 
cordova-mobile-spec');
 shelljs.exit(1);
 }
 
-if (fs.existsSync('mobilespec')) {
-console.log('Directory "mobilespec" already exists. Delete it first 
then re-run.');
+if (!fs.existsSync(cordova_js)) {
+console.log('Please run this script from the directory that contains 
cordova-js');
 shelljs.exit(1);
 }
 
-console.log('Creating mobilespec project. If you have any errors, it may 
be from missing repositories.');
-console.log('To clone needed repositories:');
-console.log("  ./cordova-coho/coho repo-clone -r plugins -r mobile-spec -r 
cli -r " + platforms.join(' -r '));
-console.log('To update all repositories:');
-console.log('  ./cordova-coho/coho repo-update');
+//Determine which platforms are available
+// Default platforms [Android, Blackberry], both platforms works under 
Windows, Linux and Mac OS
+cordovaPlatforms = ['android', 'blackberry10'];
--- End diff --

When optimist was being used and the default behavior was to create both 
Android and iOS, that was just preserving the original behavior of the shell 
script when this ran only on OSX. Now that you are getting createmobilespec to 
work on Windows and Linux dev machines, it's probably wise to revisit that 
default behavior. I'd suggest that the new default is to create only the mobile 
platforms that are requested. For example "createmobilespec --android 
--blackberry10". If no args are specified, then exit with an error. These 
should be the same words used in the "cordova platform add" command, for 
consistency. And I would also suggest to have them be args instead of a menu, 
so that createmobilespec can be used by a parent script in a scenario s

Re: support on phonegap/cordova?

[Michal Mocny]

On Tue, Apr 15, 2014 at 10:31 AM, Lisa Seacat DeLuca wrote:

> Michal +1.
>
> 1. Create a user@ group that we use to encourage users to post questions
> on SO.

Well this is the question, isn't it :)  Ian nails the root question as "How
do I get help with Cordova?" with an answer other than "You need to ask
about PhoneGap".  But we seem to all agree that SO is better than users@.
 So: I'd just start with an update the website, and see what happens.  If
we find that we really do a need an ML (hey, we haven't so far), then we
can reinvestigate.  Is that fair?


> 2. Update website to remove reference to PhoneGap Google Group and include
> reference to the user@ mailing list
>
I'd leave a reference to the existing phonegap group, for those that want
to search its history or whatnot.  We just need a general section on the
front page on how to find help/support and explain the primary source is
SO.  We could also start to try to direct traffic from the PG Group to SO,
but I leave that to those that actually moderate that list to decide.


> 3. remove the IRC #phonegap reference as well
>
I'm indifferent here.  I suspect most folks who actually know how to use
irc know how to find the channel ;) so maybe we don't need to refer to it.
 But I'm not opposed to calling out that we do have an irc channel, and I
certainly wouldn't want to split audience across #phonegap and #cordova.


>
> Is everyone in agreement on this?  Do we need to add an item to our
> hangout agenda today to discuss further?
>
May as well mention it for those who are not caught up on email.  I hope
this won't need more than 3 minutes.


>
>
>
> Lisa Seacat DeLuca
> Mobile Engineer | t: +415.787.4589 | 
> *ldel...@apache.org*| |
> *ldel...@us.ibm.com*  | 
> *lisaseacat.com*| [image:
> follow @LisaSeacat on twitter] | [image:
> follow Lisa Seacat DeLuca on linkedin]
>
>
>
>
>
> From:Michal Mocny 
> To:dev 
> Date:04/15/2014 09:50 AM
> Subject:Re: support on phonegap/cordova?
> Sent by:mmo...@google.com
> --
>
>
>
> So first: we don't *have* have to have users@ list.  This isn't about
> "apache way" at all, this is in response to several user inquiries asking
> for a user list to point them to.
>
> Seems no one is looking forward to more email, but I'd be satisfied to have
> a users@ list from which we direct people over to SO, since some people
> don't yet know about SO and/or expect a mailing list when they go looking.
>
> The most important action item I think is to update the website, since
> right now we only list the dev, commits, and issues mailing lists listed,
> and a small note about the phonegap forum for user questions (and that was
> hard to find without grep-ing).
>
> -Michal
>
>
>
>
> On Tue, Apr 15, 2014 at 8:06 AM, Mike Billau 
> wrote:
>
> > I think that between a users@ mailing list, a google group, an IRC room,
> > and StackOverflow, the best medium we can use to support our users is
> > StackOverflow. Joe makes great points about the benefits that
> StackOverflow
> > gives us that I don't see the other mediums providing. Sure the GG may be
> > searchable but not nearly as well as SO. Also, there are already a lot of
> > Cordova users helping each other out on SO (only 4 of the top 20
> > "answerers" are on this list [1]) SO also will automatically switch
> > "phonegap" to "cordova" tag but still allow things like "phonegap-build"
> or
> > "phonegap-enterprise" or whatever - nothing against phonegap, this just
> > seems to be more inline with the "Apache Way" and would help Adobe
> support
> > find relevant issues to them while letting the the overall community work
> > on the more general support questions.
> >
> > If we have to have a users@, so be it, but we should make it a point to
> > answer all questions there with a link to the relevant Stack Overflow
> > answer. I think we should also be doing this on the google group too, but
> > I'll be the first to admit that I haven't been.
> >
> > Finally I know there is a lot of push back about "getting rid of /
> > encouraging less use of" the google group because a lot of people use it
> > and apparently get a lot of their issues fixed, however it seems like
> > either the majority of the questions never get answered, or they get
> > answered by a few users. We should maybe reach out to these power users
> and
> > explain to them the motivation behind trying to move all support off the
> GG
> > and into SO and encourage them to help with this transition.
> >
> > [1] http://stackoverflow.com/tags/cordova/topusers
> >
> >
> > On Mon, Apr 14, 2014 at 5:03 PM, Joe Bowser  wrote:
> >
> > > The reasons I prefer stack overflow to users lists are as follows:
> > >
> > > 1. Most of our users aren't skilled enough to get on or off of a users
> > list
> > > 2. Stack Overflow's structure keeps things more professional than

[GitHub] cordova-windows pull request: CB-6435 ./VERSION & /template/VERSIO...

[martincgg]

Github user martincgg commented on the pull request:

https://github.com/apache/cordova-windows/pull/25#issuecomment-40494097
  
Hello @clelland , are able to merge this changes, or you will take care of 
this in another way?


---
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.
---

[GitHub] cordova-plugin-media-capture pull request: CB-5202 fix from lubogo...

[infil00p]

Github user infil00p commented on the pull request:


https://github.com/apache/cordova-plugin-media-capture/pull/13#issuecomment-40491756
  
Actually, you're right.  Android generally returns 3gp and mp4 files.  
Returning an AVI container may mess things up.


---
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: support on phonegap/cordova?

[Lisa Seacat DeLuca]

Michal +1.

1. Create a user@ group that we use to encourage users to post questions 
on SO. 
2. Update website to remove reference to PhoneGap Google Group and include 
reference to the user@ mailing list
3. remove the IRC #phonegap reference as well

Is everyone in agreement on this?  Do we need to add an item to our 
hangout agenda today to discuss further?



Lisa Seacat DeLuca
Mobile Engineer | t: +415.787.4589 | ldel...@apache.org | | 
ldel...@us.ibm.com | lisaseacat.com | | 





From:   Michal Mocny 
To: dev 
Date:   04/15/2014 09:50 AM
Subject:Re: support on phonegap/cordova?
Sent by:mmo...@google.com



So first: we don't *have* have to have users@ list.  This isn't about
"apache way" at all, this is in response to several user inquiries asking
for a user list to point them to.

Seems no one is looking forward to more email, but I'd be satisfied to 
have
a users@ list from which we direct people over to SO, since some people
don't yet know about SO and/or expect a mailing list when they go looking.

The most important action item I think is to update the website, since
right now we only list the dev, commits, and issues mailing lists listed,
and a small note about the phonegap forum for user questions (and that was
hard to find without grep-ing).

-Michal




On Tue, Apr 15, 2014 at 8:06 AM, Mike Billau  
wrote:

> I think that between a users@ mailing list, a google group, an IRC room,
> and StackOverflow, the best medium we can use to support our users is
> StackOverflow. Joe makes great points about the benefits that 
StackOverflow
> gives us that I don't see the other mediums providing. Sure the GG may 
be
> searchable but not nearly as well as SO. Also, there are already a lot 
of
> Cordova users helping each other out on SO (only 4 of the top 20
> "answerers" are on this list [1]) SO also will automatically switch
> "phonegap" to "cordova" tag but still allow things like "phonegap-build" 
or
> "phonegap-enterprise" or whatever - nothing against phonegap, this just
> seems to be more inline with the "Apache Way" and would help Adobe 
support
> find relevant issues to them while letting the the overall community 
work
> on the more general support questions.
>
> If we have to have a users@, so be it, but we should make it a point to
> answer all questions there with a link to the relevant Stack Overflow
> answer. I think we should also be doing this on the google group too, 
but
> I'll be the first to admit that I haven't been.
>
> Finally I know there is a lot of push back about "getting rid of /
> encouraging less use of" the google group because a lot of people use it
> and apparently get a lot of their issues fixed, however it seems like
> either the majority of the questions never get answered, or they get
> answered by a few users. We should maybe reach out to these power users 
and
> explain to them the motivation behind trying to move all support off the 
GG
> and into SO and encourage them to help with this transition.
>
> [1] http://stackoverflow.com/tags/cordova/topusers
>
>
> On Mon, Apr 14, 2014 at 5:03 PM, Joe Bowser  wrote:
>
> > The reasons I prefer stack overflow to users lists are as follows:
> >
> > 1. Most of our users aren't skilled enough to get on or off of a users
> list
> > 2. Stack Overflow's structure keeps things more professional than the
> > mailing list.  Personal attacks get downvoted on SO
> > 3. Stack Overflow has better searchibility than a users list.
> >
> > If we have to have one because of the much loathed "Apache Way", so be
> > it, but I don't see it being nearly as helpful as SO.
> >
> > On Mon, Apr 14, 2014 at 1:15 PM, Andrew Grieve 
> > wrote:
> > > Most Apache projects have a users@ list for this purpose. Although 
SO
> > often
> > > yields better answers, I don't think it would hurt to have a
> users@list.
> > >
> > >
> > > On Fri, Apr 11, 2014 at 9:09 AM, Joe Bowser  
wrote:
> > >
> > >> This is a dev list, not a support list. I would recommend
> StackOverflow.
> > >>  On Apr 9, 2014 3:16 PM, "Andrew Grieve" 
> wrote:
> > >>
> > >> > StackOverflow works really well as well. If it's a possible but 
in
> the
> > >> > framework or an Apache plugin though, this is the list :)
> > >> >
> > >> >
> > >> > On Wed, Apr 9, 2014 at 6:21 AM, Ray Camden 
> > wrote:
> > >> >
> > >> > > I'd use the Google Group:
> > >> > https://groups.google.com/forum/#!forum/phonegap
> > >> > > 
> > >> > > From: smo 
> > >> > > Sent: Wednesday, April 09, 2014 2:35 AM
> > >> > > To: dev@cordova.apache.org
> > >> > > Subject: support on phonegap/cordova?
> > >> > >
> > >> > > hi
> > >> > >
> > >> > > where must i post to get support on phonegap/cordova ios ?
> > >> > >
> > >> > > thanks
> > >> > >
> > >> > >
> > >> >
> > >>
> >
>

Re: Sharing code between plugman and cordova-cli

[Michal Mocny]

I like the clear distinction of plugman workflow vs cordova workflow, so I
wouldn't want to drop the separation.  If this goes well, the contents of
plugman (and cordova) will be argument parsing, help/usage messages, and
forwarding into cordova-lib, so they will not need updating often unless
the interface changes.

I do like to proposal to add plugin publishing functionality to
cordova-cli, which we can easily do once we have a common cordova-lib which
both cli call into.  Lets leave that for a follow-on task after the
restructuring (filed: CB-6447).

-Michal


On Tue, Apr 15, 2014 at 9:36 AM, Andrew Grieve  wrote:

> I think everyone is on board with the idea that modules should be used to
> enable sharing code, and for code organization.
>
> Two problems that are happening in practice:
> - Multiple pull requests (plugman and CLI) to make a change
> - Code duplication between the repositories
>
> Both of these are solved by moving all common code into the same git
> repository.
>
> I think whether to make additional npm packages should happen as a
> follow-up, and as concrete proposals (e.g. Let's publish CordovaError into
> an npm package)
>
> It's a bit weird that a lot of cordova's CLI is in a module called
> "cordova", but you need to install "plugman" to publish to the registry.
>
> Analogy: there's not an "npm-cli" separate from "npm-publisher".
>
> How about folding the functionality of plugman into cordova?
> - "cordova publish"
> - "cordova owner add"
> - "cordova plugin add --platform
>  --project 
> --plugin  [--plugins_dir ] [--www ]
> [--variable = [--variable = ...]]
>
> This would:
> - Only one tool for devs to install (aptly named "cordova")
>- "cordova --help" as one entry-point to what's available
> - Simply release process
>- Fewer release steps
>- Single set of release notes (no more having to duplicate fixes to
> plugman in CLI's release notes)
>
> For users that are accustomed to using plugman directly, we could make
> plugman depend on CLI to have it continue working.
>
> On Mon, Apr 14, 2014 at 12:16 PM, Brian LeRoux  wrote:
>
> > If we manage to get down to 1 module === 1 function then its doubtful
> we'd
> > have much advantage to the atomic commits thing. I'm cool w/ starting w/
> > one repo and seeing where it leads. Sort of a graduation step thing.
> >
> >
> > On Mon, Apr 14, 2014 at 12:02 PM, Michal Mocny 
> > wrote:
> >
> > > Alright then, lets do 3+ npm packages: cordova (cli only), plugman (cli
> > > only), and cordova-lib (or something similarly named, TBD,
> suggestions?).
> > >  As cordova-lib refactors to have some useful self-contained utils, we
> > will
> > > move those to dedicated npm modules published separately.
> > >
> > > However, we are currently debating the use of a single vs multiple git
> > > repos to hold the modules.
> > >
> > > The advantages of single repo:
> > > - Easier to create atomic commits to multiple npm modules (there are
> > often
> > > multi-part changes), which is especially true for external Pull
> Requests.
> > > - More likely that we will be willing to move utils out to dedicated
> npm
> > > modules if there is no additional repo/release management overhead.
> > >
> > > The advantages of multiple repos:
> > > - Easier to isolate github issues (though we don't really use these),
> and
> > > Pull Requests.  Note: does not affect git logs, which are easy to
> filter
> > > based on subdirectory.
> > > - We already have cordova-cli and plugman repos anyway.
> > > - "Feels" cleaner?
> > >
> > > -Michal
> > >
> > >
> > >
> > >
> > > On Mon, Apr 14, 2014 at 2:13 PM, Anis KADRI 
> > wrote:
> > >
> > > > To brian and steve's points I think it's a bad idea to move common
> code
> > > to
> > > > cordova-cli. I don't think we want another cordova-coho.
> > > >
> > > >
> > > > On Fri, Apr 11, 2014 at 5:36 PM, Brian LeRoux  wrote:
> > > >
> > > > > It would be very good for folks to understand the benefit of using
> > npm
> > > is
> > > > > that we will likely only have to release these small modules very
> > > rarely.
> > > > > Once the module is out the dependency part is done. This is vastly
> > > > simpler
> > > > > workflow, smaller codebases to reason about, quicker to test, and
> > > easier
> > > > to
> > > > > ship small releases. If the small module is only applicable to
> > Corodva
> > > > that
> > > > > is fine and good.
> > > > >
> > > > > This is less complicated. It is easier to share code that is in
> > > modules.
> > > > > Adding them to the same repo is no different than adding it to the
> > > > > package.json and require'ing it in from a programming perspective
> > (but
> > > it
> > > > > does add overhead of a large codebase in a single repo).
> > > > >
> > > > > Having large monolith codebases is considered a poor practice in
> Node
> > > > based
> > > > > projects and most of Cordova today is a Node based project. I
> > recommend
> > > > > learning more about the philosophy and reasoning for these
> practices.
> > > W

Re: support on phonegap/cordova?

[Ian Clelland]

On Tue, Apr 15, 2014 at 9:49 AM, Michal Mocny  wrote:

> So first: we don't *have* have to have users@ list.  This isn't about
> "apache way" at all, this is in response to several user inquiries asking
> for a user list to point them to.
>

Exactly this. Talking to ASF folks in Denver last week, there really aren't
many hard requirements on us, and a users@ list definitely isn't one of
them.

(http://mail-archives.apache.org/mod_mbox/ has a big list of all of the
lists that Apache projects run, and certainly not all of them have a users
list)

We talked at the conference about asking infra@ for a users list, but this
was more about the Cordova vs. PhoneGap branding, and answering the
question "How do I get help with Cordova?" with something other than "You
need to ask about PhoneGap". The PhoneGap group certainly made sense when
PhoneGap was the brand, and probably still made sense when the name
changed, but makes less sense every day, as there are more and more people
using the open source project, who may have never heard of PhoneGap, the
product.

(Also, it's odd to direct people to a Google group about an Adobe product
when they're working with an Apache open source project :) )

>
> Seems no one is looking forward to more email, but I'd be satisfied to have
> a users@ list from which we direct people over to SO, since some people
> don't yet know about SO and/or expect a mailing list when they go looking.
>
> The most important action item I think is to update the website, since
> right now we only list the dev, commits, and issues mailing lists listed,
> and a small note about the phonegap forum for user questions (and that was
> hard to find without grep-ing).
>
> -Michal
>
>
>
>
> On Tue, Apr 15, 2014 at 8:06 AM, Mike Billau 
> wrote:
>
> > I think that between a users@ mailing list, a google group, an IRC room,
> > and StackOverflow, the best medium we can use to support our users is
> > StackOverflow. Joe makes great points about the benefits that
> StackOverflow
> > gives us that I don't see the other mediums providing. Sure the GG may be
> > searchable but not nearly as well as SO. Also, there are already a lot of
> > Cordova users helping each other out on SO (only 4 of the top 20
> > "answerers" are on this list [1]) SO also will automatically switch
> > "phonegap" to "cordova" tag but still allow things like "phonegap-build"
> or
> > "phonegap-enterprise" or whatever - nothing against phonegap, this just
> > seems to be more inline with the "Apache Way" and would help Adobe
> support
> > find relevant issues to them while letting the the overall community work
> > on the more general support questions.
> >
> > If we have to have a users@, so be it, but we should make it a point to
> > answer all questions there with a link to the relevant Stack Overflow
> > answer. I think we should also be doing this on the google group too, but
> > I'll be the first to admit that I haven't been.
> >
> > Finally I know there is a lot of push back about "getting rid of /
> > encouraging less use of" the google group because a lot of people use it
> > and apparently get a lot of their issues fixed, however it seems like
> > either the majority of the questions never get answered, or they get
> > answered by a few users. We should maybe reach out to these power users
> and
> > explain to them the motivation behind trying to move all support off the
> GG
> > and into SO and encourage them to help with this transition.
> >
> > [1] http://stackoverflow.com/tags/cordova/topusers
> >
> >
> > On Mon, Apr 14, 2014 at 5:03 PM, Joe Bowser  wrote:
> >
> > > The reasons I prefer stack overflow to users lists are as follows:
> > >
> > > 1. Most of our users aren't skilled enough to get on or off of a users
> > list
> > > 2. Stack Overflow's structure keeps things more professional than the
> > > mailing list.  Personal attacks get downvoted on SO
> > > 3. Stack Overflow has better searchibility than a users list.
> > >
> > > If we have to have one because of the much loathed "Apache Way", so be
> > > it, but I don't see it being nearly as helpful as SO.
> > >
> > > On Mon, Apr 14, 2014 at 1:15 PM, Andrew Grieve 
> > > wrote:
> > > > Most Apache projects have a users@ list for this purpose. Although
> SO
> > > often
> > > > yields better answers, I don't think it would hurt to have a
> > users@list.
> > > >
> > > >
> > > > On Fri, Apr 11, 2014 at 9:09 AM, Joe Bowser 
> wrote:
> > > >
> > > >> This is a dev list, not a support list. I would recommend
> > StackOverflow.
> > > >>  On Apr 9, 2014 3:16 PM, "Andrew Grieve" 
> > wrote:
> > > >>
> > > >> > StackOverflow works really well as well. If it's a possible but in
> > the
> > > >> > framework or an Apache plugin though, this is the list :)
> > > >> >
> > > >> >
> > > >> > On Wed, Apr 9, 2014 at 6:21 AM, Ray Camden 
> > > wrote:
> > > >> >
> > > >> > > I'd use the Google Group:
> > > >> > https://groups.google.com/forum/#!forum/phonegap
> > > >> > > ___

Re: support on phonegap/cordova?

[Michal Mocny]

So first: we don't *have* have to have users@ list.  This isn't about
"apache way" at all, this is in response to several user inquiries asking
for a user list to point them to.

Seems no one is looking forward to more email, but I'd be satisfied to have
a users@ list from which we direct people over to SO, since some people
don't yet know about SO and/or expect a mailing list when they go looking.

The most important action item I think is to update the website, since
right now we only list the dev, commits, and issues mailing lists listed,
and a small note about the phonegap forum for user questions (and that was
hard to find without grep-ing).

-Michal




On Tue, Apr 15, 2014 at 8:06 AM, Mike Billau  wrote:

> I think that between a users@ mailing list, a google group, an IRC room,
> and StackOverflow, the best medium we can use to support our users is
> StackOverflow. Joe makes great points about the benefits that StackOverflow
> gives us that I don't see the other mediums providing. Sure the GG may be
> searchable but not nearly as well as SO. Also, there are already a lot of
> Cordova users helping each other out on SO (only 4 of the top 20
> "answerers" are on this list [1]) SO also will automatically switch
> "phonegap" to "cordova" tag but still allow things like "phonegap-build" or
> "phonegap-enterprise" or whatever - nothing against phonegap, this just
> seems to be more inline with the "Apache Way" and would help Adobe support
> find relevant issues to them while letting the the overall community work
> on the more general support questions.
>
> If we have to have a users@, so be it, but we should make it a point to
> answer all questions there with a link to the relevant Stack Overflow
> answer. I think we should also be doing this on the google group too, but
> I'll be the first to admit that I haven't been.
>
> Finally I know there is a lot of push back about "getting rid of /
> encouraging less use of" the google group because a lot of people use it
> and apparently get a lot of their issues fixed, however it seems like
> either the majority of the questions never get answered, or they get
> answered by a few users. We should maybe reach out to these power users and
> explain to them the motivation behind trying to move all support off the GG
> and into SO and encourage them to help with this transition.
>
> [1] http://stackoverflow.com/tags/cordova/topusers
>
>
> On Mon, Apr 14, 2014 at 5:03 PM, Joe Bowser  wrote:
>
> > The reasons I prefer stack overflow to users lists are as follows:
> >
> > 1. Most of our users aren't skilled enough to get on or off of a users
> list
> > 2. Stack Overflow's structure keeps things more professional than the
> > mailing list.  Personal attacks get downvoted on SO
> > 3. Stack Overflow has better searchibility than a users list.
> >
> > If we have to have one because of the much loathed "Apache Way", so be
> > it, but I don't see it being nearly as helpful as SO.
> >
> > On Mon, Apr 14, 2014 at 1:15 PM, Andrew Grieve 
> > wrote:
> > > Most Apache projects have a users@ list for this purpose. Although SO
> > often
> > > yields better answers, I don't think it would hurt to have a
> users@list.
> > >
> > >
> > > On Fri, Apr 11, 2014 at 9:09 AM, Joe Bowser  wrote:
> > >
> > >> This is a dev list, not a support list. I would recommend
> StackOverflow.
> > >>  On Apr 9, 2014 3:16 PM, "Andrew Grieve" 
> wrote:
> > >>
> > >> > StackOverflow works really well as well. If it's a possible but in
> the
> > >> > framework or an Apache plugin though, this is the list :)
> > >> >
> > >> >
> > >> > On Wed, Apr 9, 2014 at 6:21 AM, Ray Camden 
> > wrote:
> > >> >
> > >> > > I'd use the Google Group:
> > >> > https://groups.google.com/forum/#!forum/phonegap
> > >> > > 
> > >> > > From: smo 
> > >> > > Sent: Wednesday, April 09, 2014 2:35 AM
> > >> > > To: dev@cordova.apache.org
> > >> > > Subject: support on phonegap/cordova?
> > >> > >
> > >> > > hi
> > >> > >
> > >> > > where must i post to get support on phonegap/cordova ios ?
> > >> > >
> > >> > > thanks
> > >> > >
> > >> > >
> > >> >
> > >>
> >
>

[GitHub] cordova-plugin-media pull request: iOS play audio in background

[stinoga]

Github user stinoga commented on the pull request:

https://github.com/apache/cordova-plugin-media/pull/12#issuecomment-40482040
  
I've had the same problem in my Phonegap app 
(https://github.com/stinoga/phrase), and this code fixed my issue.

Merge +1


---
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: Great writeup from Ray Camden on PG/Cordova

[Wargo, John]

That would be interesting information to maintain. 

-Original Message-
From: Anis KADRI [mailto:anis.ka...@gmail.com] 
Sent: Monday, April 14, 2014 8:29 PM
To: dev@cordova.apache.org
Cc: Michal Mocny
Subject: Re: Great writeup from Ray Camden on PG/Cordova

We do have usage stats on the cli vs bin/create plugman workflow. Last time
I checked it was 93% CLI and 7% plugman. The stats are no longer available
since we deployed the new site but we can add them back if needed.


On Mon, Apr 14, 2014 at 11:20 AM, Brian LeRoux  wrote:

> A word of caution. Surveys are a tool, and data is good, but lets not make
> it hte only driver for our feature/bug prioritization.
>
> Henry Ford — 'If I had asked people what they wanted, they would have
> said faster
> horses.'
>
>
> On Mon, Apr 14, 2014 at 10:06 AM, Michal Mocny 
> wrote:
>
> > David pointed out the link to the raw results file is in your original
> > post!
> >
> >
> > On Mon, Apr 14, 2014 at 12:39 PM, Michal Mocny 
> > wrote:
> >
> > > Also, you referenced complaints about File plugin.  Discussed with Ian
> > > this morning that it may be great feedback to give him so he can
> address
> > > it.  Can we get the raw results was it meant to be private?
> > >
> > > -Michal
> > >
> > >
> > > On Mon, Apr 14, 2014 at 11:08 AM, Ray Camden 
> wrote:
> > >
> > >> I wasn't *planning* a survey, but this sounds interesting. Let me chew
> > on
> > >> this and create an initial doc. I'll share it here for folks to
> comment
> > on
> > >> and will then publish it.
> > >>
> > >> 
> > >> From: mmo...@google.com  on behalf of Michal
> Mocny <
> > >> mmo...@chromium.org>
> > >> Sent: Saturday, April 12, 2014 12:04 PM
> > >> To: dev
> > >> Subject: Re: Great writeup from Ray Camden on PG/Cordova
> > >>
> > >> Ray: for next survey, would you mind polling on usage of cordova-cli
> vs
> > >> bin/create workflow?
> > >>
> > >> And as subpoints:
> > >> - for cordova-cli, how many platforms?  (curious how many use cli even
> > for
> > >> 1 platform)
> > >> - for bin/create, do they use plugman?
> > >>
> > >> -Michal
> > >>
> > >>
> > >> On Sat, Apr 12, 2014 at 10:31 AM, Ray Camden 
> > wrote:
> > >>
> > >> > No problem - glad it gathered up some useful data.
> > >> > 
> > >> > From: Steven Gill 
> > >> > Sent: Friday, April 11, 2014 6:52 PM
> > >> > To: dev@cordova.apache.org
> > >> > Subject: Re: Great writeup from Ray Camden on PG/Cordova
> > >> >
> > >> > Yeah!
> > >> >
> > >> > Thanks Ray for putting this together!
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > On Fri, Apr 11, 2014 at 4:06 PM, Michal Mocny 
> > >> wrote:
> > >> >
> > >> > >
> > >> >
> > >>
> >
> http://www.raymondcamden.com/index.cfm/2014/4/11/Results-of-PhoneGap-Survey
> > >> > >
> > >> > > A few take-aways in there for us, I think.
> > >> > >
> > >> >
> > >>
> > >
> > >
> >
>

Re: Sharing code between plugman and cordova-cli

[Andrew Grieve]

I think everyone is on board with the idea that modules should be used to
enable sharing code, and for code organization.

Two problems that are happening in practice:
- Multiple pull requests (plugman and CLI) to make a change
- Code duplication between the repositories

Both of these are solved by moving all common code into the same git
repository.

I think whether to make additional npm packages should happen as a
follow-up, and as concrete proposals (e.g. Let's publish CordovaError into
an npm package)

It's a bit weird that a lot of cordova's CLI is in a module called
"cordova", but you need to install "plugman" to publish to the registry.

Analogy: there's not an "npm-cli" separate from "npm-publisher".

How about folding the functionality of plugman into cordova?
- "cordova publish"
- "cordova owner add"
- "cordova plugin add --platform
 --project 
--plugin  [--plugins_dir ] [--www ]
[--variable = [--variable = ...]]

This would:
- Only one tool for devs to install (aptly named "cordova")
   - "cordova --help" as one entry-point to what's available
- Simply release process
   - Fewer release steps
   - Single set of release notes (no more having to duplicate fixes to
plugman in CLI's release notes)

For users that are accustomed to using plugman directly, we could make
plugman depend on CLI to have it continue working.

On Mon, Apr 14, 2014 at 12:16 PM, Brian LeRoux  wrote:

> If we manage to get down to 1 module === 1 function then its doubtful we'd
> have much advantage to the atomic commits thing. I'm cool w/ starting w/
> one repo and seeing where it leads. Sort of a graduation step thing.
>
>
> On Mon, Apr 14, 2014 at 12:02 PM, Michal Mocny 
> wrote:
>
> > Alright then, lets do 3+ npm packages: cordova (cli only), plugman (cli
> > only), and cordova-lib (or something similarly named, TBD, suggestions?).
> >  As cordova-lib refactors to have some useful self-contained utils, we
> will
> > move those to dedicated npm modules published separately.
> >
> > However, we are currently debating the use of a single vs multiple git
> > repos to hold the modules.
> >
> > The advantages of single repo:
> > - Easier to create atomic commits to multiple npm modules (there are
> often
> > multi-part changes), which is especially true for external Pull Requests.
> > - More likely that we will be willing to move utils out to dedicated npm
> > modules if there is no additional repo/release management overhead.
> >
> > The advantages of multiple repos:
> > - Easier to isolate github issues (though we don't really use these), and
> > Pull Requests.  Note: does not affect git logs, which are easy to filter
> > based on subdirectory.
> > - We already have cordova-cli and plugman repos anyway.
> > - "Feels" cleaner?
> >
> > -Michal
> >
> >
> >
> >
> > On Mon, Apr 14, 2014 at 2:13 PM, Anis KADRI 
> wrote:
> >
> > > To brian and steve's points I think it's a bad idea to move common code
> > to
> > > cordova-cli. I don't think we want another cordova-coho.
> > >
> > >
> > > On Fri, Apr 11, 2014 at 5:36 PM, Brian LeRoux  wrote:
> > >
> > > > It would be very good for folks to understand the benefit of using
> npm
> > is
> > > > that we will likely only have to release these small modules very
> > rarely.
> > > > Once the module is out the dependency part is done. This is vastly
> > > simpler
> > > > workflow, smaller codebases to reason about, quicker to test, and
> > easier
> > > to
> > > > ship small releases. If the small module is only applicable to
> Corodva
> > > that
> > > > is fine and good.
> > > >
> > > > This is less complicated. It is easier to share code that is in
> > modules.
> > > > Adding them to the same repo is no different than adding it to the
> > > > package.json and require'ing it in from a programming perspective
> (but
> > it
> > > > does add overhead of a large codebase in a single repo).
> > > >
> > > > Having large monolith codebases is considered a poor practice in Node
> > > based
> > > > projects and most of Cordova today is a Node based project. I
> recommend
> > > > learning more about the philosophy and reasoning for these practices.
> > We
> > > > don't need to 'conform' to all Node-isms (like favoring callbacks to
> > > > promises or streams to sync i/o operations) but the committers here
> > would
> > > > do well to understand those primitives and the motivations for them.
> > > >
> > > >
> > > >
> > > > On Sat, Apr 12, 2014 at 5:42 AM, Mark Koudritsky 
> > > > wrote:
> > > >
> > > > > On Fri, Apr 11, 2014 at 2:53 PM, Steven Gill <
> stevengil...@gmail.com
> > >
> > > > > wrote:
> > > > > ...
> > > > >
> > > > >
> > > > > > I'd love to get more details about your proposed first patch.
> What
> > do
> > > > you
> > > > > > mean by "Move internal implementation details of plugman into
> > > > > > cordova". I interpret it as move common functionality into cli,
> > make
> > > > > > plugman dependent on cli.
> > > > >
> > > > > Yes, that's the intention.
> > > > >
> > > > >
> > > > > > If

Re: BB10 com.blackberry.utils plugin .so?

[Bryan Higgins]

We removed the binaries from source since the plugins are being fetched
from the registry now.

The device/simulator files are just renamed versions of arm and x86. There
is a build script[1] which copies everything where it needs to be.

'jake build' should do the trick

[1]
https://github.com/blackberry/cordova-blackberry-plugins/blob/master/scripts/build.js



On Mon, Apr 14, 2014 at 4:31 PM, Marcel Kinard  wrote:

> For BB10, cordova-plugin-contacts has a couple pre-reqs, one of which is
> the plugin "com.blackberry.utils". The plugin.xml for that utils plugin
> referenes a couple lib-files "device/libutils.so" and
> "simulator/libutils.so", which appears to be compiled from C source. I'd
> like to build them myself.
>
> If I install that utils plugin via the CLI (fetched from plugin repo)
> those .so files are present. If I go to the github source repo at [1] those
> .so files used to be present but are no longer present. Actually they were
> removed by a recent commit [2]. There are makefiles to build arm and x86,
> but not to build the "device" and "simulator" so's as previously present
> before the recent commit [2]. So how do I build "device/libutils.so" and
> "simulator/libutils.so"? Are they simply renamed versions of arm and x86?
> Thanks!
>
> [1]
> https://github.com/blackberry/cordova-blackberry-plugins/tree/master/plugin/com.blackberry.utils/src/blackberry10/native
>
> [2]
> https://github.com/blackberry/cordova-blackberry-plugins/commit/304cfddcd7e478fad5990bf12715d0e7f1205648

[GitHub] cordova-plugin-console pull request: Add custom support for consol...

[ivanovit]

Github user ivanovit closed the pull request at:

https://github.com/apache/cordova-plugin-console/pull/5


---
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: support on phonegap/cordova?

[Mike Billau]

I think that between a users@ mailing list, a google group, an IRC room,
and StackOverflow, the best medium we can use to support our users is
StackOverflow. Joe makes great points about the benefits that StackOverflow
gives us that I don't see the other mediums providing. Sure the GG may be
searchable but not nearly as well as SO. Also, there are already a lot of
Cordova users helping each other out on SO (only 4 of the top 20
"answerers" are on this list [1]) SO also will automatically switch
"phonegap" to "cordova" tag but still allow things like "phonegap-build" or
"phonegap-enterprise" or whatever - nothing against phonegap, this just
seems to be more inline with the "Apache Way" and would help Adobe support
find relevant issues to them while letting the the overall community work
on the more general support questions.

If we have to have a users@, so be it, but we should make it a point to
answer all questions there with a link to the relevant Stack Overflow
answer. I think we should also be doing this on the google group too, but
I'll be the first to admit that I haven't been.

Finally I know there is a lot of push back about "getting rid of /
encouraging less use of" the google group because a lot of people use it
and apparently get a lot of their issues fixed, however it seems like
either the majority of the questions never get answered, or they get
answered by a few users. We should maybe reach out to these power users and
explain to them the motivation behind trying to move all support off the GG
and into SO and encourage them to help with this transition.

[1] http://stackoverflow.com/tags/cordova/topusers


On Mon, Apr 14, 2014 at 5:03 PM, Joe Bowser  wrote:

> The reasons I prefer stack overflow to users lists are as follows:
>
> 1. Most of our users aren't skilled enough to get on or off of a users list
> 2. Stack Overflow's structure keeps things more professional than the
> mailing list.  Personal attacks get downvoted on SO
> 3. Stack Overflow has better searchibility than a users list.
>
> If we have to have one because of the much loathed "Apache Way", so be
> it, but I don't see it being nearly as helpful as SO.
>
> On Mon, Apr 14, 2014 at 1:15 PM, Andrew Grieve 
> wrote:
> > Most Apache projects have a users@ list for this purpose. Although SO
> often
> > yields better answers, I don't think it would hurt to have a users@list.
> >
> >
> > On Fri, Apr 11, 2014 at 9:09 AM, Joe Bowser  wrote:
> >
> >> This is a dev list, not a support list. I would recommend StackOverflow.
> >>  On Apr 9, 2014 3:16 PM, "Andrew Grieve"  wrote:
> >>
> >> > StackOverflow works really well as well. If it's a possible but in the
> >> > framework or an Apache plugin though, this is the list :)
> >> >
> >> >
> >> > On Wed, Apr 9, 2014 at 6:21 AM, Ray Camden 
> wrote:
> >> >
> >> > > I'd use the Google Group:
> >> > https://groups.google.com/forum/#!forum/phonegap
> >> > > 
> >> > > From: smo 
> >> > > Sent: Wednesday, April 09, 2014 2:35 AM
> >> > > To: dev@cordova.apache.org
> >> > > Subject: support on phonegap/cordova?
> >> > >
> >> > > hi
> >> > >
> >> > > where must i post to get support on phonegap/cordova ios ?
> >> > >
> >> > > thanks
> >> > >
> >> > >
> >> >
> >>
>

[GitHub] cordova-plugin-media-capture pull request: CB-5202 fix from lubogo...

[keab42]

Github user keab42 commented on the pull request:


https://github.com/apache/cordova-plugin-media-capture/pull/13#issuecomment-40471123
  
Probably a daft question, but why does this use .avi? I thought the Android 
camera returned either 3gp or mp4 files.


---
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.
---

[GitHub] cordova-plugin-console pull request: Add custom support for consol...

[ivanovit]

GitHub user ivanovit opened a pull request:

https://github.com/apache/cordova-plugin-console/pull/5

Add custom support for console.log in Icenium

Related to: https://github.com/Icenium/Ice/pull/1075

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/Icenium/cordova-plugin-console 
IIIvanov/Icenium-Console-Log-Support

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cordova-plugin-console/pull/5.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #5


commit 3bccf5c4101f9c1013b0686fe0d6a5e23a37c947
Author: ivanovit 
Date:   2014-04-15T11:01:40Z

Add custom support for console.log in Icenium




---
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.
---

[GitHub] cordova-plugin-inappbrowser pull request: Make InAppBrowser work w...

[nadyaA]

GitHub user nadyaA reopened a pull request:

https://github.com/apache/cordova-plugin-inappbrowser/pull/38

Make InAppBrowser work with embedded files, using system behavior

The plugin is changed to work with embedded files, using the system 
behavior. If one needs the system behavior, they need to pass "_system" as 
target when using the plugin. As the InAppBrowser for WP8 does not handle by 
itself the embedded pdf files, system behavior is called.

The plugin also is tested and working for wp7
https://issues.apache.org/jira/browse/CB-6405

Also this PR solves null reference exception, if no  "options" are provided:
https://issues.apache.org/jira/browse/CB-6402



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/Icenium/cordova-plugin-inappbrowser 
wp8-work-with-embedded-files

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cordova-plugin-inappbrowser/pull/38.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #38


commit 2fc9f3da1fc683442a4c41811e826476d2ca9dd6
Author: Nadya Atanasova 
Date:   2014-04-11T14:57:45Z

Make InAppBrowser work with embedded files, using system behavior

The plugin is changed to work with embedded files, using the system 
behavior. If one needs the system behavior, they need to pass "_system" as 
target when using the plugin. As the InAppBrowser for WP8 does not handle by 
itself the embedded pdf files, system behavior is called.

The plugin also is tested and working for wp7




---
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.
---

[GitHub] cordova-plugin-inappbrowser pull request: Make InAppBrowser work w...

[nadyaA]

Github user nadyaA commented on the pull request:


https://github.com/apache/cordova-plugin-inappbrowser/pull/38#issuecomment-40458002
  
Thank you!


---
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.
---

[GitHub] cordova-plugin-inappbrowser pull request: Make InAppBrowser work w...

[nadyaA]

Github user nadyaA closed the pull request at:

https://github.com/apache/cordova-plugin-inappbrowser/pull/38


---
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.
---