[jira] [Updated] (CB-14134) Unable to build android on V7.0.0, says duplicate fb_id entry
[ https://issues.apache.org/jira/browse/CB-14134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ram Krishna updated CB-14134: - Description: The facebook_app id and name is mentioned at only one place in config.xml, But when I run the build it creates automatically in res/xml folder and throws error. > Unable to build android on V7.0.0, says duplicate fb_id entry > - > > Key: CB-14134 > URL: https://issues.apache.org/jira/browse/CB-14134 > Project: Apache Cordova > Issue Type: Bug > Components: cordova-android >Affects Versions: cordova@7.0.0 >Reporter: Ram Krishna >Assignee: Joe Bowser >Priority: Major > Fix For: cordova-android-7.0.0 > > Attachments: Screen Shot 2018-06-13 at 6.49.12 PM.png > > > The facebook_app id and name is mentioned at only one place in config.xml, > But when I run the build it creates automatically in res/xml folder and > throws error. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Updated] (CB-14134) Unable to build android on V7.0.0, says duplicate fb_id entry
[ https://issues.apache.org/jira/browse/CB-14134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ram Krishna updated CB-14134: - Attachment: Screen Shot 2018-06-13 at 6.49.12 PM.png > Unable to build android on V7.0.0, says duplicate fb_id entry > - > > Key: CB-14134 > URL: https://issues.apache.org/jira/browse/CB-14134 > Project: Apache Cordova > Issue Type: Bug > Components: cordova-android >Affects Versions: cordova@7.0.0 >Reporter: Ram Krishna >Assignee: Joe Bowser >Priority: Major > Fix For: cordova-android-7.0.0 > > Attachments: Screen Shot 2018-06-13 at 6.49.12 PM.png > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Created] (CB-14134) Unable to build android on V7.0.0, says duplicate fb_id entry
Ram Krishna created CB-14134: Summary: Unable to build android on V7.0.0, says duplicate fb_id entry Key: CB-14134 URL: https://issues.apache.org/jira/browse/CB-14134 Project: Apache Cordova Issue Type: Bug Components: cordova-android Affects Versions: cordova@7.0.0 Reporter: Ram Krishna Assignee: Joe Bowser Fix For: cordova-android-7.0.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Created] (CB-14133) Avoid reinstalling already installed plugins in cordova-fetch
Zak created CB-14133:
Summary: Avoid reinstalling already installed plugins in
cordova-fetch
Key: CB-14133
URL: https://issues.apache.org/jira/browse/CB-14133
Project: Apache Cordova
Issue Type: Wish
Components: cordova-cli, cordova-fetch
Affects Versions: 8.0.0
Reporter: Zak
Relates to CB-13992
The pull request for CB-13992 removed the ```dependency-ls``` package which
helped to speed up the platform add step. However, each plugin still gets
```npm install```ed seemingly just to determine the package name.
Typical workflow is to run ```npm install``` as the first task after cloning a
node repository. The current practice for cordova is to save plugins to the
package.json meaning that plugins are already installed to the node_modules
directory, so running `npm install` for each of them individually is redundant.
If the main function in ```cordova-fetch``` is simplified to just return the
path to the given module (albeit this isn't the most elegant implementation):
```javascript
module.exports = function (target, dest, opts = {}) {
var fetchArgs = opts.link ? ['link'] : ['list'];
var nodeModulesDir = dest + '/node_modules/';
// check if npm is installed
return module.exports.isNpmInstalled()
.then(function () {
const mod = target.slice(0, target.lastIndexOf('@'));
return path.resolve(nodeModulesDir, mod)
})
.catch(function (err) {
throw new CordovaError(err);
});
};
```
the platform add process runs almost instantly rather than taking a few minutes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Updated] (CB-14133) Avoid reinstalling already installed plugins in cordova-fetch
[
https://issues.apache.org/jira/browse/CB-14133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zak updated CB-14133:
-
Description:
Relates to CB-13992
The pull request for CB-13992 removed the `dependency-ls` package which helped
to speed up the platform add step. However, each plugin still gets `npm
install`ed seemingly just to determine the package name.
Typical workflow is to run `npm install` as the first task after cloning a node
repository. The current practice for cordova is to save plugins to the
package.json meaning that plugins are already installed to the node_modules
directory, so running `npm install` for each of them individually is redundant.
If the main function in `cordova-fetch` is simplified to just return the path
to the given module (albeit this isn't the most elegant implementation):
```
module.exports = function (target, dest, opts = {}) {
var fetchArgs = opts.link ? ['link'] : ['list'];
var nodeModulesDir = dest + '/node_modules/';
// check if npm is installed
return module.exports.isNpmInstalled()
.then(function () {
const mod = target.slice(0, target.lastIndexOf('@'));
return path.resolve(nodeModulesDir, mod)
})
.catch(function (err) {
throw new CordovaError(err);
});
};
```
the platform add process runs almost instantly rather than taking a few minutes.
was:
Relates to CB-13992
The pull request for CB-13992 removed the `dependency-ls` package which helped
to speed up the platform add step. However, each plugin still gets `npm
install`ed seemingly just to determine the package name.
Typical workflow is to run `npm install` as the first task after cloning a node
repository. The current practice for cordova is to save plugins to the
package.json meaning that plugins are already installed to the node_modules
directory, so running `npm install` for each of them individually is redundant.
If the main function in `cordova-fetch` is simplified to just return the path
to the given module (albeit this isn't the most elegant implementation):
{{module.exports = function (target, dest, opts = {}) {
var fetchArgs = opts.link ? ['link'] : ['list'];
var nodeModulesDir = dest + '/node_modules/';
// check if npm is installed
return module.exports.isNpmInstalled()
.then(function () {
const mod = target.slice(0, target.lastIndexOf('@'));
return path.resolve(nodeModulesDir, mod)
})
.catch(function (err) {
throw new CordovaError(err);
});
};}}
the platform add process runs almost instantly rather than taking a few minutes.
> Avoid reinstalling already installed plugins in cordova-fetch
> -
>
> Key: CB-14133
> URL: https://issues.apache.org/jira/browse/CB-14133
> Project: Apache Cordova
> Issue Type: Wish
> Components: cordova-cli, cordova-fetch
>Affects Versions: 8.0.0
>Reporter: Zak
>Priority: Minor
>
> Relates to CB-13992
> The pull request for CB-13992 removed the `dependency-ls` package which
> helped to speed up the platform add step. However, each plugin still gets
> `npm install`ed seemingly just to determine the package name.
> Typical workflow is to run `npm install` as the first task after cloning a
> node repository. The current practice for cordova is to save plugins to the
> package.json meaning that plugins are already installed to the node_modules
> directory, so running `npm install` for each of them individually is
> redundant.
> If the main function in `cordova-fetch` is simplified to just return the path
> to the given module (albeit this isn't the most elegant implementation):
> ```
> module.exports = function (target, dest, opts = {}) {
> var fetchArgs = opts.link ? ['link'] : ['list'];
> var nodeModulesDir = dest + '/node_modules/';
> // check if npm is installed
> return module.exports.isNpmInstalled()
> .then(function () {
> const mod = target.slice(0, target.lastIndexOf('@'));
> return path.resolve(nodeModulesDir, mod)
> })
> .catch(function (err) {
> throw new CordovaError(err);
> });
> };
> ```
> the platform add process runs almost instantly rather than taking a few
> minutes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Updated] (CB-14133) Avoid reinstalling already installed plugins in cordova-fetch
[
https://issues.apache.org/jira/browse/CB-14133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zak updated CB-14133:
-
Description:
Relates to CB-13992
The pull request for CB-13992 removed the `dependency-ls` package which helped
to speed up the platform add step. However, each plugin still gets `npm
install`ed seemingly just to determine the package name.
Typical workflow is to run `npm install` as the first task after cloning a node
repository. The current practice for cordova is to save plugins to the
package.json meaning that plugins are already installed to the node_modules
directory, so running `npm install` for each of them individually is redundant.
If the main function in `cordova-fetch` is simplified to just return the path
to the given module (albeit this isn't the most elegant implementation):
{code:javascript}
module.exports = function (target, dest, opts = {}) {
var fetchArgs = opts.link ? ['link'] : ['list'];
var nodeModulesDir = dest + '/node_modules/';
// check if npm is installed
return module.exports.isNpmInstalled()
.then(function () {
const mod = target.slice(0, target.lastIndexOf('@'));
return path.resolve(nodeModulesDir, mod)
})
.catch(function (err) {
throw new CordovaError(err);
});
};
{code}
the platform add process runs almost instantly rather than taking a few minutes.
was:
Relates to CB-13992
The pull request for CB-13992 removed the `dependency-ls` package which helped
to speed up the platform add step. However, each plugin still gets `npm
install`ed seemingly just to determine the package name.
Typical workflow is to run `npm install` as the first task after cloning a node
repository. The current practice for cordova is to save plugins to the
package.json meaning that plugins are already installed to the node_modules
directory, so running `npm install` for each of them individually is redundant.
If the main function in `cordova-fetch` is simplified to just return the path
to the given module (albeit this isn't the most elegant implementation):
```
module.exports = function (target, dest, opts = {}) {
var fetchArgs = opts.link ? ['link'] : ['list'];
var nodeModulesDir = dest + '/node_modules/';
// check if npm is installed
return module.exports.isNpmInstalled()
.then(function () {
const mod = target.slice(0, target.lastIndexOf('@'));
return path.resolve(nodeModulesDir, mod)
})
.catch(function (err) {
throw new CordovaError(err);
});
};
```
the platform add process runs almost instantly rather than taking a few minutes.
> Avoid reinstalling already installed plugins in cordova-fetch
> -
>
> Key: CB-14133
> URL: https://issues.apache.org/jira/browse/CB-14133
> Project: Apache Cordova
> Issue Type: Wish
> Components: cordova-cli, cordova-fetch
>Affects Versions: 8.0.0
>Reporter: Zak
>Priority: Minor
>
> Relates to CB-13992
> The pull request for CB-13992 removed the `dependency-ls` package which
> helped to speed up the platform add step. However, each plugin still gets
> `npm install`ed seemingly just to determine the package name.
> Typical workflow is to run `npm install` as the first task after cloning a
> node repository. The current practice for cordova is to save plugins to the
> package.json meaning that plugins are already installed to the node_modules
> directory, so running `npm install` for each of them individually is
> redundant.
> If the main function in `cordova-fetch` is simplified to just return the path
> to the given module (albeit this isn't the most elegant implementation):
> {code:javascript}
> module.exports = function (target, dest, opts = {}) {
> var fetchArgs = opts.link ? ['link'] : ['list'];
> var nodeModulesDir = dest + '/node_modules/';
> // check if npm is installed
> return module.exports.isNpmInstalled()
> .then(function () {
> const mod = target.slice(0, target.lastIndexOf('@'));
> return path.resolve(nodeModulesDir, mod)
> })
> .catch(function (err) {
> throw new CordovaError(err);
> });
> };
> {code}
> the platform add process runs almost instantly rather than taking a few
> minutes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Updated] (CB-14133) Avoid reinstalling already installed plugins in cordova-fetch
[
https://issues.apache.org/jira/browse/CB-14133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zak updated CB-14133:
-
Description:
Relates to CB-13992
The pull request for CB-13992 removed the `dependency-ls` package which helped
to speed up the platform add step. However, each plugin still gets `npm
install`ed seemingly just to determine the package name.
Typical workflow is to run `npm install` as the first task after cloning a node
repository. The current practice for cordova is to save plugins to the
package.json meaning that plugins are already installed to the node_modules
directory, so running `npm install` for each of them individually is redundant.
If the main function in `cordova-fetch` is simplified to just return the path
to the given module (albeit this isn't the most elegant implementation):
{{module.exports = function (target, dest, opts = {}) {
var fetchArgs = opts.link ? ['link'] : ['list'];
var nodeModulesDir = dest + '/node_modules/';
// check if npm is installed
return module.exports.isNpmInstalled()
.then(function () {
const mod = target.slice(0, target.lastIndexOf('@'));
return path.resolve(nodeModulesDir, mod)
})
.catch(function (err) {
throw new CordovaError(err);
});
};}}
the platform add process runs almost instantly rather than taking a few minutes.
was:
Relates to CB-13992
The pull request for CB-13992 removed the `dependency-ls` package which helped
to speed up the platform add step. However, each plugin still gets `npm
install`ed seemingly just to determine the package name.
Typical workflow is to run `npm install` as the first task after cloning a node
repository. The current practice for cordova is to save plugins to the
package.json meaning that plugins are already installed to the node_modules
directory, so running `npm install` for each of them individually is redundant.
If the main function in `cordova-fetch` is simplified to just return the path
to the given module (albeit this isn't the most elegant implementation):
{{
module.exports = function (target, dest, opts = {}) {
var fetchArgs = opts.link ? ['link'] : ['list'];
var nodeModulesDir = dest + '/node_modules/';
// check if npm is installed
return module.exports.isNpmInstalled()
.then(function () {
const mod = target.slice(0, target.lastIndexOf('@'));
return path.resolve(nodeModulesDir, mod)
})
.catch(function (err) {
throw new CordovaError(err);
});
};
}}
the platform add process runs almost instantly rather than taking a few minutes.
> Avoid reinstalling already installed plugins in cordova-fetch
> -
>
> Key: CB-14133
> URL: https://issues.apache.org/jira/browse/CB-14133
> Project: Apache Cordova
> Issue Type: Wish
> Components: cordova-cli, cordova-fetch
>Affects Versions: 8.0.0
>Reporter: Zak
>Priority: Minor
>
> Relates to CB-13992
> The pull request for CB-13992 removed the `dependency-ls` package which
> helped to speed up the platform add step. However, each plugin still gets
> `npm install`ed seemingly just to determine the package name.
> Typical workflow is to run `npm install` as the first task after cloning a
> node repository. The current practice for cordova is to save plugins to the
> package.json meaning that plugins are already installed to the node_modules
> directory, so running `npm install` for each of them individually is
> redundant.
> If the main function in `cordova-fetch` is simplified to just return the path
> to the given module (albeit this isn't the most elegant implementation):
> {{module.exports = function (target, dest, opts = {}) {
> var fetchArgs = opts.link ? ['link'] : ['list'];
> var nodeModulesDir = dest + '/node_modules/';
> // check if npm is installed
> return module.exports.isNpmInstalled()
> .then(function () {
> const mod = target.slice(0, target.lastIndexOf('@'));
> return path.resolve(nodeModulesDir, mod)
> })
> .catch(function (err) {
> throw new CordovaError(err);
> });
> };}}
> the platform add process runs almost instantly rather than taking a few
> minutes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Updated] (CB-14133) Avoid reinstalling already installed plugins in cordova-fetch
[
https://issues.apache.org/jira/browse/CB-14133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zak updated CB-14133:
-
Description:
Relates to CB-13992
The pull request for CB-13992 removed the `dependency-ls` package which helped
to speed up the platform add step. However, each plugin still gets `npm
install`ed seemingly just to determine the package name.
Typical workflow is to run `npm install` as the first task after cloning a node
repository. The current practice for cordova is to save plugins to the
package.json meaning that plugins are already installed to the node_modules
directory, so running `npm install` for each of them individually is redundant.
If the main function in `cordova-fetch` is simplified to just return the path
to the given module (albeit this isn't the most elegant implementation):
```
module.exports = function (target, dest, opts = {}) {
var fetchArgs = opts.link ? ['link'] : ['list'];
var nodeModulesDir = dest + '/node_modules/';
// check if npm is installed
return module.exports.isNpmInstalled()
.then(function ()
{ const mod = target.slice(0, target.lastIndexOf('@')); return
path.resolve(nodeModulesDir, mod) }
)
.catch(function (err)
{ throw new CordovaError(err); }
);
};
```
the platform add process runs almost instantly rather than taking a few minutes.
was:
Relates to CB-13992
The pull request for CB-13992 removed the ```dependency-ls``` package which
helped to speed up the platform add step. However, each plugin still gets
```npm install```ed seemingly just to determine the package name.
Typical workflow is to run ```npm install``` as the first task after cloning a
node repository. The current practice for cordova is to save plugins to the
package.json meaning that plugins are already installed to the node_modules
directory, so running `npm install` for each of them individually is redundant.
If the main function in ```cordova-fetch``` is simplified to just return the
path to the given module (albeit this isn't the most elegant implementation):
```javascript
module.exports = function (target, dest, opts = {}) {
var fetchArgs = opts.link ? ['link'] : ['list'];
var nodeModulesDir = dest + '/node_modules/';
// check if npm is installed
return module.exports.isNpmInstalled()
.then(function () {
const mod = target.slice(0, target.lastIndexOf('@'));
return path.resolve(nodeModulesDir, mod)
})
.catch(function (err) {
throw new CordovaError(err);
});
};
```
the platform add process runs almost instantly rather than taking a few minutes.
> Avoid reinstalling already installed plugins in cordova-fetch
> -
>
> Key: CB-14133
> URL: https://issues.apache.org/jira/browse/CB-14133
> Project: Apache Cordova
> Issue Type: Wish
> Components: cordova-cli, cordova-fetch
>Affects Versions: 8.0.0
>Reporter: Zak
>Priority: Minor
>
> Relates to CB-13992
> The pull request for CB-13992 removed the `dependency-ls` package which
> helped to speed up the platform add step. However, each plugin still gets
> `npm install`ed seemingly just to determine the package name.
> Typical workflow is to run `npm install` as the first task after cloning a
> node repository. The current practice for cordova is to save plugins to the
> package.json meaning that plugins are already installed to the node_modules
> directory, so running `npm install` for each of them individually is
> redundant.
> If the main function in `cordova-fetch` is simplified to just return the path
> to the given module (albeit this isn't the most elegant implementation):
> ```
> module.exports = function (target, dest, opts = {}) {
> var fetchArgs = opts.link ? ['link'] : ['list'];
> var nodeModulesDir = dest + '/node_modules/';
> // check if npm is installed
> return module.exports.isNpmInstalled()
> .then(function ()
> { const mod = target.slice(0, target.lastIndexOf('@')); return
> path.resolve(nodeModulesDir, mod) }
> )
> .catch(function (err)
> { throw new CordovaError(err); }
> );
> };
> ```
> the platform add process runs almost instantly rather than taking a few
> minutes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Updated] (CB-14133) Avoid reinstalling already installed plugins in cordova-fetch
[
https://issues.apache.org/jira/browse/CB-14133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zak updated CB-14133:
-
Description:
Relates to CB-13992
The pull request for CB-13992 removed the {{dependency-ls}} package which
helped to speed up the platform add step. However, each plugin still gets {{npm
install}} ed seemingly just to determine the package name.
Typical workflow is to run {{npm install}} as the first task after cloning a
node repository. The current practice for cordova is to save plugins to the
package.json meaning that plugins are already installed to the node_modules
directory, so running {{npm install}} for each of them individually is
redundant.
If the main function in {{cordova-fetch}} is simplified to just return the path
to the given module (albeit this isn't the most elegant implementation):
{code:javascript}
module.exports = function (target, dest, opts = {}) {
var fetchArgs = opts.link ? ['link'] : ['list'];
var nodeModulesDir = dest + '/node_modules/';
// check if npm is installed
return module.exports.isNpmInstalled()
.then(function () {
const mod = target.slice(0, target.lastIndexOf('@'));
return path.resolve(nodeModulesDir, mod)
})
.catch(function (err) {
throw new CordovaError(err);
});
};
{code}
the platform add process runs almost instantly rather than taking a few minutes.
was:
Relates to CB-13992
The pull request for CB-13992 removed the `dependency-ls` package which helped
to speed up the platform add step. However, each plugin still gets `npm
install`ed seemingly just to determine the package name.
Typical workflow is to run `npm install` as the first task after cloning a node
repository. The current practice for cordova is to save plugins to the
package.json meaning that plugins are already installed to the node_modules
directory, so running `npm install` for each of them individually is redundant.
If the main function in `cordova-fetch` is simplified to just return the path
to the given module (albeit this isn't the most elegant implementation):
{code:javascript}
module.exports = function (target, dest, opts = {}) {
var fetchArgs = opts.link ? ['link'] : ['list'];
var nodeModulesDir = dest + '/node_modules/';
// check if npm is installed
return module.exports.isNpmInstalled()
.then(function () {
const mod = target.slice(0, target.lastIndexOf('@'));
return path.resolve(nodeModulesDir, mod)
})
.catch(function (err) {
throw new CordovaError(err);
});
};
{code}
the platform add process runs almost instantly rather than taking a few minutes.
> Avoid reinstalling already installed plugins in cordova-fetch
> -
>
> Key: CB-14133
> URL: https://issues.apache.org/jira/browse/CB-14133
> Project: Apache Cordova
> Issue Type: Wish
> Components: cordova-cli, cordova-fetch
>Affects Versions: 8.0.0
>Reporter: Zak
>Priority: Minor
>
> Relates to CB-13992
> The pull request for CB-13992 removed the {{dependency-ls}} package which
> helped to speed up the platform add step. However, each plugin still gets
> {{npm install}} ed seemingly just to determine the package name.
> Typical workflow is to run {{npm install}} as the first task after cloning a
> node repository. The current practice for cordova is to save plugins to the
> package.json meaning that plugins are already installed to the node_modules
> directory, so running {{npm install}} for each of them individually is
> redundant.
> If the main function in {{cordova-fetch}} is simplified to just return the
> path to the given module (albeit this isn't the most elegant implementation):
> {code:javascript}
> module.exports = function (target, dest, opts = {}) {
> var fetchArgs = opts.link ? ['link'] : ['list'];
> var nodeModulesDir = dest + '/node_modules/';
> // check if npm is installed
> return module.exports.isNpmInstalled()
> .then(function () {
> const mod = target.slice(0, target.lastIndexOf('@'));
> return path.resolve(nodeModulesDir, mod)
> })
> .catch(function (err) {
> throw new CordovaError(err);
> });
> };
> {code}
> the platform add process runs almost instantly rather than taking a few
> minutes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Updated] (CB-14133) Avoid reinstalling already installed plugins in cordova-fetch
[
https://issues.apache.org/jira/browse/CB-14133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zak updated CB-14133:
-
Description:
Relates to CB-13992
The pull request for CB-13992 removed the `dependency-ls` package which helped
to speed up the platform add step. However, each plugin still gets `npm
install`ed seemingly just to determine the package name.
Typical workflow is to run `npm install` as the first task after cloning a node
repository. The current practice for cordova is to save plugins to the
package.json meaning that plugins are already installed to the node_modules
directory, so running `npm install` for each of them individually is redundant.
If the main function in `cordova-fetch` is simplified to just return the path
to the given module (albeit this isn't the most elegant implementation):
{{
module.exports = function (target, dest, opts = {}) {
var fetchArgs = opts.link ? ['link'] : ['list'];
var nodeModulesDir = dest + '/node_modules/';
// check if npm is installed
return module.exports.isNpmInstalled()
.then(function () {
const mod = target.slice(0, target.lastIndexOf('@'));
return path.resolve(nodeModulesDir, mod)
})
.catch(function (err) {
throw new CordovaError(err);
});
};
}}
the platform add process runs almost instantly rather than taking a few minutes.
was:
Relates to CB-13992
The pull request for CB-13992 removed the `dependency-ls` package which helped
to speed up the platform add step. However, each plugin still gets `npm
install`ed seemingly just to determine the package name.
Typical workflow is to run `npm install` as the first task after cloning a node
repository. The current practice for cordova is to save plugins to the
package.json meaning that plugins are already installed to the node_modules
directory, so running `npm install` for each of them individually is redundant.
If the main function in `cordova-fetch` is simplified to just return the path
to the given module (albeit this isn't the most elegant implementation):
```
module.exports = function (target, dest, opts = {}) {
var fetchArgs = opts.link ? ['link'] : ['list'];
var nodeModulesDir = dest + '/node_modules/';
// check if npm is installed
return module.exports.isNpmInstalled()
.then(function ()
{ const mod = target.slice(0, target.lastIndexOf('@')); return
path.resolve(nodeModulesDir, mod) }
)
.catch(function (err)
{ throw new CordovaError(err); }
);
};
```
the platform add process runs almost instantly rather than taking a few minutes.
> Avoid reinstalling already installed plugins in cordova-fetch
> -
>
> Key: CB-14133
> URL: https://issues.apache.org/jira/browse/CB-14133
> Project: Apache Cordova
> Issue Type: Wish
> Components: cordova-cli, cordova-fetch
>Affects Versions: 8.0.0
>Reporter: Zak
>Priority: Minor
>
> Relates to CB-13992
> The pull request for CB-13992 removed the `dependency-ls` package which
> helped to speed up the platform add step. However, each plugin still gets
> `npm install`ed seemingly just to determine the package name.
> Typical workflow is to run `npm install` as the first task after cloning a
> node repository. The current practice for cordova is to save plugins to the
> package.json meaning that plugins are already installed to the node_modules
> directory, so running `npm install` for each of them individually is
> redundant.
> If the main function in `cordova-fetch` is simplified to just return the path
> to the given module (albeit this isn't the most elegant implementation):
> {{
> module.exports = function (target, dest, opts = {}) {
> var fetchArgs = opts.link ? ['link'] : ['list'];
> var nodeModulesDir = dest + '/node_modules/';
> // check if npm is installed
> return module.exports.isNpmInstalled()
> .then(function () {
> const mod = target.slice(0, target.lastIndexOf('@'));
> return path.resolve(nodeModulesDir, mod)
> })
> .catch(function (err) {
> throw new CordovaError(err);
> });
> };
> }}
> the platform add process runs almost instantly rather than taking a few
> minutes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Resolved] (CB-14125) Increase cordova-android old plugin compatibility
[ https://issues.apache.org/jira/browse/CB-14125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] jcesarmobile resolved CB-14125. --- Resolution: Fixed Fixed in 7.2.0-dev > Increase cordova-android old plugin compatibility > - > > Key: CB-14125 > URL: https://issues.apache.org/jira/browse/CB-14125 > Project: Apache Cordova > Issue Type: Improvement >Reporter: jcesarmobile >Assignee: jcesarmobile >Priority: Major > > With the structure change of cordova-android 7.1.0, a lot of plugins don't > work because they user source-file tag for images or other file types. > Right now, we only patch to the new path structure .java and .xml files. > Add 'app/src/main' to all file types, no mater what type they have. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-14125) Increase cordova-android old plugin compatibility
[ https://issues.apache.org/jira/browse/CB-14125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16511661#comment-16511661 ] ASF GitHub Bot commented on CB-14125: - jcesarmobile commented on issue #449: CB-14125:(android) Increase old plugin compatibility URL: https://github.com/apache/cordova-android/pull/449#issuecomment-397085517 Agree, but we should start by updating core plugins and docs This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Increase cordova-android old plugin compatibility > - > > Key: CB-14125 > URL: https://issues.apache.org/jira/browse/CB-14125 > Project: Apache Cordova > Issue Type: Improvement >Reporter: jcesarmobile >Assignee: jcesarmobile >Priority: Major > > With the structure change of cordova-android 7.1.0, a lot of plugins don't > work because they user source-file tag for images or other file types. > Right now, we only patch to the new path structure .java and .xml files. > Add 'app/src/main' to all file types, no mater what type they have. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-14125) Increase cordova-android old plugin compatibility
[
https://issues.apache.org/jira/browse/CB-14125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16511659#comment-16511659
]
ASF GitHub Bot commented on CB-14125:
-
jcesarmobile closed pull request #449: CB-14125:(android) Increase old plugin
compatibility
URL: https://github.com/apache/cordova-android/pull/449
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git a/bin/templates/cordova/lib/pluginHandlers.js
b/bin/templates/cordova/lib/pluginHandlers.js
index f57c28379..e6d7ffdfb 100644
--- a/bin/templates/cordova/lib/pluginHandlers.js
+++ b/bin/templates/cordova/lib/pluginHandlers.js
@@ -320,8 +320,8 @@ function studioPathRemap (obj) {
if (!obj.targetDir.includes('app/src/main')) {
if (obj.src.endsWith('.java')) {
return path.join('app/src/main/java', obj.targetDir.substring(4),
path.basename(obj.src));
-} else if (obj.src.endsWith('.xml')) {
-// We are making a huge assumption here that XML files will be
going to res/xml or values/xml
+} else {
+// For all other files, add 'app/src/main' to the targetDir if it
didn't have it already
return path.join('app/src/main', obj.targetDir,
path.basename(obj.src));
}
}
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Increase cordova-android old plugin compatibility
> -
>
> Key: CB-14125
> URL: https://issues.apache.org/jira/browse/CB-14125
> Project: Apache Cordova
> Issue Type: Improvement
>Reporter: jcesarmobile
>Assignee: jcesarmobile
>Priority: Major
>
> With the structure change of cordova-android 7.1.0, a lot of plugins don't
> work because they user source-file tag for images or other file types.
> Right now, we only patch to the new path structure .java and .xml files.
> Add 'app/src/main' to all file types, no mater what type they have.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Resolved] (CB-13540) cordova-fetch npm install --production clobbers node_modules, causes workflow issues
[
https://issues.apache.org/jira/browse/CB-13540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Raphael resolved CB-13540.
--
Resolution: Won't Fix
Cordova currently uses and supports npm only. Right now, we cannot afford the
additional complexity of maintaining support for multiple package managers.
Also, npm improved a lot since the initial release of yarn, so you might want
to take another look at it.
> cordova-fetch npm install --production clobbers node_modules, causes workflow
> issues
>
>
> Key: CB-13540
> URL: https://issues.apache.org/jira/browse/CB-13540
> Project: Apache Cordova
> Issue Type: Bug
> Components: cordova-fetch
>Reporter: Alex Matchneer
>Priority: Minor
> Labels: fetch, node_modules, npm
>
> I have tried and failed to provide a reproduction of this issue and have
> hence written/deleted/rewritten this issue many times without submitting, but
> now I'm going to just submit it, hope for feedback, and continue to try and
> reproduce:
> Basically, since this issue (https://issues.apache.org/jira/browse/CB-13303),
> cordova-fetch uses the `--production` flag with `npm install`, which tells
> npm not to install any "devDependencies".
> This seems like a sound approach, but for reasons that I can't reliably
> reproduced/put my finger on, it seems like this flag is also aggressively
> removing packages from `node_modules`, causing the following workflow issues:
> In my cordova project, I've added `cordova` as a dependency to package.json
> and encourage my teammates to use `./node_modules/.bin/cordova` rather than
> some globally installed `cordova` executable so that all dependencies are
> locked down and we don't have to fight the dependency hell of global CLI
> dependencies + local package.json dependencies.
> Now, when I freshly clone a repo, do an npm install, and then run
> `./node_modules/.bin/cordova prepare`, it will non-deterministically fail
> with the following output:
> {code}
> Discovered platform "ios@^4.5.3" in config.xml or package.json. Adding it to
> the project
> Using cordova-fetch for cordova-ios@^4.5.3
> Error: Failed to fetch platform cordova-ios@^4.5.3
> Probably this is either a connection problem, or platform spec is incorrect.
> Check your connection and platform name/version/URL.
> Failed to get absolute path to installed module
> Error: No platforms added to this project. Please use `cordova platform add
> `.
> {code}
> And when I look at node_modules, most of my dependencies have been deleted,
> and in particular, there's no more `node_modules/.bin/cordova` executable.
> My best guess is that the `npm install --production --no-save` that
> cordova-fetch internally does is nuking a bunch of dependencies considering
> "non-production", including the cli folder itself. The remedy is to use a
> globally installed cordova CLI executable, which somehow avoids these issues.
> Both my local and global cordova executables are 7.7.4.
> I will continue to try and provide a consistent reproduction of this issue;
> I've tried and failed many times and I'm starting to pull my hair out. I just
> wanted to officially post this issue in case other people have seen it, have
> advice, or have had better luck reproducing.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Comment Edited] (CB-11144) Make Git fetches faster for plugin, platforms, and templates by using --depth 1
[ https://issues.apache.org/jira/browse/CB-11144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16511417#comment-16511417 ] Raphael edited comment on CB-11144 at 6/13/18 4:47 PM: --- As of now, we do not use git in cordova-fetch but rather pass any specs directly to npm untouched. Moving on, we hope to do less dependency management ourselves, so I do not see any optimization happening from our part here. npm uses pacote to fetch its packages. As you can see from looking at [the code for fetching a git repo|https://github.com/zkat/pacote/blob/ccc6e9094c2e872f09cc12ae966a0cbc1a570eed/lib/fetchers/git.js#L165], it already does shallow cloning, but only for git hoster known to support it. A sensible decision IMHO, although a way to add hosts to the white list would be nice for private servers. was (Author: raphinesse): As of now, we do not use git in cordova-fetch but rather pass any specs directly to npm untouched. Moving on, we hope to do less dependency management ourselves, so I do not see any optimization happening from our part here. npm uses pacote to fetch its packages. As you can see from looking at [the code for fetching a git repo|https://github.com/zkat/pacote/blob/ccc6e9094c2e872f09cc12ae966a0cbc1a570eed/lib/fetchers/git.js#L165], this is already done, but only for git hoster known to support it. > Make Git fetches faster for plugin, platforms, and templates by using --depth > 1 > --- > > Key: CB-11144 > URL: https://issues.apache.org/jira/browse/CB-11144 > Project: Apache Cordova > Issue Type: Improvement > Components: cordova-fetch >Reporter: Carlos Santana >Assignee: Carlos Santana >Priority: Major > Labels: backlog > > Some users are complaining that some plugin git repos are too big, and the > plugin is not available thru npm > So people installing the plugin it can take up to 20 minutes to install a > plugin because Cordova CLI it's doing a full git clone of the repo. > I was wondering if the flag --depth 1 would make it faster by fetching just > the last copy of the repo on the specified git hash, hash can be branch, or > tag, or commit hash > Going to ask to the mailing list to see of using --depth 1 is a good and safe > change? -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Resolved] (CB-11144) Make Git fetches faster for plugin, platforms, and templates by using --depth 1
[ https://issues.apache.org/jira/browse/CB-11144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raphael resolved CB-11144. -- Resolution: Won't Fix As of now, we do not use git in cordova-fetch but rather pass any specs directly to npm untouched. Moving on, we hope to do less dependency management ourselves, so I do not see any optimization happening from our part here. npm uses pacote to fetch its packages. As you can see from looking at [the code for fetching a git repo|https://github.com/zkat/pacote/blob/ccc6e9094c2e872f09cc12ae966a0cbc1a570eed/lib/fetchers/git.js#L165], this is already done, but only for git hoster known to support it. > Make Git fetches faster for plugin, platforms, and templates by using --depth > 1 > --- > > Key: CB-11144 > URL: https://issues.apache.org/jira/browse/CB-11144 > Project: Apache Cordova > Issue Type: Improvement > Components: cordova-fetch >Reporter: Carlos Santana >Assignee: Carlos Santana >Priority: Major > Labels: backlog > > Some users are complaining that some plugin git repos are too big, and the > plugin is not available thru npm > So people installing the plugin it can take up to 20 minutes to install a > plugin because Cordova CLI it's doing a full git clone of the repo. > I was wondering if the flag --depth 1 would make it faster by fetching just > the last copy of the repo on the specified git hash, hash can be branch, or > tag, or commit hash > Going to ask to the mailing list to see of using --depth 1 is a good and safe > change? -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-14114) InAppBrowser - Problem in ios 11.3.1
[
https://issues.apache.org/jira/browse/CB-14114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16511395#comment-16511395
]
Nishanth commented on CB-14114:
---
I've exactly the same problem with SAML on ADFS.
The same error happens on ionic 1 App, ionic 2 app and also react native App
with upgrade to 11.3 and above.
One interesting thing is that the when the message 'http *service 1.1.
unavailable'* is shown in the screen, if you click the back button on the
inappbrowser it lets you login to the system
If you have users not able to login to the app,
I've a very hacky solution in place for now.
$rootScope.$on('$cordovaInAppBrowser:loadstop', function(e, event) {
if (event.url.indexOf('desired borwser url') > -1) { // hack solution to
support login on ios which breaks > ios11.3
$cordovaInAppBrowser.executeScript({
code: "document.getElementsByTagName('html')[0].innerHTML"
}).then(function(html) {
if (JSON.stringify(html).match(/1.1 Service Unavailable/i)) {
$cordovaInAppBrowser.executeScript({
code: "window.history.back()"
})
}
});
> InAppBrowser - Problem in ios 11.3.1
>
>
> Key: CB-14114
> URL: https://issues.apache.org/jira/browse/CB-14114
> Project: Apache Cordova
> Issue Type: Bug
>Affects Versions: 3.0.0
> Environment: iphone 5s, ios 11.3.1
> iphone 7+ ios 11.3.1
>
>Reporter: Nishanth
>Priority: Major
>
> Strange behaviour after the upgrade from 11.2 to 11.3 The user is not able to
> login to the identity provider using InAppBrowser. The server rejects the
> request and throws a 'http *service 1.1. unavailable'* after the user submits
> username and password
>
> I was hoping that it was an ios bug but I am able to login with wkwebview
> browser
> [https://github.com/dpa99c/cordova-plugin-inappbrowser-wkwebview]
> The usage of WKWebview browser was to just confirm the issue.
> Any help on this would be much appreciated.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Resolved] (CB-13797) Fetch failing to install plugin dependencies
[
https://issues.apache.org/jira/browse/CB-13797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Raphael resolved CB-13797.
--
Resolution: Fixed
Rejoice! For this works for me in cordova@8.0.1-nightly.2018.6.13.f567c26f :D
> Fetch failing to install plugin dependencies
>
>
> Key: CB-13797
> URL: https://issues.apache.org/jira/browse/CB-13797
> Project: Apache Cordova
> Issue Type: Bug
> Components: cordova-fetch
> Environment: cordova@8.0.0
> cordova-common@2.2.1
> cordova-lib@8.0.0
> cordova-fetch@1.3.0
> npm@5.6.0
> node@9.4.0
>
>Reporter: Darryl Pogue
>Assignee: Steve Gill
>Priority: Critical
>
> I'm currently unable to install Microsoft's cordova-plugin-code-push due to
> some incredibly confusing errors when installing the plugin dependencies.
> The plugin [lists 3
> dependencies|https://github.com/Microsoft/cordova-plugin-code-push/blob/e828a5eacd42dcd81bacf121a3e62735c3500227/plugin.xml#L10-L12]
> in plugin.xml.
> Cordova successfully installs the first (code-push) dependency.
> Cordova attempts to install the second (cordova-plugin-device) dependency. It
> appears that the npm install is successful.
> At the end of the npm install, cordova-fetch [attempts to
> discover|https://github.com/apache/cordova-fetch/blob/master/index.js#L100]
> what was just installed. Rather than finding "cordova-plugin-device", it
> finds "code-push" for a second time.
> Then it fails with the following confusing error message:
> {noformat}
> Failed to install 'cordova-plugin-code-push': Error: Expected plugin to have
> ID "cordova-plugin-dialogs" but got "code-push".{noformat}
> The full verbose output from {{cordova prepare}} is below:
> {noformat}
> Discovered plugin "cordova-plugin-code-push" in config.xml. Adding it to the
> project
> No scripts found for hook "before_plugin_add".
> Calling plugman.fetch on plugin "cordova-plugin-code-push@^1.11.2"
> Running command: npm install cordova-plugin-code-push@^1.11.2 --production
> --no-save
> Command finished with error code 0: npm
> install,cordova-plugin-code-push@^1.11.2,--production,--no-save
> Copying plugin "/PROJECT/node_modules/cordova-plugin-code-push" =>
> "/PROJECT/plugins/cordova-plugin-code-push"
> Calling plugman.install on plugin "/PROJECT/plugins/cordova-plugin-code-push"
> for platform "android
> Installing "cordova-plugin-code-push" for android
> Running command: /PROJECT/platforms/android/cordova/version
> Command finished with error code 0:
> /PROJECT/platforms/android/cordova/version
> Dependencies detected, iterating through them...
> Requesting plugin "code-push@2.0.4".
> Plugin dependency "code-push" not fetched, retrieving then installing.
> Running command: npm install code-push@2.0.4 --production --no-save
> Command finished with error code 0: npm
> install,code-push@2.0.4,--production,--no-save
> Copying plugin "/PROJECT/node_modules/code-push" =>
> "/PROJECT/plugins/code-push"
> Installing "code-push" for android
> Finding scripts for "before_plugin_install" hook from plugin code-push on
> android platform only.
> No scripts found for hook "before_plugin_install".
> Install start for "code-push" on android.
> Beginning processing of action stack for android project...
> Action stack processing complete.
> Install complete for code-push on android.
> Finding scripts for "after_plugin_install" hook from plugin code-push on
> android platform only.
> No scripts found for hook "after_plugin_install".
> Requesting plugin "cordova-plugin-dialogs@>=1.1.1".
> Plugin dependency "cordova-plugin-dialogs" not fetched, retrieving then
> installing.
> Running command: npm install cordova-plugin-dialogs@>=1.1.1 --production
> --no-save
> Command finished with error code 0: npm
> install,cordova-plugin-dialogs@>=1.1.1,--production,--no-save
> Copying plugin "/PROJECT/node_modules/code-push" =>
> "/PROJECT/plugins/code-push"
> Failed to install 'cordova-plugin-code-push': Error: Expected plugin to have
> ID "cordova-plugin-dialogs" but got "code-push".
> at checkID (/PROJECT/node_modules/cordova-lib/src/plugman/fetch.js:215:15)
> at /PROJECT/node_modules/cordova-lib/src/plugman/fetch.js:199:9
> at _fulfilled (/PROJECT/node_modules/cordova-lib/node_modules/q/q.js:787:54)
> at self.promiseDispatch.done
> (/PROJECT/node_modules/cordova-lib/node_modules/q/q.js:816:30)
> at Promise.promise.promiseDispatch
> (/PROJECT/node_modules/cordova-lib/node_modules/q/q.js:749:13)
> at /PROJECT/node_modules/cordova-lib/node_modules/q/q.js:557:44
> at flush (/PROJECT/node_modules/cordova-lib/node_modules/q/q.js:108:17)
> at process._tickCallback (internal/process/next_tick.js:150:11)
> Failed to restore plugin "cordova-plugin-code-push" from config.xml. You
> might need to try adding it again. Error: Error: Expected plugin to have ID
> "co
[jira] [Comment Edited] (CB-13503) Problems with using plugins from local file system
[
https://issues.apache.org/jira/browse/CB-13503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16510462#comment-16510462
]
Raphael edited comment on CB-13503 at 6/13/18 3:53 PM:
---
Resolved by [https://github.com/apache/cordova-fetch/pull/18]
You can test this using cordova@8.0.1-nightly.2018.6.13.f567c26f
was (Author: raphinesse):
Resolved by https://github.com/apache/cordova-fetch/pull/18
> Problems with using plugins from local file system
> --
>
> Key: CB-13503
> URL: https://issues.apache.org/jira/browse/CB-13503
> Project: Apache Cordova
> Issue Type: Bug
> Components: cordova-fetch, cordova-lib
>Affects Versions: cordova@7.1.0
>Reporter: Mark Veenstra
>Priority: Blocker
>
> I am struggling to get up and running with {{cordova@7.1.0}} sometime now.
> Maybe I am doing something wrong here but I can't figure it out. It seems to
> me something is going wrong with locally defined plugins that needs to be
> installed and the way it is saved into {{package.json}}.
> So to get upgraded I first installed the latest version {{npm install -g
> cordova@7.1.0}}. Then I did a {{cordova prepare}}.
> This {{prepare}} failed, after [some digging and
> trying|https://github.com/dpa99c/cordova-diagnostic-plugin/issues/245] it
> seemed that some locally plugins that needs to be installed into the project
> are interrupting other plugins. So I needed to disable the {{cordova-fetch}}.
> I set this globally with {{cordova config set fetch false}}.
> After this config change the {{codova prepare}} command went all fine. So I
> thought this is it.
> But when I tried to let my project be build by my CI server it failed on
> installating NPM packages.
> Because a {{npm install}} command will install the dependencies defined in
> {{package.json}} it will install the cordova plugins also. But in the
> beginning my plugins are in there like this:
> {code}
> {
> "name": "myApp",
> "version": "1.0.0",
> "description": "myApp description",
> "dependencies": {
> "cordova-android": "6.3.0",
> "cordova-browser": "5.0.1",
> "cordova-ios": "4.5.2",
> "cordova-plugin-myplugin": "resources/cordova-plugin-myplugin",
> "cordova-plugin-myplugin-locker":
> "resources/cordova-plugin-myplugin-locker"
> },
> "devDependencies": {
> },
> "scripts": {
> },
> "cordova": {
> "platforms": [
> "browser",
> "android",
> "ios"
> ],
> "plugins": {
> "cordova-plugin-myplugin": {},
> "cordova-plugin-myplugin-locker": {}
> }
> }
> }
> {code}
> With above {{npm install}} fails and tries to get the dependecies from git,
> which is incorrect. So I search the {{package.json}} definition and they say
> I should put {{file:}} in front of it, like this:
> {code}
> {
> "name": "myApp",
> "version": "1.0.0",
> "description": "myApp description",
> "dependencies": {
> "cordova-android": "6.3.0",
> "cordova-browser": "5.0.1",
> "cordova-ios": "4.5.2",
> "cordova-plugin-myplugin": "file:resources/cordova-plugin-myplugin",
> "cordova-plugin-myplugin-locker":
> "file:resources/cordova-plugin-myplugin-locker"
> },
> "devDependencies": {
> },
> "scripts": {
> },
> "cordova": {
> "platforms": [
> "browser",
> "android",
> "ios"
> ],
> "plugins": {
> "cordova-plugin-myplugin": {},
> "cordova-plugin-myplugin-locker": {}
> }
> }
> }
> {code}
> Now NPM finds the dependecies OK, but now when I do a {{cordova prepare}}
> again it throws an error that the plugin can't be installed from
> {{file:resources/cordova-plugin-myplugin}}.
> So I get stuck into different needs for different tools. Any ideas?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Comment Edited] (CB-13507) git+https or git+ssh fails when trying to install
[
https://issues.apache.org/jira/browse/CB-13507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16510424#comment-16510424
]
Raphael edited comment on CB-13507 at 6/13/18 3:52 PM:
---
Could not reproduce with Cordova 8 and npm 6. The following two tests worked
without problems:
{code:java}
cordova create example && cd example
cordova plugin add https://github.com/apache/cordova-plugin-whitelist.git
cordova platform add android
{code}
{code:java}
cordova create example && cd example
cordova plugin add git+ssh://g...@github.com:apache/cordova-plugin-whitelist.git
cordova platform add android
{code}
If the issue still persists for you in v8, please also test using
cordova@8.0.1-nightly.2018.6.13.f567c26f
If it persists even then, let me know and kindly include instructions to
reproduce it.
was (Author: raphinesse):
Could not reproduce with Cordova 8 and npm 6. The following two tests worked
without problems:
{code:java}
cordova create example && cd example
cordova plugin add https://github.com/apache/cordova-plugin-whitelist.git
cordova platform add android
{code}
{code:java}
cordova create example && cd example
cordova plugin add git+ssh://g...@github.com:apache/cordova-plugin-whitelist.git
cordova platform add android
{code}
If the issue still persists for you, please let me know and kindly include
instructions to reproduce it.
> git+https or git+ssh fails when trying to install
> -
>
> Key: CB-13507
> URL: https://issues.apache.org/jira/browse/CB-13507
> Project: Apache Cordova
> Issue Type: Bug
> Components: cordova-fetch, cordova-lib
>Affects Versions: 7.0.2
> Environment: I am selecting 7.0.2 since it's the closest but I am
> running cordova 7.1.0
> OS: Mac OS X Sierra.
> Although I don't think it has anything to do with cordova-ios and
> cordova-android, my platform versions are:
> - android 6.3.0
> - ios 4.5.2
>Reporter: Pablo Caselas
>Priority: Major
> Fix For: 8.0.0
>
>
> I start with adding plugin dependencies with https://.. on package.json
> (no plugin references on config.xml) and no platforms or plugins installed
> then I run "cordova platform ios".
> It installs the plugins without any problem, but changes config.xml and
> package.json plugin references from https to git+https, and ssh to git+ssh.
> Failed to restore plugin "cordova-plugin-document-viewer" from config.xml.
> You might need to try adding it again. Error: Failed to fetch plugin
> git+https://github.com/kas84/cordova-plugin-document-viewer.git via registry
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Comment Edited] (CB-13589) Cordova fetch updates too aggressively and breaks itself
[
https://issues.apache.org/jira/browse/CB-13589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16510458#comment-16510458
]
Raphael edited comment on CB-13589 at 6/13/18 3:50 PM:
---
Resolved by [https://github.com/apache/cordova-fetch/pull/18]
You can test this using cordova@8.0.1-nightly.2018.6.13.f567c26f
was (Author: raphinesse):
Resolved by [https://github.com/apache/cordova-fetch/pull/18]
You can test this [using
cordova@8.0.1-nightly.2018.6.13.f567c26f|mailto:using%C2%A0cordova@8.0.1-nightly.2018.6.13.f567c26f]
> Cordova fetch updates too aggressively and breaks itself
>
>
> Key: CB-13589
> URL: https://issues.apache.org/jira/browse/CB-13589
> Project: Apache Cordova
> Issue Type: Bug
> Components: cordova-fetch
>Reporter: Andrew Crites
>Priority: Blocker
>
> Related: CB-11252 CB-12262 -- these issues say they are fixed, but I can
> still reproduce them.
> Running {{cordova platform add}} with plugins directly from github or a file
> system path will update {{package.json}} in a way that subsequently breaks
> the plugin installation. To get around this, you must currently use {{cordova
> platform add $PLATFORM --nofetch}}.
> For example:
> {code}
> spec="https://github.com/pushandplay/cordova-plugin-apprate#0cc8b3b424491d35b1e571a69b21d2ae7cb9cff9";
> />
> spec="./src/local-plugins/phonegap-plugin-push">
>
>
> {code}
> On an initial {{cordova platform add}} this will work fine. However, this
> updates {{package.json}} to add these plugins as dependencies:
> {code}
> +"cordova-plugin-apprate":
> "git+https://github.com/pushandplay/cordova-plugin-apprate.git#0cc8b3b424491d35b1e571a69b21d2ae7cb9cff9";,
> +"phonegap-plugin-push": "file:src/local-plugins/phonegap-plugin-push",
> {code}
> Now try:
> {code}
> rm -rf node_modules platforms plugins
> npx npm@5.4.2 install
> npx cordova@7.1.0 platform add ios
> {code}
> for example. Plugin installation will be unsuccessful:
> {code}
> Failed to restore plugin "phonegap-plugin-push" from config.xml. You might
> need to try adding it again. Error: Failed to fetch plugin
> file:src/local-plugins/phonegap-plugin-push via registry.
> Failed to restore plugin "cordova-plugin-apprate" from config.xml. You might
> need to try adding it again. Error: Failed to fetch plugin
> git+https://github.com/pushandplay/cordova-plugin-apprate.git#0cc8b3b424491d35b1e571a69b21d2ae7cb9cff9
> via registry.
> {code}
> Manually removing the {{package.json}} update ({{\--nosave}} is broken
> CB-13463) or using {{\--nofetch}} will work.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Comment Edited] (CB-13992) Remove dependency-ls or provide option to skip npm checks
[
https://issues.apache.org/jira/browse/CB-13992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16510439#comment-16510439
]
Raphael edited comment on CB-13992 at 6/13/18 3:49 PM:
---
[https://github.com/apache/cordova-fetch/pull/18] removes the calls to depls
You can test this using cordova@8.0.1-nightly.2018.6.13.f567c26f
was (Author: raphinesse):
[https://github.com/apache/cordova-fetch/pull/18] removes the calls to depls
> Remove dependency-ls or provide option to skip npm checks
> -
>
> Key: CB-13992
> URL: https://issues.apache.org/jira/browse/CB-13992
> Project: Apache Cordova
> Issue Type: Wish
> Components: cordova-cli, cordova-fetch
>Affects Versions: 8.0.0
>Reporter: Zak
>Priority: Minor
> Labels: performance
>
> I noticed that our CI builds of cordova projects are very slow when adding
> the platforms - the stage where plugins are added taks a few minutes for each
> build. I did some digging around and profiling and eventually found that the
> slowest part is where `cordova-fetch` uses the `dependency-ls` module to list
> all installed dependencies of the project before and after installing each
> plugin.
> This dependency runs `npm list --depth=0` under the hood which is slow (~5
> seconds per run on a relatively small Ionic project). You can test this by
> running this small script:
> {{var depls = require('dependency-ls')}}
> {{return depls(process.cwd())}}
> {{.then(function(result) {}}
> {{ console.log(result)}}
> {{})}}
> Note also that the dependency runs twice for each plugin in the project
> adding 10 seconds per plugin. This means it can take a few minutes just to
> add a platform to the project - although this is much slower in CI/Docker
> build environments.
> However, this step seems pretty redundant since the plugins are likely
> already installed via npm since they are now saved in the package.json file.
> I made a fork of cordova-fetch which removes this step completely and just
> uses the existing plugins in `node_modules` and the time to add platform
> drops down to ~7 seconds (down from minutes) with no change to the actual
> result since the plugins are already there.
> https://github.com/NextFaze/cordova-fetch/tree/fix/speed
> Since plugins now install via npm and save to package.json by default it
> would be nice to at least provide the option to skip this npm step for
> plugins for cases where they already exist in node modules, if it can't be
> removed completely.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Comment Edited] (CB-13589) Cordova fetch updates too aggressively and breaks itself
[
https://issues.apache.org/jira/browse/CB-13589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16510458#comment-16510458
]
Raphael edited comment on CB-13589 at 6/13/18 3:49 PM:
---
Resolved by [https://github.com/apache/cordova-fetch/pull/18]
You can test this [using
cordova@8.0.1-nightly.2018.6.13.f567c26f|mailto:using%C2%A0cordova@8.0.1-nightly.2018.6.13.f567c26f]
was (Author: raphinesse):
Resolved by https://github.com/apache/cordova-fetch/pull/18
> Cordova fetch updates too aggressively and breaks itself
>
>
> Key: CB-13589
> URL: https://issues.apache.org/jira/browse/CB-13589
> Project: Apache Cordova
> Issue Type: Bug
> Components: cordova-fetch
>Reporter: Andrew Crites
>Priority: Blocker
>
> Related: CB-11252 CB-12262 -- these issues say they are fixed, but I can
> still reproduce them.
> Running {{cordova platform add}} with plugins directly from github or a file
> system path will update {{package.json}} in a way that subsequently breaks
> the plugin installation. To get around this, you must currently use {{cordova
> platform add $PLATFORM --nofetch}}.
> For example:
> {code}
> spec="https://github.com/pushandplay/cordova-plugin-apprate#0cc8b3b424491d35b1e571a69b21d2ae7cb9cff9";
> />
> spec="./src/local-plugins/phonegap-plugin-push">
>
>
> {code}
> On an initial {{cordova platform add}} this will work fine. However, this
> updates {{package.json}} to add these plugins as dependencies:
> {code}
> +"cordova-plugin-apprate":
> "git+https://github.com/pushandplay/cordova-plugin-apprate.git#0cc8b3b424491d35b1e571a69b21d2ae7cb9cff9";,
> +"phonegap-plugin-push": "file:src/local-plugins/phonegap-plugin-push",
> {code}
> Now try:
> {code}
> rm -rf node_modules platforms plugins
> npx npm@5.4.2 install
> npx cordova@7.1.0 platform add ios
> {code}
> for example. Plugin installation will be unsuccessful:
> {code}
> Failed to restore plugin "phonegap-plugin-push" from config.xml. You might
> need to try adding it again. Error: Failed to fetch plugin
> file:src/local-plugins/phonegap-plugin-push via registry.
> Failed to restore plugin "cordova-plugin-apprate" from config.xml. You might
> need to try adding it again. Error: Failed to fetch plugin
> git+https://github.com/pushandplay/cordova-plugin-apprate.git#0cc8b3b424491d35b1e571a69b21d2ae7cb9cff9
> via registry.
> {code}
> Manually removing the {{package.json}} update ({{\--nosave}} is broken
> CB-13463) or using {{\--nofetch}} will work.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Comment Edited] (CB-13768) cordova-fetch is unable to install from url or file system using package.json
[
https://issues.apache.org/jira/browse/CB-13768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16510468#comment-16510468
]
Raphael edited comment on CB-13768 at 6/13/18 3:48 PM:
---
Resolved by [https://github.com/apache/cordova-fetch/pull/18]
You can test this using cordova@8.0.1-nightly.2018.6.13.f567c26f
was (Author: raphinesse):
Resolved by https://github.com/apache/cordova-fetch/pull/18
> cordova-fetch is unable to install from url or file system using package.json
> -
>
> Key: CB-13768
> URL: https://issues.apache.org/jira/browse/CB-13768
> Project: Apache Cordova
> Issue Type: Bug
> Components: cordova-fetch
>Reporter: Andrew Crites
>Priority: Critical
>
> This is a big issue in cordova@8 since you can't opt out of cordova-fetch.
> Using a url such as `github.com` or the file system for a plugin doesn't work
> with package.json. It still works using config.xml:
> {code}
> spec="https://github.com/user/cordova-plugin-repo#specific-branch"; />
>
> {code}
> This works when running {{cordova platform add}}. However, if you do not use
> {{--nosave}} this will update package.json dependencies:
> {code}
> "cordova-plugin-repo":
> "git+https://github.com/user/cordova-plugin-repo#branch";,
> "local-plugin": "file:src/local-plugin",
> {code}
> If you try to install with package.json like this, you'll get errors for
> these packages:
> {code}
> Failed to restore plugin "cordova-plugin-repo" from config.xml. You might
> need to try adding it again. Error: Failed to fetch plugin
> https://github.com/user/cordova-plugin-repo#branch via registry.
> Probably this is either a connection problem, or plugin spec is incorrect.
>
>Check your connection and plugin
> name/version/URL.
> TypeError [ERR_INVALID_ARG_TYPE]: The "url" argument must be of type string.
> Received type undefined
> Discovered plugin "local-plugin" in config.xml. Adding it to the project
> Failed to restore plugin "local-plugin" from config.xml. You might need to
> try adding it again. Error: Failed to fetch plugin file:src/local-plugin via
> registry.
> Probably this is either a connection problem, or plugin spec is incorrect.
> Check your connection and plugin name/version/URL.
>
>Failed to get absolute path to installed
> module
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Resolved] (CB-14072) Remove Node 4 from CI - cordova-android
[ https://issues.apache.org/jira/browse/CB-14072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raphael resolved CB-14072. -- Resolution: Fixed > Remove Node 4 from CI - cordova-android > --- > > Key: CB-14072 > URL: https://issues.apache.org/jira/browse/CB-14072 > Project: Apache Cordova > Issue Type: Sub-task > Components: cordova-android >Reporter: Darryl Pogue >Assignee: Darryl Pogue >Priority: Minor > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-12074) Cookies are ignored on first application execution
[ https://issues.apache.org/jira/browse/CB-12074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16511022#comment-16511022 ] imran khan commented on CB-12074: - with the help of different people, I fixed the problem. here is the cordova plugin that might help someone else too: https://github.com/imransilvake/Cordova-Plugin-Sync-Cookies > Cookies are ignored on first application execution > -- > > Key: CB-12074 > URL: https://issues.apache.org/jira/browse/CB-12074 > Project: Apache Cordova > Issue Type: Bug > Components: cordova-plugin-wkwebview-engine > Environment: Cordova 5.4.0, iOS 9.3.5 >Reporter: Maxim >Assignee: Shazron Abdullah >Priority: Major > Labels: wkwebview-known-issues > > Our application authenticates to the server. The server sets a 'JSESSIONID' > cookie. The cookie is used by the server for session management. > The issue is WKWebView does not send this cookie back to the server on > subsequent requests. However, this only happens on first execution of the > application, after its installation. Once the application closed and > re-opened, the cookies are properly sent and authentication completes > successfully. > The problematic behavior is consistent, and was observed on several devices. > On the other hand, there are no such issues with UIWebView. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Created] (CB-14132) [cordova-plugin-network-information] connection.type is stale on Android 7+ if network connectivity state changes while device is in Doze mode
Dave Alden created CB-14132:
---
Summary: [cordova-plugin-network-information] connection.type is
stale on Android 7+ if network connectivity state changes while device is in
Doze mode
Key: CB-14132
URL: https://issues.apache.org/jira/browse/CB-14132
Project: Apache Cordova
Issue Type: Bug
Components: cordova-plugin-network-information
Affects Versions: 2.0.0
Reporter: Dave Alden
Attachments: connection_type.png
The {{navigator.connection.type}} plugin property [is
set|https://github.com/apache/cordova-plugin-network-information/blob/2.0.1/www/network.js#L60]
when a change in device network connectivity triggers a native callback.
On Android, this [native
callback|https://github.com/apache/cordova-plugin-network-information/blob/master/src/android/NetworkManager.java#L108]
is via a BroadcastReceiver, triggered by the {{CONNECTIVITY_ACTION}} broadcast.
This [sends the result back to the JS
layer|https://github.com/apache/cordova-plugin-network-information/blob/master/src/android/NetworkManager.java#L233]
which [triggers the JS plugin
handler|https://github.com/apache/cordova-plugin-network-information/blob/2.0.1/www/network.js#L59]
to set the property.
However, Android 7 introduces ["background
optimization"|https://developer.android.com/topic/performance/background-optimization]
limitations and Android 8 introduces further [broadcast
limitations|https://developer.android.com/about/versions/oreo/background#broadcasts].
The consequence is that the plugin's broadcast receiver is not guaranteed to
be invoked if the network state changes while the device is in Doze mode.
And therefore the {{navigator.connection.type}} property state can be stale
with respect to the actual network connectivity state.
This may be the root cause of CB-13585 and CB-12035.
The solution to this issue on Android is probably to do the same as the [iOS
implementation|https://github.com/apache/cordova-plugin-network-information/blob/2.0.1/src/ios/CDVConnection.m#L143]:
on resuming the app from the background, trigger an update of the
{{navigator.connection.type}} property.
On Android, this should mitigate the fact that the broadcast receiver may not
have been called while the app was in the background.
Note: my current workaround solution to this issue to is call the plugin's
[getInfo()|https://github.com/apache/cordova-plugin-network-information/blob/2.0.1/www/network.js#L47]
function when my app resumes from the background.
Although this function is not in the API documentation, calling it invokes a
[native
method|https://github.com/apache/cordova-plugin-network-information/blob/2.0.1/src/android/NetworkManager.java#L130]
to retrieve the current device connectivity state asyncronously via a
callback. I then use the callback result to manually update the
{{navigator.connection.type}} property, making sure it's fresh when the app is
resumed from the background.
Since {{getInfo()}} is querying the native {{ConnectivityManager}} directly,
it's guaranteed to get the correct network state from the device, as the
following screenshot illustrates:
!connection_type.png!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-14114) InAppBrowser - Problem in ios 11.3.1
[ https://issues.apache.org/jira/browse/CB-14114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16510910#comment-16510910 ] Werner Reuser commented on CB-14114: We're experiencing this issue as well. Reproducing is done by logging into a website / webapp that users SAML authentication. Steps are: # When entering the app no SAML session is found, user is redirected to SAML idp with a SAML request. # User logs in into SAML idp (in our case ADFS) # Next step is ADFS should redirect back to the SAML login entry point of the webapp with a SAML response. This doesn't happen, the message 'http *service 1.1. unavailable'* is shown in the screen. Further investigation using Fiddler shows the ADFS domain throwing a 503 server error. We've tested this with any browser we could find and the error is only triggered using the InAppBrowser, every other browser doesn't trigger the 503 server error in ADFS. So this seems a bug in probably both ADFS and InAppBrowser. Not sure what but InAppBrowser seems to send information to ADFS that is malformed or something like that. The message shown in the screen is just html send by the ADFS server: Http/1.1 Service Unavailable > InAppBrowser - Problem in ios 11.3.1 > > > Key: CB-14114 > URL: https://issues.apache.org/jira/browse/CB-14114 > Project: Apache Cordova > Issue Type: Bug >Affects Versions: 3.0.0 > Environment: iphone 5s, ios 11.3.1 > iphone 7+ ios 11.3.1 > >Reporter: Nishanth >Priority: Major > > Strange behaviour after the upgrade from 11.2 to 11.3 The user is not able to > login to the identity provider using InAppBrowser. The server rejects the > request and throws a 'http *service 1.1. unavailable'* after the user submits > username and password > > I was hoping that it was an ios bug but I am able to login with wkwebview > browser > [https://github.com/dpa99c/cordova-plugin-inappbrowser-wkwebview] > The usage of WKWebview browser was to just confirm the issue. > Any help on this would be much appreciated. > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Created] (CB-14131) Android N unable to open locally downloaded file
Sean Molyneaux created CB-14131: --- Summary: Android N unable to open locally downloaded file Key: CB-14131 URL: https://issues.apache.org/jira/browse/CB-14131 Project: Apache Cordova Issue Type: Bug Components: cordova-plugin-inappbrowser Affects Versions: Master Environment: Android N Reporter: Sean Molyneaux Attachments: inappbrowers.png The InAppBrowser is unable to open "file://" see blog [https://inthecheesefactory.com/blog/how-to-share-access-to-file-with-fileprovider-on-android-nougat/en] iOS works fine and this is specifically on android. *Suggestion* Add in method to handle local files using the "FileProvider". There are other plugins that specifically handle this but are a bit bloaty to add just to open a local file. This feature would be nice to have in the inAppBrowser plugin as a matter of convenience. If this does not seem applicable please close, so we can devise a light plugin to handle this in our projects going forward. *Steps we took to fix the problem* # Added in open local file method # Used the FileProvided to get a acceptable uri # Open the uri with an intent to a default application -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-11440) iOS: Remove default: disabled NSAppTransportSecurity - soon required by Apple
[
https://issues.apache.org/jira/browse/CB-11440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16510744#comment-16510744
]
Ken Naito commented on CB-11440:
I created a simple npm module experimentally.
By using this module, we can set the NSAllowsArbitraryLoads to false.
https://www.npmjs.com/package/cordovax-edit-ats
Install:
{code}
$ npm install cordovax-edit-ats
{code}
on the cordova application directory.
Using this module, we can set the NSAllowsArbitraryLoads to false by command
line
{code}
$ npx cordovax-edit-ats create false
{code}
or by using hook script like
config.xml:
{code}
{code}
with scripts/editPlist.js
{code}
var editATS = require('cordovax-edit-ats');
module.exports = function(context) {
if (context.opts.cordova.platforms.includes('ios')) {
editATS('create_false', context.opts.projectRoot);
}
};
{code}
I think that modifying Info.plist/AndroidManifest file should be done when
after_platform_add.
Because we can apply the modification to the original (template default)
Info.plist/AndroidManifest.xml.
> iOS: Remove default: disabled NSAppTransportSecurity - soon required by Apple
> --
>
> Key: CB-11440
> URL: https://issues.apache.org/jira/browse/CB-11440
> Project: Apache Cordova
> Issue Type: Bug
> Components: cordova-ios
> Environment: cordova-ios 4.1.1
>Reporter: Michael Schmidt
>Assignee: Shazron Abdullah
>Priority: Blocker
> Labels: backlog, iOS, triaged
> Fix For: cordova-ios@5.0.0
>
>
> iOS platform by default disables https:
> {code}
> NSAppTransportSecurity
>
> NSAllowsArbitraryLoads
>
>
> {code}
> Apple soon requires HTTPS:
> "Apple mandates App Store apps support ATS security protocol by 2017"
> http://appleinsider.com/articles/16/06/14/apple-mandates-app-store-apps-support-ats-security-protocol-by-2017
> --> remove this default from cordova ios platform
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
