Nightly build #250 for cordova has succeeded!

2016-12-07 Thread Apache Jenkins Server
Nightly build #250 for cordova has succeeded!
The latest nightly has been published and you can try it out with 'npm i -g 
cordova@nightly'

For details check build console at 
https://builds.apache.org/job/cordova-nightly/250/consoleFull

-
Jenkins for Apache Cordova

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

[VOTE] Plugins Release

2016-12-07 Thread Shazron
Please review and vote on the release of this plugins release
by replying to this email (and keep discussion on the DISCUSS thread)

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

The plugins have been published to dist/dev:
https://dist.apache.org/repos/dist/dev/cordova/CB-12224/

The packages were published from their corresponding git tags:
cordova-plugin-battery-status: 1.2.1 (59189285b6)
cordova-plugin-camera: 2.3.1 (9eba35e2f6)
cordova-plugin-console: 1.0.5 (8bf1ba18d5)
cordova-plugin-contacts: 2.2.1 (af620d6cde)
cordova-plugin-device: 1.1.4 (a736ae44b1)
cordova-plugin-device-motion: 1.2.3 (5e0e28f4f2)
cordova-plugin-device-orientation: 1.0.5 (4b5ead9000)
cordova-plugin-dialogs: 1.3.1 (233aff26f8)
cordova-plugin-file: 4.3.1 (db39e7ccab)
cordova-plugin-file-transfer: 1.6.1 (aee45754a9)
cordova-plugin-geolocation: 2.4.1 (7934ed7026)
cordova-plugin-globalization: 1.0.5 (594651d272)
cordova-plugin-inappbrowser: 1.6.0 (009e662c82)
cordova-plugin-legacy-whitelist: 1.1.2 (7c561bdff1)
cordova-plugin-media: 2.4.1 (f0a6d45120)
cordova-plugin-media-capture: 1.4.1 (b09b24d71b)
cordova-plugin-network-information: 1.3.1 (0079edbaa5)
cordova-plugin-screen-orientation: 1.4.2 (fff9124669)
cordova-plugin-splashscreen: 4.0.1 (782939f7ef)
cordova-plugin-statusbar: 2.2.1 (a50208bda2)
cordova-plugin-test-framework: 1.1.4 (1a9d5cd241)
cordova-plugin-vibration: 2.1.3 (fcc6f19a08)
cordova-plugin-whitelist: 1.3.1 (79f74a00e2)
cordova-plugin-wkwebview-engine: 1.1.1 (91e9d74e78)

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

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

How to vote on a plugins release at
https://github.com/apache/cordova-coho/blob/master/docs/plugins-release-process.md#voting

Voting will go on for a minimum of 48 hours.

I vote +1:
* Ran coho audit-license-headers over the relevant repos
* Ran coho check-license to ensure all dependencies and subdependencies
have Apache-compatible licenses
* Ensured continuous build was green when repos were tagged


Re: [DISCUSS] Plugins Release

2016-12-07 Thread Shazron
https://issues.apache.org/jira/browse/CB-12224

On Mon, Dec 5, 2016 at 5:42 PM, Shazron  wrote:

