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

[julio cesar sanchez]

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 :

> Hi Karen,
>
> I am not sure which is the best approach, but I agree that this is an
> issue.  We need to keep the copy functionality.
> I'll think more and come back.  Hopefully more people weigh in to ...
>
> Cheers,
>   Jesse
>
>
>
> @purplecabbage
> risingj.com
>
> On Tue, Nov 29, 2016 at 9:06 AM, Karen Tran  wrote:
>
> > I want to get some discussion on what the plugin.xml  tag
> > should be doing in Windows because I didn't know that it had been changed
> > for a while now.
> >
> > jira issue: https://issues.apache.org/jira/browse/CB-12163
> >
> > Current behavior: Doesn't copy resource file from src to target. Instead,
> > it will use a reference to the src location. This is the snippet from
> > PluginHandler.js explaining this behavior, which was not added to the
> docs.
> > (https://issues.apache.org/jira/browse/CB-10326)
> >
> > // do not copy, but reference the file in the plugin folder. This
> > allows to// have multiple source files map to the same target and
> > select the appropriate// one based on the current build settings, e.g.
> > architecture.// also, we don't check for existence. This allows to
> > insert build variables// into the source file name, e.g.//
> > 
> >
> >
> > This is greatly different from the original intent of a the
> 
> > tag since it doesn't do a copy. I don't think that this new behavior
> really
> > should have replaced the copy functionality. It's a little unintuitive to
> > reference resources from outside the application. Not all resource files
> > are .dll, and there's no other reasonable tag to do a copy for files that
> > are not source files, lib files, or assets. (e.g, I'm using resource-file
> > tag with a .properties file, but because it does not get copied over, I
> > can't reference my properties).
> >
> > These are the points I think we should come to a decision on
> > 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?
> >
>

[GitHub] cordova-windows pull request #212: CB-9287 Not enough Icons and Splashscreen...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-plugin-splashscreen pull request #119: CB-9287 Not enough Icons and ...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/cordova-plugin-splashscreen/pull/119


---
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 pull request #211: CB-11751 'extendedSplashScreen' is undefi...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-plugin-splashscreen pull request #118: CB-11751 'extendedSplashScree...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/cordova-plugin-splashscreen/pull/118


---
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-plugin-splashscreen issue #118: CB-11751 'extendedSplashScreen' is u...

[cordova-qa]

Github user cordova-qa commented on the issue:

https://github.com/apache/cordova-plugin-splashscreen/pull/118
  
Cordova CI Build has one or more failures. 

**Commit** - 
[Link](https://github.com/apache/cordova-plugin-splashscreen/pull/118/commits/04667e04c029f7ccfdd1567b128ee56dc041450a)
**Dashboard** - 
[Link](http://cordova-ci.cloudapp.net:8080/job/cordova-plugin-splashscreen-pr/36/)

| Builder Name  | Console Output | Test Report | Device Logs  |
| :---: | :---:  |   :---: | :---:|
| [Windows 8.1 Store]( 
http://cordova-ci.cloudapp.net:8080/job/cordova-plugin-splashscreen-pr/36//PLATFORM=windows-8.1-store/)
 | [Link]( 
http://cordova-ci.cloudapp.net:8080/job/cordova-plugin-splashscreen-pr/36//PLATFORM=windows-8.1-store/console)
 | [Link]( 
http://cordova-ci.cloudapp.net:8080/job/cordova-plugin-splashscreen-pr/36//PLATFORM=windows-8.1-store/testReport/)
 | [Link]( 
http://cordova-ci.cloudapp.net:8080/job/cordova-plugin-splashscreen-pr/36//PLATFORM=windows-8.1-store/artifact/)
 |
| [Windows 10  Store]( 
http://cordova-ci.cloudapp.net:8080/job/cordova-plugin-splashscreen-pr/36//PLATFORM=windows-10-store/)
 | [Link]( 
http://cordova-ci.cloudapp.net:8080/job/cordova-plugin-splashscreen-pr/36//PLATFORM=windows-10-store/console)
 | [Link]( 
http://cordova-ci.cloudapp.net:8080/job/cordova-plugin-splashscreen-pr/36//PLATFORM=windows-10-store/testReport/)
 | [Link]( 
http://cordova-ci.cloudapp.net:8080/job/cordova-plugin-splashscreen-pr/36//PLATFORM=windows-10-store/artifact/)
 |
| [Windows 8.1 Phone]( 
http://cordova-ci.cloudapp.net:8080/job/cordova-plugin-splashscreen-pr/36//PLATFORM=windows-8.1-phone/)
 | [Link]( 
http://cordova-ci.cloudapp.net:8080/job/cordova-plugin-splashscreen-pr/36//PLATFORM=windows-8.1-phone/console)
 | [Link]( 
http://cordova-ci.cloudapp.net:8080/job/cordova-plugin-splashscreen-pr/36//PLATFORM=windows-8.1-phone/testReport/)
 | [Link]( 
http://cordova-ci.cloudapp.net:8080/job/cordova-plugin-splashscreen-pr/36//PLATFORM=windows-8.1-phone/artifact/)
 |
| [iOS]( 
http://cordova-ci.cloudapp.net:8080/job/cordova-plugin-splashscreen-pr/36//PLATFORM=ios/)
 | [Link]( 
http://cordova-ci.cloudapp.net:8080/job/cordova-plugin-splashscreen-pr/36//PLATFORM=ios/console)
 | [Link]( 
http://cordova-ci.cloudapp.net:8080/job/cordova-plugin-splashscreen-pr/36//PLATFORM=ios/testReport/)
 | [Link]( 
http://cordova-ci.cloudapp.net:8080/job/cordova-plugin-splashscreen-pr/36//PLATFORM=ios/artifact/)
 |
| [Android]( 
http://cordova-ci.cloudapp.net:8080/job/cordova-plugin-splashscreen-pr/36//PLATFORM=android/)
 | [Link]( 
http://cordova-ci.cloudapp.net:8080/job/cordova-plugin-splashscreen-pr/36//PLATFORM=android/console)
 | [Link]( 
http://cordova-ci.cloudapp.net:8080/job/cordova-plugin-splashscreen-pr/36//PLATFORM=android/testReport/)
 | [Link]( 
http://cordova-ci.cloudapp.net:8080/job/cordova-plugin-splashscreen-pr/36//PLATFORM=android/artifact/)
 |
 



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

[Kerri Shotts]

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 :
> 
>> Hi Karen,
>> 
>> I am not sure which is the best approach, but I agree that this is an
>> issue.  We need to keep the copy functionality.
>> I'll think more and come back.  Hopefully more people weigh in to ...
>> 
>> Cheers,
>>  Jesse
>> 
>> 
>> 
>> @purplecabbage
>> risingj.com
>> 
>> On Tue, Nov 29, 2016 at 9:06 AM, Karen Tran  wrote:
>> 
>>> I want to get some discussion on what the plugin.xml  tag
>>> should be doing in Windows because I didn't know that it had been changed
>>> for a while now.
>>> 
>>> jira issue: https://issues.apache.org/jira/browse/CB-12163
>>> 
>>> Current behavior: Doesn't copy resource file from src to target. Instead,
>>> it will use a reference to the src location. This is the snippet from
>>> PluginHandler.js explaining this behavior, which was not added to the
>> docs.
>>> (https://issues.apache.org/jira/browse/CB-10326)
>>> 
>>> // do not copy, but reference the file in the plugin folder. This
>>> allows to// have multiple source files map to the same target and
>>> select the appropriate// one based on the current build settings, e.g.
>>> architecture.// also, we don't check for existence. This allows to
>>> insert build variables// into the source file name, e.g.//
>>> 
>>> 
>>> 
>>> This is greatly different from the original intent of a the
>> 
>>> tag since it doesn't do a copy. I don't think that this new behavior
>> really
>>> should have replaced the copy functionality. It's a little unintuitive to
>>> reference resources from outside the application. Not all resource files
>>> are .dll, and there's no other reasonable tag to do a copy for files that
>>> are not source files, lib files, or assets. (e.g, I'm using resource-file
>>> tag with a .properties file, but because it does not get copied over, I
>>> can't reference my properties).
>>> 
>>> These are the points I think we should come to a decision on
>>> 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?
>>> 
>> 


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

[Shazron]

I fully expect resource-file to copy things over, as advertised in the
docs.

Somewhat related issue on iOS:
https://issues.apache.org/jira/browse/CB-12009

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 :
> >
> >> Hi Karen,
> >>
> >> I am not sure which is the best approach, but I agree that this is an
> >> issue.  We need to keep the copy functionality.
> >> I'll think more and come back.  Hopefully more people weigh in to ...
> >>
> >> Cheers,
> >>  Jesse
> >>
> >>
> >>
> >> @purplecabbage
> >> risingj.com
> >>
> >> On Tue, Nov 29, 2016 at 9:06 AM, Karen Tran  wrote:
> >>
> >>> I want to get some discussion on what the plugin.xml 
> tag
> >>> should be doing in Windows because I didn't know that it had been
> changed
> >>> for a while now.
> >>>
> >>> jira issue: https://issues.apache.org/jira/browse/CB-12163
> >>>
> >>> Current behavior: Doesn't copy resource file from src to target.
> Instead,
> >>> it will use a reference to the src location. This is the snippet from
> >>> PluginHandler.js explaining this behavior, which was not added to the
> >> docs.
> >>> (https://issues.apache.org/jira/browse/CB-10326)
> >>>
> >>> // do not copy, but reference the file in the plugin folder. This
> >>> allows to// have multiple source files map to the same target and
> >>> select the appropriate// one based on the current build settings, e.g.
> >>> architecture.// also, we don't check for existence. This allows to
> >>> insert build variables// into the source file name, e.g.//
> >>> 
> >>>
> >>>
> >>> This is greatly different from the original intent of a the
> >> 
> >>> tag since it doesn't do a copy. I don't think that this new behavior
> >> really
> >>> should have replaced the copy functionality. It's a little unintuitive
> to
> >>> reference resources from outside the application. Not all resource
> files
> >>> are .dll, and there's no other reasonable tag to do a copy for files
> that
> >>> are not source files, lib files, or assets. (e.g, I'm using
> resource-file
> >>> tag with a .properties file, but because it does not get copied over, I
> >>> can't reference my properties).
> >>>
> >>> These are the points I think we should come to a decision on
> >>> 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?
> >>>
> >>
>
>
> -
> 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?

[Karen Tran]

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  "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://issues.apache.org/jira/browse/CB-12009
>
> 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 :
> > >
> > >> Hi Karen,
> > >>
> > >> I am not sure which is the best approach, but I agree that this is an
> > >> issue.  We need to keep the copy functionality.
> > >> I'll think more and come back.  Hopefully more people weigh in to ...
> > >>
> > >> Cheers,
> > >>  Jesse
> > >>
> > >>
> > >>
> > >> @purplecabbage
> > >> risingj.com
> > >>
> > >> On Tue, Nov 29, 2016 at 9:06 AM, Karen Tran 
> wrote:
> > >>
> > >>> I want to get some discussion on what the plugin.xml 
> > tag
> > >>> should be doing in Windows because I didn't know that it had been
> > changed
> > >>> for a while now.
> > >>>
> > >>> jira issue: https://issues.apache.org/jira/browse/CB-12163
> > >>>
> > >>> Current behavior: Doesn't copy resource file from src to target.
> > Instead,
> > >>> it will use a reference to the src location. This is the snippet from
> > >>> PluginHandler.js explaining this behavior, which was not added to the
> > >> docs.
> > >>> (https://issues.apache.org/jira/browse/CB-10326)
> > >>>
> > >>> // do not copy, but reference the file in the plugin folder. This
> > >>> allows to// have multiple source files map to the same target and
> > >>> select the appropriate// one based on the current build settings,
> e.g.
> > >>> architecture.// also, we don't check for existence. This allows to
> > >>> insert build variables// into the source file name, e.g.//
> > >>> 
> > >>>
> > >>>
> > >>> This is greatly different from the original intent of a the
> > >> 
> > >>> tag since it doesn't do a copy. I don't think that this new behavior
> > >> really
> > >>> should have replaced the copy functionality. It's a little
> unintuitive
> > to
> > >>> reference resources from outside the application. Not all resource
> > files
> > >>> are .dll, and there's no other reasonable tag to do a copy for files
> > that
> > >>> are not source files, lib files, or assets. (e.g, I'm using
> > resource-file
> > >>> tag with a .properties file, but because it does not get copied
> over, I
> > >>> can't reference my properties).
> > >>>
> > >>> These are the points I think we should come to a decision on
> > >>> 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?
> > >>>
> > >>
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > For additional commands, e-mail: dev-h...@cordova.apache.org
> >
> >
>

[GitHub] cordova-lib pull request #507: CB-12197 : replaced/removed multiple occuranc...

[audreyso]

GitHub user audreyso opened a pull request:

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

CB-12197 : replaced/removed multiple occurances of Anis and Brett



### Platforms affected
cordova-common and cordova-lib

### What does this PR do?
Removed multiple occurances of "Anis" and "Brett" and replaced with the 
current Apache Cordova license instead.

### What testing has been done on this change?


### Checklist
- [X] [Reported an issue](http://cordova.apache.org/contribute/issues.html) 
in the JIRA database
- [X] Commit message follows the format: "CB-3232: (android) Fix bug with 
resolving file paths", where CB- is the JIRA ID & "android" is the platform 
affected.
- [X] Added automated test coverage as appropriate for this change.

…t Apache License

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

$ git pull https://github.com/audreyso/cordova-lib CB-12197

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

https://github.com/apache/cordova-lib/pull/507.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 #507


commit 0812e5e9c7d873f13b834114a3e88e49c55ecfaa
Author: audreyso 
Date:   2016-12-02T22:58:26Z

CB-12197 : replaced multiple occurances of Anis and Brett with current 
Apache License




---
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: [Vote] 4.3.1 iOS Release

[Filip Maj]

I vote +1

I ran the following tests against an iOS 10.1 iPhone 7 plus simulator

1. mobilespec
autotests
- i get the two media failures that seem to be expected (at least per
Kerri’s vote)
- i get file.spec.147 failure every time w/ code:1 NOT_FOUND_ERR. manual
file tests all pass fine, though.
- i get two file transfer failures, either spec.42 or spec.44 (they seem to
alternate?), plus spec.45, when using evening-reaches-13417.herokuapp.com
as the remote FT server

manual tests - all worked (at least the ones that are simulator-compatible)
except:
- file-transfer: video download via cdvfile shows a broken play button and
unplayable video. via native works fine.
- media: on step 7 of the recommended test procedures (pressing play after
pressing release), track does not start playing and log shows an Audio
Error: 4. System Log does not glean anything more.

2. ./bin/create + ./cordova/build + ./cordova/run works fine

On Thu, Dec 1, 2016 at 10:32 AM, Kerri Shotts  wrote:
> I vote +1:
>
> Created mobilespec for ios
> Ran mobilespec auto tests on iOS emulator, some failures (all expected on
my end: file-transfer & 2 media tests)
> Ran npm test, no errors
> Created hello-world app via CLI, OK
> Ran on device OK
> Upgraded app via CLI, OK
> Ran cordova-lib tests, no errors
> Tested storyboard launch images, OK
> Ran on device, OK
>
> ~ Kerri
>
>> On Nov 30, 2016, at 19:28, Shazron  wrote:
>>
>> Please review and vote on this 4.3.1 iOS Release
>> by replying to this email (and keep discussion on the DISCUSS thread)
>>
>> Release issue: https://issues.apache.org/jira/browse/CB-12203
>>
>> The archive has been published to dist/dev:
>> https://dist.apache.org/repos/dist/dev/cordova/CB-12203
>>
>> The package was published from its corresponding git tag:
>> cordova-ios: 4.3.1 (8fe24d41b0)
>>
>> Note that you can test it out via:
>>
>> cordova platform add https://github.com/apache/cordova-ios#4.3.1
>>
>> Upon a successful vote I will upload the archive to dist/, publish it to
>> npm, and post the blog post.
>>
>> Voting guidelines:
>> https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md
>>
>> Voting will go on for a minimum of 48 hours.
>>
>> I vote +1:
>> * Ran coho audit-license-headers over the relevant repos
>> * Ran coho check-license to ensure all dependencies and sub-dependencies
>> have Apache-compatible licenses
>> * Ensured continuous build was green when repo was tagged
>

Re: [PROPOSAL] 'cordova platform update' alias for rm, add in cordova-ios

[Shazron]

This has not been resolved yet. We'll discuss more next week.

Archive link to this thread just in case you don't have it:
https://lists.apache.org/thread.html/dfeaab003cf67e915e342ebbf3826888c3b604d151e01dbaf9ab9950@1457466905@%3Cdev.cordova.apache.org%3E

Jesse's proposal to help fix this:
https://github.com/cordova/cordova-discuss/issues/50


On Sun, Mar 20, 2016 at 12:06 PM, julio cesar sanchez <
jcesarmob...@gmail.com> wrote:

> Not sure how many people still uses the non CLI approach, but the
> phonegap.com tutorial for android embedded webviews it uses it.
>
> 2016-03-19 2:34 GMT+01:00 Shazron :
>
> > Another issue: we still document the non-CLI way to update projects.
> > This was brought to my attention in a comment [1] in CB-10775.
> >
> > The platform specific way is still mentioned [2], and update
> > instructions for iOS [3] and android [4] still exist.
> >
> > I think we should not have any more "update" docs that don't involve
> > the CLI. What do you think?
> >
> > [1]
> > https://issues.apache.org/jira/browse/CB-10775?
> focusedCommentId=15200735&page=com.atlassian.jira.
> plugin.system.issuetabpanels:comment-tabpanel#comment-15200735
> > [2]
> > https://cordova.apache.org/docs/en/latest/guide/overview/
> index.html#development-paths
> > [3]
> > http://cordova.apache.org/docs/en/latest/guide/
> platforms/ios/upgrade.html
> > [4]
> > http://cordova.apache.org/docs/en/latest/guide/
> platforms/android/upgrade.html
> >
> >
> > On Wed, Mar 16, 2016 at 7:44 AM, Carlos Santana 
> > wrote:
> > > yep  I agree Julio about adding more power to config.xml, that's
> > basically
> > > what Mike's hook those allow  tag in config.xml
> > >
> > >
> > > On Wed, Mar 16, 2016 at 10:23 AM julio cesar sanchez <
> > jcesarmob...@gmail.com>
> > > wrote:
> > >
> > >> I like Jesse's proposal
> > >>
> > >> for #3 I think we should use a new command, I like cordova *downgrade*
> > >> platform
> > >>
> > >> As I usually read most cordova questions on stackoverflow, most people
> > is
> > >> editing and tellign others to edit the .plist manually and doing some
> > other
> > >> manual changes. I always point them to use hooks or plugins to do
> that,
> > but
> > >> as it's harder they don't want to do it.
> > >>
> > >> BTW, I think we should add a way to write on the AndroidManifest.xml
> and
> > >> info.plist from the config.xml as phonegap build does, using the
> > >> config-file tag. Right now it's possible to use the config-file tag on
> > >> plugin.xml but not on config.xml
> > >>
> > >>
> > >>
> > >>
> > >> 2016-03-16 14:54 GMT+01:00 Carlos Santana :
> > >>
> > >> > Here is an example [1] of hooks created by ionic team member
> extending
> > >> > config.xml to allow user to configure their native sdk settings
> > allowing
> > >> > have platforms as build artifacts.
> > >> >
> > >> > This could be a start at looking at some basic configuration
> settings
> > via
> > >> > hooks cordova provides or just in cordova tooling (i.e. platformAPI
> > >> parser)
> > >> >
> > >> > [1]: https://github.com/mhartington/cordova-config-utils
> > >> >
> > >> >
> > >> > On Tue, Mar 15, 2016 at 10:31 PM Carlos Santana <
> csantan...@gmail.com
> > >
> > >> > wrote:
> > >> >
> > >> > > Scratch the "migrate cli command" idea. Now I think about it
> really
> > >> messy
> > >> > > and it will be another hackHooks.
> > >> > >
> > >> > > I think we concentrate to provide more capabilities thru
> config.xml
> > and
> > >> > > hooks for making migration more smooth.
> > >> > >
> > >> > > Like a running hooks on after_platform_update event and providing
> > more
> > >> > > information in the hook context argument with from to platform
> info
> > >> > >
> > >> > >
> > >> > >
> > >> > > On Tue, Mar 15, 2016 at 9:52 PM Carlos Santana <
> > csantan...@gmail.com>
> > >> > > wrote:
> > >> > >
> > >> > >> By "I like the proposal and deleting all previous versions I
> don't
> > see
> > >> > as
> > >> > >> an issue." I meant that I don't have an issue if we don't have
> this
> > >> > feature
> > >> > >> to clean old. I prefer not to have it
> > >> > >>
> > >> > >> On Tue, Mar 15, 2016 at 9:51 PM Carlos Santana <
> > csantan...@gmail.com>
> > >> > >> wrote:
> > >> > >>
> > >> > >>> I like the proposal and deleting all previous versions I don't
> > see as
> > >> > an
> > >> > >>> issue.
> > >> > >>>
> > >> > >>> I didn't get the part of using symlinks, I don't symlinks they
> > bring
> > >> a
> > >> > >>> lot of problems to implement correctly I prefer we stick to real
> > >> > directory
> > >> > >>> and rename directories, user can choose to create symlinks on
> > their
> > >> > needs,
> > >> > >>> we would just handle them.
> > >> > >>>
> > >> > >>> If end up doing a flag I prefer just deleting the one being
> > replace,
> > >> as
> > >> > >>> --no-backup
> > >> > >>> cordova platform update ios --no-backup (using nopt notation)
> > >> > >>> will do the rename ios -> ios@4.0.1
> > >> > >>> will do the add ios
> > >> > >>> then only then if the add wor

Re: [Vote] 4.3.1 iOS Release

[Jesse]

I vote +1:
* Ran coho audit-license-headers
* Ran coho check-license
* Ran coho verify-archive
* created a new cordova project and added ios@4.3.1 and ran it successfully


@purplecabbage
risingj.com

On Fri, Dec 2, 2016 at 4:53 PM, Filip Maj  wrote:

> I vote +1
>
> I ran the following tests against an iOS 10.1 iPhone 7 plus simulator
>
> 1. mobilespec
> autotests
> - i get the two media failures that seem to be expected (at least per
> Kerri’s vote)
> - i get file.spec.147 failure every time w/ code:1 NOT_FOUND_ERR. manual
> file tests all pass fine, though.
> - i get two file transfer failures, either spec.42 or spec.44 (they seem to
> alternate?), plus spec.45, when using evening-reaches-13417.herokuapp.com
> as the remote FT server
>
> manual tests - all worked (at least the ones that are simulator-compatible)
> except:
> - file-transfer: video download via cdvfile shows a broken play button and
> unplayable video. via native works fine.
> - media: on step 7 of the recommended test procedures (pressing play after
> pressing release), track does not start playing and log shows an Audio
> Error: 4. System Log does not glean anything more.
>
> 2. ./bin/create + ./cordova/build + ./cordova/run works fine
>
> On Thu, Dec 1, 2016 at 10:32 AM, Kerri Shotts 
> wrote:
> > I vote +1:
> >
> > Created mobilespec for ios
> > Ran mobilespec auto tests on iOS emulator, some failures (all expected on
> my end: file-transfer & 2 media tests)
> > Ran npm test, no errors
> > Created hello-world app via CLI, OK
> > Ran on device OK
> > Upgraded app via CLI, OK
> > Ran cordova-lib tests, no errors
> > Tested storyboard launch images, OK
> > Ran on device, OK
> >
> > ~ Kerri
> >
> >> On Nov 30, 2016, at 19:28, Shazron  wrote:
> >>
> >> Please review and vote on this 4.3.1 iOS Release
> >> by replying to this email (and keep discussion on the DISCUSS thread)
> >>
> >> Release issue: https://issues.apache.org/jira/browse/CB-12203
> >>
> >> The archive has been published to dist/dev:
> >> https://dist.apache.org/repos/dist/dev/cordova/CB-12203
> >>
> >> The package was published from its corresponding git tag:
> >> cordova-ios: 4.3.1 (8fe24d41b0)
> >>
> >> Note that you can test it out via:
> >>
> >> cordova platform add https://github.com/apache/cordova-ios#4.3.1
> >>
> >> Upon a successful vote I will upload the archive to dist/, publish it to
> >> npm, and post the blog post.
> >>
> >> Voting guidelines:
> >> https://github.com/apache/cordova-coho/blob/master/docs/
> release-voting.md
> >>
> >> Voting will go on for a minimum of 48 hours.
> >>
> >> I vote +1:
> >> * Ran coho audit-license-headers over the relevant repos
> >> * Ran coho check-license to ensure all dependencies and sub-dependencies
> >> have Apache-compatible licenses
> >> * Ensured continuous build was green when repo was tagged
> >
>

[GitHub] cordova-docs pull request #663: CB-12203 - Cordova iOS 4.3.1 release blog po...

[shazron]

GitHub user shazron opened a pull request:

https://github.com/apache/cordova-docs/pull/663

CB-12203 - Cordova iOS 4.3.1 release blog post



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

$ git pull https://github.com/shazron/cordova-docs CB-12203

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

https://github.com/apache/cordova-docs/pull/663.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 #663


commit 364d4721b74d8cbbb3add6fecc1157e8acfc738e
Author: Shazron Abdullah 
Date:   2016-12-03T01:20:17Z

CB-12203 - Cordova iOS 4.3.1 release blog post




---
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-docs pull request #662: CB-12127 - (ios) Add buildFlag support in bu...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/cordova-docs/pull/662


---
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-docs issue #649: If you want to record sound on ios10 permission mus...

[shazron]

Github user shazron commented on the issue:

https://github.com/apache/cordova-docs/pull/649
  
Not sure why the doc was added to the Tizen section?


---
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: [Vote] 4.3.1 iOS Release

[Shazron]

The vote has now closed. The results are:

Positive Binding Votes: 4

Shazron Abdullah
Jesse MacFadyen
Filip Maj
Kerri Shotts


The vote has passed.

On Fri, Dec 2, 2016 at 5:01 PM, Jesse  wrote:

> I vote +1:
> * Ran coho audit-license-headers
> * Ran coho check-license
> * Ran coho verify-archive
> * created a new cordova project and added ios@4.3.1 and ran it
> successfully
>
>
> @purplecabbage
> risingj.com
>
> On Fri, Dec 2, 2016 at 4:53 PM, Filip Maj  wrote:
>
> > I vote +1
> >
> > I ran the following tests against an iOS 10.1 iPhone 7 plus simulator
> >
> > 1. mobilespec
> > autotests
> > - i get the two media failures that seem to be expected (at least per
> > Kerri’s vote)
> > - i get file.spec.147 failure every time w/ code:1 NOT_FOUND_ERR. manual
> > file tests all pass fine, though.
> > - i get two file transfer failures, either spec.42 or spec.44 (they seem
> to
> > alternate?), plus spec.45, when using evening-reaches-13417.
> herokuapp.com
> > as the remote FT server
> >
> > manual tests - all worked (at least the ones that are
> simulator-compatible)
> > except:
> > - file-transfer: video download via cdvfile shows a broken play button
> and
> > unplayable video. via native works fine.
> > - media: on step 7 of the recommended test procedures (pressing play
> after
> > pressing release), track does not start playing and log shows an Audio
> > Error: 4. System Log does not glean anything more.
> >
> > 2. ./bin/create + ./cordova/build + ./cordova/run works fine
> >
> > On Thu, Dec 1, 2016 at 10:32 AM, Kerri Shotts 
> > wrote:
> > > I vote +1:
> > >
> > > Created mobilespec for ios
> > > Ran mobilespec auto tests on iOS emulator, some failures (all expected
> on
> > my end: file-transfer & 2 media tests)
> > > Ran npm test, no errors
> > > Created hello-world app via CLI, OK
> > > Ran on device OK
> > > Upgraded app via CLI, OK
> > > Ran cordova-lib tests, no errors
> > > Tested storyboard launch images, OK
> > > Ran on device, OK
> > >
> > > ~ Kerri
> > >
> > >> On Nov 30, 2016, at 19:28, Shazron  wrote:
> > >>
> > >> Please review and vote on this 4.3.1 iOS Release
> > >> by replying to this email (and keep discussion on the DISCUSS thread)
> > >>
> > >> Release issue: https://issues.apache.org/jira/browse/CB-12203
> > >>
> > >> The archive has been published to dist/dev:
> > >> https://dist.apache.org/repos/dist/dev/cordova/CB-12203
> > >>
> > >> The package was published from its corresponding git tag:
> > >> cordova-ios: 4.3.1 (8fe24d41b0)
> > >>
> > >> Note that you can test it out via:
> > >>
> > >> cordova platform add https://github.com/apache/cordova-ios#4.3.1
> > >>
> > >> Upon a successful vote I will upload the archive to dist/, publish it
> to
> > >> npm, and post the blog post.
> > >>
> > >> Voting guidelines:
> > >> https://github.com/apache/cordova-coho/blob/master/docs/
> > release-voting.md
> > >>
> > >> Voting will go on for a minimum of 48 hours.
> > >>
> > >> I vote +1:
> > >> * Ran coho audit-license-headers over the relevant repos
> > >> * Ran coho check-license to ensure all dependencies and
> sub-dependencies
> > >> have Apache-compatible licenses
> > >> * Ensured continuous build was green when repo was tagged
> > >
> >
>

[BLOG POST] iOS 4.3.1 Release

[Shazron]

https://github.com/apache/cordova-docs/pull/663

[GitHub] cordova-docs issue #663: CB-12203 - Cordova iOS 4.3.1 release blog post

[purplecabbage]

Github user purplecabbage commented on the issue:

https://github.com/apache/cordova-docs/pull/663
  
+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.
---

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

[Tim Barham]

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 

 "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&data=02%7C01%7CTim.Barham%40mi
> crosoft.com%7C8aad7996a77c4232984008d41aff194c%7C72f988bf86f141af91ab2
> d7cd011db47%7C1%7C0%7C636163130331524841&sdata=UoNsuqqH3EYZjTSZgDQkv1q
> 49XuAGwoUXyWp8OfxjyI%3D&reserved=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 :
> > >
> > >> Hi Karen,
> > >>
> > >> I am not sure which is the best approach, but I agree that this 
> > >> is an issue.  We need to keep the copy functionality.
> > >> I'll think more and come back.  Hopefully more people weigh in to ...
> > >>
> > >> Cheers,
> > >>  Jesse
> > >>
> > >>
> > >>
> > >> @purplecabbage
> > >> risingj.com
> > >>
> > >> On Tue, Nov 29, 2016 at 9:06 AM, Karen Tran 
> wrote:
> > >>
> > >>> I want to get some discussion on what the plugin.xml 
> > >>> 
> > tag
> > >>> should be doing in Windows because I didn't know that it had 
> > >>> been
> > changed
> > >>> for a while now.
> > >>>
> > >>> jira issue: 
> > >>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2
> > >>> Fissues.apache.org%2Fjira%2Fbrowse%2FCB-12163&data=02%7C01%7CTim
> > >>> .Barham%40microsoft.com%7C8aad7996a77c4232984008d41aff194c%7C72f
> > >>> 988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636163130331524841&sdata
> > >>> =49A%2B8MMPoHudHvDyGRBWmqV27i2%2BldXGrB92g0sbVfA%3D&reserved=0
> > >>>
> > >>> Current behavior: Doesn't copy resource file from src to target.
> > Instead,
> > >>> it will use a reference to the src location. This is the snippet 
> > >>> from PluginHandler.js explaining this behavior, which was not 
> > >>> added to the
> > >> docs.
> > >>> (https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%
> > >>> 2Fissues.apache.org%2Fjira%2Fbrowse%2FCB-10326&data=02%7C01%7CTi
> > >>> m.Barham%40microsoft.com%7C8aad7996a77c4232984008d41aff194c%7C72
> > >>> f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636163130331524841&sdat
> > >>> a=xMO4L%2B2JBIy5LERs2JJeT6tjaJweSOfX8HAb9kdTvfU%3D&reserved=0)
> > >>>
> > >>> // do not copy, but reference the file in the plugin folder. 
> > >>> This allow

Nightly build #245 for cordova has succeeded!

[Apache Jenkins Server]

Nightly build #245 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/245/consoleFull

-
Jenkins for Apache Cordova

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

[GitHub] cordova-docs pull request #663: CB-12203 - Cordova iOS 4.3.1 release blog po...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/cordova-docs/pull/663


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