Oh boo - nice catch. Certainly need to fix this.
How about using FirstCap and making the code use case-insensitive
comparisons?
Just checked Android source, and the defaults actually are the same
(false), so we should just be consistent about having things not commented
out by default.
On Tue,
Merged the dependencies work that I've been doing that was on a branch
into master.
It's uploading to npm as we speak.
If you're interested, give it a shot. iOS + Android are verified. I am
taking a look at BlackBerry's pull request to get that lined up, then I
will hop over to update windows
I noticed that it has been removed in config.xml:
https://github.com/apache/cordova-ios/blob/a07794d88c8e9cf72c24427908462a583241834b/CordovaLibTests/CordovaLibApp/config.xml
Just a copy and paste thing or something more? (are we removing it). I'm in
favour of not patching Apple's mistakes (sorry
Hey Bryan
I am just looking at this stuff now. Thanks for updating the tests too.
Do you have any plugins that I can try on my BB10 device that I could test
plugman with?
On 5/14/13 11:29 AM, Bryan Higgins br...@bryanhiggins.net wrote:
Hey Fil,
I'll fill in for Jeff since he's away at BB Live
Hey Fil,
check out the BlackBerry plugin repo on github
https://github.com/blackberry/cordova-blackberry-plugins
On Thu, May 16, 2013 at 10:33 AM, Filip Maj f...@adobe.com wrote:
Hey Bryan
I am just looking at this stuff now. Thanks for updating the tests too.
Do you have any plugins that
Thx Lorin!
On 5/16/13 10:35 AM, Lorin Beer lorin.beer@gmail.com wrote:
Hey Fil,
check out the BlackBerry plugin repo on github
https://github.com/blackberry/cordova-blackberry-plugins
On Thu, May 16, 2013 at 10:33 AM, Filip Maj f...@adobe.com wrote:
Hey Bryan
I am just looking at this
Hey Fil,
You'll need this branch of cordova-blackberry to test everything:
https://github.com/apache/cordova-blackberry/pull/14
On Thu, May 16, 2013 at 1:39 PM, Filip Maj f...@adobe.com wrote:
Thx Lorin!
On 5/16/13 10:35 AM, Lorin Beer lorin.beer@gmail.com wrote:
Hey Fil,
check
Seems like it was removed from the pull request to convert plugin to
feature. Re-adding.
On Thu, May 16, 2013 at 10:00 AM, Shazron shaz...@gmail.com wrote:
I noticed that it has been removed in config.xml:
Thanks guys!
On 5/16/13 11:05 AM, Bryan Higgins br...@bryanhiggins.net wrote:
Hey Fil,
You'll need this branch of cordova-blackberry to test everything:
https://github.com/apache/cordova-blackberry/pull/14
On Thu, May 16, 2013 at 1:39 PM, Filip Maj f...@adobe.com wrote:
Thx Lorin!
On
Pretty sure it has to do with 2.7.0 removing the deprecated Plugin class
that PushPlugin still relies on.
Switch all references of Plugin to CordovaPlugin and that should fix most
issues.
On 5/16/13 11:15 AM, John Sphar jlsp...@gmail.com wrote:
Hi all,
Since this is my first posting, I just
Hi all,
Since this is my first posting, I just want to thank the creators of and
contributors to this project. Bravo!
I can't seem to fix this import error (or what seems to be...) with
cordova-2.7.0.jar...
I've added the right stuff to the build path and everything.
Details (even
Yeah, I didn't mean to remove it.
On Thu, May 16, 2013 at 2:10 PM, Shazron shaz...@gmail.com wrote:
Seems like it was removed from the pull request to convert plugin to
feature. Re-adding.
On Thu, May 16, 2013 at 10:00 AM, Shazron shaz...@gmail.com wrote:
I noticed that it has been
Hey guys,
I pushed up a bb10 branch of plugman to apache's repo:
https://git-wip-us.apache.org/repos/asf?p=cordova-plugman.git;a=shortlog;h=
refs/heads/bb10
Added one more commit to update the design to reflect the changes
introduced by supporting dependencies.
Now am going to try to get my
We deprecated this recently. Can we leave an empty plugins element in
config.xml for each platform while the deprecation window is still open?
This way tooling such as plugman can still add plugin elements while the
platforms still support it.
Once we fully remove plugin support then IMO that is
+1 to leave in an empty plugin/ until deprecation time is reached, it
just makes sense.
On Thu, May 16, 2013 at 12:51 PM, Gorkem Ercan gorkem.er...@gmail.comwrote:
+1 for a deprecation period
--
Gorkem
On Thu, May 16, 2013 at 3:45 PM, Filip Maj f...@adobe.com wrote:
We deprecated this
I am indifferent.
On Thu, May 16, 2013 at 2:45 PM, Filip Maj f...@adobe.com wrote:
We deprecated this recently. Can we leave an empty plugins element in
config.xml for each platform while the deprecation window is still open?
This way tooling such as plugman can still add plugin elements
Thanks Fil!
Let me know if you need a hand with anything.
I'd really like to get that pull into cordova-blackberry merged into
master. We can point package.json to the bb10 branch of plugman for now.
On Thu, May 16, 2013 at 3:42 PM, Filip Maj f...@adobe.com wrote:
Hey guys,
I pushed up a
+1, and another point: make sure your native bits continue to load from
both plugin/ and feature/ until the deprecation window slams shut.
@purplecabbage
risingj.com
On Thu, May 16, 2013 at 12:56 PM, Benn Mapes benn.ma...@gmail.com wrote:
+1 to leave in an empty plugin/ until deprecation time
Sounds good, I will file issues on relevant platforms.
On 5/16/13 1:30 PM, Jesse purplecabb...@gmail.com wrote:
+1, and another point: make sure your native bits continue to load from
both plugin/ and feature/ until the deprecation window slams shut.
@purplecabbage
risingj.com
On Thu, May 16,
Filed 3416: https://issues.apache.org/jira/browse/CB-3416
Affects only android and iOS on master.
On 5/16/13 1:30 PM, Jesse purplecabb...@gmail.com wrote:
+1, and another point: make sure your native bits continue to load from
both plugin/ and feature/ until the deprecation window slams shut.
Other platforms still need to be sure not to remove plugins/ though.
@purplecabbage
risingj.com
On Thu, May 16, 2013 at 2:29 PM, Filip Maj f...@adobe.com wrote:
Filed 3416: https://issues.apache.org/jira/browse/CB-3416
Affects only android and iOS on master.
On 5/16/13 1:30 PM, Jesse
I'm irritated by this change but not enough to -1 it. This has gone
through our deprecation timeline and it's not like we decided on the new
XML yesterday. I don't understand why we can't meet our own deadlines.
Will this be gone by 3.0? If not, why not.
On May 16, 2013 2:30 PM, Filip Maj
Should we be aiming to ship 2.8.0 with a unified version of config.xml in
the template, and the project created by the CLI? In adding the feature tag
support to WP7, I have been using a config.xml that has elements like this:
feature name=Device
param name=android-package
Wondering if others are seeing this, get this when I try to push:
fil-MacBookAir:cordova-plugman fil$ git push apache master
Counting objects: 19, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (10/10), done.
Writing objects: 100% (10/10), 937 bytes, done.
Total 10
Same here when pushing to cordova-ios:
Pushing to https://git-wip-us.apache.org/repos/asf/cordova-ios.git
Counting objects: 5, done.
Delta compression using up to 8 threads.
Compressing objects: 33% (1/3)
Compressing objects: 66% (2/3)
Compressing objects: 100% (3/3)
Compressing objects: 100%
Im in the infra channel, someone's working on it
On 5/16/13 4:10 PM, Shazron shaz...@gmail.com wrote:
Same here when pushing to cordova-ios:
Pushing to https://git-wip-us.apache.org/repos/asf/cordova-ios.git
Counting objects: 5, done.
Delta compression using up to 8 threads.
Compressing
Filing an INFRA issue.
On Thu, May 16, 2013 at 4:10 PM, Shazron shaz...@gmail.com wrote:
Same here when pushing to cordova-ios:
Pushing to https://git-wip-us.apache.org/repos/asf/cordova-ios.git
Counting objects: 5, done.
Delta compression using up to 8 threads.
Compressing objects: 33%
Ok, will hold
On Thu, May 16, 2013 at 4:12 PM, Filip Maj f...@adobe.com wrote:
Im in the infra channel, someone's working on it
On 5/16/13 4:10 PM, Shazron shaz...@gmail.com wrote:
Same here when pushing to cordova-ios:
Pushing to https://git-wip-us.apache.org/repos/asf/cordova-ios.git
Hey Jesse,
For WP7+8, if XHR relies on some cordova APIs, I think those APIs need to
be loaded as special-cases for windows phone, I.e. Integrate those bits
before onNativeReady fires in cordova-js. This way the plugin loading code
can happen as-is and can rely on XHR safely.
It'd be good to see
So XHR patch the browser directly ( but do it without using the File API )
I think is the best approach.
It is not hard, not at all, that is/was my point.
The fact that the file is cordova_plugin.json means that it MUST be loaded
by XHR, where if it was cordova_plugin.js it could just be added as
Seems to be working ok now
On Thu, May 16, 2013 at 4:13 PM, Shazron shaz...@gmail.com wrote:
Ok, will hold
On Thu, May 16, 2013 at 4:12 PM, Filip Maj f...@adobe.com wrote:
Im in the infra channel, someone's working on it
On 5/16/13 4:10 PM, Shazron shaz...@gmail.com wrote:
Same here
Without knowing much about wp plugins, would there be necessity to
differentiate between wp7 and wp8? So that param name would be for
wp7-package for wp7.
--
Gorkem
On Thursday, May 16, 2013, Jesse wrote:
Should we be aiming to ship 2.8.0 with a unified version of config.xml in
the template,
Red Hat is building a Cordova plugin for eclipse as part of the JBoss
tools. You can read about current state[1]. We have not yet implemented the
plugin support but it is certainly on the roadmap.
[1]
http://www.gorkem-ercan.com/2013/05/hybrid-mobile-application-development.html?m=1
On Tuesday,
Sweet!
On 5/16/13 6:57 PM, Gorkem Ercan gorkem.er...@gmail.com wrote:
Red Hat is building a Cordova plugin for eclipse as part of the JBoss
tools. You can read about current state[1]. We have not yet implemented
the
plugin support but it is certainly on the roadmap.
[1]
Awesome!
On Thu, May 16, 2013 at 7:05 PM, Filip Maj f...@adobe.com wrote:
Sweet!
On 5/16/13 6:57 PM, Gorkem Ercan gorkem.er...@gmail.com wrote:
Red Hat is building a Cordova plugin for eclipse as part of the JBoss
tools. You can read about current state[1]. We have not yet implemented
35 matches
Mail list logo
