Hi Vladyslav,
This mailing list is only for development of the Cordova framework, not
for support for building apps or plugins with Cordova.
For support, I'd suggest try asking in our Slack community at
http://slack.cordova.io/
Alternatively, you can also try asking on StackOverflow at
https
t seems to work - Anyone know if there are
potential unintended side-effects of doing that?
-Chuck
-Original Message-
From: Chuck Lantz [mailto:cla...@microsoft.com]
Sent: Thursday, May 7, 2015 8:05 AM
To: dev@cordova.apache.org
Subject: RE: Cordova Plugins with Symlinks
Possibly
an acceptable workaround. Need to validate.
-Chuck
-Original Message-
From: agri...@google.com [mailto:agri...@google.com] On Behalf Of Andrew Grieve
Sent: Thursday, May 7, 2015 6:55 AM
To: dev
Subject: Re: Cordova Plugins with Symlinks
Could we fix our un-tarring logic to create symlin
. #1 is likely a
> bit more robust.
>
> -Chuck
>
> -Original Message-
> From: Josh Soref [mailto:jso...@blackberry.com]
> Sent: Wednesday, May 6, 2015 11:05 AM
> To: dev@cordova.apache.org
> Subject: RE: Cordova Plugins with Symlinks
>
> It should be possible f
these hooks and add them to the default
template for plugins and in addition to the docs. #1 is likely a bit more
robust.
-Chuck
-Original Message-
From: Josh Soref [mailto:jso...@blackberry.com]
Sent: Wednesday, May 6, 2015 11:05 AM
To: dev@cordova.apache.org
Subject: RE: Cordova Pl
another directory, other platforms should be able to do similar.
> -Original Message-
> From: Shazron [mailto:shaz...@gmail.com]
> Sent: Wednesday, May 06, 2015 1:23 PM
> To: dev@cordova.apache.org
> Subject: Re: Cordova Plugins with Symlinks
>
> Ordinarily I agree with Je
---
> From: Jesse [mailto:purplecabb...@gmail.com]
> Sent: Wednesday, May 6, 2015 9:16 AM
> To: dev@cordova.apache.org
> Subject: Re: Cordova Plugins with Symlinks
>
> I think in this case we should be not be using symlinks. All of our output
> project types support adding a referen
ediate the problem does
it not?
-Chuck
-Original Message-
From: Jesse [mailto:purplecabb...@gmail.com]
Sent: Wednesday, May 6, 2015 9:16 AM
To: dev@cordova.apache.org
Subject: Re: Cordova Plugins with Symlinks
I think in this case we should be not be using symlinks. All of our output
pro
I think in this case we should be not be using symlinks. All of our output
project types support adding a reference to a file or folder, we should
leverage this directly.
Of course, this could possibly lead to forward vs back slash issues, but should
be easier than running hook hacks.
At least
It does thank you!
Sent from my Windows Phone
From: Jesse<mailto:purplecabb...@gmail.com>
Sent: 11/17/2014 7:32 PM
To: dev@cordova.apache.org<mailto:dev@cordova.apache.org>
Subject: Re: Cordova Plugins
In this case, the platform itself is not suppo
In this case, the platform itself is not supported, so you will not find
any plugins for anything pre WP7.5
Hopefully that saves you some time.
@purplecabbage
risingj.com
On Mon, Nov 17, 2014 at 4:23 PM, Shazron wrote:
> Also, when in your project folder you can do:
>
> cordova plugin search
Also, when in your project folder you can do:
cordova plugin search 'barcode'
replace 'barcode' with your search term.
On Mon, Nov 17, 2014 at 4:07 PM, tommy-carlos williams
wrote:
> Cordova / PhoneGap plugin repositories:
>
> http://plugins.cordova.io/
> http://plugins.telerik.com/
> https://
Cordova / PhoneGap plugin repositories:
http://plugins.cordova.io/
http://plugins.telerik.com/
https://build.phonegap.com/plugins
http://plugreg.com/plugins
--
tommy-carlos williams
On 18 November 2014 at 11:03:40, Ryan Finnesey (r...@finnesey.com) wrote:
Where can I find a list of Cordova P
Had to get infra to re-create the statusbar repo since I mistakenly asked
it to be named "cordova-statusbar" instead of "cordova-plugin-statusbar"
(thus the flurry of statusbar commits again)
On Thu, Mar 13, 2014 at 12:43 PM, Shazron wrote:
> cordova-statusbar created, that was fast. I'm migrat
cordova-statusbar created, that was fast. I'm migrating the statusbar
folder to that repo now.
On Thu, Mar 13, 2014 at 12:35 PM, Shazron wrote:
> https://issues.apache.org/jira/browse/INFRA-7444
>
>
> On Thu, Mar 13, 2014 at 11:50 AM, Shazron wrote:
>
>> Alright, I'm going to start on this tod
https://issues.apache.org/jira/browse/INFRA-7444
On Thu, Mar 13, 2014 at 11:50 AM, Shazron wrote:
> Alright, I'm going to start on this today:
>
> org.apache.cordova.keyboard stays in cordova-plugins but has a new
> namespace: org.apache.cordova.labs.keyboard
> org.apache.cordova.statusbar stay
+1 sgtm
@purplecabbage
risingj.com
On Thu, Mar 13, 2014 at 11:50 AM, Shazron wrote:
> Alright, I'm going to start on this today:
>
> org.apache.cordova.keyboard stays in cordova-plugins but has a new
> namespace: org.apache.cordova.labs.keyboard
> org.apache.cordova.statusbar stays in cordova-
Alright, I'm going to start on this today:
org.apache.cordova.keyboard stays in cordova-plugins but has a new
namespace: org.apache.cordova.labs.keyboard
org.apache.cordova.statusbar stays in cordova-plugins *for now* until we
get a new repo, and keeps its existing namespace
On Tue, Mar 11, 2014
On Mon, Mar 10, 2014 at 4:07 PM, Jesse wrote:
> More on the concept of rolling into a platform ...
> My distinction is that there are some things that every platform should
> consider a baseline of browser functionality, and if the OS SDKs do not
> provide it out of the box, then we should. Some
oops, yeah Shaz. "statusbar namespace does *not* change"
@purplecabbage
risingj.com
On Tue, Mar 11, 2014 at 11:50 AM, Shazron wrote:
> The proposal looks good to me. Since the majority of the code for the two
> plugins have been contributed by me, I will continue to help maintain them.
> One t
The proposal looks good to me. Since the majority of the code for the two
plugins have been contributed by me, I will continue to help maintain them.
One thing though -- "statusbar namespace changes" -- I believe you wanted
to say "statusbar namespace does *not* change"
On Tue, Mar 11, 2014 at
sgtm
On Tue, Mar 11, 2014 at 2:01 PM, Jesse wrote:
> Andrew, I agree with all of that, and never suggested that statusbar not be
> a plugin.
>
> Attempting to rescue this thread into something we can do? ...
>
>
>
> Plugins:
> [PROPOSAL]
> org.apache.cordova.labs.keyboard
> - a iOS only keyboar
Andrew, I agree with all of that, and never suggested that statusbar not be
a plugin.
Attempting to rescue this thread into something we can do? ...
Plugins:
[PROPOSAL]
org.apache.cordova.labs.keyboard
- a iOS only keyboard plugin doing some very iOS specific stuff, lives in
labs
- there is no
I like this idea. Achieves all concerns. (Separation thereof, and
onboarding ease.)
On Tue, Mar 11, 2014 at 9:04 AM, Carlos Santana wrote:
> +1 Keep it as a plugin not embed into platform repo
>
> default plugins ?
>
> what about binding a set of default plugins with our www template app (the
>
+1 Keep it as a plugin not embed into platform repo
default plugins ?
what about binding a set of default plugins with our www template app (the
template app specified what plugins are required)
meaning associate a set of plugins with a template www app, and not
associate with platform or cli
Plugins allow us to share JS. Rolling statusbar into platforms means
different JS for all platforms, and make it easier for the APIs to diverge.
Plugins allow us to share docs, and to have the docs live with the code.
APIs like Android's "app" plugin don't have very good docs (or maybe they
are ju
On Mon Mar 10 04:07 PM, Jesse wrote:
> More on the concept of rolling into a platform ...
> My distinction is that there are some things that every platform should
> consider a
> baseline of browser functionality, and if the OS SDKs do not provide it out
> of the
> box, then we should. Some examp
> Import 'plaforms/android' into Eclipse:
> https://onedrive.live.com/?gologin=1&mkt=en-
> US#cid=295047487FC4F731&id=295047487FC4F731%215602&v=3
>
> Broken... but "cordova run" works... Is using eclipse still a 'core' thing?
> It's a "still want to use an IDE" thing. My preference is a cordova th
On Mon Mar 10 02:52 PM, Brian LeRoux wrote:
> While I wholeheartedly agree plugins, clean separation of concerns, discreet
> repos, all have big benefits if every single developer installs a plugin on
> day 1 that
> is specific to a particular platform I feel that might be a good indication
> the
+1
On 10 Mar 2014, at 20:05, Tommy-Carlos Williams wrote:
> +1
>
>
> On 11 Mar 2014, at 5:52 am, Brian LeRoux wrote:
>
>> While I wholeheartedly agree plugins, clean separation of concerns,
>> discreet repos, all have big benefits if every single developer installs a
>> plugin on day 1 that
More on the concept of rolling into a platform ...
My distinction is that there are some things that every platform should
consider a baseline of browser functionality, and if the OS SDKs do not
provide it out of the box, then we should. Some examples of this :
1. Local XHR, Windows Phone does not
+1
On 11 Mar 2014, at 5:52 am, Brian LeRoux wrote:
> While I wholeheartedly agree plugins, clean separation of concerns,
> discreet repos, all have big benefits if every single developer installs a
> plugin on day 1 that is specific to a particular platform I feel that might
> be a good indicat
While I wholeheartedly agree plugins, clean separation of concerns,
discreet repos, all have big benefits if every single developer installs a
plugin on day 1 that is specific to a particular platform I feel that might
be a good indication the platform should conditionally roll that plugin in.
I th
On Mon Mar 10 12:51 PM, Michal Mocny wrote:
>
> I think we can solve that problem using a plethora of better
> alternatives, including
> install scripts (perhaps with a generator
> like yeoman, perhaps my just pasting
> snippets in tutorials), by
> supporting plugin dependencies for platforms, or
Whats the benefit of rolling plugins into a platform? The only one I can
see is "installed by default" which means better "out of box" experience
for new users.
I think we can solve that problem using a plethora of better alternatives,
including install scripts (perhaps with a generator like yeom
I like it. Statusbar is considered core by the community. That said, should
it be rolled into the platform as a feature?
On Mon, Mar 10, 2014 at 7:39 AM, Andrew Grieve wrote:
> What does core mean?
>
> Does "core" mean that it has the namespace "org.apache.cordova."?
> Does "core" mean that it
What does core mean?
Does "core" mean that it has the namespace "org.apache.cordova."?
Does "core" mean that it is something we will support?
Does "core" mean that it is something that applies to multiple platforms?
I would like "core" to be the first two. And by "we", I mean at least one
commit
StatusBar wp7+8 is mostly done. Just testing some stuff now.
Sent from my iPhone
> On Mar 7, 2014, at 3:30 PM, Shazron wrote:
>
> Technically there are two platforms right now. Android has minimal support,
> and Jesse wants to do WP8 (again minimal), so thats another.
>
>
>> On Fri, Mar 7, 2
Well, as much as I'd like the faster iteration of plugins, I think from a
user perspective that these two bits of functionality are pretty important.
Users need them. iOS apps without the status bar plugin are fairly limited
in how they can be styled, etc. The default is dark text, so only a light
Technically there are two platforms right now. Android has minimal support,
and Jesse wants to do WP8 (again minimal), so thats another.
On Fri, Mar 7, 2014 at 3:23 PM, Anis KADRI wrote:
> +1 for labs. it doesn't really make sense to have them in core if they only
> support one platform.
>
>
>
+1 for labs. it doesn't really make sense to have them in core if they only
support one platform.
On Thu, Mar 6, 2014 at 8:47 AM, James Jong wrote:
> Similar to keyboard plugin, I like the idea of letting this bake in labs
> for now and moving them into core if we see multiple platforms start
>
Similar to keyboard plugin, I like the idea of letting this bake in labs for
now and moving them into core if we see multiple platforms start needing a
similar API. So (a) and (c) for me.
I would add that the iOS 6/7 specific code may not make sense as "core”.
-James Jong
On Mar 5, 2014, at 9
I like the idea of letting this bake in labs for now and moving them into core
if we see multiple platforms start needing a similar API. So (a) and (c) for
me.
-James Jong
On Mar 5, 2014, at 8:19 PM, Shazron wrote:
> Some background on the keyboard plugin.
>
> This was extracted from the iOS
I have created a task in JIRA for all the statusbar related discussion. [1]
There are numerous inconsistencies we need to address here.
[1] https://issues.apache.org/jira/browse/CB-6177
@purplecabbage
risingj.com
On Wed, Mar 5, 2014 at 5:15 PM, Shazron wrote:
> Some background on the statusba
Some background on the keyboard plugin.
This was extracted from the iOS core, and put into its own plugin so
updates are not tied to a platform release, and fixes can be rapid. Someone
filed this issue https://issues.apache.org/jira/browse/CB-6176 and I didn't
know that BlackBerry also supported s
Some background on the statusbar plugin.
This was conceived because of iOS 7 where the statusbar overlays the
webview, and a lot of people didn't like their UI changing especially if
they still support iOS 6. That is the primary purpose of this plugin, but
there are other features in there as well
(a) Yes.
(b) No -- some organizations (Adobe) don't like this, and we respect that.
We also want to point users at these plugins, so its good to have
developers protected by Apache.
(c) Sure -- so long as labs is clearly separate, and we leave them out of
blogs / plugin release notes, and we don't
Yeah I have been saying to do them independent of the plugin releases I do.
The authors have been doing that so far.
On Thu, Nov 28, 2013 at 12:01 PM, Brian LeRoux wrote:
> ya I think/thought so too
>
>
> On Wed, Nov 27, 2013 at 8:41 PM, Michal Mocny wrote:
>
> > I think the conclusion was tha
ya I think/thought so too
On Wed, Nov 27, 2013 at 8:41 PM, Michal Mocny wrote:
> I think the conclusion was that cordova-plugins are just *not* included in
> plugin releases.
>
>
> On Wed, Nov 27, 2013 at 11:32 PM, Andrew Grieve >wrote:
>
> > Back to the original question - we should specify h
I think the conclusion was that cordova-plugins are just *not* included in
plugin releases.
On Wed, Nov 27, 2013 at 11:32 PM, Andrew Grieve wrote:
> Back to the original question - we should specify how cordova-plugins
> should be included in plugin releases.
>
> Really, the thing we need is to
Back to the original question - we should specify how cordova-plugins
should be included in plugin releases.
Really, the thing we need is to be able to know if there are any unreleased
commits and to update releasenotes.md for each plugin.
I think it'd be enough to run "git log -- plugin-dir" and
the problem wasn't isolated to the repo (there were many problems) but
suffice to say lack of shared issue tracking was a key point of failure and
inability to discreetly version changesets created more suffering than good
On Mon, Nov 25, 2013 at 3:20 PM, Josh Soref wrote:
> Lindsey Simon wrote
Lindsey Simon wrote:
> It seems like a shared repo is just a recipe for the troubles of the last
> shared repo.
For those of us who didn't live through the last shared repo, is there a
document describing what happened?
There's a great writeup from some Github using group who accidentally force
It seems like a shared repo is just a recipe for the troubles of the last
shared repo.
On Mon, Nov 25, 2013 at 1:17 PM, Jesse wrote:
> All of this is fine.
>
> I also see no reason why you cannot hack in your own repo, just ensure you
> start with the right license. Nothing says that the apach
All of this is fine.
I also see no reason why you cannot hack in your own repo, just ensure you
start with the right license. Nothing says that the apache git has to be
the origin of code.
@purplecabbage
risingj.com
On Mon, Nov 25, 2013 at 1:01 PM, Anis KADRI wrote:
> It sounds like we all
It sounds like we all agree. Start hacking on cordova-plugins and
if/when it's mature move it to its own repository. Publishig from
cordova-plugins should not be an issue.
On Mon, Nov 25, 2013 at 11:52 AM, Braden Shepherdson
wrote:
> I'm not sure if I was clear: I am content with the current repo
I'm not sure if I was clear: I am content with the current repo setup and
argue for keeping it as it is. The main core plugins are in their own repos
and I support that. On the other hand I support having the cordova-plugins
repo as an incubator for experimental projects that either die or graduate
Okay -- while I do agree with Braden -- in the interests of not debating
again, I'll concede to not publishing core plugins from a shared repo (if
for no other reason than for consistency with the other core plugins). But
I think its still worth having a cordova-plugins repo for early
experiments/
Super disagree about putting src into a single big repo. I get why we do
that. I do not buy that we 'have too many repos' or that complexity is
minimized by combining. Anyhow: not a discussion I think is even worth us
having AGAIN. =/
On Mon, Nov 25, 2013 at 10:32 AM, Braden Shepherdson wrote:
>
Hang on a second:
The release you send to the plugman registry doesn't care about git. You
point it at a (sub)directory and it uploads the plugin. The version is set
by the plugin.xml of that plugin.
If we want tags for when those plugins were pushed to npm, what's wrong
with tags like "whateverp
Would that only be true if you shared readable tag names between plugins?
If we used tags unique to each plugin, perhaps by prefixing tags with the
target plugins' name, then plugin releases would be isolated, right?
-Michal
On Fri, Nov 22, 2013 at 8:02 PM, Jesse wrote:
> The issue that if us
The issue that if use a tag to signify the new version, then the tag is
applied to all plugins in the repo. This is probably not a big deal for
minor bumps, but when a plugin needs a major bump, they all will. So you
will/could have a plugin with a major version bump even though the code has
not ch
I don't understand, whats the problem? I thought you publish plugins by
git-repo & subdir & hash -- so multiple plugins makes no difference.
The master & dev branch deal was to do with cordova-3.0 users that did not
support plugin repo install from !master branch, right? But none of these
plugin
+1 on one plugin per repo. Would making releasing and tagging much simpler.
On Fri, Nov 22, 2013 at 1:29 PM, Carlos Santana wrote:
> Yep that's the problem with having independent plugins in a single repo,
> and just using directories to separate them.
>
> If I would have a choice I would strong
Yep that's the problem with having independent plugins in a single repo,
and just using directories to separate them.
If I would have a choice I would strongly encourage one plugin per repo
containing its own version and source control.
On Friday, November 22, 2013, Shazron wrote:
> The cordova
Hi,
This is cool don't get me wrong, but it's just the other way around. With this,
one could create a cordova application using CocoaPods, but I want to have a
plugin that uses some CocoaPods libraries. Then it would be nice to add a
PodFile to your plugin directory and have the cli 'install'
The core and core plugins are cocoapods already, see the list (search for
'Cordova'): https://github.com/CocoaPods/Specs
Someone is maintaining them, modifying the specs for them as versions go
out: https://github.com/CocoaPods/Specs/pull/4539
On Thu, Oct 31, 2013 at 8:11 AM, Don Coleman wrote:
The AeroGear-PushPlugin uses cocoa pods, what would be nice is to be able to
include a pod install into the CLI.
On 31 Oct,2013, at 16:11 , Don Coleman wrote:
> I have some iOS code that we are converting into a Cordova plugin.
>
> The project uses CocoaPods to manage dependencies.
>
> Have y
Sorry, stupid question, this is exactly what callbackID is for, I can pass
that into native and back into java to know which callback to call.
On Thu, Apr 18, 2013 at 4:33 PM, Aaron Charbonneau wrote:
> Hi,
> Does anyone know of any Cordova plugin implementations that do a roundtrip
> of callbac
69 matches
Mail list logo
