Automatic update of files in CrowdIn
Hi all, During the work on translation, I always in rush to produce it before release, because of docs updated not very often. Maybe we could configure Git to publish docs after commit, so on CrowdIn would be always the latest docs? Thanks
[GitHub] cordova-lib pull request:
Github user purplecabbage commented on the pull request: https://github.com/apache/cordova-lib/commit/fd679f38013c3171cddebed8173409b4546f0c95#commitcomment-11337166 In src/registry/registry.js: In src/registry/registry.js on line 137: This is the source of https://issues.apache.org/jira/browse/CB-9067 2 years ago! --- 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: [CI] Medic Report
Hey Jesse, Yes, we can definitely have Medic run with different configurations. We have a full test matrix that we can set up. Currently the biggest problem is: there is a “clone and build” step that takes about 5 minutes of the time of every build, and running it for every configuration does not scale. Ideally, this step needs to only happen once per host OS (i.e. Windows and OSX), and then the respective test runs should happen. This paradigm is blocked because we’ve been unable to deal with copying/zipping/transmitting the overly long paths in the builds. I’m at a loss on how to unblock on this. Do you have any ideas? Running builds on PRs will happen as soon as INFRA-9678 and INFRA-9683 get resolved (should be next week). However, this will still lack the convenience of the nice checkmarks on GitHub (i.e. the integration is still only one-way). We’ll do that once the PRs are triggering the builds. Since we use “cordova run” to run the tests now, we support running on devices. This is a good time to plan out adding your slaves to the CI so we can use your devices. Kindly, Dmitry > On May 22, 2015, at 2:26 PM, Jesse wrote: > > Thanks for the update Dmitry! > > I have kept somewhat distant from the intricacies of our CI, so I have a > few questions. > > Do you think we can get Medic running different build variations, like with > and without the --browserify flag? > Can we have Medic run tests for every pull request and report results back > to github so we can see if a pr breaks something? > > The now long ago original architecture of Medic was designed to support > running tests on physical devices that would then report their results back > to the url specified url in medic.json. Is this still available? And if so, > can we configure test devices to report back to the federated test results > server? We have nearly every device here at Adobe, but many are used > rarely, we could potentially set them up for use in running tests. This > would be especially useful in android land, where every device seems to > 'feature' some sort of manufacturer quirk. > > > > > @purplecabbage > risingj.com > > On Fri, May 22, 2015 at 2:00 PM, Dmitry Blotsky > wrote: > >> Hi list, >> >> >> >> Here are some points of interest regarding the CI: >> >> - Builds now know what commits went into them >> >> - Waiting on Infra to configure GitHub repos to send changes our >> way so that they will *trigger* the builds (right now they're still >> periodic) >> >> - Windows build recently broke, and here is the JIRA: >> https://issues.apache.org/jira/browse/CB-9066 >> >> - Other JIRAs outstanding, being fixed piece by piece by folks in >> the community >> >> >> >> Here is this week's report on test failures: >> >> - 14 on Android OSX (flaky) >> >> - ~14 on Android Windows >> >> - ~21 on iOS >> >> - Windows breaking >> >> - 0 on WP8 (flaky) >> >> >> >> As always, the Medic URI is: http://ci.cordova.io >> >> >> >> Kindly, >> >> Dmitry >> >> - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
[GitHub] cordova-lib pull request: CB-9065 Allow removing plugins by short ...
Github user muratsu commented on the pull request: https://github.com/apache/cordova-lib/pull/225#issuecomment-104789786 :+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
[GitHub] cordova-lib pull request: CB-9065 Allow removing plugins by short ...
Github user purplecabbage commented on the pull request: https://github.com/apache/cordova-lib/pull/225#issuecomment-104788948 Yeah, I like that better. If we fail to find it in our typical id search, we then retry with the addition of `cordova-plugin-` Incidentally, internally here we discussed doing the same thing with install ... adding entries to the plugin-mapper so you could `cordova plugin install camera` and get `cordova-plugin-camera`. Unfortunately the plugin-mapper is currently only outputting warnings and not redirecting, so that will have to wait. --- 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-lib pull request: CB-9065 Allow removing plugins by short ...
Github user TimBarham commented on the pull request: https://github.com/apache/cordova-lib/pull/225#issuecomment-104787089 Hmmm... Interesting point. I like the convenience of a short name, but I don't think it is worth the weirdness of adding a custom field to package.json just for that. If I check this in, and people get used to it, they'll expect it to be supported going forward. So, here's a possible alternatively that will work now and in the future... rather than supporting removing by name, we could support removing by a "short id". That is - you could drop the `cordova-plugin-` from the start. So `camera`, for example, would match `cordova-plugin-camera`. I think that makes sense - having to specify `cordova-plugin-` is kinda superfluous. We should support this shortcut when *adding* a plugin, too. What do you think? --- 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-lib pull request: CB-9065 Allow removing plugins by short ...
Github user purplecabbage commented on the pull request: https://github.com/apache/cordova-lib/pull/225#issuecomment-104784245 So, I discussed this a bit with Steve, and he brought up an interesting point. A stretch goal is to not have a plugin.xml file at all, and simply use package.json for the entire plugin definition. Given that the `` tag only exists in plugin.xml, could be removed, and is not unique ( which I see you handle ) does it still make sense to push users to rely on a convenience function that we may end up removing? The name property in a package.json IS the id. Potentially we could also add a cordova.name field to package.json --- 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: CB-8900: Documentation for the platform...
Github user TimBarham commented on a diff in the pull request: https://github.com/apache/cordova-docs/pull/292#discussion_r30933383 --- Diff: docs/en/edge/platform_plugin_versioning_ref/index.md --- @@ -0,0 +1,70 @@ +--- +license: Licensed to the Apache Software Foundation (ASF) under one + or more contributor license agreements. See the NOTICE file + distributed with this work for additional information + regarding copyright ownership. The ASF licenses this file + to you under the Apache License, Version 2.0 (the + "License"); you may not use this file except in compliance + with the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, + software distributed under the License is distributed on an + "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + KIND, either express or implied. See the License for the + specific language governing permissions and limitations + under the License. +--- + +# Platforms and Plugins Version Management +From version 4.3.0 onwards, Cordova provides the ability to save and restore platforms and plugins. +This feature allows developers to save and restore their app to a known state without having to check in all of the platform and plugin source code. +When a save command is issued, the config.xml file is used to reference details about platforms and plugins versions that should be used with the app. The 'restore' step happens automatically when a **'cordova prepare'** is issued. Restoration makes use of information previously saved in the config.xml file. + +One scenario where save/restore capabilities come in handy is in large teams that work on an app, with each team member focusing on a platform or plugin. This feature makes it easier to share the project and reduce the amount of redundant code that is checked in the repository. + + +## Platform Versioning + +### Saving platforms +To save a platform, you issue the following command : + +$ cordova platform add ] | directory | git_url> --save + +After running the above command, the resulting config.xml looks like : + + +... + +... + + + +Some examples : + * **'cordova platform add android --save'** => retrieves the pinned version of the android platform, adds it to the project and then updates config.xml. + * **'cordova platform add android@3.7.0 --save'** => retrieves the android platform, version 3.7.0 from npm, adds it to the project and then updates config.xml. + * **'cordova platform add https://github.com/apache/cordova-android.gitâ --save'** => clones the specified cordova-android git repository, adds the android platform to the project, then updates config.xml and point its version to the specified git-url. + * **'cordova platform add C:/path/to/android/platform --save'** => retrieves the android platform from the specified directory, adds it to the project, then updates config.xml and point to the directory. + +### Mass saving platforms on an existing project +The '--save' flag describe above is only useful when you remember to use it during the platform addition. +If you have a pre-existing project and you want to mass-save all existing platforms in it, you can use : + +$ cordova platform save + + +### Updating / Removing platforms +It is also possible to update/delete from config.xml during the commands 'cordova platform update' and 'cordova platform remove' : + +$ cordova platform update > --save --- End diff -- Strictly speaking, shouldn't this be: $ cordova platform update ]> --save (should it also include `directory` and `git_url` - does update work with those?) --- 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: CB-8900: Documentation for the platform...
Github user purplecabbage commented on a diff in the pull request: https://github.com/apache/cordova-docs/pull/292#discussion_r30932290 --- Diff: docs/en/edge/platform_plugin_versioning_ref/index.md --- @@ -0,0 +1,70 @@ +--- +license: Licensed to the Apache Software Foundation (ASF) under one + or more contributor license agreements. See the NOTICE file + distributed with this work for additional information + regarding copyright ownership. The ASF licenses this file + to you under the Apache License, Version 2.0 (the + "License"); you may not use this file except in compliance + with the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, + software distributed under the License is distributed on an + "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + KIND, either express or implied. See the License for the + specific language governing permissions and limitations + under the License. +--- + +# Platforms and Plugins Version Management +From version 4.3.0 onwards, Cordova provides the ability to save and restore platforms and plugins. +This feature allows developers to save and restore their app to a known state without having to check in all of the platform and plugin source code. +When a save command is issued, the config.xml file is used to reference details about platforms and plugins versions that should be used with the app. The 'restore' step happens automatically when a **'cordova prepare'** is issued. Restoration makes use of information previously saved in the config.xml file. --- End diff -- +1 has no place in a markdown file --- 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: CB-8900: Documentation for the platform...
Github user TimBarham commented on a diff in the pull request: https://github.com/apache/cordova-docs/pull/292#discussion_r30932058 --- Diff: docs/en/edge/platform_plugin_versioning_ref/index.md --- @@ -0,0 +1,70 @@ +--- +license: Licensed to the Apache Software Foundation (ASF) under one + or more contributor license agreements. See the NOTICE file + distributed with this work for additional information + regarding copyright ownership. The ASF licenses this file + to you under the Apache License, Version 2.0 (the + "License"); you may not use this file except in compliance + with the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, + software distributed under the License is distributed on an + "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + KIND, either express or implied. See the License for the + specific language governing permissions and limitations + under the License. +--- + +# Platforms and Plugins Version Management +From version 4.3.0 onwards, Cordova provides the ability to save and restore platforms and plugins. +This feature allows developers to save and restore their app to a known state without having to check in all of the platform and plugin source code. +When a save command is issued, the config.xml file is used to reference details about platforms and plugins versions that should be used with the app. The 'restore' step happens automatically when a **'cordova prepare'** is issued. Restoration makes use of information previously saved in the config.xml file. --- End diff -- Instead of using a `` here, can you just leave a blank line? The resulting paragraph spacing is much nicer. Like this: From version 4.3.0 onwards, Cordova provides the ability to save and restore platforms and plugins. This feature allows developers to save and restore their app to a known state without having to check in all of the platform and plugin source code. --- 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: [CI] Medic Report
Thanks for the update Dmitry! I have kept somewhat distant from the intricacies of our CI, so I have a few questions. Do you think we can get Medic running different build variations, like with and without the --browserify flag? Can we have Medic run tests for every pull request and report results back to github so we can see if a pr breaks something? The now long ago original architecture of Medic was designed to support running tests on physical devices that would then report their results back to the url specified url in medic.json. Is this still available? And if so, can we configure test devices to report back to the federated test results server? We have nearly every device here at Adobe, but many are used rarely, we could potentially set them up for use in running tests. This would be especially useful in android land, where every device seems to 'feature' some sort of manufacturer quirk. @purplecabbage risingj.com On Fri, May 22, 2015 at 2:00 PM, Dmitry Blotsky wrote: > Hi list, > > > > Here are some points of interest regarding the CI: > > - Builds now know what commits went into them > > - Waiting on Infra to configure GitHub repos to send changes our > way so that they will *trigger* the builds (right now they're still > periodic) > > - Windows build recently broke, and here is the JIRA: > https://issues.apache.org/jira/browse/CB-9066 > > - Other JIRAs outstanding, being fixed piece by piece by folks in > the community > > > > Here is this week's report on test failures: > > - 14 on Android OSX (flaky) > > - ~14 on Android Windows > > - ~21 on iOS > > - Windows breaking > > - 0 on WP8 (flaky) > > > > As always, the Medic URI is: http://ci.cordova.io > > > > Kindly, > > Dmitry > >
Re: [DISCUSS] Should pinned platforms allow for patch updates?
I'm okay with accepting patch changes without upgrading the tooling for
now. If it works well and once we have more extensive testing in place, we
can swap to accepting minor changes.
-Steve
On Fri, May 22, 2015 at 2:21 PM, Tim Barham
wrote:
> It's been a while since we discussed this, and I'd like to implement the
> change. I'd like to get some consensus on whether we should go with
> accepting patch changes only ('~1.2.3') or accepting minor version changes
> ('^1.2.3'). Should we go with patch changes only for now, and see how
> things go? I wonder how good we will be at maintaining backward
> compatibility of minor version changes :).
>
> -Original Message-
> From: Nikhil Khandelwal [mailto:nikhi...@microsoft.com]
> Sent: Tuesday, May 12, 2015 4:31 PM
> To: dev@cordova.apache.org
> Subject: RE: [DISCUSS] Should pinned platforms allow for patch updates?
>
> > For platform releases, we would have to test it with the oldest version
> of the CLI that could potentially pull it down.
>
> This one worries me a bit in terms of the testing burden and the version
> matrix that we will need to support.
>
> Totally in favor of having patch versions be available right away without
> requiring a tools release.
>
> Thanks,
> Nikhil
>
>
> -Original Message-
> From: Shazron [mailto:shaz...@gmail.com]
> Sent: Tuesday, May 12, 2015 3:38 PM
> To: dev@cordova.apache.org
> Subject: Re: [DISCUSS] Should pinned platforms allow for patch updates?
>
> +1 on loosening the grip on platform pinning
>
> On Tue, May 12, 2015 at 3:21 PM, Steven Gill
> wrote:
> > I am totally on board with --save flag saving '^1.2.3' in config.xml
> > since it mimics the behavior of npm --save. No need to change anything.
> >
> > The more I think about it, the more I think we should loosen our grips
> > on platform pinning. As long as we are being semver compliant for all
> > of our platforms, we shouldn't run into issues.
> >
> > I like the idea of changing our pins to `^1.2.3` so it respects major
> only.
> > It would grab the newest released version of the platform with the
> > same major. This would only impact new projects or projects that are
> > adding a platform for the first time. Existing projects would still
> > have to cordova platform rm PLATFORM and cordova platform add PLATFORM
> > to get the latest platform.
> >
> > One of the reasons we originally wanted to keep pinning was so we
> > could easily help users when they tell us what version of Cordova they
> > are having problems with. With the ability to add whatever version of
> > platforms via `cordova platform add windows@VERSION`, knowing the cli
> > version doesn't give us the details we want. Users can get installed
> > platform versions with `cordova platform ls`.
> >
> > If we make this change, we should review our fetch/cache logic to see
> > if it would grab the latest if an older version exists).
> >
> > We seem to have a fairly good track record with newer platform
> > versions working with older CLI versions. Everytime we do a tools
> > release, we could update the pinned versions to the latest released
> > ones/newest version cli was tested with at release time. For platform
> > releases, we would have to test it with the oldest version of the CLI
> > that could potentially pull it down.
> >
> > What do others think?
> >
> >
> >
> >
> >
> >
> > On Tue, May 12, 2015 at 6:36 AM, Tim Barham
> > wrote:
> >
> >> ?Currently our pinned platforms are all in the form "1.2.3", which I
> >> expect means we'll always get that exact version. Should we instead
> >> use the form "1.2.x" to allow for patches without having to do a tools
> release?
> >>
> >>
> >> BTW... When you add a platform, and we use the pinned version of,
> >> say, '1.2.3', if you use the '--save' flag, we'll save it to
> >> config.xml as '^1.2.3', like npm currently doe (in other words...
> >> 'allow any backwardly compatible version'). This means adding the
> >> platform later could end up with a later version (even with the minor
> >> version greater than 2 in this example). Perhaps we need to be
> >> consistent here - if we change pinned version to use the form
> >> '1.2.x', then should we save exactly that to config.xml? Or
> >> alternatively should we use the form '^1.2.3' for our pinned version,
> >> which will introduce a lot more variation, but will be more consistent
> with how semver and npm work?
> >>
> >>
> >> Thanks!
> >>
> >>
> >> Tim
> >>
> >>
> >>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
> B CB
> [ X ܚX K K[XZ[
>] ][ X ܚX P ܙ ݘK \ X K ܙ B ܈ Y ] [ۘ[[X[ K[XZ[
>] Z [ܙ ݘK \ X K ܙ B
>
RE: [DISCUSS] Should pinned platforms allow for patch updates?
It's been a while since we discussed this, and I'd like to implement the
change. I'd like to get some consensus on whether we should go with accepting
patch changes only ('~1.2.3') or accepting minor version changes ('^1.2.3').
Should we go with patch changes only for now, and see how things go? I wonder
how good we will be at maintaining backward compatibility of minor version
changes :).
-Original Message-
From: Nikhil Khandelwal [mailto:nikhi...@microsoft.com]
Sent: Tuesday, May 12, 2015 4:31 PM
To: dev@cordova.apache.org
Subject: RE: [DISCUSS] Should pinned platforms allow for patch updates?
> For platform releases, we would have to test it with the oldest version of
> the CLI that could potentially pull it down.
This one worries me a bit in terms of the testing burden and the version matrix
that we will need to support.
Totally in favor of having patch versions be available right away without
requiring a tools release.
Thanks,
Nikhil
-Original Message-
From: Shazron [mailto:shaz...@gmail.com]
Sent: Tuesday, May 12, 2015 3:38 PM
To: dev@cordova.apache.org
Subject: Re: [DISCUSS] Should pinned platforms allow for patch updates?
+1 on loosening the grip on platform pinning
On Tue, May 12, 2015 at 3:21 PM, Steven Gill wrote:
> I am totally on board with --save flag saving '^1.2.3' in config.xml
> since it mimics the behavior of npm --save. No need to change anything.
>
> The more I think about it, the more I think we should loosen our grips
> on platform pinning. As long as we are being semver compliant for all
> of our platforms, we shouldn't run into issues.
>
> I like the idea of changing our pins to `^1.2.3` so it respects major only.
> It would grab the newest released version of the platform with the
> same major. This would only impact new projects or projects that are
> adding a platform for the first time. Existing projects would still
> have to cordova platform rm PLATFORM and cordova platform add PLATFORM
> to get the latest platform.
>
> One of the reasons we originally wanted to keep pinning was so we
> could easily help users when they tell us what version of Cordova they
> are having problems with. With the ability to add whatever version of
> platforms via `cordova platform add windows@VERSION`, knowing the cli
> version doesn't give us the details we want. Users can get installed
> platform versions with `cordova platform ls`.
>
> If we make this change, we should review our fetch/cache logic to see
> if it would grab the latest if an older version exists).
>
> We seem to have a fairly good track record with newer platform
> versions working with older CLI versions. Everytime we do a tools
> release, we could update the pinned versions to the latest released
> ones/newest version cli was tested with at release time. For platform
> releases, we would have to test it with the oldest version of the CLI
> that could potentially pull it down.
>
> What do others think?
>
>
>
>
>
>
> On Tue, May 12, 2015 at 6:36 AM, Tim Barham
> wrote:
>
>> ?Currently our pinned platforms are all in the form "1.2.3", which I
>> expect means we'll always get that exact version. Should we instead
>> use the form "1.2.x" to allow for patches without having to do a tools
>> release?
>>
>>
>> BTW... When you add a platform, and we use the pinned version of,
>> say, '1.2.3', if you use the '--save' flag, we'll save it to
>> config.xml as '^1.2.3', like npm currently doe (in other words...
>> 'allow any backwardly compatible version'). This means adding the
>> platform later could end up with a later version (even with the minor
>> version greater than 2 in this example). Perhaps we need to be
>> consistent here - if we change pinned version to use the form
>> '1.2.x', then should we save exactly that to config.xml? Or
>> alternatively should we use the form '^1.2.3' for our pinned version,
>> which will introduce a lot more variation, but will be more consistent with
>> how semver and npm work?
>>
>>
>> Thanks!
>>
>>
>> Tim
>>
>>
>>
-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org
B CB [
X ܚX KK[XZ[
] ][ X ܚX P ܙݘK \X K ܙ B ܈Y][ۘ[ [X[ K[XZ[
] Z[ ܙݘK \X K ܙ B
Re: cordova-vm.apache.org
afaik, it's still available, but probably we'd need to ping INFRA to make it alive again (doesn't respond to pings atm) On Thu, May 21, 2015 at 5:59 PM, Dmitry Blotsky wrote: > Hey folks, > > Resurrecting an old thread here: is cordova-vm.apache.org still available > for us? We still need a couchdb machine on Apache Infra. > > Kindly, > Dmitry > > -Original Message- > From: Dmitry Blotsky [mailto:dblot...@microsoft.com] > Sent: Wednesday, April 8, 2015 5:29 PM > To: dev@cordova.apache.org > Subject: RE: cordova-vm.apache.org > > Thanks for the exposition, Jesse! Yeah, it seems like getting logs off > some devices and emulators is either impossible or insurmountably > difficult. I know Android and iOS emulators and devices create logs on the > file system or have a utility to retrieve them from the device (e.g. adb > logcat), but it doesn't seem like we can get the same easy access on > Windows, BlackBerry, etc. Network seems to be the far superior solution. > > So, shall we then commandeer the Apache VM for medic's logging needs? > Right now it's still using a private machine and it would be great to move > this last piece to Apache infrastructure. > > Kindly, > Dmitry > > -Original Message- > From: Jesse [mailto:purplecabb...@gmail.com] > Sent: Wednesday, April 8, 2015 4:07 PM > To: dev@cordova.apache.org > Subject: Re: cordova-vm.apache.org > > In reply to Dmitry, perhaps going off topic a bit ... > > All devices cannot echo their results back to the console that launched > them. > That was the reason in the first place for using a central db for > federated test results. > This is likely the ONLY way that this will ever work. > > Medic/BuildBot was originally designed to support a device wall with > multiple devices running tests and reporting results to the db server, > which then provided some interpretations of those results, including fancy > graphs that showed things like 'the media plugin is failing 2 tests on > Android 4.4 on a moto-x' > > Some of this has been lost along the way, but understand that there are > limitations reporting test results by other means. > 1. Windows Phone Emulator has tons of network weirdness, so reporting > results to the command line that launched it is near impossible. > 2. cordova-ios does not ship with any console.log capability, so there is > nowhere to report tests to. > 3. all of our cli build tooling exits as soon as it has built and launched > the app, it would need to stick around and wait for results otherwise. > 4. android does not echo console.log calls to the terminal that launched it > > cordova-paramedic leverages much of the way that medic works by creating > it's own server to receive posted test results, thereby side-stepping some > of the issues above. This however is still not perfect in that it does not > always play well with vms, wp8/windows are still unworkable, but > ios/android do work. Also, this is not intended to be a replacement for > what medic does ( runs all the tests and federates the results ) but more > so to integrate with TravisCI so we can see if a plugin pull request breaks > anything, or to run yourself and test a particular plugin/platform > combination in isolation. > > Ultimately though, I agree with Andrew's statement. We need to spend more > time fixing the bugs + the tests, instead of playing with how they are > reported. > > > > > > > > @purplecabbage > risingj.com > > On Wed, Apr 8, 2015 at 2:59 PM, Dmitry Blotsky > wrote: > > > The logs pull down the output from CouchDB; CouchDB serves as the main > > dump point of output from a running mobilespec. This is the chosen > > path for gathering output because we can't get logs for every platform > > on every environment (i.e. both emulator and device), but we can get > > network access for each. > > > > I'm not too knowledgeable on why logs aren't programmatically > > available on every platform, but it is indeed another avenue that has > > merit, and could eliminate the need for a DB in the middle. What are > > the reasons that we can't get the logs from some emulators/devices on > some platforms? > > > > - Dmitry > > > > -Original Message- > > From: agri...@google.com [mailto:agri...@google.com] On Behalf Of > > Andrew Grieve > > Sent: Wednesday, April 8, 2015 11:54 AM > > To: Andrew Grieve > > Cc: dev > > Subject: Re: cordova-vm.apache.org > > > > Although - could you remind me why we need a couchdb? It's a hasstle > > and will require maintentance. > > The logs from the builders seem sufficient to me (they show which > > tests fail). Effort might be better spent improving the tests & fixing > bugs. > > > > On Wed, Apr 8, 2015 at 2:53 PM, Andrew Grieve > > wrote: > > > > > Sounds good! > > > > > > Here's the thread where I got myself access: > > > > > > http://markmail.org/thread/ee4ujznt6lhw6ug5#query:+page:1+mid:aqjyaw > > > mz > > > tdbnb2bf+state:results > > > > > > My notes from before: > > > 1. Make sure you have an SSH key registere
[GitHub] cordova-docs pull request: CB-8900: Documentation for the platform...
Github user TimBarham commented on the pull request: https://github.com/apache/cordova-docs/pull/292#issuecomment-104768868 You should also describe what happens if you add a platform (via `cordova platform add`) that has an entry saved in `config.xml` (specifically that if you add the platform using some "@" spec, that will be used and will overwrite the entry in `config.xml`, and if you add the platform without any "@" spec, we will use whatever is saved in `config.xml`). Also, as of 5.0.0, a platform version is saved to `config.xml` using the caret prefix, which means you won't necessarily get the exact version you saved, but it should be a *compatible* version. --- 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
[CI] Medic Report
Hi list, Here are some points of interest regarding the CI: - Builds now know what commits went into them - Waiting on Infra to configure GitHub repos to send changes our way so that they will *trigger* the builds (right now they're still periodic) - Windows build recently broke, and here is the JIRA: https://issues.apache.org/jira/browse/CB-9066 - Other JIRAs outstanding, being fixed piece by piece by folks in the community Here is this week's report on test failures: - 14 on Android OSX (flaky) - ~14 on Android Windows - ~21 on iOS - Windows breaking - 0 on WP8 (flaky) As always, the Medic URI is: http://ci.cordova.io Kindly, Dmitry
[GitHub] cordova-docs pull request: CB-8900: Documentation for the platform...
Github user TimBarham commented on a diff in the pull request: https://github.com/apache/cordova-docs/pull/292#discussion_r30929325 --- Diff: docs/en/edge/platform_plugin_versioning_ref/index.md --- @@ -0,0 +1,70 @@ +--- +license: Licensed to the Apache Software Foundation (ASF) under one + or more contributor license agreements. See the NOTICE file + distributed with this work for additional information + regarding copyright ownership. The ASF licenses this file + to you under the Apache License, Version 2.0 (the + "License"); you may not use this file except in compliance + with the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, + software distributed under the License is distributed on an + "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + KIND, either express or implied. See the License for the + specific language governing permissions and limitations + under the License. +--- + +# Platforms and Plugins Version Management +From version 4.3.0 onwards, Cordova provides the ability to save and restore platforms and plugins. +This feature allows developers to save and restore their app to a known state without having to check in all of the platform and plugin source code. +When a save command is issued, the config.xml file is used to reference details about platforms and plugins versions that should be used with the app. The 'restore' step happens automatically when a **'cordova prepare'** is issued. Restoration makes use of information previously saved in the config.xml file. --- End diff -- I don't think this reads well (`config.xml file is used to reference details`). Perhaps rearrange the sentence a bit - something like *The save command will store details about the app's platform and plugin versions in config.xml*. Also... not sure what our approach in docs is typically... but should command names be in monospace? As in `save` and `cordova prepare` etc? --- 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-lib pull request: CB-9065 Allow removing plugins by short ...
Github user TimBarham commented on the pull request: https://github.com/apache/cordova-lib/pull/225#issuecomment-104762109 Hah, yeah, I think that'd definitely be doable. I won't include it as part of this change, though. --- 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-lib pull request: CB-9065 Allow removing plugins by short ...
Github user purplecabbage commented on the pull request: https://github.com/apache/cordova-lib/pull/225#issuecomment-104747950 Interesting, I like it. How about removing by path/url? Does it make sense having installed via `cordova plugin add ../myplugin/` that I could then remove it with `cordova plugin rm ../myplugin/` ? Not entirely sure this makes sense, or adds value, just throwing it out there. --- 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-geolocation pull request: Add missing module refere...
Github user asfgit closed the pull request at: https://github.com/apache/cordova-plugin-geolocation/pull/36 --- 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-lib pull request: CB-9065 Allow removing plugins by short ...
GitHub user TimBarham opened a pull request: https://github.com/apache/cordova-lib/pull/225 CB-9065 Allow removing plugins by short name. Adds logic to `plugin remove` to look up a plugin by "short name" if we don't find it by id. This means, for example, that you can use the following command: cordova plugin remove camera Instead of: cordova plugin remove cordova-plugin-camera Also removes a bunch of unecessary calls to `path.join(projectRoot, 'plugins')`, since we already have this path stored in a variable. You can merge this pull request into a Git repository by running: $ git pull https://github.com/MSOpenTech/cordova-lib CB-9065 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cordova-lib/pull/225.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 #225 commit 92c4c16ebd852fb04f3b8c970abf76ccb0eb1015 Author: Tim Barham Date: 2015-05-22T19:11:59Z CB-9065 Allow removing plugins by short name. Adds logic to 'plugin remove' to look up a plugin by "short name" if we don't find it by id. --- 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: CB-8900: Documentation for the platform...
Github user omefire commented on the pull request: https://github.com/apache/cordova-docs/pull/292#issuecomment-104746042 I'll soon send another one for the plugin side of things. --- 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: CSP ignored when using remote content
If using the wkwebview-engine plugin in cordova-ios 4.0 (release TBD), using file:/// URLs will respect CORS, I believe (Device: you can only test this currently with files loaded from the tmp folder: https://github.com/shazron/WKWebViewFIleUrlTest - Simulator: anything goes) The wkwebview-engine plugin uses the new WKWebView component in iOS 8, instead of the system UIWebView (which doesn't care about CORS). I haven't tested this with the latest iOS 8.3 though. On Fri, May 22, 2015 at 11:42 AM, Nikhil Khandelwal wrote: > CORS does not apply for local content using file:///, hence, browser will > allow all XHRs when your origin is local. When you host content on > remoteserver.com CORS is applied. If you make an XHR to xhr.com, the browser > will pre-flight a request to xhr.com asking if xhr.com supports xhr access > from remoteserver.com. xhr.com responds using a response header - > 'Access-Control-Allow-Origin' allowing XHR to be allowed or not. You can use > network inspection tools to see the request/response to see what's happening > in your case and understand the failure. > > Thanks, > Nikhil > > > -Original Message- > From: Pär [mailto:p.majh...@gmail.com] > Sent: Thursday, May 21, 2015 6:24 PM > To: dev@cordova.apache.org > Subject: Re: CSP ignored when using remote content > > Thanks for the reply. Yes, the CSP rules are defined by the page that is > loaded, wherever that is. The thing is that the behavior when loading that > page from a remote server is different from the behavior when loading the > page locally, even though its the exact same page. > > I have and CSP "default-src *". When i have a local > content src i can do any cross origin XHR's. Then i change content src to a > server where i serve the platform/www folder of my cordova project, and > suddently the same XHR's are blocked. So the behaviour is different just from > one varialbe changning; content src. > > On 22 May 2015 at 02:27, Jesse wrote: > >> This is the intended behavior. The csp rules are defined by the page >> that is loaded, wherever it is. >> Pointing content.src to a remote server basically means, ignore >> anything that is in www/index.html. >> >> @purplecabbage >> risingj.com >> >> On Thu, May 21, 2015 at 2:16 PM, Pär wrote: >> >> > When using a remote content src like http://remoteserver.com/app/index.html";> the CSP rules seems to be >> > ignored; cross origin requests fail even with a "default-src *" CSP. >> > Is this intended behaviour or a bug? >> > >> - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
[GitHub] cordova-plugin-contacts pull request: Fixed bug with installation
Github user asfgit closed the pull request at: https://github.com/apache/cordova-plugin-contacts/pull/60 --- 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: CB-8900: Documentation for the platform...
GitHub user omefire opened a pull request: https://github.com/apache/cordova-docs/pull/292 CB-8900: Documentation for the platform save / restore feature This PR's goal is to document the platform save / restore feature. I'll soon send another one for the plugin side of things. You can merge this pull request into a Git repository by running: $ git pull https://github.com/omefire/cordova-docs CB-8900 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cordova-docs/pull/292.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 #292 commit 6aa8e8ffba648be2a895ac10eda8e7c908fce806 Author: Omar Mefire Date: 2015-05-18T18:04:05Z CB-8900: Documentation for the platform save / restore feature --- 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-geolocation pull request: Add missing module refere...
Github user infil00p commented on the pull request: https://github.com/apache/cordova-plugin-geolocation/pull/36#issuecomment-104742963 Just as @jcesarmobile said, there are no modules needed, therefore this should be closed. Because this is a copy of the repository, and not the repository itself, I can't close this one from here. --- 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: CSP ignored when using remote content
CORS does not apply for local content using file:///, hence, browser will allow all XHRs when your origin is local. When you host content on remoteserver.com CORS is applied. If you make an XHR to xhr.com, the browser will pre-flight a request to xhr.com asking if xhr.com supports xhr access from remoteserver.com. xhr.com responds using a response header - 'Access-Control-Allow-Origin' allowing XHR to be allowed or not. You can use network inspection tools to see the request/response to see what's happening in your case and understand the failure. Thanks, Nikhil -Original Message- From: Pär [mailto:p.majh...@gmail.com] Sent: Thursday, May 21, 2015 6:24 PM To: dev@cordova.apache.org Subject: Re: CSP ignored when using remote content Thanks for the reply. Yes, the CSP rules are defined by the page that is loaded, wherever that is. The thing is that the behavior when loading that page from a remote server is different from the behavior when loading the page locally, even though its the exact same page. I have and CSP "default-src *". When i have a local content src i can do any cross origin XHR's. Then i change content src to a server where i serve the platform/www folder of my cordova project, and suddently the same XHR's are blocked. So the behaviour is different just from one varialbe changning; content src. On 22 May 2015 at 02:27, Jesse wrote: > This is the intended behavior. The csp rules are defined by the page > that is loaded, wherever it is. > Pointing content.src to a remote server basically means, ignore > anything that is in www/index.html. > > @purplecabbage > risingj.com > > On Thu, May 21, 2015 at 2:16 PM, Pär wrote: > > > When using a remote content src like http://remoteserver.com/app/index.html";> the CSP rules seems to be > > ignored; cross origin requests fail even with a "default-src *" CSP. > > Is this intended behaviour or a bug? > > >
[GitHub] cordova-plugin-contacts pull request: CB-9056 Increased timeout of...
Github user asfgit closed the pull request at: https://github.com/apache/cordova-plugin-contacts/pull/63 --- 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-contacts pull request: Making sure the photoCursor ...
Github user recursion1122 commented on the pull request: https://github.com/apache/cordova-plugin-contacts/pull/61#issuecomment-104730019 This seems to occur with at least moderate consistency on Samsung Galaxy S5 devices running Android 5.x. I tested it on two different devices and both of them consistently crash and this error is thrown from at least one of the devices. --- 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
[DISCUSS] Cordova-windows 4.0.0 release
Does anyone have reason to delay this release? This is the first release with Windows 10 support and has a breaking change that requires an accompanying tools release. Hence, I propose we version it 4.0.0 Here are the next steps: - Prepare blog for the release include details of support of Windows 10. - Do an accompany DOCS & TOOLS release. I have created a JIRA issue for this: https://issues.apache.org/jira/browse/CB-9064 I have made updates to the RELEASENOTES.md: [4.0.0-dev] * Updating appx manifest to a large extent now happens in the `prepare` step as opposed to the `build` step. This change implies that cordova-windows 4.0.0 can only work with with cordova CLI > 5.0 * CB-8486 Support for creating signed package and build.json for Windows * Add preview support for Windows 10 Universal Apps. To target Windows 10, add `` to config.xml. * The default windows target version is now 8.1. * Support for `--appx` command line argument to override the windows target version * CB-8946: Added the `WindowsToastCapable` preference to indicate that the app can support toasts. This is to support the Local Notifications plugin. * CB-8856 Fix 'Id' attribute is invalid when creating Windows Store submission build * CB-8307: Adding a 25-year expiration temporary certificate. * CB-8760 platform list doesn't show version for windows platform. **Known Issues with 4.0.0-dev and Windows 10** * Windows 10 Technical Preview 2 does not have a command-line compatible emulator deployment scenario. To deploy to an emulator, open your solution file in Visual Studio. * The Windows SDK included with Visual Studio 2015 RC does not include a tool to deploy to a Windows 10 Phone. To deploy to a phone, open your solution file in Visual Studio. * WinJS is included inline in the package. In the future, it will be migrated to an NPM dependency, and the dependency will not include any UI-related files. You should not take a dependency on WinJS UI functionality unless you include it yourself (see [WinJS on Github](http://github.com/winjs/winjs)). Thanks, Nikhil
RE: Cordova-js update
Thanks for the explanation. This change and workflow makes sense now. Currently, createmobilespec.js is used by the Cordova CI: http://ci.apache.org/builders/cordova-windows-phone8.1/builds/4/steps/creating-mobilespec-app/logs/stdio The intent of the CI is to test the latest unreleased version of cordova.js. createmobilespec.js, by default, uses grunt compile to generate the latest cordova.js. Now that grunt compile has npm dependency - I believe cordova.js is being generated with the latest released version of platform cordova.js components and this is an issue. I have filed a JIRA here: https://issues.apache.org/jira/browse/CB-9063 A tricky thing with this change is that npm link is now the correct way to get the latest unreleased version of cordova.js but that requires admin permissions on Windows and the cordova CI does not run with admin permissions. Perhaps the contents of the cordova- need to be copied to node_modules of cordova.js *before* generating the cordova.js. Thanks, Nikhil -Original Message- From: Steven Gill [mailto:stevengil...@gmail.com] Sent: Thursday, May 21, 2015 8:27 PM To: dev@cordova.apache.org Subject: Re: Cordova-js update This change was made so we could get the browserify workflow working well. The main advantage of the browserify workflow is build time inclusion of plugins javascript instead of runtime. Our old way, we use cordova_plugins.js to inject the javascript of every plugin at runtime. With the browserify workflow, all of the JS for the plugins essentially gets concatenated to cordova.js. createmobilespec should work the same. You still use the same grunt commands and it grabs the platform specific js from the platforms in the node_modules/PLATFORM/cordova-js-src directories. If the platform dependencies don't have a cordova-js-src directory (amazon, firefoxos, browser, osx) then it will use the src/legacy-exec/PLATFORM directories to build cordova.js. grunt, grunt compile, grunt test all work still. You actually don't need to pass in the --platformVersion flag anymore as it will figure out the version based on the platform dependencies of cordova.js. It still accepts it though. createmobilespec also takes a --browserify flag if you want to build the mobile-spec project with the browserified cordovajs. You could also just go to generated mobilespec project and run cordova prepare --browserify to generate the browserified cordova.js. Lastly, I added support to paramedic for the --browserify flag to test the plugins that way. Let me know if you have more questions! I'd love to clear everything up. If you are having issues with createmobilespec, please let me know the issue so I can investigate it. Been working fine for me. Cheers, -Steve On Thu, May 21, 2015 at 5:19 PM, Nikhil Khandelwal wrote: > I'm new to this area. Steve: Can you provide some background on the > motivation for this change? In particular, what is the advantage of > this workflow, over the existing one: > > I have also made some changes to cordova-lib which will copy the > contents of cordova-js-src into platform_www when a project gets > created. If a user decided to do cordova prepare --browserify, it will > use the platform specific js files included in their app to build > their cordova.js. [3] [4] > > I think you need to update createmobilespec as it uses the grunt task > to generate the latest cordova.js for creating an app that is used by > the Apache CI (http://ci.cordova.io). Now the latest cordova.js is not > being generated and we are likely missing some test coverage as we > make changes to cordova.js. > > Thanks, > Nikhil > > -Original Message- > From: Steven Gill [mailto:stevengil...@gmail.com] > Sent: Monday, May 18, 2015 2:18 AM > To: dev@cordova.apache.org > Subject: Cordova-js update > > I have a pull request [1] ready for cordova-js which adds platforms as > dev dependencies and uses the previously moved cordova-js-src from the > platform repos instead of src/platform. I moved existing platform > specific js into cordovajs/src/legacy-exec to use in cases where > released platforms don't have a cordova-js-src directory. [2] > > I have updated both normal build and browserify build to use > cordova-js-src if present when building cordova.js. > > I have also made some changes to cordova-lib which will copy the > contents of cordova-js-src into platform_www when a project gets > created. If a user decided to do cordova prepare --browserify, it will > use the platform specific js files included in their app to build > their cordova.js. [3] [4] > > I will need to make sure each platform has their most up to date > platform specific js files in cordova-platform/cordova-js-src. After > these PRs get merged, platform maintainers should only worry about > updating these files instead of what exists in cordovajs/src/legacy-exec. > > Let me know if you have any questions or concerns. > > [1] https://github.com
[GitHub] cordova-plugin-statusbar pull request: Stop "object has no method"...
Github user Gillardo commented on the pull request: https://github.com/apache/cordova-plugin-statusbar/pull/25#issuecomment-104697601 This message acknowledges receipt of your ICLA, which has been filed in the Apache Software Foundation records. If you have been invited as a committer, please advise the project PMC that your ICLA has been filed. --- 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: Updated schedule for cordova-ios 4.0.0 with pluggable webviews?
I'm the only one working on this unfortunately -- the agile board is here: https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=76 On Fri, May 22, 2015 at 8:10 AM, Homer, Tony wrote: > In March, Shazron mentioned a tentative April release[1]. Can we get an > updated estimate? > Are there tasks that need help before it can move forward? > > [1] > https://shazronatadobe.wordpress.com/2015/03/03/wkwebview-and-apache-cordov > a/ > > Thanks! > Tony > > > - > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > For additional commands, e-mail: dev-h...@cordova.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Updated schedule for cordova-ios 4.0.0 with pluggable webviews?
In March, Shazron mentioned a tentative April release[1]. Can we get an updated estimate? Are there tasks that need help before it can move forward? [1] https://shazronatadobe.wordpress.com/2015/03/03/wkwebview-and-apache-cordov a/ Thanks! Tony - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
[GitHub] cordova-plugin-statusbar pull request: Stop "object has no method"...
Github user Gillardo commented on the pull request: https://github.com/apache/cordova-plugin-statusbar/pull/25#issuecomment-104608748 @nikhilkh i have emailed the agreement to secret...@apache.org this morning for 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. --- - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
[GitHub] cordova-wp8 pull request: CB-8954 Adds support for `requirements` ...
GitHub user vladimir-kotikov opened a pull request: https://github.com/apache/cordova-wp8/pull/82 CB-8954 Adds support for `requirements` command Implementation for https://issues.apache.org/jira/browse/CB-8954 You can merge this pull request into a Git repository by running: $ git pull https://github.com/MSOpenTech/cordova-wp8 CB-8954 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cordova-wp8/pull/82.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 #82 commit 6294952199791ec6c61757bcaebd1387362fee77 Author: Vladimir Kotikov Date: 2015-05-05T10:32:32Z Adds `requirements` command support to check_reqs module --- 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: CB-8954 Adds support for `requiremen...
GitHub user vladimir-kotikov opened a pull request: https://github.com/apache/cordova-windows/pull/83 CB-8954 Adds support for `requirements` command Implementation for https://issues.apache.org/jira/browse/CB-8954 You can merge this pull request into a Git repository by running: $ git pull https://github.com/MSOpenTech/cordova-windows CB-8954 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cordova-windows/pull/83.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 #83 commit 8b6b50212dbfc6aacbf0cdda861c63ff81555295 Author: Vladimir Kotikov Date: 2015-05-05T10:05:55Z Adds `requirements` command support to check_reqs module --- 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-ios pull request: CB-8954 Adds support for `requirements` ...
GitHub user vladimir-kotikov opened a pull request: https://github.com/apache/cordova-ios/pull/142 CB-8954 Adds support for `requirements` command Implemetation for https://issues.apache.org/jira/browse/CB-8954 You can merge this pull request into a Git repository by running: $ git pull https://github.com/MSOpenTech/cordova-ios CB-8954 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cordova-ios/pull/142.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 #142 commit f376e9501153883b09799e9bda9aac5650d058f5 Author: Vladimir Kotikov Date: 2015-05-05T12:08:54Z CB-8954 Adds `requirements` command support to check_reqs module --- 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-android pull request: CB-8954 Adds support for `requiremen...
GitHub user vladimir-kotikov opened a pull request: https://github.com/apache/cordova-android/pull/176 CB-8954 Adds support for `requirements` command Implemetation for https://issues.apache.org/jira/browse/CB-8954 You can merge this pull request into a Git repository by running: $ git pull https://github.com/MSOpenTech/cordova-android CB-8954 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cordova-android/pull/176.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 #176 commit 7013b1ff01efe3a666b16e358f2028c4219b286e Author: Vladimir Kotikov Date: 2015-04-22T11:24:26Z Updates check_reqs API to aloow consume it in more advanced way. * Updates all check_* methods to return information about version of tool installed. * Introduces Requirement class * Introduces check_all method, which return result of checks instead of resolving/failing in case of unsatisfied requirements * Makes check_all method check all of the requirements commit a84d5e3f168b8866273a45bae000352279a8 Author: Vladimir Kotikov Date: 2015-04-22T11:30:33Z Makes error mesages a bit more descriptive. --- 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-mobile-spec pull request: CB-8843 Fixed mobilespec tests t...
Github user alsorokin commented on a diff in the pull request:
https://github.com/apache/cordova-mobile-spec/pull/130#discussion_r30874137
--- Diff: cordova-plugin-mobilespec-tests/tests/whitelist.tests.js ---
@@ -202,7 +202,7 @@ exports.defineAutoTests = function () {
itShouldReject('http://www.apache.org.evil.com/');
itShouldAccept('file:///foo');
if (cordova.platformId == 'android')
-itShouldAccept('content:///foo');
+itShouldReject('content:///foo');
--- End diff --
It has been changed in
https://github.com/apache/cordova-mobile-spec/commit/b8401eb3c99573de6e6ae6af952f32d19bd2cd28#diff-e3ccd521f7df2ab57e6ee9133e737b36R205
I have asked the author of this change if this is intentional but received
no reply.
I suppose that it was not intentional so I am reverting that change here.
---
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-mobile-spec pull request: CB-8843 Fixed mobilespec tests t...
GitHub user alsorokin opened a pull request: https://github.com/apache/cordova-mobile-spec/pull/130 CB-8843 Fixed mobilespec tests to pass on Android https://issues.apache.org/jira/browse/CB-8843 You can merge this pull request into a Git repository by running: $ git pull https://github.com/MSOpenTech/cordova-mobile-spec CB-8843 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cordova-mobile-spec/pull/130.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 #130 commit 440468f9cc24000e8f74bcc76ade7da7ef174487 Author: alsorokin Date: 2015-05-22T07:19:03Z CB-8843 Fixed mobilespec tests to pass on Android --- 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-file-transfer pull request: Gzip support for wp8.x ...
Github user sviluppatoribk commented on the pull request: https://github.com/apache/cordova-plugin-file-transfer/pull/85#issuecomment-104544749 Please can you tell me what error code you get instead of 401? Test 6 of file-transfer-plugin call "http://cordova-filetransfer.jitsu.com/download_basic_auth"; url and on my run it return correct error code.. I have see there are many pull request failed for this test case, you are able to call that url from test machine? --- 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
