No, at least I don't think so. The install/uninstall are more clobbers
and plugin.xml is not a thing npm has any desire to become aware of.
On Mon, Jul 29, 2013 at 11:24 PM, Andrew Grieve wrote:
> On Mon, Jul 29, 2013 at 11:19 PM, Brian LeRoux wrote:
>
>> > Would this require that we use the nod
> The main difference between plugman & cli is that CLI provides
> multi-platform support and plugman doesn't.
Yes?
> I'm not suggesting we change CLI to have platform-specific logic (neither
> was Tyler). I *am* suggesting that we can make the platforms aware of when
> they exist within a CLI w
On Mon, Jul 29, 2013 at 11:19 PM, Brian LeRoux wrote:
> > Would this require that we use the node_modules dependency structure?
>
> No. We would teach npm install about our structure.
>
>
> > Would we be able to enforce our as well
> > as our
> > constraints?
>
> Yes.
>
>
> > Some things will b
> Would this require that we use the node_modules dependency structure?
No. We would teach npm install about our structure.
> Would we be able to enforce our as well
> as our
> constraints?
Yes.
> Some things will be uglier to express as json I think. E.g.: trying to
> embed xml snippets (l
Sorry yes, Plugins.plist
Maybe folks are using plugman with old cordova-ios projects? Iuno
On 7/29/13 7:19 PM, "Andrew Grieve" wrote:
>You mean plugins.plist?
>
>No need to deprecate it if it doesn't work right now anyways.
>
>
>On Mon, Jul 29, 2013 at 10:12 PM, Filip Maj wrote:
>
>> Yeah, bac
You mean plugins.plist?
No need to deprecate it if it doesn't work right now anyways.
On Mon, Jul 29, 2013 at 10:12 PM, Filip Maj wrote:
> Yeah, back before we had config.xml, we had a plugins.xml for cordova-ios
> projects, and that¹s where service labels were mapped to classes
>
> On 7/29/13
Yeah, back before we had config.xml, we had a plugins.xml for cordova-ios
projects, and that¹s where service labels were mapped to classes
On 7/29/13 7:09 PM, "Andrew Grieve" wrote:
>I'm not 100% sure of what does, but if it's for setting
>plugin-specific config settings, the code on iOS has al
I'm not 100% sure of what does, but if it's for setting
plugin-specific config settings, the code on iOS has already changed to
remove support for that (only settings in the main config.xml are supported
now).
On Mon, Jul 29, 2013 at 9:22 PM, Filip Maj wrote:
> We currently document support fo
Would this require that we use the node_modules dependency structure?
e.g. Our dependency system works differently from node's. We don't support
A depends on B-v1 and C depends on B-v2.
Would we be able to enforce our as well
as our
constraints?
Some things will be uglier to express as json I t
Sorry for the generic first-post, here's a little more fine-grained
commenting / approval:
> cordova-cli:
>
>- "plugin rm --force" To remove a plugin that is depended on
>
> - Motive here is to be able to remove & re-add plugins in mobile-spec
+1, let's file an issue for that. From Adobe's side
The main difference between plugman & cli is that CLI provides
multi-platform support and plugman doesn't.
I'm not suggesting we change CLI to have platform-specific logic (neither
was Tyler). I *am* suggesting that we can make the platforms aware of when
they exist within a CLI world.
Cordova ce
Shaz,
I've been away a good portion in July but will be around in August. I can
cover iOS testing/release duties while you're away.
-James Jong
On Jul 29, 2013, at 7:26 PM, Shazron wrote:
> iOS 7 beta 4 out today, I'd say we probably can start testing with the next
> beta onwards. Checking API
We currently document support for in our spec [1]. This is
to support old cordova-ios (2.2 I believe).
It would save with some lame special-case code [2] [3] [4].
Warn folks using plugman w/ plugins using elements that
support is being removed soon? 3 releases for deprecation ya, so around
3.3
Compatibility with npm sounds great and I fully support it.
We still need to be conscious of old plugin.xml compatibility, though
Interesting thing there is putting plugman or cordova-cli into plugins'
package.json as dependencies, which would give you all tools you need to
do cool things like au
Ya, the Node characters in this story that I'm talking w/ are dshaw,
mikeal, izs, and joemccann. All pushing we go this route and YES its
super easier than it sounds. =P
Agree on discovery getting a little harder but this isn't an exclusive
move but rather an additive operation. That is to say, th
I spoke with @dshaw about this and told him why it was (currently) not
an option for Cordova.
Specifically (un)install actions and dependency management are
different. It seems like a a lot of overhead to get npm to do what
plugman (un)install does.
Everything else is pretty much the same and mov
I have a parallel conversation rolling w/ the node guys and they're
hoping to convince us to move everything to the npm registry itself.
(Or at least be compatible to do so.)
I think this is a worthwhile goal but it does mean:
- plugin.xml gets either deprecated for package.json or we continue
to
iOS 7 beta 4 out today, I'd say we probably can start testing with the next
beta onwards. Checking API diffs, tons of new APIs added/removed in this
release, so I wouldn't call it "stable" yet.
On Mon, Jul 29, 2013 at 4:22 PM, Brian LeRoux wrote:
> Also, think we are following the tradition of
I'd rather we kept our native platform abstractions in the actual
native platform code. The CLI is ignorant to the implementation
details of the native platforms so that the abstractions stay with the
code they work against. If we've learned anything these past five
years its that Eclipse, Android
Also, think we are following the tradition of not shipping a platform
update (3.1) until end of Sept. Though consensus otherwise could make
this statement irrelevant. Either way, we probably want to wait for
iOS7 to drop.
On Mon, Jul 29, 2013 at 6:07 PM, Shazron wrote:
> If any of the committers
Yes that is the process for now. Hopefully we'll be able to support
IDEs in CLI as well in the future.
On Mon, Jul 29, 2013 at 2:58 PM, Filip Maj wrote:
> +1, totally agree, this was the main use case for separating our plugman
> vs cli tooling in the first place I thought..
>
> On 7/29/13 12:05
If any of the committers want read-write privileges to the ios-sim and
ios-deploy repos, let me know...
On Mon, Jul 29, 2013 at 2:10 PM, Shazron wrote:
> Hi guys,
> I'll be away from Aug 1st and back on Aug 26th, where my work hours will
> be UTC+08:00 (Singapore time) based.
>
> Not sure when
Definitely agree that the presentation bits need a ton of work. I
bikeshedded the whole thing. Essentially the web frontend can be
completely tossed. The reusable bits are the bits integrating with the
couch db.
I really want to have medic run on top of cordova-cli, but there are
limitations there
Agree.
For the last point. There is a tag added to the spec to
facilitate search. Has to be added by plugin author.
I am going to drop the current names for the registry and republish
them with the new convention. Unless anyone has any objections. We'll
implement that prefixing right after.
On Mo
+1, totally agree, this was the main use case for separating our plugman
vs cli tooling in the first place I thought..
On 7/29/13 12:05 PM, "Brian LeRoux" wrote:
>Woah woah, not my perception at all. If you want to work in native projs
>then use plugman directly. CLI tools are designed to avoid
I think what would work is:
- use ids to uniquely identify
- prepending org.apache.cordova.core or w/e our core plugin namespace is
as a fallback attempt to match makes sense
- finally, for discovery/searching, we should do searches vs a plugin's
field and do our best to enforce good descriptions
Nah, the blue water in Singapore has long lost its corals and is now algae
green -- not my cup of tea. Just vacation, and working remotely from there
for a couple of weeks after.
On Mon, Jul 29, 2013 at 2:43 PM, Michal Mocny wrote:
> Are you moving to Singapore?!
>
>
> On Mon, Jul 29, 2013 at 5
Are you moving to Singapore?!
On Mon, Jul 29, 2013 at 5:10 PM, Shazron wrote:
> Hi guys,
> I'll be away from Aug 1st and back on Aug 26th, where my work hours will be
> UTC+08:00 (Singapore time) based.
>
> Not sure when 3.1.0 is slated to be released, but it's likely I will miss
> the window f
This is the data from my testing of the Android bridge, with some
explanatory details.
Shared from my personal account.
https://docs.google.com/spreadsheet/ccc?key=0Au2WqzdGt6FvdDEzMEswUkViTmZLMzI0dEpTNFlrSkE&usp=sharing
Hi guys,
I'll be away from Aug 1st and back on Aug 26th, where my work hours will be
UTC+08:00 (Singapore time) based.
Not sure when 3.1.0 is slated to be released, but it's likely I will miss
the window for helping out with the release -- if someone can pick up the
release/testing baton for iOS t
Right but npm registry uses JSON not XML. I think prefixing core
plugins when no package name is provided is a good idea.
On Mon, Jul 29, 2013 at 1:08 PM, Marcel Kinard wrote:
> That could be accomplished with XSLT. And XPath has basic query capability.
> James Jong and I have skills in those.
>
That could be accomplished with XSLT. And XPath has basic query capability.
James Jong and I have skills in those.
On Jul 26, 2013, at 2:19 PM, Filip Maj wrote:
> Ahh yeah. Some kind of at-publish-time conversion of certain plugin.xml
> fields to json fields?
>
> On 7/26/13 10:27 AM, "Anis KAD
FYI: @msierra, I added a shout-out to your style guide from the
ContributorWorkflow and CommitterWorkflow wiki pages.
Begin forwarded message:
> From: Apache Wiki
> Subject: [Cordova Wiki] Update of "ContributorWorkflow" by MarcelKinard
> Date: July 29, 2013 3:35:18 PM EDT
> To: Apache Wiki
>
That is not a bad idea. We would just need to update the uninstall
action to support that "prefix" as well. I like the use of id for its
uniqueness, it's just not as user-friendly as just typing a name.
On Mon, Jul 29, 2013 at 12:10 PM, Andrew Grieve wrote:
> Great summary Fil.
>
> Sounds to me l
Options could be:
- Buffer PluginResults using a good scheme (perhaps the RAF method), and
just don't clobber. Without spam, hopefully backup isn't common (for good
apps, that would be true..)
- Support querying list of currently queued PluginResults, so plugin can
chose how to replace itself. T
Great summary Fil.
Sounds to me like what we should do is use the id for the npm "name".
For the lazy, we could special-case core plugins, so that if you leave off
the fqn, plugman will prepend "org.apache.cordova.core".
On Mon, Jul 29, 2013 at 3:02 PM, Filip Maj wrote:
> I'll try to summarize
Woah woah, not my perception at all. If you want to work in native projs
then use plugman directly. CLI tools are designed to avoid IDE land and
associated pain from cat/mouse release antics. Combined usage will be too
leaky an abstraction.
On Jul 29, 2013 3:02 PM, "Andrew Grieve" wrote:
> On Mon
I considered clobber, but I think it falls apart in this case:
E.g. for sockets, your callback sends back as much *new* data as is ready.
With clobbers, how do you know what the JS side has already been sent?
We could probably do similar timing + logging to detect slow plugins in
this case.
On
I'll try to summarize where we were before and where we are at currently.
In The Beginning:
- we spec'ed an `id` attribute to the plugin manifest under the pretense
of having a unique identifier (generally a good idea), and a preemptive
approach at easing a situation where we have a multi-registry
On Mon, Jul 29, 2013 at 1:30 PM, Tyler Wilson wrote:
> See below.
>
> On Jul 29, 2013, at 12:56 PM, Brian LeRoux wrote:
>
> > Hey Tyler, thanks for capturing this. And yup filing relevant issues
> > very welcome! I have some responses below inline:
> >
> >
> >> You would need to create a new proj
I have been reviewing the medic components and the procedures for testing
the various parts of the Cordova project. With the changes in 3.0, there
are plugins that need to be handled and as already mentioned, I would like
to expand to include the tooling as well. One side effect of this is error
re
thats 58% of the round-trip
On Mon, Jul 29, 2013 at 2:12 PM, Michal Mocny wrote:
> Just to be clear, thats 58% of *total* exec round trip time (580ms) , or
> 58% of only the native bits?
>
> If its over half of the total, thats ridiculous.
>
> -Michal
>
>
> On Mon, Jul 29, 2013 at 11:36 AM, Dav
On Mon, Jul 29, 2013 at 7:29 AM, Andrew Grieve wrote:
> On Sun, Jul 28, 2013 at 12:32 AM, Joe Bowser wrote:
>
>> OK, since we're not talking about each individual one in their own
>> thread (or at least a thread I can find), let's talk about them here:
>>
>> On Thu, Jul 25, 2013 at 10:48 AM, Andr
Just to be clear, thats 58% of *total* exec round trip time (580ms) , or
58% of only the native bits?
If its over half of the total, thats ridiculous.
-Michal
On Mon, Jul 29, 2013 at 11:36 AM, David Kemp wrote:
> I have been doing some testing on the bridge to see how the current
> implementa
While I like that idea, what happens when creating the plugin result is
"heavy", perhaps needing to synchronize with background threads etc?
Waiting on the callbacks may not be a great plan.
Could an alternative be to just support a "clobber" boolean flag, to
replace old PluginResult (instead of
My understand was that: events fire faster than UI paints, and general good
design is to coalesce and update UI once on RAF. In this case, the events
came from native and were sent across the bridge, which meant the while the
app js could do the coalescing, doing it on the native side meant huge p
I have encountered a problem twice where the bridge throws an error on the
JS side and continues to attempt to process the message forever. It
generates 10s of thousands of log message that say :
processMessage failed: Error:
CB-4005 may also be reporting the same issue, but in that case I su
:D
D'aw my baby is growing up :)
On 7/29/13 9:54 AM, "Andrew Grieve" wrote:
>https://issues.apache.org/jira/browse/INFRA-6602
>
>
>On Mon, Jul 29, 2013 at 12:01 PM, Filip Maj wrote:
>
>> +1
>>
>> On 7/29/13 8:43 AM, "Brian LeRoux" wrote:
>>
>> >Yes
>> >On Jul 29, 2013 10:45 AM, "Andrew Grieve
Tommy-Carlos: Just so I understand, are you saying that it is necessary to
run a script to move your icons around correctly? Isn't that defeating the
point of the merges folder? Are you using merges/ specifically for its
merging ability, or just as a place to hold resources -- and isn't the
www/.
See below.
On Jul 29, 2013, at 12:56 PM, Brian LeRoux wrote:
> Hey Tyler, thanks for capturing this. And yup filing relevant issues
> very welcome! I have some responses below inline:
>
>
>> You would need to create a new project to get the updated template files,
>> correct?
>
> This is cor
Hey Tyler, thanks for capturing this. And yup filing relevant issues
very welcome! I have some responses below inline:
> You would need to create a new project to get the updated template files,
> correct?
This is correct. I believe we have a backlog item for implementing an
`upgrade` command.
https://issues.apache.org/jira/browse/INFRA-6602
On Mon, Jul 29, 2013 at 12:01 PM, Filip Maj wrote:
> +1
>
> On 7/29/13 8:43 AM, "Brian LeRoux" wrote:
>
> >Yes
> >On Jul 29, 2013 10:45 AM, "Andrew Grieve" wrote:
> >
> >> Fil alluded to this last week I think, but wanted to confirm. Should we
Good day,
I am just getting back to updating some projects to the latest Cordova. I have
a few item reports. I can put them in the bug tracker if needed, but wanted to
get them all here just in case.
- I had previously installed cordova 2.9 via npm. It took me a few minutes to
find how to upda
Mike - Assuming you've recovered from the bachelor party, could you help me
get the docs published today?
I haven't done anything with the commits besides adding them to master /
edge. Do I need to manually apply them to the 3.0 directory or merge into
the 3.0.x branch?
Thanks!
On Sat, Jul 27,
If you do
$ cordova -d blah
It will output more logs..
On 7/29/13 9:10 AM, "Tyler Wilson" wrote:
>Unfortunately, in my attempt to get the latest Codova files installed, I
>killed the whole ~/.cordova folder. It had an incomplete /lib/www/3.0
>folder, so I killed it and am doing the cordova cr
Unfortunately, in my attempt to get the latest Codova files installed, I killed
the whole ~/.cordova folder. It had an incomplete /lib/www/3.0 folder, so I
killed it and am doing the cordova create command again to get it re-populated.
Would be nice to have a log statement saying that it is inst
Run:
$ cd /Users/tylerwilson/.cordova/lib/android/cordova/2.9.0/framework
$ ant jar
And report back the error message you get. It is likely something to do
with your dev environment, but perhaps we can figure out how to fail
gracefully in your case with the cli tools
On 7/29/13 8:24 AM, "Tyler
+1
On 7/29/13 8:43 AM, "Brian LeRoux" wrote:
>Yes
>On Jul 29, 2013 10:45 AM, "Andrew Grieve" wrote:
>
>> Fil alluded to this last week I think, but wanted to confirm. Should we
>>be
>> creating a cordova-medic repo?
>>
Yes
On Jul 29, 2013 10:45 AM, "Andrew Grieve" wrote:
> Fil alluded to this last week I think, but wanted to confirm. Should we be
> creating a cordova-medic repo?
>
Yes, we do.
On Jul 29, 2013 7:38 AM, "Andrew Grieve" wrote:
> Fil alluded to this last week I think, but wanted to confirm. Should we be
> creating a cordova-medic repo?
>
I did the update on the Nexus 10 and will be testing on it today. I don't
expect any major surprises.
On Jul 29, 2013 8:25 AM, "Mike Billau" wrote:
> Hello, we were wondering if anybody has been performing testing on Android
> 4.3? and if so, how it has it been looking? I can start testing on a N
I have been doing some testing on the bridge to see how the current
implementation stands up.
For large data going to native, the highest single time impact is the
conversion of the string rawArgs to a JSONArray.
Currently Echo, FileUtils, FileTransfer are likely to be impacted by this.
The plug
FYI. http://www.w3.org/TR/2013/CR-vibration-20130723/
I added this to the RoadmapProjects API as a potential.
Hello, we were wondering if anybody has been performing testing on Android
4.3? and if so, how it has it been looking? I can start testing on a Nexus
7 and maybe a few other devices today and post results in this thread, for
lack of a better place. Thanks!
I just tried using Cordova CLI to create a new project and add iOS and Android
targets. I get the following:
$ cordova create TestApp com.pulserobotics.com TestApp
$ cd TestApp
$ cordova platform add ios
$ cordova platform add android
[Error: An error occured during creation of android sub-projec
Ok
On Mon, Jul 29, 2013 at 9:12 PM, Michael Sierra wrote:
> Yes, you can close it up, thanks
>
>
> From: Sharif Ahmed [sharifdu...@gmail.com]
> Sent: Friday, July 26, 2013 12:29 PM
> To: dev@cordova.apache.org
> Subject: Re: Is Formatting issue fixed?
>
Yes yes, I totally overlooked.
Ok I will do it by tomorrow and let you guys know.
Thanks for reminder me :)
On Mon, Jul 29, 2013 at 8:15 PM, Andrew Grieve wrote:
> Sharif, fixes look good. I think you need to sign the Apache ICLA before we
> can pull the code in though:
>
> http://www.apache.
Yes, you can close it up, thanks
From: Sharif Ahmed [sharifdu...@gmail.com]
Sent: Friday, July 26, 2013 12:29 PM
To: dev@cordova.apache.org
Subject: Re: Is Formatting issue fixed?
Ok, should I close my issue?
On 7/26/13, Michael Sierra wrote:
> The fix i
On Thu, Jul 25, 2013 at 3:06 PM, Shazron wrote:
> Comments inline.
>
>
> cordova-ios:
> >
> > - Move header symbols into .m files where possible (reduce API surface)
> >
> > Makes sense now since the core code shouldn't be called into with the
> exception of some classes like CDVPlugin.h
>
>
>
>
Fil alluded to this last week I think, but wanted to confirm. Should we be
creating a cordova-medic repo?
I'm not sure the exact details, but it was something Andrew Trice said he
did in his PGD talk. I may not have understood correctly. I think the issue
might be that our bridge doesn't have any throttling built in.
On Mon, Jul 29, 2013 at 12:01 AM, Jesse MacFadyen
wrote:
> Hopefully the subject ch
On Sun, Jul 28, 2013 at 12:32 AM, Joe Bowser wrote:
> OK, since we're not talking about each individual one in their own
> thread (or at least a thread I can find), let's talk about them here:
>
> On Thu, Jul 25, 2013 at 10:48 AM, Andrew Grieve
> wrote:
> >
> > cordova-android:
> >
> > - Change
Sharif, fixes look good. I think you need to sign the Apache ICLA before we
can pull the code in though:
http://www.apache.org/licenses/#clas
As noted on: http://wiki.apache.org/cordova/ContributorWorkflow
On Sun, Jul 28, 2013 at 3:22 AM, Sharif Ahmed wrote:
> Hi,
>
> Need a review to my rec
oh yes thats hawt! =)
On Sat, Jul 27, 2013 at 9:09 PM, Anis KADRI wrote:
> It's there nao! Tests are all passing.
>
> On Sat, Jul 27, 2013 at 6:38 AM, Brian LeRoux wrote:
>> Wiki for now. Discovery via homepage link to the wiki.
>>
>> Anis: hows the merge goin?
>> On Jul 27, 2013 12:02 AM, "Shar
thank you.
Am 29.07.2013 um 10:47 schrieb Shazron:
> Fixed, ie get the new cordova-plugin-splashscreen plugin bits
>
>
> On Mon, Jul 29, 2013 at 1:46 AM, Shazron wrote:
>
>> Fixed.
>> https://issues.apache.org/jira/browse/CB-4355
>> https://issues.apache.org/jira/browse/CB-4374
>>
>>
>> On
Fixed, ie get the new cordova-plugin-splashscreen plugin bits
On Mon, Jul 29, 2013 at 1:46 AM, Shazron wrote:
> Fixed.
> https://issues.apache.org/jira/browse/CB-4355
> https://issues.apache.org/jira/browse/CB-4374
>
>
> On Mon, Jul 29, 2013 at 1:36 AM, Oliver Müller wrote:
>
>> Hello,
>> I jus
Fixed.
https://issues.apache.org/jira/browse/CB-4355
https://issues.apache.org/jira/browse/CB-4374
On Mon, Jul 29, 2013 at 1:36 AM, Oliver Müller wrote:
> Hello,
> I just updated my cordova project to 3.0.3 and noticed that preferences
> like
>
>
> stopped working on iOS.
>
> I'm using XCode
Hello,
I just updated my cordova project to 3.0.3 and noticed that preferences like
stopped working on iOS.
I'm using XCode to compile and tested on device and simulator.
Is there a way to force preferences directly in MainViewController?
thanks,
Oliver
78 matches
Mail list logo