> Sergey - I reviewed the two PRs.
> I'll start on the Plugins Release tomorrow if there are no other issues.
>
> On Mon, Dec 5, 2016 at 1:38 AM, Sergey Shakhnazarov (Akvelon) <
> v-ses...@microsoft.com> wrote:
>
>> Hi guys,
>>
>> I would be grateful if someone could take a look at the file-transfer
>> plugin PRs related to chunkedMode:
>> https://github.com/apache/cordova-plugin-file-transfer/pull/170
>> https://github.com/apache/cordova-plugin-file-transfer/pull/169
>> The changes are not breaking:
>>   for Android we do not force chunkedMode=true for HTTPS any more (i.e.
>> if developer passed it as false in the opts thus overriding the defaults),
>>   for iOS we make chunkedMode=true progress events to be computable.
>>
>> Please let me know if you have any questions or considerations.
>>
>> Best regards,
>> Sergey Shakhnazarov.
>>
>> -Original Message-
>> From: Shazron [mailto:shaz...@gmail.com]
>> Sent: Thursday, December 1, 2016 22:47
>> To: dev@cordova.apache.org
>> Subject: Re: [DISCUSS] Plugins Release
>>
>> I've got a ladder, I'll step up.
>>
>> On Thu, Dec 1, 2016 at 5:02 AM, Simon MacDonald <
>> simon.macdon...@gmail.com>
>> wrote:
>>
>> > Well Steve is in Hawaii for 10 days so someone else will have to step
>> > up for a plugins release.
>> >
>> > Simon Mac Donald
>> > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsimonm
>> > acdonald.com=02%7C01%7Cv-seshak%40microsoft.com%7Ccdfb69402bfb4f9
>> > e075008d41a22e7ab%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6361621
>> > 84597304603=ezMgBuVruBF5EOKtscMs%2FDD8Gh9%2B3elC7PrTgzkzi8k%3D
>> > eserved=0
>> >
>> >
>> > On Thu, Dec 1, 2016 at 8:00 AM, julio cesar sanchez
>> >  wrote:
>> > > Bump
>> > >
>> > > I updated cordova-plugin-media to work with iOS 10, we should release
>> it.
>> > > Joe also wanted to release cordova-plugin-camera.
>> > >
>> > > We should do the full plugin release.
>> > >
>> > >
>> > > 2016-10-28 0:57 GMT+02:00 julio cesar sanchez > >:
>> > >
>> > >> No, geolocation works fine on iOS 10, the last commit it's just to
>> > >> allow the customization of the message.
>> > >> I think the only one that doesn't work with iOS 10 is media plugin,
>> > >> I'm going to look into it this weekend.
>> > >>
>> > >> But +1 to doing a release, I want to merge a commit on statusbar
>> > >> plugin too, but was waiting for cordova-ios 3.4.0 to do it.
>> > >>
>> > >>
>> > >> 2016-10-27 19:53 GMT+01:00 Steven Gill :
>> > >>
>> > >>> I noticed geolocation needs a release for ios10. Going to try to
>> > >>> do a
>> > full
>> > >>> plugins release next week.
>> > >>>
>> > >>> Point me at any PRs you want reviewed.
>> > >>>
>> > >>
>> > >>
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> > For additional commands, e-mail: dev-h...@cordova.apache.org
>> >
>> >
>>
>
>


Re: An idea for manually testing plugins

2016-12-07 Thread Filip Maj
As Alex Sorokin kindly pointed out to me on Slack, we have Appium UI
automation already existing for the contacts [1] and camera [2]
plugins. Our CI system also executes on this to automate the UI
end-to-end and guard against further errors [3]. The CI tosses this
job over to Sauce Labs to do the heavy lifting: Sauce runs the test
[4] from the example from [3], and, based on the logs, looks to
execute all that fun web + native context UI automation -
unfortunately Sauce only stores assets around for a month, so we can't
see the video or screenshots (it's been over a month since the last
contacts PR).

But all that's to say that, with that in place, I think it's mostly a
matter of applying this approach to other plugins. I think the value
of the UI automation-based tests is wa higher than the autotests;
asserting that a JavaScript function exists inside the Cordova webview
is a good sanity check, but asserting that you can pick a contact via
a native UI and have the relevant contact details show up back in the
Cordova webview, in my opinion, is a much more thorough test of the
functions of the plugin APIs.

Lastly, I think documenting how to set up UI automation tests such as
the ones in the camera and contacts plugins in the
cordova-plugin-test-framework readme makes sense.

Let me know what y'all think.

[1] https://github.com/apache/cordova-plugin-contacts/blob/master/appium-tests
[2] https://github.com/apache/cordova-plugin-camera/blob/master/appium-tests
[3] 
http://cordova-ci.cloudapp.net:8080/view/Pull%20requests/job/cordova-plugin-contacts-pr/lastSuccessfulBuild/PLATFORM=ios/consoleText
[4] https://saucelabs.com/beta/tests/b014505bd8894ff58b383471bdaf4759

