Github user asfgit closed the pull request at:
https://github.com/apache/cordova-android/pull/264
---
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 featur
Github user bso-intel commented on the pull request:
https://github.com/apache/cordova-android/pull/264#issuecomment-191616111
Since now I created the --force-copying-src option, the current behavior of
throwing exception is preserved.
To get around this issue, the user can use th
Github user nikhilkh commented on the pull request:
https://github.com/apache/cordova-android/pull/264#issuecomment-191341584
@brodybits Would love to see some contributions in the area of plugin dev
documentation - we know we have a lot of gaps there - since you have a bunch of
exper
Github user bso-intel commented on the pull request:
https://github.com/apache/cordova-android/pull/264#issuecomment-191319864
I am working on adding a command-line option --force-copying-src to allow
the Cordova user to try overwriting the conflicting file.
I hope this gives some
Github user bso-intel commented on the pull request:
https://github.com/apache/cordova-android/pull/264#issuecomment-190952289
Right. I agree that silently passing is not good.
So, I said that we should print the warning message to the user "Warning:
in the already exists. {Skipp
Github user brodybits commented on the pull request:
https://github.com/apache/cordova-android/pull/264#issuecomment-190951704
I would favor leaving it to the plugins to use the `lib-file` instead of
`source-file` to install the libraries. A couple of things that could really
help:
Github user nikhilkh commented on the pull request:
https://github.com/apache/cordova-android/pull/264#issuecomment-190947034
My concern with silently passing here is that there could be a
runtime/build failure because potentially the wrong version of the file is
added depending on th
Github user bso-intel commented on the pull request:
https://github.com/apache/cordova-android/pull/264#issuecomment-190937260
Hi nikhill,
I am not a plugin writer so I don't know whether the plugin write can use
other tags for their purposes.
This issue was reported from
Github user nikhilkh commented on the pull request:
https://github.com/apache/cordova-android/pull/264#issuecomment-190929927
I agree we should improve the error messages - especially the 'Uh oh!' :)
We have three tags:
-
[lib-file](http://cordova.apache.org/docs/en/dev/pl
Github user bso-intel commented on the pull request:
https://github.com/apache/cordova-android/pull/264#issuecomment-190778940
@vladimir-kotikov,
This is just one example of the conflicting plugins.
There could be so many plugins out there that requires the same library
files.
Github user vladimir-kotikov commented on the pull request:
https://github.com/apache/cordova-android/pull/264#issuecomment-190719953
@bso-intel, IMO there is a reason for current approach - ``
element is intended to handle `.java`, `.m` and other types of source files -
not binary pa
Github user nikhilkh commented on the pull request:
https://github.com/apache/cordova-android/pull/264#issuecomment-190564383
@vladimir-kotikov to review. Is there a test case that we can add? PR #265
has a good framework for testing something like this.
---
If your project is set up
GitHub user bso-intel opened a pull request:
https://github.com/apache/cordova-android/pull/264
CB-10673 fixed conflicting plugin install issue with overlapped tag
The problem is that copyNewFile is too strict for tag.
You will never know which two plugins will write the library
13 matches
Mail list logo