On Wed, Dec 7, 2016 at 6:14 AM, Filip Maj  wrote:
> I am planning on putting a proof of concept together for a few plugins, and
> having something like mobile spec be able to string multiple plugins' UI
> automation tests together and assert pass/failure (via its defineAutoTests /
> defineManualTests-like functions).
>
> I'll post more when I have something to show :)
>
> The idea would then be to help guide how to do this kind of testing via the
> framework Cordova has built up for plugin testing via the
> cordova-plugin-test-framework plugin.
>
> On Dec 7, 2016 05:56, "julio cesar sanchez"  wrote:
>>
>> I was the other way around, I got Appium working easily, but I was never
>> able to make calabash work in iOS because it always failed to instrument
>> my
>> app.
>> Both worked fine for Android though.
>>
>>
>> 2016-12-07 12:48 GMT+01:00 Trevor Brindle :
>>
>> > As little market share as windows has, it's hard to say how much effort
>> > should be dedicated to additional testing for it. That said, if windows
>> > testing is deemed necessary, I don't think we have much choice.
>> >
>> > Just keep in mind the new windows support and new iOS driver are all
>> > appium
>> > 1.6, only released less than 60 days ago.
>> >
>> > Perhaps a PoC project should be done for picking the appropriate
>> > technology?
>> >
>> > We are midway through a similar PoC at my place of work, I could
>> > volunteer
>> > some time.
>> >
>> > On Tue, Dec 6, 2016 at 10:02 PM Filip Maj  wrote:
>> >
>> > > Full disclosure: I contribute(d) to appium and worked for Sauce Labs,
>> > >
>> > > so I am pretty biased ;)
>> > >
>> > >
>> > >
>> > > Calabash, unfortunately, is iOS and Android only and does not support
>> > >
>> > > Windows app, whereas Appium does via WinAppDriver [1].
>> > >
>> > >
>> > >
>> > > I agree that appium, at least earlier on, was difficult to set up.
>> > >
>> > > These days it's a simple `npm install`. I think appium has a much more
>> > >
>> > > prolific committership to boot (MSFT contributes to it, for example).
>> > >
>> > > The github network stats for each project back that up as well.
>> > >
>> > >
>> > >
>> > > [1] https://github.com/microsoft/winappdriver
>> > >
>> > >
>> > >
>> > > On Tue, Dec 6, 2016 at 4:02 PM, Trevor Brindle 
>> > > wrote:
>> > >
>> > > > In my experience with appium, it is troublesome to set up and
>> > > > maintain.
>> > > We
>> > >
>> > > > may investigate other frameworks that have similar functionality. I
>> > have
>> > >
>> > > > had great luck with calabash.
>> > >
>> > > >
>> > >
>> > > >
>> > >
>> > > > On Tue, Dec 6, 2016 at 5:30 PM julio cesar sanchez <
>> > > jcesarmob...@gmail.com>
>> > >
>> > > > wrote:
>> > >
>> > > >
>> > >
>> > > >> +1 to appium
>> > >
>> > > >>
>> > >
>> > > >>
>> > >
>> > > >>
>> > >
>> > > >> 2016-12-05 23:33 GMT+01:00 Filip Maj :
>> > >
>> > > >>
>> > >
>> > > >>
>> > >
>> > > >>
>> > >
>> > > >> > Hi, it's me again!
>> > >
>> > > >>
>> > >
>> > > >> >
>> > >
>> > > >>
>> > >
>> > > >> > How I'd like to contribute to Cordova is to help automate the
>> > > >> > stuff
>> > >
>> > > >>
>> > >
>> > > >> > that saves committers having to take the manual time to do
>> 

[GitHub] cordova-windows issue #213: CB-12163 Make resource-file copy files again

2016-12-07 Thread ktop
Github user ktop commented on the issue:

https://github.com/apache/cordova-windows/pull/213
  
@daserge Thanks for the bump, Tim's email was in my spam. Yes, this would 
be a breaking change as it is now. We should wait until we come to a final 
decision before proceeding with this pr. 


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

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



Re: [DISCUSSION] Windows tag, what should it be doing?

2016-12-07 Thread Karen Tran
Sorry I missed this, it was in my spam folder.

I think the general consensus is that  should definitely
have the copy function added back. Not sure if it was clear if we came to a
conclusion on whether it should be default behavior though.

As for what to do for the reference behavior, I think the easy route is to
do what you suggested Tim and keep the current behavior as the default and
have the copy be an attribute users can set. Intuitively though, I think
resource-file should default to copy as expected just like other platforms,
and any other behavior can be handled with attribute flags or moved to
another more appropriate tag.

I would lean towards the second option because it makes more sense to me as
a plugin developer because all  tags do a copy. I know it would
break existing plugins that depend on the current behavior, but I can say
the same for resource-file being changed in the first place and never
documented nor mentioned in any blog release (my plugin is currently
broken). I don't know if many developers are even aware that it was changed
besides the contributor. It's been in cordova-windows since v4.4.0.

So this falls back on my initial two questions I asked:
1. What should be the default behavior of  tag? Should it
simply be copy resources as it was originally intended to, or should it be
doing what it is now, which is making a reference to the resource files.
2. Should  tag handle both functionalities, or should one be
separated out into another tag?


On Fri, Dec 2, 2016 at 9:31 PM, Tim Barham  wrote:

> It seems to me it would be bad form to simply change the default behavior
> back to copy, if that will break existing plugins that rely on the current
> behavior. While it would be inconsistent with other platforms, perhaps we
> should leave the current default behavior as-is and add an attribute to
> specify copy behavior? And then document the discrepancy.
>
> Otherwise we shouldn't do it until we know framework can work as an
> alternative, but will plugin developers be able to implement their plugin
> in such a way that it works for both cases? And how will they know they
> need to make this change?
>
> -Original Message-
> From: Karen Tran [mailto:ktop...@gmail.com]
> Sent: Saturday, December 3, 2016 8:04 AM
> To: dev@cordova.apache.org
> Subject: Re: [DISCUSSION] Windows  tag, what should it be
> doing?
>
> Thanks for the input everyone. resource-file definitely makes better sense
> to copy files. I can work on getting the copy functionality back into
> resource-file some time next week.
>
> Sidenote:
> The issue with the `framework` tag from the contributor to this change
> said, from CB-10326  https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FCB-
> 10326=02%7C01%7CTim.Barham%40microsoft.com%
> 7C8aad7996a77c4232984008d41aff194c%7C72f988bf86f141af91ab2d7cd011
> db47%7C1%7C0%7C636163130331524841=xMO4L%
> 2B2JBIy5LERs2JJeT6tjaJweSOfX8HAb9kdTvfU%3D=0> "When I'm using
> framework VS14 complains that my dll's don't have a manifest ".
> Which is why he opted to use resource-file tag instead of framework tag.
>
> I'm not sure if framework tag has since updated to handle this, otherwise
> like Cesar's suggestion we can add something to the framework tag to handle
> this use case of .dll files without a manifest.
>
>
> On Fri, Dec 2, 2016 at 3:34 PM, Shazron  wrote:
>
> > I fully expect resource-file to copy things over, as advertised in the
> > docs.
> >
> > Somewhat related issue on iOS:
> > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissue
> > s.apache.org%2Fjira%2Fbrowse%2FCB-12009=02%7C01%7CTim.Barham%40mi
> > crosoft.com%7C8aad7996a77c4232984008d41aff194c%7C72f988bf86f141af91ab2
> > d7cd011db47%7C1%7C0%7C636163130331524841=UoNsuqqH3EYZjTSZgDQkv1q
> > 49XuAGwoUXyWp8OfxjyI%3D=0
> >
> > On Fri, Dec 2, 2016 at 11:27 AM, Kerri Shotts 
> > wrote:
> >
> > > Interesting; if I were configuring a project, I’d be pretty
> > > surprised
> > that
> > > resource-file didn’t copy my file over. I prefer the path of least
> > surprise
> > > here, so I’d think that resource-file should copy files (if we have
> > > to
> > keep
> > > the existing method, maybe an attribute to switch?). BUT, I’d also
> > > prefer to keep things simpler, so I’d lean to using  for
> > > things like linking to DLLs and  for copying
> > > resources to the project (that don’t fit into other categories).
> > >
> > > So, +1 for @jcesar’s suggestion.
> > >
> > >
> > > > On Dec 2, 2016, at 02:26, julio cesar sanchez
> > > > 
> > > wrote:
> > > >
> > > > We have the framework tag for the .dll files, so I think the
> > > resource-file
> > > > should copy as the other platforms do.
> > > > If the framework tag is not working as expected, we can change the
> > > > behaviour on windows to work as needed.
> > > >
> > > >
> > > > 2016-12-02 6:56 GMT+01:00 Jesse 

[GitHub] cordova-windows issue #213: CB-12163 Make resource-file copy files again

2016-12-07 Thread daserge
Github user daserge commented on the issue:

https://github.com/apache/cordova-windows/pull/213
  
@ktop, could you please comment on @timbarham message?
http://markmail.org/message/2fproqgmbrc2gxpz
Is this a breaking change?


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

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



[GitHub] cordova-windows issue #213: CB-12163 Make resource-file copy files again

2016-12-07 Thread ktop
Github user ktop commented on the issue:

https://github.com/apache/cordova-windows/pull/213
  
@vladimir-kotikov Can you review? This pr reverts resource-file to what it 
used to do so it will copy 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.
---

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



Requesting to add Mobiscroll in tools section of cordova homepage

2016-12-07 Thread Levi Kovacs
Hello,

I have recently sent two pull requests #665
 and #666
 regarding my request to
add Mobiscroll in the tools section of the Cordova homepage as per Shazron
Abdullah's  recommendation.

We provide cross-platform UI tools for Cordova and mobile web - Mobiscroll
 -  and while not everything is open source (the
core is available in our Github repository
) I believe that it would be a great
fit.

Although there are a lot of UI plugins and widgets out there, we
differentiate ourselves by providing a polished and consistent user
experience that is cross-platform and framework agnostic and help
cordova developers
deliver great apps.

Looking forward to hearing back from you.

Thanks & Regards,
Levi Kovacs