from:"Andrew Grieve"

Re: Plugin Audit 2015

2015-11-10 Thread Andrew Grieve

Nice work! Couldn't resist checking out the results of the
thought-it-would-never-happen audit :).

On Tue, Nov 10, 2015 at 9:25 AM, Raymond Camden 
wrote:

> "Globalization (make sync"
>
> YES, YES, YES!
>
> (Sorry, but that makes me *very* happy to hear!)
>
> "Dialogs (Should use HTML/CS/JS dialogs instead)"
>
> Strongly no, but I'm assuming there is a good reason for this beyond
> just what is listed in the parenthesis. Yes, UI frameworks normally
> have their own dialog widgets, but the fact that I can use a device
> standard dialog is a big plus for me. I'll even use it over Ionic's
> even when inside an Ionic app.
>
>
> On Fri, Nov 6, 2015 at 4:53 PM, Steven Gill 
> wrote:
> > Jesse, Simon and I spent sometime doing a plugin audit. Our
> recommendations
> > can be found at https://github.com/cordova/cordova-discuss/pull/28
> >
> > Overview:
> >
> https://github.com/stevengill/cordova-discuss/blob/master/proposals/PluginsAudit2015/overview.md
> >
> > Please give us feedback!
> >
> > -Steve
>
>
>
> --
> ===
> Raymond Camden, Developer Advocate for MobileFirst at IBM
>
> Email : raymondcam...@gmail.com
> Blog : www.raymondcamden.com
> Twitter: raymondcamden
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: CordovaPlugin lifecycle differs from Activity lifecycle

2015-08-24 Thread Andrew Grieve

I noted this as weird as well, but it's just always been this way in
Cordova. I think it came from the fact that on iOS you only get a resume
after a pause.

You can always use
http://developer.android.com/reference/android/app/Application.html#registerActivityLifecycleCallbacks%28android.app.Application.ActivityLifecycleCallbacks%29
to listen to the callbacks directly though.

On Mon, Aug 24, 2015 at 1:27 PM, Joe Bowser bows...@gmail.com wrote:

 Sorry, I was sick for a couple of days.

 That sounds like a bug.  onStart and onResume should be called on the
 plugins, and this most likely got broken when the last refactor.  Do you
 have an issue open in JIRA for this?

 On Sun, Aug 23, 2015 at 1:35 PM Kai Schlamp schl...@gmx.de wrote:

  The CordovaPlugin has the same onStart and onResume callback methods as
  Androids Activity class. Unfortunately those differ from the Activity
  Lifecycle (see
 
 
 http://developer.android.com/reference/android/app/Activity.html#ActivityLifecycle
  ).
  The onStart and onResume methods of CordovaPlugin are not called when the
  app starts for the first time (in contrast to the appropriate Activitiy
  methods).
  Wouldn't it make sense to have the same lifecycle as an Activity (which
 is
  quite right in my opinion)?
 
  Best regards,
  Kai

Re: [Android] Working with M - An update

2015-08-18 Thread Andrew Grieve

Yes! It's fixed :) Great work Joe on finding this!

On Tue, Aug 18, 2015 at 10:51 AM, Karen Tran ktop...@gmail.com wrote:

 I just tried the manual geolocation tests on mobilespec with the 3rd
 preview and I am able to get location data now.
 Thanks for the help Andrew!

 On Mon, Aug 17, 2015 at 11:29 AM, Carlos Santana csantan...@gmail.com
 wrote:

  Hey Andrew any update on this, Do you have a link we can track progress?
 Or
  do you know if latest preview dropped contains this fix?
 
  By the way when is Android M suppose to be General Available?
 
 
  On Fri, Jul 24, 2015 at 1:56 PM Andrew Grieve agri...@chromium.org
  wrote:
 
   Was out last week, but did manage to escalate the geolocation bug. Will
   hopefully be fixed for official M release :)
  
   On Thu, Jul 16, 2015 at 1:31 PM, Joe Bowser bows...@gmail.com wrote:
  
Sent you the test app off-list.
   
On Wed, Jul 15, 2015 at 11:12 AM Andrew Grieve agri...@chromium.org
 
wrote:
   
 Thanks for looking into this Joe! The runtime permissions is quite
 a
   big
 change!

 M is still in preview, so if you find any webview bugs, please feel
   free
to
 send me a repro app and I'll do my best to get it fixed.

 In terms of Cordova API changes, here's some thoughts on your
 branch:
 - Plugins may want to request different perms at different times,
 so
   I'd
 remove new functions from CordovaPlugin except
   onRequestPermissionResult
 - Might be better to copy how CordovaInterfaceImpl does
 startActivityForResult/onActivityResponse rather than have
   PluginManager
do
 it.


 On Tue, Jul 14, 2015 at 6:07 PM, Joe Bowser bows...@gmail.com
  wrote:

  So, since Cordova-Android wasn't completely killed off by Google
 at
   the
  last Google IO like I thought it would be, we're going to have to
   make
 sure
  it's compatible with Android M (Marshmellow? Marzipan?).  The
 good
   news
 is
  that this only affects the following plugins:
 
  MediaRecorder
  Contacts
  File
  FileTransfer
  Geolocation
 
  Now, for the really bad news.  We might have to write a
 Geolocation
 plugin
  for Android again, because Google's Android WebView doesn't play
  nice
 with
  Android's new permission system, and even when you do grant the
 application
  containing the process permission to use geolocation, you still
  get a
  location error.  I still have to test this further, but it also
 may
   be
  possible that file URIs no longer have the ability to get the
geolocation
  either, which would be weird, since this would be a Chrome thing
  and
not
 an
  Android thing.
 
  Given our poor track record of maintaining plugins in general,
 and
   the
  weird errors with Geolocation, I'm not really wanting to bring
 back
   the
  code, so I'm hoping that this gets resolved in M3 with the next
 dev
 version
  of M.
 
  But so far, I have the changes that I made to Cordova on a
 private
branch
  on Github that people can see here:
 
  https://github.com/infil00p/cordova-android/tree/m-compat
 
  Let me know if you have any questions.  I'm not sure whether this
   makes
  perfect sense yet, but I think these API changes indicate that we
should
  probably bump the version to 5.0 once M comes out.
 
  Thoughts? Questions?

Re: Android Project Structures, Libraries and the Embedded Case

2015-08-13 Thread Andrew Grieve

The structure isn't a big deal to me, because it seems to work fine in
Android Studio how it is.

Moving plugins to maven as .aar files is actually possible now by using a
maven ref in a framework within you plugin.xml.




On Thu, Aug 13, 2015 at 2:05 PM, Joe Bowser bows...@gmail.com wrote:

 Hey

 So, as you know, Google switched from supporting Eclipse to supporting
 their IntelliJ based Android Studio IDE, and in an effort to keep up, we
 followed them, somewhat.  One thing we didn't do is update our project
 structure so it works similar to an Android Studio one, and there's a
 reason we didn't do that.

 The reason is that Android didn't do that.  If you autogenerate an Android
 project from the command line, even if you use Gradle (which should be the
 default, but still isn't for some reason), you still get the old
 eclipse-style structure that we're currently using.  I've been making tiny
 changes so that we can use Cordova as a library, but then there's these
 development problems that I really don't have the answers to:

 1. Where do tests live for plugins? People who contribute want JUnit tests
 to make sure the native code works.  I want them as well, but our current
 plugin system has no support for this and people don't seem super
 interested in changing this when I have off-list private conversations,
 which is why I'm bringing it up here.

 2. Should plugins be AAR/Projects instead of just code?  Honestly, I think
 this would make more sense than trying to guess what the structure of a
 Java project is.  I want to support users regardless of how they create
 their Android project instead of just saying that using the Cordova CLI is
 the one and only way, and I think people who use this in Enterprise
 environments would agree with me.  Although, I haven't explicitly asked
 anyone, which is why I'm bringing this up here.

 3. If we keep the current way of loading Android code as plugins, how do we
 support all the IDE structures? Currently cordova-lib only supports the
 current Android project structure, and if I was to extend it, Android
 Studio would have to be its own platform, which isn't correct, since it's
 just a different project directory structure.

 I'm interested in what people think in this, and whether we should bother
 with these use cases, or just say that everyone has to use the old
 structure until Google changes their minds, or whatever.

 Thoughts?

 Joe

Re: [Android] Working with M - An update

2015-07-24 Thread Andrew Grieve

Was out last week, but did manage to escalate the geolocation bug. Will
hopefully be fixed for official M release :)

On Thu, Jul 16, 2015 at 1:31 PM, Joe Bowser bows...@gmail.com wrote:

 Sent you the test app off-list.

 On Wed, Jul 15, 2015 at 11:12 AM Andrew Grieve agri...@chromium.org
 wrote:

  Thanks for looking into this Joe! The runtime permissions is quite a big
  change!
 
  M is still in preview, so if you find any webview bugs, please feel free
 to
  send me a repro app and I'll do my best to get it fixed.
 
  In terms of Cordova API changes, here's some thoughts on your branch:
  - Plugins may want to request different perms at different times, so I'd
  remove new functions from CordovaPlugin except onRequestPermissionResult
  - Might be better to copy how CordovaInterfaceImpl does
  startActivityForResult/onActivityResponse rather than have PluginManager
 do
  it.
 
 
  On Tue, Jul 14, 2015 at 6:07 PM, Joe Bowser bows...@gmail.com wrote:
 
   So, since Cordova-Android wasn't completely killed off by Google at the
   last Google IO like I thought it would be, we're going to have to make
  sure
   it's compatible with Android M (Marshmellow? Marzipan?).  The good news
  is
   that this only affects the following plugins:
  
   MediaRecorder
   Contacts
   File
   FileTransfer
   Geolocation
  
   Now, for the really bad news.  We might have to write a Geolocation
  plugin
   for Android again, because Google's Android WebView doesn't play nice
  with
   Android's new permission system, and even when you do grant the
  application
   containing the process permission to use geolocation, you still get a
   location error.  I still have to test this further, but it also may be
   possible that file URIs no longer have the ability to get the
 geolocation
   either, which would be weird, since this would be a Chrome thing and
 not
  an
   Android thing.
  
   Given our poor track record of maintaining plugins in general, and the
   weird errors with Geolocation, I'm not really wanting to bring back the
   code, so I'm hoping that this gets resolved in M3 with the next dev
  version
   of M.
  
   But so far, I have the changes that I made to Cordova on a private
 branch
   on Github that people can see here:
  
   https://github.com/infil00p/cordova-android/tree/m-compat
  
   Let me know if you have any questions.  I'm not sure whether this makes
   perfect sense yet, but I think these API changes indicate that we
 should
   probably bump the version to 5.0 once M comes out.
  
   Thoughts? Questions?

Re: [Android] Working with M - An update

2015-07-15 Thread Andrew Grieve

Thanks for looking into this Joe! The runtime permissions is quite a big
change!

M is still in preview, so if you find any webview bugs, please feel free to
send me a repro app and I'll do my best to get it fixed.

In terms of Cordova API changes, here's some thoughts on your branch:
- Plugins may want to request different perms at different times, so I'd
remove new functions from CordovaPlugin except onRequestPermissionResult
- Might be better to copy how CordovaInterfaceImpl does
startActivityForResult/onActivityResponse rather than have PluginManager do
it.


On Tue, Jul 14, 2015 at 6:07 PM, Joe Bowser bows...@gmail.com wrote:

 So, since Cordova-Android wasn't completely killed off by Google at the
 last Google IO like I thought it would be, we're going to have to make sure
 it's compatible with Android M (Marshmellow? Marzipan?).  The good news is
 that this only affects the following plugins:

 MediaRecorder
 Contacts
 File
 FileTransfer
 Geolocation

 Now, for the really bad news.  We might have to write a Geolocation plugin
 for Android again, because Google's Android WebView doesn't play nice with
 Android's new permission system, and even when you do grant the application
 containing the process permission to use geolocation, you still get a
 location error.  I still have to test this further, but it also may be
 possible that file URIs no longer have the ability to get the geolocation
 either, which would be weird, since this would be a Chrome thing and not an
 Android thing.

 Given our poor track record of maintaining plugins in general, and the
 weird errors with Geolocation, I'm not really wanting to bring back the
 code, so I'm hoping that this gets resolved in M3 with the next dev version
 of M.

 But so far, I have the changes that I made to Cordova on a private branch
 on Github that people can see here:

 https://github.com/infil00p/cordova-android/tree/m-compat

 Let me know if you have any questions.  I'm not sure whether this makes
 perfect sense yet, but I think these API changes indicate that we should
 probably bump the version to 5.0 once M comes out.

 Thoughts? Questions?

Re: [iOS 4.x] cordova-plugin-whitelist deficiencies

2015-07-08 Thread Andrew Grieve

On Wed, Jul 8, 2015 at 4:47 AM, Shazron shaz...@gmail.com wrote:

 FYI, we get to revisit this whitelist stuff again for iOS 9 with it's
 Application Transport Security (ATS):

 https://developer.apple.com/library/prerelease/ios/technotes/App-Transport-Security-Technote/index.html#//apple_ref/doc/uid/TP40016240

 Should be relatively simple -- convert access tags to the appropriate
 Info.plist tags and not filter the request in CDVURLProtocol (which doesn't
 work for WKWebView anyway).


Neat!



 On Wed, Jul 8, 2015 at 1:43 AM, Shazron shaz...@gmail.com wrote:

  Related: https://issues.apache.org/jira/browse/CB-9329
 
  From the README: https://github.com/apache/cordova-plugin-whitelist
 
  The Android whitelist supports allow-navigation, allow-intent and
  access.
  The iOS whitelist supports allow-navigation only currently.

This is certainly the most important one.


 
  The docs mention access SHOULD be supported, but CSP is the way to go.
 
  Therefore access needs to be supported on iOS for native code requests
  (see failing FileTransfer tests CB-9329) since CSP is only in the context
  of the UIWebView. This is duplication of definitions unless we read the
  meta tag from native and dynamically create the allowRequests whitelist
  plugin.


I think it'd be fine to just say iOS doesn't support access, so use CSP
(although sounds like there is a way to add it via .plist, might be pretty
low priority)


 
  allow-intent I think is the domain of the InAppBrowser plugin only
  (window.open).


This one was meant to enable things like tel: URLs that result in other
applications being opened, so more the domain of the main webview I think
(although I'm less knowledgeable about why we even want this whitelist, so
not sure how important it is to implement)


 
  Am I missing anything?

Re: Installation Preference in config.xml

2015-06-23 Thread Andrew Grieve

Doesn't ring a bell (I've never seen it).

On Tue, Jun 23, 2015 at 2:30 PM, Joe Bowser bows...@gmail.com wrote:

 Hey

 When working on CB-9220, I noticed that there was a configuration that I
 didn't recognize.  When did we add the android-installLocation preference,
 and where does this logic exist? I'm asking because I don't use the CLI for
 testing (because I need to be able to debug using Android Studio), and I
 need to chase this preference down.

 Anyone have any idea where this is being set?  I suspect it's not in the
 build scripts bundled with Android.

 Joe

Re: Cordova issue.

2015-06-22 Thread Andrew Grieve

+ dev@ mailing list

There have been (fixed) bugs with the online bridge in the past. Are you
running a recent version of cordova-android?
https://issues.apache.org/jira/browse/CB-6761
https://issues.apache.org/jira/browse/CB-6746

As a quick fix, you can switch to use the PROMPT-based bridge.

On Sun, Jun 21, 2015 at 6:31 PM, David Hadas david.ha...@gmail.com wrote:

 Hi agrieve,

 While hunting what initialy appeared to be a file plugin bug on a an S3
 Neo android 4.3 device, we had learned that OnlineEventsBridgeMode seem to
 be broken on that device. We noticed that from a certain point in time,
 the boolean *online* was always set to false during toggleNetworkRunnable
 { ...webView.setNetworkAvailable(*online*) } - hence *online* was no
 longer toggled via notifyOfFlush - consequently there were no more
 webView *online *events sent out to the JS. From that moment events from
 JAVA to JS were delivered only when someone from the JS was
 calling androidExec (cordova.js) and we were always missing the last set of
 events as there were stuck down at the JAVA queue.

 We realized that the OnlineEventsBridgeMode depends on the boolean
 *online* always being maintained as an inverse of the WebView
 online-state. Once it is reversed for any reason/bug, the system never
 corrects itself.

 Till now we were unable to track down the exact sequance leading to the
 reversal event, but we do notice a sequance of two consecutive calls to 
 notifyOfFlush,
 flipping *online* twice - thereafter *online* is left unchanged (stuck on
 teh wrong value).

 In fact we are somewhat uncomfirtable with the design choice of using
 online toggling and blindly trying to keep the *online* variable as an
 inverse of the WebView state. Our main conccern there is that this design
 does not converge to a stable state and does not follow a KISS methodology
 which may be painful in view of the asynchnous environment, dependency on
 different WebView implementations etc, as a result  implementation issues
 and bugs such as the one we encuntered are more likely. We are wondering
 about a simpler design choice of replacing:
 webView.setNetworkAvailable(*online*);
 with:
 webView.setNetworkAvailable(*true*);   // trigger an event
 webView.setNetworkAvailable(*false*);  // reset the webView to its
 default state
 thereafter removing redundent code such as the notifyOfFlush mechanism
 which would no longer be needed, the JS event listener for offline etc.

 This apperently solved the problem with that S3 NEO android 4.3  - but may
 be a better strategy to follow alltogether.
 If so, we might be able to take the challange and suggest a patch or
 better so, work with an existing contributer to create one.

 Please advise,
 David Hadas

Re: [iOS] Remove non-CLI template

2015-06-17 Thread Andrew Grieve

I think the difference between the two templates is that the CLI template
adds extra navigator entries to point to ../../www and ../../config.xml.

Might still be worth not keeping two templates though, and just have these
entries be red for non-CLI projects (doesn't break builds).

On Tue, Jun 16, 2015 at 2:18 PM, Shazron shaz...@gmail.com wrote:

 I propose to remove the non-CLI template starting in cordova-ios 4.0.0.

 It was originally used to easily test your own plugins, but now we have the
 alternative using the CLI:

 cordova plugin add --link path/to/your/plugin

Re: [iOS 8] WKWebView moving forward

2015-06-11 Thread Andrew Grieve

Could maybe try creating symlinks / hardlinks to save on space / creation
time?

On Wed, Jun 10, 2015 at 12:00 PM, Shazron shaz...@gmail.com wrote:

 Safari View Controller video:
 https://developer.apple.com/videos/wwdc/2015/?id=504

 What's New in Web Development in WebKit and Safari video:
 https://developer.apple.com/videos/wwdc/2015/?id=501


 On Tue, Jun 9, 2015 at 3:59 PM, Shazron shaz...@gmail.com wrote:

  I definitely will watch.
  Just read about ODR
 
 https://developer.apple.com/library/prerelease/ios/documentation/FileManagement/Conceptual/On_Demand_Resources_Guide/Chapters/IntroToODR.html#//apple_ref/doc/uid/TP40015083-CH2-SW1
 
  So we could still use the copy method (fast, small app bundle) and have a
  solution in Cordova for ODR for app bundles that are huge. For example,
 in
  the CLI prepare step.
 
  Of course this won't be a universal solution and is more complicated.
 
  On Tuesday, June 9, 2015, Carlos Santana csantan...@gmail.com wrote:
 
  What do we loose, I just attended the session.
  I think for most uses is a win at least in the security aspect
  Watch the session when the video is available and we can discuss later.
 
  On Tue, Jun 9, 2015 at 1:23 PM Shazron shaz...@gmail.com wrote:
 
   We could use it for InAppBrowser but we might lose some features that
 we
   have possibly.
  
   Anyways, one piece of bad news for WKWebView iOS 9 - you can load file
  urls
   in Library and Documents, but not the app bundle.
   https://twitter.com/wkwebview/status/608359163299819521
  
   On Tue, Jun 9, 2015 at 1:02 PM, Carlos Santana csantan...@gmail.com
   wrote:
  
Yay !
There is also a new Safari View Controller, don't know if it's
  applicable
to replace wkwebview but at least I think it can be use to build the
  next
gen inappbrowser since its beats a makeup in iOS anyway.
   
The session is in 30 minutes so I'm planning attending.
On Mon, Jun 8, 2015 at 2:33 PM Shazron shaz...@gmail.com wrote:
   
 There is a WWDC session: Safari Extensibility: Content Blocking
 and
Shared
 Links. So I'm hopeful for whitelisting

 On Mon, Jun 8, 2015 at 1:22 PM, Shazron shaz...@gmail.com
 wrote:

  Moar news
 https://twitter.com/wkwebview/status/608005652720451584
 
 
  On Monday, June 8, 2015, Shazron shaz...@gmail.com wrote:
 
  Cordova developers rejoice, iOS 9 includes the API to load
 pages
   from
  file:// urls
   https://twitter.com/wkwebview/status/608002548151119872
 
  On Mon, Feb 9, 2015 at 2:19 PM, Shazron shaz...@gmail.com
  wrote:
 
  Also Xcode 6.3 now *requires* Yosemite. Fair warning to
 upgrade
  I
  suppose for your dev machines and build servers...
 
 
  On Mon, Feb 9, 2015 at 2:13 PM, tommy-carlos williams
  to...@devgeeks.org wrote:
   Oh, FFS.
  
   I give up on Apple solving this, personally. Most apps don’t
  *actually* need it (they think they do, but they don’t). I am
  going
to
 find
  another way to solve it for our apps… maybe I will actually
  have to
 write a
  native plugin for the crypto :(
  
   --
   tommy-carlos williams
  
   On 10 February 2015 at 08:18:31, Shazron (shaz...@gmail.com
 )
wrote:
  
   In other news -- the new Xcode 6.3 beta (iOS 8.3) does *not*
contain
   the loadFileURL:readAccessURL: selector that we are all
  waiting
   for
   :'(
   https://twitter.com/wkwebview/status/564865657225756672

Re: Sticky Channels

2015-06-09 Thread Andrew Grieve

I think the only place sticky channels are used is for startup events
(deviceready, nativeready, pluginsready, etc). I think you could probably
change them to fire multiple times without breaking too much, but the
semantics of that seem really strange to me (fire the most recent event, or
all events? upon registering, but only to the newly added listener(s))

They are not based on any standard, so it might be nice not to use them,
and instead use standard events (e.g. cordova.fireWindowEvent). As long as
we promise not to fire them until after deviceready, apps should be able to
register listeners reliably.

One other data point for this is that I dealt with the as-a-service vs.
as-a-launch in
https://github.com/MobileChromeApps/cordova-plugin-background-app. In this
model, I set a property before each resume / deviceready that can be
queried to find out the app's state. Could possibly do similar for intents
(but would need an event as well since they can come at any time, not just
on start-up)

On Fri, Jun 5, 2015 at 7:18 PM, Jesse purplecabb...@gmail.com wrote:

 I have been looking into unifying launchParameters across devices so that
 all cordova apps can get some context of how they were launched/activated.
 This includes everything from a url/protocol launch in another app, to a
 touch on a notification (toast,local,push,... )

 My intent was to add a channel for this, however I have had some issues
 with channels + stickiness.

 I wanted a channel that would call new subscribers immediately if it had
 already fired.  In our channel implementation this is what we call a sticky
 channel.  However, this particular channel may fire more than once, ie. we
 could be activated multiple times while running, or receive multiple
 notifications.
 The current implementation for sticky will only ever call subscribers once,
 and if I call fire() more than once, it actually removes it's subscribers.
 [1] So I cannot use this as is for my needs.

 So my questions are :
 1. Why is like this? Is there some standard or expectation that this is
 based on?
 2. Can I change it? What would be the impact of changing the behavior to
 have a sticky channel fire more than once, and keep its list of
 subscribers?
 3. Are there historical reasons that things are the way they are? The code
 has been through several major moves since it was written, so it is
 difficult to pin the original commit (Fil, Andrew? some merged pr?)  If
 there are historical reasons, are they still relevant?

 Please keep in mind too that I am not asking for the solution to my
 specific task, I can work around anything ... I am asking solely about the
 current channel-sticky implementation and it we should change it.

 Cheers,
   Jesse


 The current implementation
 [1]
 https://github.com/apache/cordova-js/blob/master/src/common/channel.js#L216


 @purplecabbage
 risingj.com

Re: plugins framework on Android

2015-06-02 Thread Andrew Grieve

We want plugman to always work, even if you don't have the android sdk
installed. So, plugman calling android update project is not allowed.

As of cordova-5.0, this line will be re-written by the build script to its
Gradle equivalent, where no android update project call is necessary
(this was an ANT thing)

One issue we have seen with gradle though, is that people haven't installed
the Support Repository into their SDK. We could consider having the android
build script detect whether the requisite directories exist on the machine,
and show an error earlier in this case.

On Mon, Jun 1, 2015 at 2:40 PM, Axel Nennker ignisvul...@gmail.com wrote:

Hi,

the documentation here

https://cordova.apache.org/docs/en/4.0.0/plugin_ref_spec.md.html#Plugin%20Specification_info_element

says that some tasks needed by framework ... are not done by plugman.

framework src=extras/android/support/v7/appcompat custom=false

But it seems quite easy to do this by calling this command e.g. for Google
Play Services:
$ android update project --path . --library

/home/ignisvulpis/Android/Sdk/extras/google/google_play_services/libproject/google-play-services_lib/
--target android-21

Cordova has all the information that is needed, right?!
Or doesn't this work in all cases?

My latest custom plugin can not be added to my project because plugman's
android.js calls the property-parser which tries to determine the
androidSdkDir which fails because it tries to open local.properties which
was not created (by cordova).
Why doesn't plugman try ANDROID_HOME (too)?

I think that using android update project ... would always work instead
of plugman editing project file directly.

Axel

ps: There are several unanswered
stackoverflow questions regarding Google Play Services and Cordova

http://stackoverflow.com/questions/22002424/admob-with-cordova-3-and-google-play-services

http://stackoverflow.com/questions/30399421/cordova-testing-google-play-game-services

http://stackoverflow.com/questions/25872707/how-to-link-google-play-services-to-cordova-project

Re: [Android] VERSION_CODE generation

2015-06-02 Thread Andrew Grieve

I can shed some light.

The code for it is here:
https://github.com/apache/cordova-android/blob/master/bin/templates/project/build.gradle#L178

There are two times we fiddle with it:
1 - When building multiple architectures (cough crosswalk cough)
2 - When a minSdkVersion is set.

Play store requires that each architecture-dependent .apk has a unique
versionCode, so that's why we do that.
Play store also requires that when using multiple apks, apks with a higher
minSdkVersion have higher versionCodes.

https://github.com/crosswalk-project/cordova-plugin-crosswalk-webview
outlines instructions for building multiple apks:

Install xwalk and run:
cordova build --release

Uninstall xwalk and run:
cordova build --release -- --minSdkVersion=21

This gives three apks where versionCode is bigger in the right cases. The
reason to not want xwalk for 21 is that it has an updating webview anyways.

So, where I was seeing downgrade happen a lot was when going back and forth
between xwalk and system webview.

Sad that adb can't just deal with it on older devices :S. I think it's fine
to just remove the -d flag as you've done.

On Tue, Jun 2, 2015 at 11:01 AM, Joe Bowser bows...@gmail.com wrote:

I just fixed CB-9080 by removing the fix for CB-8834, since I consider
VERSION_DOWNGRADE to be easily worked around while not launching the
application on older devices is an unacceptable fail state.

The thing is why is VERSION_DOWNGRADE happening in the first place, and why
are we generating the versionCode? This code should be linear every time
you actually release something to the play store, and otherwise should stay
the same. I know there was a bunch of messing around with it to sync it to
whatever Apple does, but I don't know if that's the right approach here.

See this form more info on versioning:
http://developer.android.com/tools/publishing/versioning.html

Can anyone explain more about why we're generating the versionCode the way
we are right now?

Re: [DISCUSS] Moving Rat Excludes closer to source

2015-06-01 Thread Andrew Grieve

sgtm!

On Fri, May 29, 2015 at 9:05 PM, Dmitry Blotsky dblot...@microsoft.com
wrote:

 Hi all,

 Right now coho stores rat excludes inside its source code, which often
 goes out of date and we end up with a lot of noise in coho
 audit-license-headers”. Do you think it would be a good idea to instead add
 a “.ratignore” file in each repo, much like .npmignore and .gitignore?

 Kindly,
 Dmitry

Re: Why does coho need coho?

2015-05-29 Thread Andrew Grieve

I think it's because it downloads the RAT tool to coho's directory.

On Thu, May 28, 2015 at 9:52 PM, Dmitry Blotsky dblot...@microsoft.com
wrote:

 Hi all,

 When I run 'coho audit-licence-headers' INSIDE of 'cordova-js' (should
 work since it runs in the current directory by default), I get the
 following error: Repo directory does not exist: cordova-coho. First run
 coho repo-clone. Why does coho need itself to be in the PWD?

 Kindly,
 Dmitry

Re: [BUG] Fail to build Mobilespec with --thirdpartyplugins (CB-9032)

2015-05-29 Thread Andrew Grieve

I think we can mostly cover this by saying anything that's marked as
public or protected is part of the public API. If we don't want it to
be public, we should use package private.

On Wed, May 27, 2015 at 11:21 PM, Joe Bowser bows...@gmail.com wrote:

 The bigger issue is the question of what is a public API.  Android used
 public docs to delineate between public and private APIs and I think we
 should do the same, mostly because I want to draw a line between what we
 can and can't support and not have everything in third-party tests break
 because of a single contributor's opinion.

 This also means that when we do deprecate something, we write why. Of
 course, we're tight on resources so if anyone wants to take that on, it
 would be great. It's been on our to-do list for years and has never
 happened.

 On Wed, May 27, 2015, 8:05 PM Andrew Grieve agri...@chromium.org wrote:

  I'm wary of creating any docs for the Java APIs, since I think they will
  inevitably get out of sync with the real code (it's hard enough getting
  code comments to match the code).
 
  I think some beefed up Javadocs might be nice, but I think plugin
  developers should just read through Cordova's code to see how it works
  (there's not that much of it).
 
  I found learning how cordova-android works was vastly easier than
 learning
  how Android development works (intents, activities, resources,
 services,
  etc), so I'm not convinced that there's any low-hanging fruit here.
 
 
 
  On Wed, May 27, 2015 at 8:59 PM, Nikhil Khandelwal 
 nikhi...@microsoft.com
  
  wrote:
 
   Joe, Andrew, Ian, Michael: I'm hoping one of you can plug this
   documentation gap since you are most knowledgeable about changes from
   Cordova-android 3.7 to 4.0.
  
   Thanks,
   Nikhil
  
  
   -Original Message-
   From: Joe Bowser [mailto:bows...@gmail.com]
   Sent: Friday, May 15, 2015 4:23 PM
   To: dev@cordova.apache.org
   Subject: Re: [BUG] Fail to build Mobilespec with --thirdpartyplugins
   (CB-9032)
  
   I agree.  This is something that I believe that is in the tracker.  The
   real problem with this is that we have no idea what our public API
 looks
   like for plugin developers, or any documentation as to what the best
   practices for plugin developers are.  As far as regular non-plugin devs
  are
   concerned, we didn't actually have a breaking API change for
   Cordova-Android 4.0.0 other than the whitelists, which we made into a
   plugin.
  
   One of the things that we actually fixed/improved in Cordova-Android
 4.0,
   the third-party Java dependencies, has no documentation, and we're
   basically directing people to Crosswalk as the way to do this.  We
 should
   really be adding the documentation, and if anyone wants to take that
 on,
   that'd be awesome.
  
   On Fri, May 15, 2015 at 4:06 PM Nikhil Khandelwal 
  nikhi...@microsoft.com
   wrote:
  
Is there a list of cordova-android 4.0 APIs that have been removed? I
think a migration guide from Androind 3.7.1 = Androind 4.0.0 would
 be
super useful.
   
Thanks,
Nikhil
   
   
-Original Message-
From: Joe Bowser [mailto:bows...@gmail.com]
Sent: Friday, May 15, 2015 7:02 AM
To: dev@cordova.apache.org
Subject: Re: [BUG] Fail to build Mobilespec with --thirdpartyplugins
(CB-9032)
   
Hey
   
I just took a look at those, and those are all the methods we decided
to remove when we changed the API for Cordova-Android 4.0.  We have
 no
plans on bringing those methods back, so I'm going to close the
 issue.
I recommend filing issues with those repositories to get them to
update their plugins to the current API.
   
On Fri, May 15, 2015 at 1:37 AM Lin, Wanming wanming@intel.com
wrote:
   
 Hello,

 It is failed to build Mobilespec with --thirdpartyplugins on
 Cordova CLI
 5.0.0 and latest commit of cordova-mobile-spec.
 I've filed a JIRA bug:
 https://issues.apache.org/jira/browse/CB-9032,
 could anyone help take a look? Many thanks in advance!

 Thanks,
 Wanming


 
 - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
 For additional commands, e-mail: dev-h...@cordova.apache.org

Re: Building cordova.js on first build

2015-05-27 Thread Andrew Grieve

Certainly would be nice to have the create scripts generate cordova.js in
the same way CLI does. Maybe have the create script call into cordova-js?

Would it make sense in this case to have platforms depend on cordova-js,
rather than the other way around?

Having cordova-js depend on platforms means:
- we have pinned versions of platforms in cordova-lib
- we have pinned versions of platforms in cordova-js
- cordova-lib depends on cordova-js, meaning platforms are double-pinned?

Is it possible that the pinned versions could get out of sync? Seems
possible...

I think there's probably two ways that we can simplify the dependencies:
1. Have platforms depend on cordova-js, and have their create script know
how to generate a cordova.js
2. Have platforms' create script require a --path-to-cordova-js flag.

We could actually do both, since in CLI we don't download package
dependencies when adding downloading platform packages.

On Tue, May 26, 2015 at 9:14 PM, Murat Sutunc mura...@microsoft.com wrote:

 I think this would be a valuable addition to coho.

 +1

 -Original Message-
 From: Steven Gill [mailto:stevengil...@gmail.com]
 Sent: Tuesday, May 26, 2015 5:40 PM
 To: dev@cordova.apache.org
 Subject: Re: Building cordova.js on first build

 npm linking is suggested when testing platform specific JS changes.

 cordova-coho's prepare-release-branch command will generate cordova.js and
 move it over to the platform, as well as other things, when doing a
 release. It might be worth breaking out the generating and moving JS part
 of that step in coho to make that command standalone so platform developers
 could do cordova-coho update-js -r windows to generate + copy cordova.js
 into cordova-windows (sibling to cordova-coho).





 On Tue, May 26, 2015 at 5:25 PM, Murat Sutunc mura...@microsoft.com
 wrote:

  Thanks Steven for clarifying this for me.
 
  For now I'll update the www\cordova.js manually for the windows platform.
  Windows cordova.js is outdated and I'm hitting a bug.
 
  Personally, I'm +1 with auto generating cordova.js but it's not as
  easy as I originally thought because of the dependencies.
 
  Currently, updating cordova.js is also not so trivial. We have a
  folder structure like this:
 
  Cordova Project
  ├─┬ cordova-js @ Dev (local) Version
  │ └── cordova-windows @ NPM Version
  └── cordova-windows @ Dev (local) Version
 
  For platform developers the easiest workflow is to npm-link
  cordova-js\cordova-windows to cordova-windows. Once linked you have to
  grunt compile cordova-js and manually move file over cordova-windows.
 
  On second thought, regenerating cordova.js from cordova-cli is not a
  great idea. For browserify workflow it makes a lot of sense because we
  don't know which plugins the user has but otherwise the file is static.
 
  -Original Message-
  From: Steven Gill [mailto:stevengil...@gmail.com]
  Sent: Tuesday, May 26, 2015 5:10 PM
  To: dev@cordova.apache.org
  Subject: Re: Building cordova.js on first build
 
  If people are into it, I can handle this one as I am very familiar
  with the code base since I just did it for the browserify workflow.
 
  On Tue, May 26, 2015 at 4:15 PM, Steven Gill stevengil...@gmail.com
  wrote:
 
   Hey Murat,
  
   By two files you mean cordova-js-src and www\cordova.js I assume.
   The www\cordova.js file is generated and updated on each release of
   the platform. It will use cordova-js-src to build it when available
   (instead of legacy-exe version)
  
   Problem with removing www\cordova.js and building it on runtime is
   that we loose support of platforms being able to build cordova
   projects independently of cordova-cli. We would have to have
   cordova.js as a dependency for each platform to be able to keep the
   ./bin/create scripts still having access to a cordova.js file.
  
   Right now, the browserify way builds cordova.js at runtime with the
   CLI by grabbing cordova-js-src from platform_www of added platforms
   or from cordovajs/src/legacy-exec if cordova-js-src doesn't exist
   (older
   platforms) . Because of this, we already have cordovajs as a
   dependency of cordova-lib. So theoretically, we could build
   cordova.js at runtime for non-browserify use case using a similar
 workflow.
  
   I think we should keep the www\cordova.js for now, and add
   non-browserify runtime cordova.js generation behind a flag so we can
   test it out. I see the value in it because we have use cases where
   we update the platform specific JS (in cordova-js-src) but can't
   test without generating a new cordova.js and moving it over to our
 platforms.
  
   Obviously using the --browserify flag will also work for you to be
   able to test those platform specific changes.
  
   On Tue, May 26, 2015 at 3:31 PM, Murat Sutunc
   mura...@microsoft.com
   wrote:
  
   Hey there,
   I've a quick question. Now that every platform comes with
   cordova-js-src should we remove the www\cordova.js from platform
 repos?
   I

Re: [BUG] Fail to build Mobilespec with --thirdpartyplugins (CB-9032)

2015-05-27 Thread Andrew Grieve

I'm wary of creating any docs for the Java APIs, since I think they will
inevitably get out of sync with the real code (it's hard enough getting
code comments to match the code).

I think some beefed up Javadocs might be nice, but I think plugin
developers should just read through Cordova's code to see how it works
(there's not that much of it).

I found learning how cordova-android works was vastly easier than learning
how Android development works (intents, activities, resources, services,
etc), so I'm not convinced that there's any low-hanging fruit here.



On Wed, May 27, 2015 at 8:59 PM, Nikhil Khandelwal nikhi...@microsoft.com
wrote:

 Joe, Andrew, Ian, Michael: I'm hoping one of you can plug this
 documentation gap since you are most knowledgeable about changes from
 Cordova-android 3.7 to 4.0.

 Thanks,
 Nikhil


 -Original Message-
 From: Joe Bowser [mailto:bows...@gmail.com]
 Sent: Friday, May 15, 2015 4:23 PM
 To: dev@cordova.apache.org
 Subject: Re: [BUG] Fail to build Mobilespec with --thirdpartyplugins
 (CB-9032)

 I agree.  This is something that I believe that is in the tracker.  The
 real problem with this is that we have no idea what our public API looks
 like for plugin developers, or any documentation as to what the best
 practices for plugin developers are.  As far as regular non-plugin devs are
 concerned, we didn't actually have a breaking API change for
 Cordova-Android 4.0.0 other than the whitelists, which we made into a
 plugin.

 One of the things that we actually fixed/improved in Cordova-Android 4.0,
 the third-party Java dependencies, has no documentation, and we're
 basically directing people to Crosswalk as the way to do this.  We should
 really be adding the documentation, and if anyone wants to take that on,
 that'd be awesome.

 On Fri, May 15, 2015 at 4:06 PM Nikhil Khandelwal nikhi...@microsoft.com
 wrote:

  Is there a list of cordova-android 4.0 APIs that have been removed? I
  think a migration guide from Androind 3.7.1 = Androind 4.0.0 would be
  super useful.
 
  Thanks,
  Nikhil
 
 
  -Original Message-
  From: Joe Bowser [mailto:bows...@gmail.com]
  Sent: Friday, May 15, 2015 7:02 AM
  To: dev@cordova.apache.org
  Subject: Re: [BUG] Fail to build Mobilespec with --thirdpartyplugins
  (CB-9032)
 
  Hey
 
  I just took a look at those, and those are all the methods we decided
  to remove when we changed the API for Cordova-Android 4.0.  We have no
  plans on bringing those methods back, so I'm going to close the issue.
  I recommend filing issues with those repositories to get them to
  update their plugins to the current API.
 
  On Fri, May 15, 2015 at 1:37 AM Lin, Wanming wanming@intel.com
  wrote:
 
   Hello,
  
   It is failed to build Mobilespec with --thirdpartyplugins on
   Cordova CLI
   5.0.0 and latest commit of cordova-mobile-spec.
   I've filed a JIRA bug:
   https://issues.apache.org/jira/browse/CB-9032,
   could anyone help take a look? Many thanks in advance!
  
   Thanks,
   Wanming
  
   
   - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
   For additional commands, e-mail: dev-h...@cordova.apache.org

Re: Cordova 5 - Android and 3rd party libraries question

2015-05-26 Thread Andrew Grieve

Finally got around to looking at this.

Cloned  was able to reproduce the error.

Changing the build-extras.gradle to:

dependencies {
debugCompile project(path: ':org.apache.cordova.xapkreader:library',
configuration: debug)
releaseCompile project(path: ':org.apache.cordova.xapkreader:library',
configuration: release)
}

Fixed it for me. Probably gradle's not de-duping correctly when mixing
compile(foo), and debugCompile(foo)

On Thu, May 21, 2015 at 9:19 AM, Maffett, Ian ian.maff...@intel.com wrote:

 Thanks for the info Andrew.  I did confirm I was able to build with your
 plugin fine.  It looks like that was a red herring on my end.

 I¹ve pushed up a github repo showing the DEX issue.  You should be able to
 clone it and
 run cordova commands.  This does have the fix to generate the proper
 settings.gradle file.

 https://github.com/imaffett/gradle-dex-issue


 One thing to note -
 https://github.com/imaffett/gradle-dex-issue/blob/master/platforms/android/
 org.apache.cordova.xapkreader/foobar-downloader_library/build-extras.gradle

 If I do not have compile in there, then I get reference errors trying to
 build.  I think
 this is causing the DEX issue since the main build.gradle is building
 project(':org.apache.cordova.xapkreader:library¹)


 Thanks,
 Ian

 On 5/19/15, 8:05 PM, Andrew Grieve agri...@chromium.org wrote:

 Hmm, I've written a couple of other plugins that don't suffer from
 multiple
 dex exceptions. I forget the first, but the second is:
 
 https://github.com/MobileChromeApps/cordova-plugin-background-app
 
 So, I think there might be something else going on besides the plugin's
 lib
 having a dependency on CordovaLib (this is what allows plugin library
 projects to reference Cordova APIs)
 
 On Mon, May 18, 2015 at 9:18 AM, Maffett, Ian ian.maff...@intel.com
 wrote:
 
  I¹ve run into a few issues with Cordova CLI5, Android 4 and
  libraries/frameworks.  I will try to explain below, but the issue
 appears
  to be related to the dependency section in build.gradle and each
 librarie¹s
  build.gradle file.
 
  We¹ve developed a plugin to enable expansion files on Android.  It is
  dependent on three custom Android libraries, which declare in the
  plugin.xml file.
 
  framework src=AndroidLibrary/GoogleExtras/play_licensing/library
  custom=true /
  framework
  src=AndroidLibrary/GoogleExtras/play_apk_expansion/downloader_library
  custom=true/
  framework src=AndroidLibrary/GoogleExtras/play_apk_expansion/zip_file
  custom=true /¹
 
 
  The first problem we ran into we will be submitting a patch to fix.  The
  issue is that the project¹s folder name was prepended to the path when
 it
  was created. We could not reference this in the build-extras.gradle due
 to
  the constant name change.  Below is an example where my project¹s
 directory
  from cordova create is ³foobar
 
  org.apache.cordova.xapkreader/foobar-library
 
  I spoke with Andrew Grieve via email and he recommend changing the
  build.js file in cordova-android to enable the following in creating the
  settings.gradle .  We can now properly reference the library in a
  build-extras.gradle
 
  include :org.apache.cordova.xapkreader:library
  project(:org.apache.cordova.xapkreader:library).projectDir = new
  File(org.apache.cordova.xapkreader/foobar-library²)
 
 
  The second issue we are running into is bigger.  Whenever we run a
 build,
  we get DEX errors.  There are two specific cases we are running into.
 The
  first is for general Cordova errors, the second is specific to our
  AndroidLibrary/GoogleExtras/play_licensing/library .
 
  com.android.dex.DexException: Multiple dex files define
 
  I believe this is due to the following
 
1.  The main build.gradle has dependencies to all the sub
  projects/libraries which get built
2.  The libraries each have their own build.gradle which has a
  dependency on CordovaLib
 
  In the general case, it appears that with each library CordovaLib is
 being
  compiled into the jar and causes the error for DEX since it includes
  multiple definitions.  If I open up Android studio and change each
  libraries build.gradle dependency to only have the following (the
 reference
  to CordovaLib was removed)
 
 
  dependencies {
  compile fileTree(dir: 'libs', include: '*.jar')
  }
 
  This removes the DEX errors for Cordova.   The issue specific to our
  plugin is that I have to modify the main build.gradle dependency to
 remove
  the references for the following, which is a custom library we¹ve
 declared.
 
 
  debugCompile project(path: :org.apache.cordova.xapkreader:library,
  configuration: debug)
  releaseCompile project(path: :org.apache.cordova.xapkreader:library,
  configuration: release)
 
  Removing those references allows the
  AndroidLibrary/GoogleExtras/play_apk_expansion/downloader_library
  build-extras.gradle file to reference it and build successfully.
 
  dependencies {
  compile(project(':org.apache.cordova.xapkreader:library'))
  compile fileTree

Re: cordova-vm.apache.org

2015-05-22 Thread Andrew Grieve

afaik, it's still available, but probably we'd need to ping INFRA to make
it alive again (doesn't respond to pings atm)

On Thu, May 21, 2015 at 5:59 PM, Dmitry Blotsky dblot...@microsoft.com
wrote:

 Hey folks,

 Resurrecting an old thread here: is cordova-vm.apache.org still available
 for us? We still need a couchdb machine on Apache Infra.

 Kindly,
 Dmitry

 -Original Message-
 From: Dmitry Blotsky [mailto:dblot...@microsoft.com]
 Sent: Wednesday, April 8, 2015 5:29 PM
 To: dev@cordova.apache.org
 Subject: RE: cordova-vm.apache.org

 Thanks for the exposition, Jesse! Yeah, it seems like getting logs off
 some devices and emulators is either impossible or insurmountably
 difficult. I know Android and iOS emulators and devices create logs on the
 file system or have a utility to retrieve them from the device (e.g. adb
 logcat), but it doesn't seem like we can get the same easy access on
 Windows, BlackBerry, etc. Network seems to be the far superior solution.

 So, shall we then commandeer the Apache VM for medic's logging needs?
 Right now it's still using a private machine and it would be great to move
 this last piece to Apache infrastructure.

 Kindly,
 Dmitry

 -Original Message-
 From: Jesse [mailto:purplecabb...@gmail.com]
 Sent: Wednesday, April 8, 2015 4:07 PM
 To: dev@cordova.apache.org
 Subject: Re: cordova-vm.apache.org

 In reply to Dmitry, perhaps going off topic a bit ...

 All devices cannot echo their results back to the console that launched
 them.
 That was the reason in the first place for using a central db for
 federated test results.
 This is likely the ONLY way that this will ever work.

 Medic/BuildBot was originally designed to support a device wall with
 multiple devices running tests and reporting results to the db server,
 which then provided some interpretations of those results, including fancy
 graphs that showed things like 'the media plugin is failing 2 tests on
 Android 4.4 on a moto-x'

 Some of this has been lost along the way, but understand that there are
 limitations reporting test results by other means.
 1. Windows Phone Emulator has tons of network weirdness, so reporting
 results to the command line that launched it is near impossible.
 2. cordova-ios does not ship with any console.log capability, so there is
 nowhere to report tests to.
 3. all of our cli build tooling exits as soon as it has built and launched
 the app, it would need to stick around and wait for results otherwise.
 4. android does not echo console.log calls to the terminal that launched it

 cordova-paramedic leverages much of the way that medic works by creating
 it's own server to receive posted test results, thereby side-stepping some
 of the issues above.  This however is still not perfect in that it does not
 always play well with vms, wp8/windows are still unworkable, but
 ios/android do work.  Also, this is not intended to be a replacement for
 what medic does ( runs all the tests and federates the results ) but more
 so to integrate with TravisCI so we can see if a plugin pull request breaks
 anything, or to run yourself and test a particular plugin/platform
 combination in isolation.

 Ultimately though, I agree with Andrew's statement.  We need to spend more
 time fixing the bugs + the tests, instead of playing with how they are
 reported.







 @purplecabbage
 risingj.com

 On Wed, Apr 8, 2015 at 2:59 PM, Dmitry Blotsky dblot...@microsoft.com
 wrote:

  The logs pull down the output from CouchDB; CouchDB serves as the main
  dump point of output from a running mobilespec. This is the chosen
  path for gathering output because we can't get logs for every platform
  on every environment (i.e. both emulator and device), but we can get
  network access for each.
 
  I'm not too knowledgeable on why logs aren't programmatically
  available on every platform, but it is indeed another avenue that has
  merit, and could eliminate the need for a DB in the middle. What are
  the reasons that we can't get the logs from some emulators/devices on
 some platforms?
 
  - Dmitry
 
  -Original Message-
  From: agri...@google.com [mailto:agri...@google.com] On Behalf Of
  Andrew Grieve
  Sent: Wednesday, April 8, 2015 11:54 AM
  To: Andrew Grieve
  Cc: dev
  Subject: Re: cordova-vm.apache.org
 
  Although - could you remind me why we need a couchdb? It's a hasstle
  and will require maintentance.
  The logs from the builders seem sufficient to me (they show which
  tests fail). Effort might be better spent improving the tests  fixing
 bugs.
 
  On Wed, Apr 8, 2015 at 2:53 PM, Andrew Grieve agri...@chromium.org
  wrote:
 
   Sounds good!
  
   Here's the thread where I got myself access:
  
   http://markmail.org/thread/ee4ujznt6lhw6ug5#query:+page:1+mid:aqjyaw
   mz
   tdbnb2bf+state:results
  
   My notes from before:
   1. Make sure you have an SSH key registered on id.apache.org
   (ssh'ing to the machine should work) 2. Install an OPIE
   (one-time-password) client

Re: Cordova 5 - Android and 3rd party libraries question

2015-05-19 Thread Andrew Grieve

Hmm, I've written a couple of other plugins that don't suffer from multiple
dex exceptions. I forget the first, but the second is:

https://github.com/MobileChromeApps/cordova-plugin-background-app

So, I think there might be something else going on besides the plugin's lib
having a dependency on CordovaLib (this is what allows plugin library
projects to reference Cordova APIs)

On Mon, May 18, 2015 at 9:18 AM, Maffett, Ian ian.maff...@intel.com wrote:

 I’ve run into a few issues with Cordova CLI5, Android 4 and
 libraries/frameworks.  I will try to explain below, but the issue appears
 to be related to the dependency section in build.gradle and each librarie’s
 build.gradle file.

 We’ve developed a plugin to enable expansion files on Android.  It is
 dependent on three custom Android libraries, which declare in the
 plugin.xml file.

 framework src=AndroidLibrary/GoogleExtras/play_licensing/library
 custom=true /
 framework
 src=AndroidLibrary/GoogleExtras/play_apk_expansion/downloader_library
 custom=true/
 framework src=AndroidLibrary/GoogleExtras/play_apk_expansion/zip_file
 custom=true /’


 The first problem we ran into we will be submitting a patch to fix.  The
 issue is that the project’s folder name was prepended to the path when it
 was created. We could not reference this in the build-extras.gradle due to
 the constant name change.  Below is an example where my project’s directory
 from cordova create is “foobar

 org.apache.cordova.xapkreader/foobar-library

 I spoke with Andrew Grieve via email and he recommend changing the
 build.js file in cordova-android to enable the following in creating the
 settings.gradle .  We can now properly reference the library in a
 build-extras.gradle

 include :org.apache.cordova.xapkreader:library
 project(:org.apache.cordova.xapkreader:library).projectDir = new
 File(org.apache.cordova.xapkreader/foobar-library”)


 The second issue we are running into is bigger.  Whenever we run a build,
 we get DEX errors.  There are two specific cases we are running into.  The
 first is for general Cordova errors, the second is specific to our
 AndroidLibrary/GoogleExtras/play_licensing/library .

 com.android.dex.DexException: Multiple dex files define

 I believe this is due to the following

   1.  The main build.gradle has dependencies to all the sub
 projects/libraries which get built
   2.  The libraries each have their own build.gradle which has a
 dependency on CordovaLib

 In the general case, it appears that with each library CordovaLib is being
 compiled into the jar and causes the error for DEX since it includes
 multiple definitions.  If I open up Android studio and change each
 libraries build.gradle dependency to only have the following (the reference
 to CordovaLib was removed)


 dependencies {
 compile fileTree(dir: 'libs', include: '*.jar')
 }

 This removes the DEX errors for Cordova.   The issue specific to our
 plugin is that I have to modify the main build.gradle dependency to remove
 the references for the following, which is a custom library we’ve declared.


 debugCompile project(path: :org.apache.cordova.xapkreader:library,
 configuration: debug)
 releaseCompile project(path: :org.apache.cordova.xapkreader:library,
 configuration: release)

 Removing those references allows the
 AndroidLibrary/GoogleExtras/play_apk_expansion/downloader_library
 build-extras.gradle file to reference it and build successfully.

 dependencies {
 compile(project(':org.apache.cordova.xapkreader:library'))
 compile fileTree(dir: 'libs', include: '*.jar')
  }



 -
 To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
 For additional commands, e-mail: dev-h...@cordova.apache.org

Re: Cordova 5.0 user feedback - move to npm whitelist plugin

2015-05-13 Thread Andrew Grieve

It's here:
cordova-lib/cordova-lib/node_modules/cordova-app-hello-world/config.xml

A use can change the defaults by providing a config.xml within their own
template (--copy-from target)

On Wed, May 13, 2015 at 10:51 AM, Raymond Camden raymondcam...@gmail.com
wrote:

Ah interesting. Where is the default config.xml actually defined? I
assume it is baked in and a user can't change the default used?

On Tue, May 12, 2015 at 11:02 AM, Andrew Grieve agri...@chromium.org
wrote:
if you use --copy-from and the template doesn't already have a
config.xml,
then the default config.xml will be used.

I wouldn't expect what you describe if your template already had a
config.xml

On Tue, May 12, 2015 at 10:46 AM, Raymond Camden
raymondcam...@gmail.com
wrote:

So query - I thought the whitelist plugin was being added because it
was in the default Cordova sample config.xml - but when I built a new
project and used --copy-from, it *also* installed the plugin. So is it
just *always* added?

On Tue, May 12, 2015 at 9:21 AM, Andrew Grieve agri...@chromium.org
wrote:
On Mon, May 11, 2015 at 1:56 PM, Nikhil Khandelwal
nikhi...@microsoft.com
wrote:

Responses inline.

-Original Message-
From: Steven Gill [mailto:stevengil...@gmail.com]
Sent: Thursday, May 7, 2015 6:17 PM
To: dev@cordova.apache.org
Subject: Re: Cordova 5.0 user feedback - move to npm whitelist
plugin

(1) older versions of our docs point to plugins.cordova.io for
plugin
documentation. We haven't pointed people to github for plugin docs.
Those
docs are accurate with the ID of the plugin. Adding a section to the
readme
about needing cordova 5+ isn't a bad idea.

[NK] There are places that this is not true.

http://cordova.apache.org/docs/en/4.0.0/guide_support_index.md.html#Platform%20Support
.

The plan is to switch our tools to grab from npm first and CPR
second. I
believe we discussed doing this around the time CPR goes read only.
Giving
IDE's and people using older versions a chance to upgrade.

We can publish updated plugins to CPR, but it is going to be quite a
bit
of work. I created old-id branches for our core plugins that revert
the
commits changing the ID and the commits where I change internal
plugin
references from org.apache.cordova.* to cordova-plugin-*. It was a
fairly
large change. The reason for the major jump was the plugin id change.
I'd
recommend them sticking the versioning they are on instead of copying
the
version of the npm series. The major version bump wasn't due to a
change in
functionality in the plugins themselves.

If we want to release updated plugins to CPR, someone will need to do
the
work to cherry-pick the new commits into old-id and do a separate
vote
for
them.

[NK] I understand this is a lot of work. Alternatlively, shall we
change
the behavior of the CLI to use npm first - even for old ids -
perhaps,
as
part of 5.1 tools release? There is not much value in old Ids causing
stale, old version of plugin getting downloaded from CPR.

(2) It is a fairly recent change. Any new app made with cordova-cli
5+
will auto include the whitelist plugin due to the hello world
config.xml
including it as a dependency. I think we need to document it more and
make
more noise within the community about it. iOS 4.0 will also require
the
whitelist plugin when it gets released. The more prepared we are, the
better.

As for re-enabling network access by default, I wasn't really part of
the
original thread so I will leave it to the people who were to discuss
that
further.

http://markmail.org/search/?q=Android%27s+new+Whitelist+Plugins#query:Android%27s%20new%20Whitelist%20Plugins+page:1+mid:z2r2sj5e3kvrnqv6+state:results
Additionally, on prepare, platforms should see the use of access tags
and
encourage users to use one of the whitelist plugins if they have not
already done so.

I agree that needing the new whitelist plugin to make network calls is
unfortunate. I know Ian really wanted everything to secure by default,
and
having network access via a plugin means you can update the plugin
separately if there are bugs. I think it might be a bit late to change
things now though. Better to just stick with it rather than changing
things
again and again.

On Thu, May 7, 2015 at 8:55 AM, Nikhil Khandelwal
nikhi

Re: [DISCUSS] Dropping the -dev suffix

2015-05-13 Thread Andrew Grieve

I think -dev is working fine and doing what it's supposed to do. The logic
of -label is subtle:

 var sem = require('semver')
undefined
 sem.satisfies('4.0.0-dev', '=4.0.0')
false
 sem.satisfies('4.0.0-dev', '=4.0')
true

So, the engine check should just to =4.0, or =4.0.0-dev

On Wed, May 13, 2015 at 1:39 PM, So, Byoungro byoungro...@intel.com wrote:

 Sorry, I got the other way around. :)
 4.0.0-dev is  4.0.0.

 Byoungro So
 SSG / DPD / Mobile Computing and Compilers
 Intel Corporation

 -Original Message-
 From: So, Byoungro
 Sent: Wednesday, May 13, 2015 10:37 AM
 To: dev@cordova.apache.org
 Subject: RE: [DISCUSS] Dropping the -dev suffix

 Semver should be able to understand '4.0.0-dev' as the valid version
 string.
 There could be some other requirement problems, like =, .
 For example, 4.0.0-dev is  4.0.0.
 So, if the requirement is =4.0.0, then the version string '4.0.0-dev'
 will fail to satisfy the requirement.

 Byoungro So
 SSG / DPD / Mobile Computing and Compilers Intel Corporation

 -Original Message-
 From: Steven Gill [mailto:stevengil...@gmail.com]
 Sent: Wednesday, May 13, 2015 10:21 AM
 To: dev@cordova.apache.org
 Subject: [DISCUSS] Dropping the -dev suffix

 Recently, a issue (CB-9021) popped up where mobile spec was failing
 because the semver check failed on a platform due to `-dev` being in the
 version and not valid.

 I think we should remove -dev from our versions. Right now, after we do a
 release, we add -dev to show that the repo is in development and hasn't
 been released. I think we can accomplish the same by just bumping the
 version (minor?) in the package.json and just know it isn't released by
 seeing what is published on npm.

 Thoughts?

 -
 To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
 For additional commands, e-mail: dev-h...@cordova.apache.org

Re: cordova-plugin-background-app

2015-05-13 Thread Andrew Grieve

Here we go!
https://github.com/MobileChromeApps/cordova-plugin-background-app/tree/master/example-app

Also makes use of CLI's ability to store plugins  platforms in config.xml
:)

On Tue, May 5, 2015 at 2:50 PM, Andrew Grieve agri...@chromium.org wrote:

 Hmm, just have mobile chrome apps' mobilespec equivalent. It'd be worth
 creating a smaller just-uses-local-notifications-or-alarms app to show it
 off. I'll try and do that some time this week.

 On Tue, May 5, 2015 at 11:52 AM, Raymond Camden raymondcam...@gmail.com
 wrote:

 Do you have an example appl?

 On Tue, May 5, 2015 at 10:20 AM, Andrew Grieve agri...@chromium.org
 wrote:
  Wanted to draw attention to a new plugin we've created for allowing
 Android
  apps to behave as a service on Android (without actually being a
 service!)
 
  https://github.com/MobileChromeApps/cordova-plugin-background-app
 
  We use it as part of our chrome.gcm, chrome.notifications, and
  chrome.alarms plugins.
 
  Under-the-hood, it uses less-well-known Android features to have an
  Activity start without any visual cues, then have it be able to switch
 to
  the foreground through task reparenting. Crazy stuff, but nice
 results :)



 --

 ===
 Raymond Camden, Developer Advocate for MobileFirst at IBM

 Email : raymondcam...@gmail.com
 Blog : www.raymondcamden.com
 Twitter: raymondcamden

 -
 To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
 For additional commands, e-mail: dev-h...@cordova.apache.org

Re: Cordova 5.0 user feedback - move to npm whitelist plugin

2015-05-12 Thread Andrew Grieve

if you use --copy-from and the template doesn't already have a config.xml,
then the default config.xml will be used.

I wouldn't expect what you describe if your template already had a
config.xml

On Tue, May 12, 2015 at 10:46 AM, Raymond Camden raymondcam...@gmail.com
wrote:

On Tue, May 12, 2015 at 9:21 AM, Andrew Grieve agri...@chromium.org
wrote:
On Mon, May 11, 2015 at 1:56 PM, Nikhil Khandelwal
nikhi...@microsoft.com
wrote:

Responses inline.

(1) older versions of our docs point to plugins.cordova.io for plugin
documentation. We haven't pointed people to github for plugin docs.
Those
docs are accurate with the ID of the plugin. Adding a section to the
readme
about needing cordova 5+ isn't a bad idea.

[NK] There are places that this is not true.

http://cordova.apache.org/docs/en/4.0.0/guide_support_index.md.html#Platform%20Support
.

The plan is to switch our tools to grab from npm first and CPR second. I
believe we discussed doing this around the time CPR goes read only.
Giving
IDE's and people using older versions a chance to upgrade.

We can publish updated plugins to CPR, but it is going to be quite a bit
of work. I created old-id branches for our core plugins that revert the
commits changing the ID and the commits where I change internal plugin
references from org.apache.cordova.* to cordova-plugin-*. It was a
fairly
large change. The reason for the major jump was the plugin id change.
I'd
recommend them sticking the versioning they are on instead of copying
the
version of the npm series. The major version bump wasn't due to a
change in
functionality in the plugins themselves.

If we want to release updated plugins to CPR, someone will need to do
the
work to cherry-pick the new commits into old-id and do a separate vote
for
them.

[NK] I understand this is a lot of work. Alternatlively, shall we change
the behavior of the CLI to use npm first - even for old ids - perhaps,
as
part of 5.1 tools release? There is not much value in old Ids causing
stale, old version of plugin getting downloaded from CPR.

(2) It is a fairly recent change. Any new app made with cordova-cli 5+
will auto include the whitelist plugin due to the hello world config.xml
including it as a dependency. I think we need to document it more and
make
more noise within the community about it. iOS 4.0 will also require the
whitelist plugin when it gets released. The more prepared we are, the
better.

As for re-enabling network access by default, I wasn't really part of
the
original thread so I will leave it to the people who were to discuss
that
further.

On Thu, May 7, 2015 at 8:55 AM, Nikhil Khandelwal
nikhi...@microsoft.com
wrote:

There is a bunch of confusion with Cordova 5.0 users because of these
two
changes:

1. Move to npm for plugins (There have been multiple PRs trying to
update plugin docs to reference the old id instead of the new one -
because people are still using the old version of the CLI)

2. No network access in Android 4.0 without whitelist plugin:

- https://issues.apache.org/jira/browse/CB-8969

http://stackoverflow.com/questions/29735597/cordova-5-0-0-android-app-
can-not-connect-to-internet-using-android-4-0-0

http

Re: Cordova 5.0 user feedback - move to npm whitelist plugin

2015-05-12 Thread Andrew Grieve

On Mon, May 11, 2015 at 1:56 PM, Nikhil Khandelwal nikhi...@microsoft.com
wrote:

Responses inline.

(1) older versions of our docs point to plugins.cordova.io for plugin
documentation. We haven't pointed people to github for plugin docs. Those
docs are accurate with the ID of the plugin. Adding a section to the readme
about needing cordova 5+ isn't a bad idea.

[NK] There are places that this is not true.
http://cordova.apache.org/docs/en/4.0.0/guide_support_index.md.html#Platform%20Support
.

The plan is to switch our tools to grab from npm first and CPR second. I
believe we discussed doing this around the time CPR goes read only. Giving
IDE's and people using older versions a chance to upgrade.

We can publish updated plugins to CPR, but it is going to be quite a bit
of work. I created old-id branches for our core plugins that revert the
commits changing the ID and the commits where I change internal plugin
references from org.apache.cordova.* to cordova-plugin-*. It was a fairly
large change. The reason for the major jump was the plugin id change. I'd
recommend them sticking the versioning they are on instead of copying the
version of the npm series. The major version bump wasn't due to a change in
functionality in the plugins themselves.

If we want to release updated plugins to CPR, someone will need to do the
work to cherry-pick the new commits into old-id and do a separate vote for
them.

[NK] I understand this is a lot of work. Alternatlively, shall we change
the behavior of the CLI to use npm first - even for old ids - perhaps, as
part of 5.1 tools release? There is not much value in old Ids causing
stale, old version of plugin getting downloaded from CPR.

(2) It is a fairly recent change. Any new app made with cordova-cli 5+
will auto include the whitelist plugin due to the hello world config.xml
including it as a dependency. I think we need to document it more and make
more noise within the community about it. iOS 4.0 will also require the
whitelist plugin when it gets released. The more prepared we are, the
better.

As for re-enabling network access by default, I wasn't really part of the
original thread so I will leave it to the people who were to discuss that
further.

[NK] I agree that making more noise is the right short term move to help
people upgrading to 5.0 realize this. I still believe that network access
should be enabled in the platform by default without any plugins. For
controlling network access, devs should either use CSP or a whitelist
plugin that gets the chance to override the networking behavior. Andrew,
Michael, and Ian are most familiar with the decision around this.
http://markmail.org/search/?q=Android%27s+new+Whitelist+Plugins#query:Android%27s%20new%20Whitelist%20Plugins+page:1+mid:z2r2sj5e3kvrnqv6+state:results
Additionally, on prepare, platforms should see the use of access tags and
encourage users to use one of the whitelist plugins if they have not
already done so.

I agree that needing the new whitelist plugin to make network calls is
unfortunate. I know Ian really wanted everything to secure by default, and
having network access via a plugin means you can update the plugin
separately if there are bugs. I think it might be a bit late to change
things now though. Better to just stick with it rather than changing things
again and again.

On Thu, May 7, 2015 at 8:55 AM, Nikhil Khandelwal nikhi...@microsoft.com
wrote:

There is a bunch of confusion with Cordova 5.0 users because of these
two
changes:

1. Move to npm for plugins (There have been multiple PRs trying to
update plugin docs to reference the old id instead of the new one -
because people are still using the old version of the CLI)

2. No network access in Android 4.0 without whitelist plugin:

- https://issues.apache.org/jira/browse/CB-8969

-
http://stackoverflow.com/questions/29735597/cordova-5-0-0-android-app-
can-not-connect-to-internet-using-android-4-0-0

-
http://stackoverflow.com/questions/30060534/ajax-requests-fail-after-u
pgrading-to-cordova-5-0-cordova-android4-0

I think for the (1), I suggest we do the following:

1. Update the plugin documentation that the old id can be used for
older CLI versions.

2. Either update the CPM with 1.0 versions of the plugins or have
the CLI get core plugins from npm first then CPR even with the old id.
Using the old id because they were hardcoded in IDEs etc, devs are
getting older version of the plugins.

For (2), I think we should re-visit making whitelist part of the
Android platform again or some other way of enabling network access by
default. No network access (XHR) for a platform by

Re: Cordova Plugins with Symlinks

2015-05-07 Thread Andrew Grieve

 provide
  guidance to plugin authors to work around this problem  Cordova plugin
 hook
  to create the symlinks or should we develop a way for this to happen
  automatically?  Ex: A npm pre-publish hook persists symlinks in a file
 that are
  then used before_compile on an OS that supports them. Or frameworks can
  be referenced as tar balls in plugin.xml that are then untar'd as a
  before_compile step.
  
   Thoughts?
  
   -Chuck
  
   -Original Message-
   From: Ally Ogilvie [mailto:aogil...@wizcorp.jp]
   Sent: Friday, September 5, 2014 3:31 AM
   To: dev@cordova.apache.org
   Subject: Re: Cordova Plugin Registry iOS frameworks
  
   Thanks Carlos. I'll take a look Monday. Have a good weekend.
  
  
   On Fri, Sep 5, 2014 at 4:06 AM, Carlos Santana csantan...@gmail.com
 
  wrote:
  
   Source code is here:
  
   https://github.com/apache/cordova-lib/blob/master/cordova-
  lib/src/plu
   g
   man/registry/registry.js#L97
  
   I think the fix will be to create a tarball in some tmp after
   generating pacakgeJson, then calling npm .commands, 'publish', args
   with the tarball instead of a folder containing the package.json
  
   Have fun !, remember to add unit tests :-)
  
  
  
   On Wed, Sep 3, 2014 at 10:37 PM, Ally Ogilvie aogil...@wizcorp.jp
  wrote:
  
   I tried to find plugman source code responsible for npm publish but
   failed.
  
   I'm gonna bump this for someone to assign too.. any takers? 3
  
  
  
   On Wed, Aug 20, 2014 at 12:12 PM, Ally Ogilvie aogil...@wizcorp.jp
 
   wrote:
  
   Ally, do you know if the symlinks are required for the
   FacebookConnect
   framework?
  
   @Ian Absolutely required. Not just for Facebook, but all .framework
   files.
  
   MyFramework.framework // (directory)
info.plist
MyFramework // (symbolic link to
   Versions/Current/MyFramework)
Resources   // (symbolic link to
   Versions/Current/Resources)
Headers // (symbolic link to
   Versions/Current/Headers)
Versions// (directory)
  Current   // (symbolic link to directory A below)
  A // (directory)
Headers // (directory containing framework
 headers)
Resources   // (directory holding framework resources)
MyFramework // (actual compiled library, really a .a
   file)
  
   As you can see there are 4 symbolic links in .frameworks.
  
  
  
  
   On Tue, Aug 19, 2014 at 5:59 AM, Shazron shaz...@gmail.com
  wrote:
  
   I think the right approach is what Andrew suggested. So the
   current workaround is to tarball it first then publish?
  
   On Mon, Aug 18, 2014 at 12:04 PM, Andrew Grieve
   agri...@chromium.org
  
   wrote:
   Tarballs support symlinks.
   npm uses tarballs.
   npm publish lets you give a path to a tarball rather than
   having
   it
   pack
   it for you.
  
   So, I think we probably could fix this in plugman by having it
   create
   the
   tgz more intelligently.
  
  
   On Mon, Aug 18, 2014 at 2:24 PM, Ian Clelland 
   iclell...@chromium.org
  
   wrote:
  
   On Mon, Aug 18, 2014 at 12:40 PM, Brian LeRoux b...@brian.io
  wrote:
  
   I like the idea of not supporting them until I hear a really
   great
   reason
   to support them. =)
  
   Certainly; YAGNI and all that.
  
   Ally, do you know if the symlinks are required for the
   FacebookConnect
   framework? Is it possible to just git mv the files to the
   location
   that
   Xcode expects to find them, and not have to worry about this
   issue
   in
   plugman?
  
   Ian
  
  
  
  
  
   On Mon, Aug 18, 2014 at 9:31 AM, Ian Clelland 
   iclell...@chromium.org
   wrote:
  
   We could have some sort of preprocessing step on the
   current
   directory,
   that would prepare it for publishing.
  
   Maybe we can either annotate the directory with where the
   symlinks
   should
   go, or else copy the files, if it's okay to do that.
  
   On Monday, August 18, 2014, Mark Koudritsky
   kam...@google.com
  
   wrote:
  
   Plugins are published using npm publish. As far as I
   understood,
   npm
   does
   not include symlinks by design [1] when packing a
   package. So
   I'm not
   sure
   about how we could start including symlinks while still
   using
   npm
   packages
   as distribution method.
   [1] https://github.com/npm/npm/issues/3310
  
  
  
   On Mon, Aug 18, 2014 at 9:02 AM, Ian Clelland 
   iclell...@chromium.org
   javascript:;
   wrote:
  
   I saw this come up on Friday on IRC -- I didn't see
   you in
   the
   channel,
   Ally, or I would have pinged you.
  
   It's definitely an issue with plugman, either with the
   packaging or
   the
   extraction, when there are symlinks present in the repo.
  
   I upgraded the severity of the CB-6092 to critical; we
   need
   to
   find a
   solution for this.
  
  
   On Mon, Aug 18, 2014 at 3:06 AM, Ally Ogilvie 
   aogil...@wizcorp.jp
   javascript:; wrote:
  
   https

cordova-plugin-background-app

2015-05-05 Thread Andrew Grieve

Wanted to draw attention to a new plugin we've created for allowing Android
apps to behave as a service on Android (without actually being a service!)

https://github.com/MobileChromeApps/cordova-plugin-background-app

We use it as part of our chrome.gcm, chrome.notifications, and
chrome.alarms plugins.

Under-the-hood, it uses less-well-known Android features to have an
Activity start without any visual cues, then have it be able to switch to
the foreground through task reparenting. Crazy stuff, but nice results :)

Re: Would like to submit PR, unable to figure out JIRA

2015-05-05 Thread Andrew Grieve

Thanks Matt!

Not sure what's going on with JIRA, but I created an issue for it:
https://issues.apache.org/jira/browse/CB-8956

ICLA's are required only for big changes (though still a nice thing to have
on file). I'll go ahead and merge.

On Mon, May 4, 2015 at 6:50 PM, Matt Steele orp...@gmail.com wrote:

 Hi folks, I'd like to contribute a change to cordova-lib but am a little
 confused by the contribution guidelines.

 In particular, I'd like to create a ticket in JIRA, but I can't quite seem
 to figure out how. I haven't used JIRA before, but I assumed I could create
 an issue using the blue Create button, but that seems to be a dead end (I
 can create a Service Desk request, but I don't think that's the same
 thing?)

 I also need to still sign the ICLA, but I'll do that soon.

 Anyhow, my PR should be simple and available here:
 https://github.com/apache/cordova-lib/pull/211

 Could someone point me in the right direction to get started creating an
 issue, so I can finish the workflow? Thanks!

Also moving to a new team

2015-05-05 Thread Andrew Grieve

As with Michal, you'll be seeing less of me around. My new full-time
project will be on the Android port of Chrome.

Just want to make it clear that us moving to new teams has nothing to do
with a lack of faith in the project, but rather is due to needing a change
of scenery and exciting new projects becoming available here.

I'm super excited to see a new wave of committers joining the project! The
momentum has certainly picked up:
- Cordova-android 4.0.0 was huge
- Plugins to npm was huge
- Win10 and wkwebview will be massive launches as well!

Great time for Cordova! (or a bad one... you know... if you're measuring
against the goal of becoming obsolete :P)

Re: Does cordova-mobile-spec support CLI build?

2015-04-29 Thread Andrew Grieve

The createmobilespec.js script within the repo is meant to be the CLI for
the test suite.

Sounds like what you want it:

createmobilespec.js --android --global --webview=crosswalk

Of course, I just tried it and it failed due to some recent churn. I've now
committed a fix for it though.

The --global flag means you should need nothing checked out other than
cordova-mobile-spec repo.


On Wed, Apr 29, 2015 at 2:29 AM, Lin, Wanming wanming@intel.com wrote:

 Hi, Rob  Parashuram N

 I come from Crosswalk QA, we integrate cordova-mobile-spec targets to test
 features of Crosswalk WebView plugin and compatibility among Crosswalk,
 Cordova, and upstream plugins.

 Thank you so much for your helpful command lines, this would reduce quite
 a lot of time on test suite update.
 But the precondition is that people have already deployed multiple
 dependencies.
 What I exactly want is to reduce the time and steps on first time creating
 mobile-spec, and no longer handle the source code of those dependencies.
 And I wonder if it can be implemented by Cordova CLI for end user?

 Thanks,
 Wanming

 -Original Message-
 From: Parashuram N (MS OPEN TECH) [mailto:panar...@microsoft.com]
 Sent: Wednesday, April 29, 2015 12:52 PM
 To: dev@cordova.apache.org
 Subject: Re: Does cordova-mobile-spec support CLI build?

 Just out of curiosity, what are you using mobile spec for ? Are you using
 this to test non-core plugins ? Would be interesting to see how mobile-spec
 fares on that.

 On 4/28/15, 9:35 PM, Rob Paveza rob.pav...@microsoft.com wrote:

 Try out this at your command line:
 
  cordova-coho/coho for-each git pull
  cordova-coho/coho for-each npm install
  cordova-coho/coho npm-link
 
 I had to go through that process today, so maybe it'll work for you too!
 
 From: Lin, Wanming wanming@intel.com
 Sent: Tuesday, April 28, 2015 6:47 PM
 To: dev@cordova.apache.org
 Subject: Does cordova-mobile-spec support CLI build?
 
 Hello
 
 I use
 cordova-mobile-spechttps://github.com/apache/cordova-mobile-spec
 for several months with great experience, but the test suite build.
 I follow the steps in
 README.mdhttps://github.com/apache/cordova-mobile-spec/blob/master/REA
 DME .md, which is extremely complex and tedious.
 User have to pull many git repos, cordova-cli, cordova-plugman,
 cordova-js, cordova-android, cordova-coho... then pull npm packages,
 make npm link...
 Is there a simpler way? Can it be possible to build via Cordova CLI?
 
 Really appreciate all your help in advance.
 
 Thanks,
 Wanming
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
 For additional commands, e-mail: dev-h...@cordova.apache.org
 


 -
 To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
 For additional commands, e-mail: dev-h...@cordova.apache.org


 -
 To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
 For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [Android] InAppBrowser and URI whitelisting

2015-04-27 Thread Andrew Grieve

Yeah, that does sound messed up :S.

Perhaps IAB should be restricted to network  intent whitelists? With CSP,
our basic guidance is to allow full network access and restrict via CSP
anyways.

On Fri, Apr 24, 2015 at 7:48 PM, Joe Bowser bows...@gmail.com wrote:

 So, since we make this Category.BROWSABLE, we can safely say that this is
 working as intended and close it? :P

 I disagree about not restricting it to the intent whitelist, because that
 sounds messed up that we wouldn't let an app, with the trusted content run
 an intent, but we'd let untrusted content run one.

 On Fri, Apr 24, 2015 at 4:38 PM Andrew Grieve agri...@chromium.org
 wrote:

  The browser allows any intents, but attaches Category.BROWSABLE to the
  intents, which is supposed to make them safe.
  We don't restrict the IAB to the network whitelist, so it follows
 (maybe?)
  that we wouldn't restrict it to the intent whitelist.
 
  On Fri, Apr 24, 2015 at 6:06 PM, Jesse purplecabb...@gmail.com wrote:
 
   What does the browser do? That's what the InAppBrowser should do ...
  
   It may also make sense to allow the host cordova app decide whether or
  not
   to allow it.
   Presumably the host app could allow all intents, but not want to extend
   that to it's InAppBrowser control, or allow some intents for some
 domains
   ... based on their own logic ...
   Ideally, I think this should be a user problem, ie. give the app
  developer
   a chance to intercept the request, and if they don't just perform the
   default browser behaviour.
  
  
  
  
  
   @purplecabbage
   risingj.com
  
   On Fri, Apr 24, 2015 at 2:34 PM, Joe Bowser bows...@gmail.com wrote:
  
Hey
   
I was looking at CB-8180, and I'm wondering what the correct
 behaviour
   for
intents being launched from URIs should be for an InAppBrowser.
 Should
these have free reign to open whatever, or should they also be bound
 by
   the
rules of the whitelist?
   
What do people think?
   
Joe

Re: Two small tools for Cordova

2015-04-27 Thread Andrew Grieve

Thanks Murat! Sounds really useful!

WDYT about integrating these with coho?
- So that cordova devs don't need to npm install multiple dev commands
- So that the commands will be more discoverable
- So that you can restrict to repos: e.g. coho travis -r plugins

On Sun, Apr 26, 2015 at 11:53 PM, Murat Sutunc mura...@microsoft.com
wrote:

 Hey everyone,
 I've been working on two side projects that I think others might also find
 useful.

 Cordova Travis (https://www.npmjs.com/package/cordova-travis)
 Prints out the latest travis build result on console; for all Apache
 Cordova repos. Whenever there's something red, it's time to fix something :)

 Cordova Stale (https://www.npmjs.com/package/cordova-stale)
 This is more to help with our personal repos. Once a PR is merged we often
 forget to delete our own local branch. This tool helps to identify stale
 branches.

 Hope these would be useful. Thanks!
 Murat

Re: Build signed archives using CLI

2015-04-22 Thread Andrew Grieve

PR LGTM, but I have one question (maybe mostly for Shaz):

Seems our build script pass -xcconfig build-release.xcconfig, but our
project template doesn't use any .xcconfig:
http://pasteboard.co/2L2wg6r2.png

Would it be better to:
- use a different build-extras.xcconfig for debug / release (e.g.
build-extras-release.xcconfig)
- Set the xcconfigs in the project template so that they are used when
building from Xcode?


On Tue, Apr 21, 2015 at 4:47 PM, Nikhil Khandelwal nikhi...@microsoft.com
wrote:

 Support for iOS is in this PR now:
 https://github.com/apache/cordova-ios/pull/138

 It allows you to specify a signing identity and a provisioning profile
 using command line arguments or build.json.

 Thanks,
 Nikhil


 -Original Message-
 From: Nikhil Khandelwal [mailto:nikhi...@microsoft.com]
 Sent: Monday, April 6, 2015 9:37 AM
 To: dev@cordova.apache.org
 Subject: RE: Build signed archives using CLI

 Thanks, Andrew for doing a thorough review. This was merged in last week.
 I have created a new PR for the docs update:
 https://github.com/apache/cordova-docs/pull/277

 It's important to note, to make it simple to pass multiple signing
 parameters, I have created the concept of a build.json file (instead of
 cordova-keys.json suggested below) that can be used to specify build-time
 parameters. It supports specifying two sets of values - debug  release.

 This support is currently only for Android, I am working on another PR for
 iOS.

 Thanks,
 Nikhil


 -Original Message-
 From: agri...@google.com [mailto:agri...@google.com] On Behalf Of Andrew
 Grieve
 Sent: Wednesday, March 18, 2015 4:48 PM
 To: dev
 Subject: Re: Build signed archives using CLI

 Left some comments on the PR.

 On Tue, Mar 17, 2015 at 5:04 PM, Nikhil Khandelwal nikhi...@microsoft.com
 
 wrote:

  I just submitted a PR for this for Android:
  https://github.com/apache/cordova-android/pull/164
 
  Here's the rough design:
 
  - Build.json or command line args can be used to specify details
  required for packaging:
  - Keystore
  - Alias
  - Keystore password
  - Password
  - Keystore type.
  - Debug-signing.properties or release-signing.properties is created at
  prepare time to allow gradle or Ant build systems to pick up those
  properties and generate a signed archive.
  - ‘Clean’ will delete these autogenerated .properties files.
  - If no password is specified for release signing, Ant  gradle will
  prompt for passwords.
 
  I will shortly have a PR to update the docs.
 
  Thanks,
  Nikhil
 
 
  -Original Message-
  From: Carlos Santana [mailto:csantan...@gmail.com]
  Sent: Friday, February 13, 2015 2:28 PM
  To: dev@cordova.apache.org
  Subject: Re: Build signed archives using CLI
 
  Thanks Nikhil I see this as a very good and important feature to have
  in our CLI stack
 
  On Fri, Feb 13, 2015 at 4:48 PM, Nikhil Khandelwal
  nikhi...@microsoft.com
  
  wrote:
 
   I'm taking this over from Dan. I like the idea of having the release
   signing information persisted in a json file.
  
   I have made some updates on the specific issue of how keys/passwords
   can be passed through CLI and JSON:
  
   https://docs.google.com/document/d/1tJQ9OoGrrMhZcLI3mg46rGzAfbiQu9Pu
   NB
   L1auAMGFM/edit#
  
   I'm still going through the details of packaging requirements of
   each platform. I expect to add some more details on how the
   packaging process will work with individual platform build systems
   in the coming days. I will update this thread when I do so.
  
   Here's the main JIRA with platform specific tasks here:
   https://issues.apache.org/jira/browse/CB-8483. I would love to
   collaborate with others who are interested in this area.
   Specifically, I plan to take up the task of implementing this for
 Android first.
  
   Thanks,
   Nikhil
  
  
   -Original Message-
   From: Victor Sosa [mailto:sosah.vic...@gmail.com]
   Sent: Tuesday, February 10, 2015 2:29 PM
   To: dev@cordova.apache.org
   Subject: Re: Build signed archives using CLI
  
   I'm leaning to Andrew and Omar's idea. I like the idea of having a
   file where all the platform-specific information will be stored,
   then each platform will take that information to sign the archive
   and produce a usable, I mean ready-to-distribute, binary.
  
   As for Omar's comment, I also concur there. If a user has the
   signing info in gradle or ant properties and that info is also
   provided in the new file discussed here, then it should take
   precedence and override the platform-specific one.
  
   Wondering if Dan is feeling OK now and ready to be back in the game
   :D
  
   2015-02-02 14:58 GMT-06:00 Mefire O. ommen...@microsoft.com:
  
+1 for having an additional file to abstract away all the platform
specific stuff. Currently, we support both gradle and ant for
android for example, I think it wouldn't make sense for end-users
to have to change their specs depending on what

Re: cordova 5.0.0 and gradle

2015-04-22 Thread Andrew Grieve

We do pin the gradle version since that's what we've tested with. Seems
reasonable to add an option to try setting your own version though (feel
free to file an issue / hack away at it).

The two spots the version is pinned:
- within build.gradle
- within cordova/lib/build.js's prepEnv function (just search for 2.2.1)

As for proxy configuration, I've never dealt with that :(. If you can
figure out how to make it work, please file an issue  PR and we'll be glad
to merge it in.

On Wed, Apr 22, 2015 at 7:03 AM, Axel Nennker ignisvul...@gmail.com wrote:

 Ignoring the no-network-while-building requirement for a moment and setting
 the JAVA_OPTS proxy variable correctly leads to this:
  [exec] Downloading
 http://services.gradle.org/distributions/gradle-2.2.1-all.zip
  [exec]

 ..
  [exec] Unzipping

 /home/ignisvulpis/.gradle/wrapper/dists/gradle-2.2.1-all/2m8005s69iu8v0oiejfej094b/gradle-2.2.1-all.zip
 to

 /home/ignisvulpis/.gradle/wrapper/dists/gradle-2.2.1-all/2m8005s69iu8v0oiejfej094b
  [exec] Set executable permissions for:

 /home/ignisvulpis/.gradle/wrapper/dists/gradle-2.2.1-all/2m8005s69iu8v0oiejfej094b/gradle-2.2.1/bin/gradle
  [exec]
  [exec] FAILURE: Build failed with an exception.
  [exec]
  [exec] * What went wrong:
  [exec] A problem occurred configuring root project 'android'.
  [exec]  Could not resolve all dependencies for configuration
 ':classpath'.
  [exec] Could not resolve com.android.tools.build:gradle:1.0.0+.
  [exec]  Required by:
  [exec]  :android:unspecified
  [exec]Failed to list versions for
 com.android.tools.build:gradle.
  [exec]   Unable to load Maven meta-data from

 https://repo1.maven.org/maven2/com/android/tools/build/gradle/maven-metadata.xml
 .
  [exec]  Could not GET '

 https://repo1.maven.org/maven2/com/android/tools/build/gradle/maven-metadata.xml
 '.
  [exec] Connection to https://repo1.maven.org refused
  [exec]
  [exec] * Try:
  [exec] Run with

Re: [ANNOUNCEMENT] Cordova Tools (CLI 5.0.0) + Plugins (renamed) have been released

2015-04-22 Thread Andrew Grieve

WOOOHOOOHOHOOO!!

On Wed, Apr 22, 2015 at 11:04 AM, Raymond Camden raymondcam...@gmail.com
wrote:

 Ah - a shift reload fixed it. Is the caching a bit high for the page?

 On Wed, Apr 22, 2015 at 7:15 AM, Carlos Santana csantan...@gmail.com
 wrote:
  Hi Ray
  Home page http://cordova.apache.org shows the last 3 blog posts with
  corresponding Read More that takes you directly to post.
 
  21 Apr 2015 » Tools Release: April 21, 2015
  http://cordova.apache.org/news/2015/04/21/tools-release.html
  21 Apr 2015 » Plugins Release and Moving plugins to npm: April 21, 2015
  
 http://cordova.apache.org/announcements/2015/04/21/plugins-release-and-move-to-npm.html
 
  15 Apr 2015 » Apache Cordova Android 4.0.0
  
 http://cordova.apache.org/announcements/2015/04/15/cordova-android-4.0.0.html
 
 
  If you see this now, maybe it was a caching problem, and now is resolved.
 
 
 
  On Wed, Apr 22, 2015 at 12:53 AM, Shazron shaz...@gmail.com wrote:
 
  It should be, I see it?
 
  On Tue, Apr 21, 2015 at 8:12 PM, Raymond Camden 
 raymondcam...@gmail.com
  wrote:
   Query - the blog listing on the home page isn't updated. Is that a
 known
  issue?
  
   On Tue, Apr 21, 2015 at 5:46 PM, Steven Gill stevengil...@gmail.com
  wrote:
   Tools and plugins have been released.
  
   Includes fetching from npm and renamed plugins.
  
   Plugins:
  
 
 http://cordova.apache.org/announcements/2015/04/21/plugins-release-and-move-to-npm.html
  
   Tools: http://cordova.apache.org/news/2015/04/21/tools-release.html
  
   Tweets:
   https://twitter.com/apachecordova/status/590676867046383616
   https://twitter.com/apachecordova/status/590677169745068034
   https://twitter.com/apachecordova/status/590677437454929920
  
  
  
   --
  
 
 ===
   Raymond Camden, Developer Advocate for MobileFirst at IBM
  
   Email : raymondcam...@gmail.com
   Blog : www.raymondcamden.com
   Twitter: raymondcamden
  
   -
   To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
   For additional commands, e-mail: dev-h...@cordova.apache.org
  
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
  For additional commands, e-mail: dev-h...@cordova.apache.org
 
 
 
 
  --
  Carlos Santana
  csantan...@gmail.com



 --
 ===
 Raymond Camden, Developer Advocate for MobileFirst at IBM

 Email : raymondcam...@gmail.com
 Blog : www.raymondcamden.com
 Twitter: raymondcamden

 -
 To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
 For additional commands, e-mail: dev-h...@cordova.apache.org

Re: Cookie support in docs.

2015-04-22 Thread Andrew Grieve

Cookies work the same as they do in a browser AFAIK. cookies for file:
don't make sense because you talk to a server at file:. If you make an XHR
to http:///, they it can set cookies.

On Wed, Apr 22, 2015 at 6:12 AM, Andrey Kurdumov kant2...@googlemail.com
wrote:

 Hi,

 I come across the following SO question.

 http://stackoverflow.com/questions/24374397/cookie-support-in-cordova-official-documentation

 The guy could not find any mentions about cookie support in the Phonegap. I
 do google search and find that the only mention about cookie support is
 issue CB-8026 where stated that Android support third-party cookies. I
 personally was having problems with that, but resolve it using custom HTTP
 header.

 Question is: Does it make sense add the section in the docs regarding
 cookies, and their limitations in Cordova apps, due to fact that files
 server over file:/// protocol?

Re: Deprecation Wars: ICS vs Gingerbread

2015-04-22 Thread Andrew Grieve

Not sure it's worth doing another release just for this. Devs can already
set the minSdkVersion using a preference.

On Wed, Apr 22, 2015 at 5:33 PM, Joe Bowser bows...@gmail.com wrote:

 BTW: Sorry for rushing the commit and sticking the ugly merge commit to try
 and fix it.

 On Wed, Apr 22, 2015 at 2:28 PM Steven Gill stevengil...@gmail.com
 wrote:

  Okay. Since pluggable webviews don't work with 2.3.x, I'd say we do a
  cordova-android 4.1.0 release with minsdk 14.
 
  I'll update the docs to say we only support android 4+
 
  On Wed, Apr 22, 2015 at 2:24 PM, Joe Bowser bows...@gmail.com wrote:
 
   As in they don't work on Android 2.3.x, sorry hit send way too soon.
  Also,
   there's a lot of bad security issues on 2.3.x that we just can't fix,
 so
   it's best that we draw the line here and not support 2.3.x
  
   On Wed, Apr 22, 2015 at 2:23 PM Joe Bowser bows...@gmail.com wrote:
  
None of the Third Party WebViews work for 4.0.x
   
On Wed, Apr 22, 2015 at 2:19 PM Steven Gill stevengil...@gmail.com
wrote:
   
4.1.0? Is the minsdk the only thing keeping gingerbread support
  around?
Are
there other things about 4.0.0 that broke support for 2.3.0?
   
   
   
On Wed, Apr 22, 2015 at 2:13 PM, Joe Bowser bows...@gmail.com
  wrote:
   
 OK, because we screwed up, should we release a Cordova-Android
 5.0?
This
 is going to break people, even though I don't care about the
  breakage,
I do
 care about telling them about the breakage.

 Thoughts?

 On Wed, Apr 22, 2015 at 2:10 PM Joe Bowser bows...@gmail.com
  wrote:

  It should be replaced with 14.  This was definitely an oversight
since we
  all agreed in theory but never came to a proper decision.
 
  On Wed, Apr 22, 2015 at 12:20 PM Sergey Grebnov (Akvelon) 
  v-seg...@microsoft.com wrote:
 
  I still see minSdkVersion = 10 (GINGERBREAD) in platform
  template.
 Should
  it be replaced w/ 14 (ICE_CREAM_SANDWICH) in this case and also
updated
 in
  platform docs? -  per docs we still support Gingerbread.
 
  Steve is currently working on docs update so this is perfect
 time
   to
  change this.
 
  -Sergey
  -Original Message-
  From: Shazron [mailto:shaz...@gmail.com]
  Sent: Tuesday, April 21, 2015 1:04 PM
  To: dev@cordova.apache.org
  Subject: Re: Deprecation Wars: ICS vs Gingerbread
 
  Joe, perhaps that can be part of the Tools Release blog post?
  Steve
put
  out a link to the draft in another thread.
 
  On Tue, Apr 21, 2015 at 10:14 AM, Joe Bowser 
 bows...@gmail.com
wrote:
   Resurrecting this thread!
  
   I think we need to let our users know that Cordova 4.0
 doesn't
support
   Gingerbread, or at least some of the features don't work on
 Gingerbread.
   I've been trying to clean up the JIRA a bit today, and it
 seems
that
   while we came to a consensus to drop 2.3, we didn't tell
  anyone.
   :/
  
  
   On Tue, Jan 13, 2015 at 12:41 PM Joe Bowser 
 bows...@gmail.com
  
 wrote:
  
   Firefox works on 2.3, and Chrome does not. It also depends
 on
   the
   device
  
   On Tue, Jan 13, 2015, 12:20 PM Josh Soref 
   jso...@blackberry.com
  wrote:
  
   Michal Mocny wrote:
   ... we aren't telling those individuals that they cannot
 use
their
   phones, we are telling developers that want to create new
   applications for that target to either build mobile web,
packaged
   native, or just stick to existing versions of cordova if
   really
  needed.
   
   I do not buy the argument that you are doing those
  individuals
with
   those phones a favour by building them hybrid apps using
 the
   antiquated 2.3 webview on antiquated machine specs.
  
   I don't have an opinion on this. But I do have a question.
  
   Ignoring the fact that GeckoView is flaky today,
  
   1. Does GeckoView / Firefox work (at all? well?) on a
 sample
  /
   typical 2.3 device?
   2. Can I run Chrome (or some relative) on that same device
  (at
all?
   well?)
  
  
 
 
   -
  To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
  For additional commands, e-mail: dev-h...@cordova.apache.org
 
 
 
   -
  To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
  For additional commands, e-mail: dev-h...@cordova.apache.org

Re: Scoped package names for npm?

2015-04-21 Thread Andrew Grieve

Given the state of some of our plugins, dropping the distinguishing
namespace might be a good thing :P

On Tue, Apr 21, 2015 at 8:45 AM, Horn, Julian C julian.c.h...@intel.com
wrote:

 I am also against another rename.  These name changes are very costly and
 disruptive.

 There is code in several places that assumes that you can enumerate the
 plugins selected by a project by enumerating the subdirectories of plugins.
 If you allow a plugin root folder to be more than a single directory,
 like @cordova/plugin-device then you break that code.

 Also, please remember that when you rename a plugins, you require people
 to update every dependency tag that refers to that plugin, unless you
 want to rely on the rename machinery forever.

 Julian

 -Original Message-
 From: Steven Gill [mailto:stevengil...@gmail.com]
 Sent: Monday, April 20, 2015 9:42 PM
 To: dev@cordova.apache.org
 Subject: Re: Scoped package names for npm?

 I also like scoped packages but am against another rename. Haha.

 I know organizations are coming soon so we will be able to create the
 Cordova organization and I believe scope packages that way. Add PMC members
 to the organization to be able to publish instead of relying on a Cordova
 npm user account.

 Lets wait and see how it goes.
 On Apr 20, 2015 2:29 PM, Jesse purplecabb...@gmail.com wrote:

  re: the scoped package id, I like it, but not sure we want to change
  them again ... and how much of our existing world will it break. Can
  we install an '@' id currently on all platforms? It will result in a
  www/plugins/@cordova/plugin-device/ folder right now, won't it?
 
  re: other questions
  Personally, I would rather see only committers able to publish to our
  scope (assuming we go that way), just like we wanted to prevent non
  committers from using org.apache.cordova namespace.
 
  I considered 'cordova plugin add device' awhile back, I was going to
  do it directly in plugman, but I decided against it. Currently it
  would mean a 3rd attempt to find the plugin over http; 1) cpr, 2) npm,
  3)munge name and go back to npm By this time, I think I would just ask
  the user what they really want.
  We could also do this via cordova-registry-mapper aliases.
 
 
 
  @purplecabbage
  risingj.com
 
  On Mon, Apr 20, 2015 at 2:13 PM, Parashuram N (MS OPEN TECH) 
  panar...@microsoft.com wrote:
 
   Scopes are like namespaces. In the reverse domain name world,
   org.apache.cordova was considered a namespace, right ?
  
   We did not want non core packages to publish to that namespace, so
   does the same argument apply ?
  
   Alternatively, we can think of scope as packages that apply to a
   particular environment - for example, all cordova packages would be
   @cordova scope.
  
   -Original Message-
   From: Michal Mocny [mailto:mmo...@google.com]
   Sent: Monday, April 20, 2015 2:03 PM
   To: dev
   Subject: Re: Scoped package names for npm?
  
   Other questions to answer:
   - Can 3rd-parties publish to this scope?
 - Do we want them to?
   - Do we want to default to @cordova scope if none is provided, such
   that you could do `cordova plugin add device`?
  
   -Michal
  
  
   On Mon, Apr 20, 2015 at 5:00 PM, Michal Mocny mmo...@google.com
 wrote:
  
https://docs.npmjs.com/getting-started/scoped-packages
   
Should we be @cordova/plugin-device instead of cordova-plugin-device?
   
-Michal
   
  
 

 -
 To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
 For additional commands, e-mail: dev-h...@cordova.apache.org

Re: Question about bypassing the run-loop wait/entire bridge for plugins on iOS

2015-04-20 Thread Andrew Grieve

I think Jesse pretty much covered it.

I would be surprised if you could get web animations to be in sync with
native animations like the keyboard. If you are to try, I think you'd get
closest by attaching a timestamp to the event you're sending to JS, and use
requestAnimationFrame to animate. CSS animations don't guarantee that they
will start right away I don't think.

That said - yes, you should just experiment with whether using
stringByEvaluatingJavaScriptFromString helps at all. If it doesn't help
anyways though, there's no point in using it.
What can go wrong?
- possibility of deadlock, esp when JS callback tries to do an alert()
- does not optimized calls to exec() made from within the callback
- will not work out-of-the-box with WKWebView.

On Mon, Apr 20, 2015 at 5:40 PM, Jesse purplecabb...@gmail.com wrote:

I think you are best off to experiment and see what you can get working
consistently. The focus lately has been on the wkwebview bridge, which is
entirely new, while the current webview implementation is a collection of
workarounds for various issues.

If you can distill this down to a simple project that demonstrates the
issue, I would be happy to have a look.

@purplecabbage
risingj.com

On Mon, Apr 20, 2015 at 3:25 PM, Tim Lancina t...@drifty.com wrote:

Whoops should probably have subscribed to the mailing list! Apologies if
this screws up the thread.

Thanks for your response Jesse. The problem is knowing when to start the
css animation, hence why it would be best to be able to fire an event
indicating the keyboard is about to show as quickly as possible. If you
wait for the run-loop, the animation will be behind by an arbitrary
amount
by the time it receives the event. This isn't the end of the world, it
just isn't as smooth and simultaneous as native.

In the case of the keyboard plugin, all it does is trigger an event on
the
document indicating the keyboard will show/hide. So if I'm understanding
correctly, it would be better to leave the default evalJS
scheduledOnRunLoop:YES call because the handlers for those events fired
by
the plugin could in theory result in more calls to native, correct?

I suppose we could fire one event immediately, with the stipulation that
handlers for the event shouldn't trigger any native calls, and another
marginally slower, 'safe' event that could be used in most circumstances.

If I'm making any false assumptions or overlooking something, please let
me
know!

Best,
Tim

On Mon, Apr 20, 2015 at 4:45 PM, Josh Bavari jbav...@gmail.com wrote:

-- Forwarded message --
From: Jesse purplecabb...@gmail.com
Date: Mon, Apr 20, 2015 at 1:39 PM
Subject: Re: Question about bypassing the run-loop wait/entire bridge
for
plugins on iOS
To: dev@cordova.apache.org dev@cordova.apache.org

If you can be sure that your calls into js will not result in more
calls
back to native, then it is probably fine. Delegating back to the main
thread may have similar performance trouble though ...

For this specific case, can't you use a timed css animation that
matches
the keyboard animation?

@purplecabbage
risingj.com

On Mon, Apr 20, 2015 at 12:18 PM, Tim Lancina t...@drifty.com wrote:

Hey Andrew,

Just had a quick question about plugins on iOS. For the keyboard
plugin
we're using evalJS to fire an event when the keyboard shows, which by
default waits for the run loop to cycle before executing any JS. My
question is, would terrible things happen if we didn't wait, or even
just
went straight stringByEvaluatingJavaScriptFromString? I can see from
the
commented code (

https://github.com/apache/cordova-ios/blob/master/CordovaLib/Classes/CDVCommandDelegateImpl.m#L83
)
that there are certain scenarios where it looks like you need to
wait,
but
was wondering if those are extreme edge cases or regular occurrences.

The reason I'm asking is that we had someone bring up an issue on the
Ionic
issue tracker about getting the keyboard plugin to fire quickly
enough
so
they could animate an element along with the keyboard animation like
on
native. The issue is here:
https://github.com/driftyco/ionic/issues/3537,
but I was hesitant to give them a definitive answer on either
bypassing
the
wait or not. It would also be nice to update the plugin if bypassing
the
wait isn't an issue in most cases.

Cheers,
Tim

--
Clear thoughts produce clear results.
Josh Bavari
Application Developer
Phone: 405-509-9448
Cell: 405-812-0496
Email: jbav...@gmail.com

Re: moving plugins to npm

2015-04-20 Thread Andrew Grieve

On Thu, Apr 16, 2015 at 3:51 PM, Steven Gill stevengil...@gmail.com wrote:

 On Thu, Apr 16, 2015 at 1:36 PM, Don Coleman don.cole...@gmail.com
 wrote:

  I'm little nervous about changing the ids for my plugins for npm.
 
  I like the cordova-plugin-* prefix. I think the consistency is good. Is
  there any concern that the namespace is too small?
 

 I don't think so. I would suggest trying to keep the names short. You don't
 have to use cordova-plugin-* prefix. Important part is adding
 ecosystem:cordova keyword


FWIW, I am hoping that the smaller namespace will be a good thing, and
cause there to be fewer higher-quality plugins to emerge.




 
  Will newer versions of plugman automatically install the right plugin
 based
  on the id mapping or does it just issue a warning?
 

 Warning for now. We may do the auto map and install in the future though.

 
  During the transition do I publish new versions of plugins to both
  cordova.io and npm?
 

 Up to you. plugins.cordova.io will be switched to read-only in about 3
 months (July 15).

Re: Proposal: Expose check_reqs at the CLI level

2015-04-15 Thread Andrew Grieve

We've worked to make iOS add'able from Windows, so I do think it's a good
idea to *not* run check_reqs from add (we used to but removed it).

We already run it on build, so potentially we already have this command:
cordova platform build android --nobuild



On Tue, Apr 14, 2015 at 9:51 PM, Treggiari, Leo leo.treggi...@intel.com
wrote:

 My opinions.

 Q1.  Just say that platform is not added, so cannot check requirements.

 I don't think it is important to support the platform-not-added case.

 Q2.  Should the requirements be checked when a platform is added, or when
 it is built ?

 'platform add' should work even when the requirements are not met.  If
 requirements
 used to be checked on 'platform add', then I suspect they were removed to
 support
 the scenario of using the same Cordova project on multiple host platforms.
 E.g. a team with some developers on Windows and some on Mac.  As a user of
 Cordova CLI on Windows, I want it to be OK to have the project I'm working
 on have the
 iOS platform added and I only get errors if I try to do something (build,
 emulate)
 which requires the native SDK.

 Leo

 -Original Message-
 From: Parashuram N (MS OPEN TECH) [mailto:panar...@microsoft.com]
 Sent: Tuesday, April 14, 2015 6:04 PM
 To: dev@cordova.apache.org
 Subject: RE: Proposal: Expose check_reqs at the CLI level

 I think you raise an interesting point on the behavior of check_reqs for
 platform that are not yet added.

 The options, as you mention are

 Question 1
 1 -  Add the platform, run check_reqs script, remove the platform and
 report results.
 1.5 - Just download the check_reqs script (or use it from the cached
 platform directory) without adding the platform, and run that.
 2 -  Just say that platform is not added, so cannot check requirements.

 Question 2: It also comes to the case of - when would a user want to run
 the requirement check
 - before starting a cordova project ?
 - before adding a platform ?
 - should the requirements be checked when a platform is added, or when it
 is built ?

 The answer to the above questions will help us understand if a top level
 req_check is required or not. We should also look at what check_reqs do
 today - the do not tell you ALL the missing pieces for building an SDK.

 It would be good to hear what the others in the community think about
 these answers.

 -Original Message-
 From: Josh Soref [mailto:jso...@blackberry.com]
 Sent: Tuesday, April 14, 2015 9:55 AM
 To: dev@cordova.apache.org
 Subject: RE: Proposal: Expose check_reqs at the CLI level

 Fwiw, for the case of a platform that isn't in a project yet, I'd envision:

 `cordova platform doctor not-yet-installed`

 to do effectively:
 ```sh
 (
 PLATFORM=not-yet-installed
 (cordova platform add $PLATFORM 21)  /dev/null 
 cordova platform doctor $PLATFORM;
 (cordova platform remove $PLATFORM 21)
 )
 ```

 i.e. add the platform (or create a temporary project, and add the platform
 to the temporary project), and then run platform doctor, and then remove
 the
 platform (and if it was in a temporary project, delete the temporary
 project...).

 I don't really want to expos a 'check_reqs' verb via CLI.

 If we really really want to, we could have `cordova platform requirements
 [PLATFORM...]` as a verb, that's ok.

 If someone wants to call `check_reqs` directly, they're welcome to do so,
 but it's an incredibly ugly thing and doesn't belong in a public facing
 interface.


  -Original Message-
  From: Parashuram N (MS OPEN TECH) [mailto:panar...@microsoft.com]
  Sent: Tuesday, April 14, 2015 10:19 AM
  To: dev@cordova.apache.org
  Subject: Re: Proposal: Expose check_reqs at the CLI level
 
  Carlos, you are right, check_reqs should be in the platform repo, CLI
 will
  just proxy the call to the platforms.
 
  On 4/13/15, 10:29 PM, Carlos Santana csantan...@gmail.com wrote:
 
  +1 if check_reqs are kept in the platform repos, currently check_reqs is
 a
  platform concerned
  if it's available from CLI it will be just a proxy to the platform
  check_reqs.
  
  if don't keep it in the platform repo, and add this logic to cli repo,
 we
  will need to maintained a list of reqs for each platform, for each
 version
  of each platform.
  
  This is the reason why it was removed from cli and just is present in
 the
  platform repo/code
  
  
  
  On Mon, Apr 13, 2015 at 5:13 PM, Josh Soref jso...@blackberry.com
  wrote:
  
   I'm +1 for `cordova doctor` and `cordova platform doctor
  {platformname}`.
  
   The former should apply to all current platforms, the latter should
  support
   doctoring for available but not added platforms -- if said platform
 were
   specified.
   And we should note in the documentation or `cordova doctor` that it
 may
  do
   other checks -- e.g. linting the config.xml, warning about CSP,
 possibly
   mentioning when a plugin is out of date -- just to indicate to people
  that
   the behavior may evolve.
  
   Not that this is more or less fixing a

Re: Tools for Cordova Commits Presentation Slides

2015-04-15 Thread Andrew Grieve

No video, but I can certainly answer any questions or add more notes to the
slides if anything's unclear.

On Tue, Apr 14, 2015 at 1:58 PM, Willy Aguirre marti1...@gmail.com wrote:

 Is there a video about this presentation?

 2015-04-14 12:55 GMT-05:00 Michael Brooks mich...@michaelbrooks.ca:

  Fantastic deck Andrew!
 
  On Mon, Apr 13, 2015 at 10:46 PM, Carlos Santana csantan...@gmail.com
  wrote:
 
   slides look great ! ;-)
  
   On Mon, Apr 13, 2015 at 5:53 PM, Andrew Grieve agri...@chromium.org
   wrote:
  
Thanks guys!
   
Jesse - your name is there because you were last to comment on the
 PR.
   
Here's an editable link to the doc in case anyone wants to further
   annotate
or make available offline somehow:
   
   
   
  
 
 https://docs.google.com/presentation/d/1xVWmQOfE2gIklX3D12_7dCKXeyU295nLQOGDGd_Mi6A/edit?usp=sharing
   
On Mon, Apr 13, 2015 at 5:49 PM, Michal Mocny mmo...@chromium.org
   wrote:
   
 I think we should implement a smiley adding email triggering system
hosted
 by apache.  I don't have time to work on this, but it could be
implemented
 using...

 :D

 On Mon, Apr 13, 2015 at 5:36 PM, Shazron shaz...@gmail.com
 wrote:

  Yeah http 403. Andrew, if you don't mind maybe post a file link?
 Or
  slideshare or something :)  -- how am I doing
 
  On Mon, Apr 13, 2015 at 2:31 PM, Homer, Tony 
 tony.ho...@intel.com
  
 wrote:
   First, thanks for sharing this!
   Second, I tried to download so I could read offline, but I
 guess
   the
   permissions don¹t allow it? It seemed to silently fail.  If
 that
  is
   intended, no problem.
   Thanks again, reading online now.
  
   Tony
  
   On 4/13/15, 4:58 PM, Jesse purplecabb...@gmail.com wrote:
  
  And I almost forgot the last bit I learnt from your slides ...
 ;)
  smileys!
  
  
  @purplecabbage
  risingj.com
  
  On Mon, Apr 13, 2015 at 1:53 PM, Jesse 
 purplecabb...@gmail.com
 wrote:
  
   I got a little confused by slide #54/55
   My name is circled, but I didn't merge that pull request, I
commented
  on
   the next one #172 ... of course, if I had your narration, I
  would
 have
  been
   fine.
  
   Thanks for sharing this!
   Were the talks recorded?
  
   @purplecabbage
   risingj.com
  
   On Mon, Apr 13, 2015 at 1:31 PM, Michal Mocny 
   mmo...@chromium.org

  wrote:
  
   Great lessons learned!
  
   On Mon, Apr 13, 2015 at 4:29 PM, Murat Sutunc 
 mura...@microsoft.com
   wrote:
  
Looks pretty good to me!
   
-Original Message-
From: agri...@google.com [mailto:agri...@google.com] On
   Behalf
Of
   Andrew
Grieve
Sent: Monday, April 13, 2015 1:14 PM
To: dev
Subject: Tools for Cordova Commits Presentation Slides
   
Created the slides to be readable without me talking over
  them
in
  hopes
   to
be a form of documentation for the project :)
   
Mainly:
- how to use some of coho,
- how to do a pull request
- picture guides to visual debugging for node, android,
 ios
   
http://goo.gl/ciGnaR
   
  
  
  
  
  
  
   -
   To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
   For additional commands, e-mail: dev-h...@cordova.apache.org
  
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
  For additional commands, e-mail: dev-h...@cordova.apache.org
 
 

   
  
  
  
   --
   Carlos Santana
   csantan...@gmail.com
  
 



 --
 Willy Aguirre | @willrre
 Blog: http://osgux.tumblr.com/
 Mozilla Rep: https://reps.mozilla.org/u/Willy/
 Mozilla Hispano - Willyaguirre
 https://www.mozilla-hispano.org/documentacion/Usuario:Willyaguirre

Android 4.0 Blog Post

2015-04-15 Thread Andrew Grieve

The 4.0 release is posted to npm, and I've updated the blog post to work
without the need for a tools release:

I'd like to publish the blog post without waiting for a CLI release:
- I've updated the post to use plugins-from-git so it works without new CLI
- I've mentioned those can just wait for tools if they like
- This should give us some early adopter feedback in case there's a need
for a 4.0.1

https://github.com/cordova/apache-blog-posts/blob/master/2015-04-10-cordova-android-4.0.0.md

Any objections?

Re: [Vote] 4.0.0 Android Release

2015-04-15 Thread Andrew Grieve

The vote has now closed. The results are:
Positive Binding Votes: 6

Andrew Grieve
Joe Bowser
Brian LeRoux
Simon MacDonald
Sergey Grebnov
Ian Clelland

Negative Binding Votes: 0

The vote has passed.

On Wed, Apr 15, 2015 at 10:15 AM, Ian Clelland iclell...@chromium.org
wrote:

 +1

 Verified package integrity against signatures, checksums and public repo
at
 the same commit.
 Successfully built and ran mobilespec.

Re: Android 4.0 Blog Post

2015-04-15 Thread Andrew Grieve

You can customize the tags per-platform via platform
name=android.../platform.
Although, the new tags will be ignored by other platforms anyways, and
access remains the way to whitelist network URLs.
So, in practice I think things should mostly just work out.

On Wed, Apr 15, 2015 at 2:43 PM, Brian LeRoux b...@brian.io wrote:

 from a fictional blog post I should write: 3 ways to bulletproof your
 network

 if you want to ensure your app only talks to domains you specify then:

 1. do not include 3rd party scripts (or if you do make sure you trust them
 and maybe keep an eye out for document.write!)
 2. use ssl for all your http traffic
 3. only talk to external services through a proxy you run (and auth)



 On Wed, Apr 15, 2015 at 1:14 PM, Ian Clelland iclell...@chromium.org
 wrote:

  On Wed, Apr 15, 2015 at 1:47 PM, Treggiari, Leo leo.treggi...@intel.com
 
  wrote:
 
   If anyone has the time to educate me, then please pardon my ignorance.
  
   Then you're suggesting that if I'm writing a cross-platform app, I
 stick
   with
   the legacy whitelist plugin until all of the platforms I care about
  support
   new whitelisting?  Or they already do support the new whitelisting?
  
 
  Most platforms *do not* support the new whitelisting. As of right now,
 it's
  Android 4.0.0, and iOS (4.0.x development branch).
 
  If you're building a cross-platform app, there are a couple of options,
 but
  they all come down to the fact that you need to use the old syntax for
 any
  platforms other than Android.
 
 
  1. Install the legacy plugin, and use the same syntax for everything
  (easiest)
 
  2. Install the new whitelist plugin, and have separate config.xml files
 for
  each platform. This may or may not be feasible, depending on your build
  system. You'll probably have to swap the config file out between builds
 of
  different platforms (I can't remember off-hand if there's any syntax in
  config.xml to have platform-dependent sections, but that would make this
  easier.)
 
  3. Install the new whitelist plugin, and use *both* syntaxes in
 config.xml.
  The new plugin uses access tags for network requests, but not for
  navigation, so you'd have to include allow-navigation tags as well, if
  you have more than a single-page-app. You can include both kinds of tags,
  though, and the platforms will happily just pick out the ones they
  understand.
 
 
   Thanks,
   Leo
  
   -Original Message-
   From: Joe Bowser [mailto:bows...@gmail.com]
   Sent: Wednesday, April 15, 2015 10:42 AM
   To: dev@cordova.apache.org
   Subject: Re: Android 4.0 Blog Post
  
   Isn't this why the Legacy Whitelist plugin exists?
  
   On Wed, Apr 15, 2015 at 10:40 AM Treggiari, Leo 
 leo.treggi...@intel.com
  
   wrote:
  
I have a question.  With the new whitelist support in Android, does
  that
mean if I'm writing a cross-platform app, do I need to deal with
whitelisting differently in Android and other platforms (at least
 until
   the
other platforms 'catch up')?  If not, thanks.  If so, what would be
 the
best way to handle the differences - perhaps using the merges
   functionality?
   
Thanks,
Leo
   
-Original Message-
From: agri...@google.com [mailto:agri...@google.com] On Behalf Of
  Andrew
Grieve
Sent: Wednesday, April 15, 2015 10:18 AM
To: dev
Subject: Android 4.0 Blog Post
   
The 4.0 release is posted to npm, and I've updated the blog post to
  work
without the need for a tools release:
   
I'd like to publish the blog post without waiting for a CLI release:
- I've updated the post to use plugins-from-git so it works without
 new
   CLI
- I've mentioned those can just wait for tools if they like
- This should give us some early adopter feedback in case there's a
  need
for a 4.0.1
   
   
   
  
 
 https://github.com/cordova/apache-blog-posts/blob/master/2015-04-10-cordova-android-4.0.0.md
   
Any objections?
   
-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: Android 4.0 Blog Post

2015-04-15 Thread Andrew Grieve

Posted!

Steve - can tweet it from @ApacheCordova?
https://cordova.apache.org/announcements/2015/04/15/cordova-android-4.0.0.html

On Wed, Apr 15, 2015 at 5:31 PM, Treggiari, Leo leo.treggi...@intel.com
wrote:

 Thanks all for the information and suggestions on whitelisting.  Very
 helpful!

 Leo

 -Original Message-
 From: agri...@google.com [mailto:agri...@google.com] On Behalf Of Andrew
 Grieve
 Sent: Wednesday, April 15, 2015 11:51 AM
 To: dev
 Subject: Re: Android 4.0 Blog Post

 You can customize the tags per-platform via platform
 name=android.../platform.
 Although, the new tags will be ignored by other platforms anyways, and
 access remains the way to whitelist network URLs.
 So, in practice I think things should mostly just work out.

 On Wed, Apr 15, 2015 at 2:43 PM, Brian LeRoux b...@brian.io wrote:

  from a fictional blog post I should write: 3 ways to bulletproof your
  network
 
  if you want to ensure your app only talks to domains you specify then:
 
  1. do not include 3rd party scripts (or if you do make sure you trust
 them
  and maybe keep an eye out for document.write!)
  2. use ssl for all your http traffic
  3. only talk to external services through a proxy you run (and auth)
 
 
 
  On Wed, Apr 15, 2015 at 1:14 PM, Ian Clelland iclell...@chromium.org
  wrote:
 
   On Wed, Apr 15, 2015 at 1:47 PM, Treggiari, Leo 
 leo.treggi...@intel.com
  
   wrote:
  
If anyone has the time to educate me, then please pardon my
 ignorance.
   
Then you're suggesting that if I'm writing a cross-platform app, I
  stick
with
the legacy whitelist plugin until all of the platforms I care about
   support
new whitelisting?  Or they already do support the new whitelisting?
   
  
   Most platforms *do not* support the new whitelisting. As of right now,
  it's
   Android 4.0.0, and iOS (4.0.x development branch).
  
   If you're building a cross-platform app, there are a couple of options,
  but
   they all come down to the fact that you need to use the old syntax for
  any
   platforms other than Android.
  
  
   1. Install the legacy plugin, and use the same syntax for everything
   (easiest)
  
   2. Install the new whitelist plugin, and have separate config.xml files
  for
   each platform. This may or may not be feasible, depending on your build
   system. You'll probably have to swap the config file out between builds
  of
   different platforms (I can't remember off-hand if there's any syntax in
   config.xml to have platform-dependent sections, but that would make
 this
   easier.)
  
   3. Install the new whitelist plugin, and use *both* syntaxes in
  config.xml.
   The new plugin uses access tags for network requests, but not for
   navigation, so you'd have to include allow-navigation tags as well,
 if
   you have more than a single-page-app. You can include both kinds of
 tags,
   though, and the platforms will happily just pick out the ones they
   understand.
  
  
Thanks,
Leo
   
-Original Message-
From: Joe Bowser [mailto:bows...@gmail.com]
Sent: Wednesday, April 15, 2015 10:42 AM
To: dev@cordova.apache.org
Subject: Re: Android 4.0 Blog Post
   
Isn't this why the Legacy Whitelist plugin exists?
   
On Wed, Apr 15, 2015 at 10:40 AM Treggiari, Leo 
  leo.treggi...@intel.com
   
wrote:
   
 I have a question.  With the new whitelist support in Android, does
   that
 mean if I'm writing a cross-platform app, do I need to deal with
 whitelisting differently in Android and other platforms (at least
  until
the
 other platforms 'catch up')?  If not, thanks.  If so, what would be
  the
 best way to handle the differences - perhaps using the merges
functionality?

 Thanks,
 Leo

 -Original Message-
 From: agri...@google.com [mailto:agri...@google.com] On Behalf Of
   Andrew
 Grieve
 Sent: Wednesday, April 15, 2015 10:18 AM
 To: dev
 Subject: Android 4.0 Blog Post

 The 4.0 release is posted to npm, and I've updated the blog post to
   work
 without the need for a tools release:

 I'd like to publish the blog post without waiting for a CLI
 release:
 - I've updated the post to use plugins-from-git so it works without
  new
CLI
 - I've mentioned those can just wait for tools if they like
 - This should give us some early adopter feedback in case there's a
   need
 for a 4.0.1



   
  
 
 https://github.com/cordova/apache-blog-posts/blob/master/2015-04-10-cordova-android-4.0.0.md

 Any objections?


 -
 To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
 For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [Vote] 4.0.0 Android Release

2015-04-14 Thread Andrew Grieve

I don't think we need to re-start since no one's -'ve voted, and nothing
would be different. Feel free to start voting! :)

On Tue, Apr 14, 2015 at 10:36 AM, Joe Bowser bows...@gmail.com wrote:

 So...since nobody voted on this thread, I think it's safe to say the vote
 failed.  We should probably re-start this soon.

 On Thu, Apr 9, 2015 at 11:04 AM Treggiari, Leo leo.treggi...@intel.com
 wrote:

  Did the DISCUSS thread have a pointer to the release notes about
 whitelist
  support?
  Sorry that I missed that.
 
  Leo
 
  -Original Message-
  From: Shazron [mailto:shaz...@gmail.com]
  Sent: Thursday, April 09, 2015 11:00 AM
  To: dev@cordova.apache.org
  Subject: Re: [Vote] 4.0.0 Android Release
 
  Why is this on the Vote thread? please take it to the Discuss thread.
 
  On Thursday, April 9, 2015, Treggiari, Leo leo.treggi...@intel.com
  wrote:
 
   Another question, based upon my understanding, which must be wrong!
  
   The 4.0.0 Android Release will require the cordova-plugin-whitelist in
   order
   to get a whitelist implemented correctly.
  
   Given its name (dash-style) it is only available as an node component.
  
   The is no released CLI that knows how to fetch from npm?
   Or does 4.3, even though I don't see it in the release notes?
   Even so, there are many previous CLI releases which will not work?
  
   It would be good for the release notes to explain the situation.
  
   Leo
  
   -Original Message-
   From: Treggiari, Leo [mailto:leo.treggi...@intel.com javascript:;]
   Sent: Thursday, April 09, 2015 10:27 AM
   To: dev@cordova.apache.org javascript:;
   Subject: RE: [Vote] 4.0.0 Android Release
  
   Do the whitelist changes mean that current access origin entries in a
   config.xml file will be ignored the next time that a developer builds
   their project?  If so, that will certainly surprise some developers.
  
   Or does this just impact newly created projects?
  
   Thanks,
   Leo
  
   -Original Message-
   From: mmo...@google.com javascript:; [mailto:mmo...@google.com
   javascript:;] On Behalf Of Michal Mocny
   Sent: Thursday, April 09, 2015 9:54 AM
   To: dev
   Subject: Re: [Vote] 4.0.0 Android Release
  
   PR for Blogpost changes, hopefully making it a bit more obvious what
 the
   whitelist changes are:
   https://github.com/cordova/apache-blog-posts/pull/35
  
   Possibly we want to link to a more in-depth guide and remove some of my
   notes (i.e. specifically what needs adding, which config.xml should
 look
   like).
  
   Question: some of the plugin links are to github, some to npm.  Should
 we
   document how to add these plugins using the new npm plugin name format?
  
   On Thu, Apr 9, 2015 at 12:15 PM, Andrew Grieve agri...@chromium.org
   javascript:; wrote:
  
Please review and vote on this 4.0.0 Android Release.
   
Release issue: https://issues.apache.org/jira/browse/CB-8833
   
Repos ready to be released have been published to dist/dev:
https://dist.apache.org/repos/dist/dev/cordova/CB-8833
   
The package was published from its corresponding git tag:
cordova-android: 4.0.0 (f224b1f2d4)
   
Note that you can test it out via:
   
cordova platform add
  https://github.com/apache/cordova-android#4.0.0
   
Blog post to review is here:
   
   
   
   
  
 
 https://github.com/cordova/apache-blog-posts/blob/master/2015-04-10-cordova-android-4.0.0.md
   
Upon a successful vote I will upload the archive to dist/, publish it
  to
NPM, and post the corresponding blog post.
   
Voting guidelines:
   
  
 
 https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md
   
Voting will go on for a minimum of 48 hours.
   
I vote +1:
* Ran coho audit-license-headers over the relevant repos
* Ran coho check-license to ensure all dependencies and
 subdependencies
have Apache-compatible licenses
* Ran mobilespec and only expected failures were happening
* Verified contents of archive
   
  
  B�CB�
   � [��X��ܚX�K  K[XZ[
   �  ]�][��X��ܚX�P �ܙ ݘK�\ X� K�ܙ�B��܈ Y  ] [ۘ[  ��[X[� �  K[XZ[
   �  ]�Z [   �ܙ ݘK�\ X� K�ܙ�B

Tools for Cordova Commits Presentation Slides

2015-04-13 Thread Andrew Grieve

Created the slides to be readable without me talking over them in hopes to
be a form of documentation for the project :)

Mainly:
- how to use some of coho,
- how to do a pull request
- picture guides to visual debugging for node, android, ios

http://goo.gl/ciGnaR

Re: Tools for Cordova Commits Presentation Slides

2015-04-13 Thread Andrew Grieve

Thanks guys!

Jesse - your name is there because you were last to comment on the PR.

Here's an editable link to the doc in case anyone wants to further annotate
or make available offline somehow:

https://docs.google.com/presentation/d/1xVWmQOfE2gIklX3D12_7dCKXeyU295nLQOGDGd_Mi6A/edit?usp=sharing

On Mon, Apr 13, 2015 at 5:49 PM, Michal Mocny mmo...@chromium.org wrote:

 I think we should implement a smiley adding email triggering system hosted
 by apache.  I don't have time to work on this, but it could be implemented
 using...

 :D

 On Mon, Apr 13, 2015 at 5:36 PM, Shazron shaz...@gmail.com wrote:

  Yeah http 403. Andrew, if you don't mind maybe post a file link? Or
  slideshare or something :)  -- how am I doing
 
  On Mon, Apr 13, 2015 at 2:31 PM, Homer, Tony tony.ho...@intel.com
 wrote:
   First, thanks for sharing this!
   Second, I tried to download so I could read offline, but I guess the
   permissions don¹t allow it? It seemed to silently fail.  If that is
   intended, no problem.
   Thanks again, reading online now.
  
   Tony
  
   On 4/13/15, 4:58 PM, Jesse purplecabb...@gmail.com wrote:
  
  And I almost forgot the last bit I learnt from your slides ... ;)
  smileys!
  
  
  @purplecabbage
  risingj.com
  
  On Mon, Apr 13, 2015 at 1:53 PM, Jesse purplecabb...@gmail.com
 wrote:
  
   I got a little confused by slide #54/55
   My name is circled, but I didn't merge that pull request, I commented
  on
   the next one #172 ... of course, if I had your narration, I would
 have
  been
   fine.
  
   Thanks for sharing this!
   Were the talks recorded?
  
   @purplecabbage
   risingj.com
  
   On Mon, Apr 13, 2015 at 1:31 PM, Michal Mocny mmo...@chromium.org
  wrote:
  
   Great lessons learned!
  
   On Mon, Apr 13, 2015 at 4:29 PM, Murat Sutunc 
 mura...@microsoft.com
   wrote:
  
Looks pretty good to me!
   
-Original Message-
From: agri...@google.com [mailto:agri...@google.com] On Behalf Of
   Andrew
Grieve
Sent: Monday, April 13, 2015 1:14 PM
To: dev
Subject: Tools for Cordova Commits Presentation Slides
   
Created the slides to be readable without me talking over them in
  hopes
   to
be a form of documentation for the project :)
   
Mainly:
- how to use some of coho,
- how to do a pull request
- picture guides to visual debugging for node, android, ios
   
http://goo.gl/ciGnaR
   
  
  
  
  
  
   -
   To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
   For additional commands, e-mail: dev-h...@cordova.apache.org
  
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
  For additional commands, e-mail: dev-h...@cordova.apache.org

Fwd: Infrastructure introduces JIRA Service Desk

2015-04-13 Thread Andrew Grieve

Right on the front page is a button for creating a new git repo :)

https://infrahelp.apache.org

-- Forwarded message --
From: Tony Stevenson pct...@apache.org
Date: Mon, Apr 13, 2015 at 4:29 PM
Subject: Infrastructure introduces JIRA Service Desk
To: committers committ...@apache.org

Folks,

The Infrastructure team today has enabled the use of JIRA Service Desk to
streamline the helpdesk process when opening INFRA JIRA issues. We would
like to ask everyone to use this interface to open new issues going
forward. We hope this will make it a lot easier for everyone.

You can read more about it here,
https://blogs.apache.org/infra/entry/introducing_jira_service_desk

--
Cheers,
Tony

On behalf of the ASF Infrastructure Team

--
Tony Stevenson

t...@pc-tony.com
pct...@apache.org

http://www.pc-tony.com

GPG - 1024D/51047D66
--

Re: [DISCUSS] Cordova-Android 4.0.0 Release

2015-04-09 Thread Andrew Grieve

The plugins being on npm will likely be a bump. Perhaps we should mention
that it requires the latest CLI (not yet release one), and defer the blog
post until CLI is released?

On Thu, Apr 9, 2015 at 2:20 PM, Ian Clelland iclell...@chromium.org wrote:

 Moving from [VOTE] thread:

 On Thu, Apr 9, 2015 at 1:44 PM, Serge Huijben s.huij...@gmail.com wrote:

  But why is the meta csp tag required?


 It's not required, only recommended. It's more secure, as it can restrict
 more network access than the whitelist itself is capable of. (streaming
 audio and video tags, for instance).

 On Thu, Apr 9, 2015 at 1:44 PM, Treggiari, Leo leo.treggi...@intel.com
  wrote:

  Another question, based upon my understanding, which must be wrong!
 
  The 4.0.0 Android Release will require the cordova-plugin-whitelist in
  order
  to get a whitelist implemented correctly.
 
  Given its name (dash-style) it is only available as an node component.
 
  The is no released CLI that knows how to fetch from npm?
  Or does 4.3, even though I don't see it in the release notes?
  Even so, there are many previous CLI releases which will not work?
 

 This is at least partly resolved by the fact that no released CLI points to
 cordova-android 4.0.0. Once 4.0.0 is released. we will be able to release a
 version of the CLI which downloads it by default.

 The whitelist plugins are published already, and discussion is underway
 about voting/releasing cordova-lib (and accompanying tools), so I think
 there are only two possible timelines:

 A) whitelist plugins released, then cordova-android 4 released, then tools
 released (supports NPM plugins and Android 4).

 B) plugins released, then tools released (supports NPM plugins), then
 cordova-android 4 released, then a small bump of tools is released (to pin
 to cordova-android 4)

 In either case, users of the released CLI always have a version which
 works.


  It would be good for the release notes to explain the situation.
 
  Leo
 


 On Thu, Apr 9, 2015 at 1:24 PM, Michal Mocny mmo...@chromium.org wrote:

  Splashscreens was mentioned, icons was not.  I don't think there is an
  icons change?
 
  On Thu, Apr 9, 2015 at 1:17 PM, Joe Bowser bows...@gmail.com wrote:
 
   So, wasn't there a change regarding icons and spashscreens being
 moved? I
   have no idea if we want to add that, or if adding that should happen
  after
   the release?
  
   On Wed, Apr 8, 2015 at 7:09 PM Andrew Grieve agri...@chromium.org
  wrote:
  
CB-8684 is now merged and I've updated the targetSdk (and made a
 couple
other changes).
   
I'll start the release process in the morning as long as there no
objections.
   
   
On Tue, Apr 7, 2015 at 2:20 PM, Andrew Grieve agri...@chromium.org
wrote:
   
 I'll start on it once CB-8684 lands (Tony - assuming you'll have
 this
done
 shortly and would prefer it lands?)

 On Tue, Apr 7, 2015 at 1:33 PM, Jesse purplecabb...@gmail.com
  wrote:

 Sweet!

 @purplecabbage
 risingj.com

 On Tue, Apr 7, 2015 at 8:35 AM, Andrew Grieve 
 agri...@chromium.org
  
 wrote:

  Let's do it!
 
  On Mon, Apr 6, 2015 at 7:33 PM, Joe Bowser bows...@gmail.com
   wrote:
 
   So, I think we should put off the embedder's guide until after
  the
   release.  A lot of it has changed, and since we're still
   technically
   obligated to support the 3.x release tree for six months, that
should
 buy
   us some time to figure out how that is going to work.  Getting
 Cordova to
   work with a vanilla Android Studio project is a non-trivial
  task.
  
   Given that everything else appears to be done, should we start
voting
 on
  an
   RC for this?   What do people think?
  
  
  
   On Thu, Mar 19, 2015 at 10:31 AM Andrew Grieve 
agri...@chromium.org
   wrote:
  
Here's issues:
https://issues.apache.org/jira/browse/CB-8715 (docs)
https://issues.apache.org/jira/browse/CB-8716 (whitelist)
https://issues.apache.org/jira/browse/CB-8717 (write
 RELEASENOTES.md)
   
On Tue, Mar 17, 2015 at 10:15 AM, Carlos Santana 
 csantan...@gmail.com
  
wrote:
   
 I would say let's start RC testing and voting, But not pin
  the
  version
   in
 Cordova CLI until the tasks that Andrew mentioned are
 done.
 Andrew can you create the JIRA Items for the tasks that
 need
   to
be
   done.
I
 thought there was a discussion about creating JIRA Items
 to
   help
  track
and
 know what's left for release something.

 - upgrade guide,
 - publishing whitelist plugins,
 - and making it so that the default project template
  includes
 plugin
 name=cordova-plugin-whitelist /)


 On Mon, Mar 16, 2015 at 11:21 PM, Ian Clelland 
  iclell

Re: [DISCUSS] Cordova-Android 4.0.0 Release

2015-04-09 Thread Andrew Grieve

merged. thanks!

On Thu, Apr 9, 2015 at 3:01 PM, Nikhil Khandelwal nikhi...@microsoft.com
wrote:

 I have another small PR to the blog post for the release:
 https://github.com/cordova/apache-blog-posts/pull/36/commits

 Thanks,
 Nikhil


 -Original Message-
 From: Serge Huijben [mailto:s.huij...@gmail.com]
 Sent: Thursday, April 9, 2015 11:47 AM
 To: Ian Clelland; dev@cordova.apache.org
 Cc: leo.treggi...@intel.com
 Subject: Re: [DISCUSS] Cordova-Android 4.0.0 Release

 Then, it seems strange to me that it logs an error and repeated warnings
 if the meta tag is missing. Perhaps we should remove that from the plugin.

 Op do 9 apr. 2015 om 20:21 schreef Ian Clelland iclell...@chromium.org

  Moving from [VOTE] thread:
 
  On Thu, Apr 9, 2015 at 1:44 PM, Serge Huijben s.huij...@gmail.com
 wrote:
 
  But why is the meta csp tag required?
 
 
  It's not required, only recommended. It's more secure, as it can
  restrict more network access than the whitelist itself is capable of.
  (streaming audio and video tags, for instance).
 
  On Thu, Apr 9, 2015 at 1:44 PM, Treggiari, Leo
  leo.treggi...@intel.com
   wrote:
 
  Another question, based upon my understanding, which must be wrong!
 
 
 
  The 4.0.0 Android Release will require the cordova-plugin-whitelist
  in order to get a whitelist implemented correctly.
 
  Given its name (dash-style) it is only available as an node component.
 
  The is no released CLI that knows how to fetch from npm?
  Or does 4.3, even though I don't see it in the release notes?
  Even so, there are many previous CLI releases which will not work?
 
 
  This is at least partly resolved by the fact that no released CLI
  points to cordova-android 4.0.0. Once 4.0.0 is released. we will be
  able to release a version of the CLI which downloads it by default.
 
  The whitelist plugins are published already, and discussion is
  underway about voting/releasing cordova-lib (and accompanying tools),
  so I think there are only two possible timelines:
 
  A) whitelist plugins released, then cordova-android 4 released, then
  tools released (supports NPM plugins and Android 4).
 
  B) plugins released, then tools released (supports NPM plugins), then
  cordova-android 4 released, then a small bump of tools is released (to
  pin to cordova-android 4)
 
  In either case, users of the released CLI always have a version which
  works.
 
 
  It would be good for the release notes to explain the situation.
 
  Leo
 
 
  On Thu, Apr 9, 2015 at 1:24 PM, Michal Mocny mmo...@chromium.org
 wrote:
 
  Splashscreens was mentioned, icons was not.  I don't think there is
  an icons change?
 
  On Thu, Apr 9, 2015 at 1:17 PM, Joe Bowser bows...@gmail.com wrote:
 
   So, wasn't there a change regarding icons and spashscreens being
 moved?
  I
   have no idea if we want to add that, or if adding that should
   happen
  after
   the release?
  
   On Wed, Apr 8, 2015 at 7:09 PM Andrew Grieve agri...@chromium.org
  wrote:
  
CB-8684 is now merged and I've updated the targetSdk (and made a
  couple
other changes).
   
I'll start the release process in the morning as long as there no
objections.
   
   
On Tue, Apr 7, 2015 at 2:20 PM, Andrew Grieve
agri...@chromium.org
wrote:
   
 I'll start on it once CB-8684 lands (Tony - assuming you'll
 have
  this
done
 shortly and would prefer it lands?)

 On Tue, Apr 7, 2015 at 1:33 PM, Jesse purplecabb...@gmail.com
  wrote:

 Sweet!

 @purplecabbage
 risingj.com

 On Tue, Apr 7, 2015 at 8:35 AM, Andrew Grieve 
  agri...@chromium.org
 wrote:

  Let's do it!
 
  On Mon, Apr 6, 2015 at 7:33 PM, Joe Bowser
  bows...@gmail.com
   wrote:
 
   So, I think we should put off the embedder's guide until
   after
  the
   release.  A lot of it has changed, and since we're still
   technically
   obligated to support the 3.x release tree for six months,
   that
should
 buy
   us some time to figure out how that is going to work.
   Getting
 Cordova to
   work with a vanilla Android Studio project is a
   non-trivial
  task.
  
   Given that everything else appears to be done, should we
   start
voting
 on
  an
   RC for this?   What do people think?
  
  
  
   On Thu, Mar 19, 2015 at 10:31 AM Andrew Grieve 
agri...@chromium.org
   wrote:
  
Here's issues:
https://issues.apache.org/jira/browse/CB-8715 (docs)
https://issues.apache.org/jira/browse/CB-8716
(whitelist)
https://issues.apache.org/jira/browse/CB-8717 (write
 RELEASENOTES.md)
   
On Tue, Mar 17, 2015 at 10:15 AM, Carlos Santana 
 csantan...@gmail.com
  
wrote:
   
 I would say let's start RC testing and voting, But not
 pin
  the
  version
   in
 Cordova CLI until the tasks that Andrew mentioned

Re: [DISCUSS] Cordova-Android 4.0.0 Release

2015-04-09 Thread Andrew Grieve

Michal - Good point about npm vs github for links. We tend to tweak docs
post npm publish, so I've changed the blog post links to github ones.

On Thu, Apr 9, 2015 at 3:55 PM, Andrew Grieve agri...@chromium.org wrote:

 The plugins being on npm will likely be a bump. Perhaps we should mention
 that it requires the latest CLI (not yet release one), and defer the blog
 post until CLI is released?

 On Thu, Apr 9, 2015 at 2:20 PM, Ian Clelland iclell...@chromium.org
 wrote:

 Moving from [VOTE] thread:

 On Thu, Apr 9, 2015 at 1:44 PM, Serge Huijben s.huij...@gmail.com
 wrote:

  But why is the meta csp tag required?


 It's not required, only recommended. It's more secure, as it can restrict
 more network access than the whitelist itself is capable of. (streaming
 audio and video tags, for instance).

 On Thu, Apr 9, 2015 at 1:44 PM, Treggiari, Leo leo.treggi...@intel.com
  wrote:

  Another question, based upon my understanding, which must be wrong!
 
  The 4.0.0 Android Release will require the cordova-plugin-whitelist in
  order
  to get a whitelist implemented correctly.
 
  Given its name (dash-style) it is only available as an node component.
 
  The is no released CLI that knows how to fetch from npm?
  Or does 4.3, even though I don't see it in the release notes?
  Even so, there are many previous CLI releases which will not work?
 

 This is at least partly resolved by the fact that no released CLI points
 to
 cordova-android 4.0.0. Once 4.0.0 is released. we will be able to release
 a
 version of the CLI which downloads it by default.

 The whitelist plugins are published already, and discussion is underway
 about voting/releasing cordova-lib (and accompanying tools), so I think
 there are only two possible timelines:

 A) whitelist plugins released, then cordova-android 4 released, then tools
 released (supports NPM plugins and Android 4).

 B) plugins released, then tools released (supports NPM plugins), then
 cordova-android 4 released, then a small bump of tools is released (to pin
 to cordova-android 4)

 In either case, users of the released CLI always have a version which
 works.


  It would be good for the release notes to explain the situation.
 
  Leo
 


 On Thu, Apr 9, 2015 at 1:24 PM, Michal Mocny mmo...@chromium.org wrote:

  Splashscreens was mentioned, icons was not.  I don't think there is an
  icons change?
 
  On Thu, Apr 9, 2015 at 1:17 PM, Joe Bowser bows...@gmail.com wrote:
 
   So, wasn't there a change regarding icons and spashscreens being
 moved? I
   have no idea if we want to add that, or if adding that should happen
  after
   the release?
  
   On Wed, Apr 8, 2015 at 7:09 PM Andrew Grieve agri...@chromium.org
  wrote:
  
CB-8684 is now merged and I've updated the targetSdk (and made a
 couple
other changes).
   
I'll start the release process in the morning as long as there no
objections.
   
   
On Tue, Apr 7, 2015 at 2:20 PM, Andrew Grieve agri...@chromium.org
 
wrote:
   
 I'll start on it once CB-8684 lands (Tony - assuming you'll have
 this
done
 shortly and would prefer it lands?)

 On Tue, Apr 7, 2015 at 1:33 PM, Jesse purplecabb...@gmail.com
  wrote:

 Sweet!

 @purplecabbage
 risingj.com

 On Tue, Apr 7, 2015 at 8:35 AM, Andrew Grieve 
 agri...@chromium.org
  
 wrote:

  Let's do it!
 
  On Mon, Apr 6, 2015 at 7:33 PM, Joe Bowser bows...@gmail.com
   wrote:
 
   So, I think we should put off the embedder's guide until
 after
  the
   release.  A lot of it has changed, and since we're still
   technically
   obligated to support the 3.x release tree for six months,
 that
should
 buy
   us some time to figure out how that is going to work.
 Getting
 Cordova to
   work with a vanilla Android Studio project is a non-trivial
  task.
  
   Given that everything else appears to be done, should we
 start
voting
 on
  an
   RC for this?   What do people think?
  
  
  
   On Thu, Mar 19, 2015 at 10:31 AM Andrew Grieve 
agri...@chromium.org
   wrote:
  
Here's issues:
https://issues.apache.org/jira/browse/CB-8715 (docs)
https://issues.apache.org/jira/browse/CB-8716 (whitelist)
https://issues.apache.org/jira/browse/CB-8717 (write
 RELEASENOTES.md)
   
On Tue, Mar 17, 2015 at 10:15 AM, Carlos Santana 
 csantan...@gmail.com
  
wrote:
   
 I would say let's start RC testing and voting, But not
 pin
  the
  version
   in
 Cordova CLI until the tasks that Andrew mentioned are
 done.
 Andrew can you create the JIRA Items for the tasks that
 need
   to
be
   done.
I
 thought there was a discussion about creating JIRA Items
 to
   help
  track
and
 know what's left for release something.

 - upgrade guide,
 - publishing whitelist

Re: Does Cordova have a problem making developers happy?

2015-04-09 Thread Andrew Grieve

Apache provides a lot of benefit. I don't want elaborate right now, but I
will promise to post back with some formulated thoughts a bit later (some
of this I'm prepping for my ApacheCon talk, so I need to do it anyways).

Joe - Please please *please* do not write emails that are not constructive.
If you want to be negative, don't hit the send button. If not for the sake
of others, for the sake of yourself - saying negative things about others
almost always ends up making you look worse than those you are being
negative towards.

Another angle:
Even if you are convinced that you're right, and even though your views are
your own (although statements like Or we could just leave the ASF make it
sound like you are representing more than that), your tone often just makes
people want to run away rather than engage. Would you want to contribute to
a project that is full of smileys and encouragement, or one where people
are negative and abrasive? It really goes a long way to keep the email tone
positive even when you disagree.

Since I've been on this project, I've felt that non-Cordova Apache'ers (we
are apache'ers too remember) have been constructive and helpful:
- We want a VM. Mike Billau reached out, and INFRA helped us set one up.
- We want to do BuildBot. Infra helped get us going on their shared
instance.
- We want to use git. So do other projects, and it has been a collaboration
between Infra and other projects that made it happen (we complained, but
didn't do the work to make it possible).
- We want to try reviewboard - Infra got us going in no time (although we
decided not to stick with it).

Why can we not use Github issues?
- It's certainly *not* the case that Apache hates github.
- Has anyone even thought to ask? Maybe it's just a conversation that
hasn't happened yet.
- It's important that Apache projects host their own data, but do issue
trackers count as data?
- Sounds like a *great* discussion to have.
- d...@community.apache.org would be a great place to start, since that's
meant for cross-project discussion.


On Thu, Apr 9, 2015 at 1:53 PM, Joe Bowser bows...@gmail.com wrote:

 On Thu, Apr 9, 2015 at 10:35 AM Ross Gardler (MS OPEN TECH) 
 ross.gard...@microsoft.com wrote:

  Firstly, don't call someone a liar simply because you disagree, it is
  offensive and exactly the kind of behavior I am referring to (and why *I*
  dread ever posting to this list, shame that question wasn't in the Stack
  Overflow survey).
 
 
 Did you intend this to go to me or the list, because based on the tone
 you're using, I can't be sure.  If you're looking to make a personal attack
 on me publicly, then fine, go ahead.  On this list, these comments only
 reflect my own personal views.  It's clear that people don't agree with me,
 because we're still here.

 Joe

 Ross
 
 
  -Original Message-
  From: Joe Bowser [mailto:bows...@gmail.com]
  Sent: Thursday, April 9, 2015 9:28 AM
  To: dev@cordova.apache.org
  Subject: Re: Does Cordova have a problem making developers happy?
 
  On Thu, Apr 9, 2015 at 9:13 AM Ross Gardler (MS OPEN TECH) 
  ross.gard...@microsoft.com wrote:
 
  
   There are no powers that be. Bring a member brings no additional
   influence. What matters around here is constructive contributions and
   participation.
  
  
  That's a lie that we've seen played out numerous times.  There are
 clearly
  people who bully people in project to fall into line. We've had to fight
  the ASF every single time we wanted to do anything with this project, and
  I'm expecting us to fight the ASF again until we eventually leave.
 
 
   To be constructive one needs to understand why things are the way they
   are and, if they don't fit, one needs to work with people to propose
   changes that work.
  
  
  Or we could just leave the ASF and find a different foundation whose
 rules
  aren't as rigid.  That could work too.
 
 
   Historically this project has had real difficulty doing just that.
   Instead it has focused on negativity and mud slinging (there are some
   individuals who certainly do not fit into this category, but their
   voices are usually drowned out.
  
  
  I'm very proud of my record of fighting the ASF.  I regret that we
 donated
  the PhoneGap code to Cordova, since The Apache Way has been complained
  about so many times by our community members who have followed us since
 we
  started this thing.  However, we're stuck here now, and the people who
 feel
  like working with the ASF are doing so.  You're never going to convince
  everyone our community that the ASF is a good thing, especially since
 your
  organization has been passively aggressively attacking various parts of
 the
  JS community for years.  Honestly, I think it's a miracle that we haven't
  forked yet.
 
  Joe
 
  Ross
  
  
   Sent from my Windows Phone
   
   From: Carlos Santanamailto:csantan...@gmail.com
   Sent: ‎4/‎9/‎2015 9:00 AM
   To:

Re: Discussions on vote threads

2015-04-09 Thread Andrew Grieve

That's a good point. Perhaps we should update our template to say minium
or 48 hours, and at least 24 hours after the last non-vote comment

On Thu, Apr 9, 2015 at 3:58 PM, Joe Bowser bows...@gmail.com wrote:

 There's nothing wrong with the practice except that a vote thread with
 comments means that we probably shouldn't proceed and should discuss it
 more.  Too much discussion on  vote thread means we don't have any sort of
 consensus and should work that out first.

 On Thu, Apr 9, 2015, 12:52 PM Andrew Grieve agri...@chromium.org wrote:

  Have become very common for us. Probably because the release VOTE is the
  thing that actually gets people motivated to take a good look.
 
  Thought it'd be good for us to discuss this practice.
 
  My thoughts:
  - I think it still makes sense to DISCUSS before starting a release
  - I think it's perfectly reasonable to go through several RCs as things
  come up during testing (RCs are easy)
  - I think it helps to have the blog post ready before a vote (I made this
  change to the platforms release process this time around)
  - I don't have any problem with VOTE threads that are full of discussion.
  What's the concern?

Discussions on vote threads

2015-04-09 Thread Andrew Grieve

Have become very common for us. Probably because the release VOTE is the
thing that actually gets people motivated to take a good look.

Thought it'd be good for us to discuss this practice.

My thoughts:
- I think it still makes sense to DISCUSS before starting a release
- I think it's perfectly reasonable to go through several RCs as things
come up during testing (RCs are easy)
- I think it helps to have the blog post ready before a vote (I made this
change to the platforms release process this time around)
- I don't have any problem with VOTE threads that are full of discussion.
What's the concern?

Re: [DISCUSS] Cordova-Android 4.0.0 Release

2015-04-09 Thread Andrew Grieve

Certainly makes you notice though. You're free to have an empty CSP tag,
and the plugin docs are full of copy/pastable examples:

https://github.com/apache/cordova-plugin-whitelist/blob/master/README.md

I do think that since CSP is our main way of enforcing whitelists going
forward, that we should be loud in raising awareness of them.

On Thu, Apr 9, 2015 at 2:47 PM, Serge Huijben s.huij...@gmail.com wrote:

 Then, it seems strange to me that it logs an error and repeated warnings if
 the meta tag is missing. Perhaps we should remove that from the plugin.

 Op do 9 apr. 2015 om 20:21 schreef Ian Clelland iclell...@chromium.org

  Moving from [VOTE] thread:
 
  On Thu, Apr 9, 2015 at 1:44 PM, Serge Huijben s.huij...@gmail.com
 wrote:
 
  But why is the meta csp tag required?
 
 
  It's not required, only recommended. It's more secure, as it can restrict
  more network access than the whitelist itself is capable of. (streaming
  audio and video tags, for instance).
 
  On Thu, Apr 9, 2015 at 1:44 PM, Treggiari, Leo leo.treggi...@intel.com
   wrote:
 
  Another question, based upon my understanding, which must be wrong!
 
 
 
  The 4.0.0 Android Release will require the cordova-plugin-whitelist in
  order
  to get a whitelist implemented correctly.
 
  Given its name (dash-style) it is only available as an node component.
 
  The is no released CLI that knows how to fetch from npm?
  Or does 4.3, even though I don't see it in the release notes?
  Even so, there are many previous CLI releases which will not work?
 
 
  This is at least partly resolved by the fact that no released CLI points
  to cordova-android 4.0.0. Once 4.0.0 is released. we will be able to
  release a version of the CLI which downloads it by default.
 
  The whitelist plugins are published already, and discussion is underway
  about voting/releasing cordova-lib (and accompanying tools), so I think
  there are only two possible timelines:
 
  A) whitelist plugins released, then cordova-android 4 released, then
 tools
  released (supports NPM plugins and Android 4).
 
  B) plugins released, then tools released (supports NPM plugins), then
  cordova-android 4 released, then a small bump of tools is released (to
 pin
  to cordova-android 4)
 
  In either case, users of the released CLI always have a version which
  works.
 
 
  It would be good for the release notes to explain the situation.
 
  Leo
 
 
  On Thu, Apr 9, 2015 at 1:24 PM, Michal Mocny mmo...@chromium.org
 wrote:
 
  Splashscreens was mentioned, icons was not.  I don't think there is an
  icons change?
 
  On Thu, Apr 9, 2015 at 1:17 PM, Joe Bowser bows...@gmail.com wrote:
 
   So, wasn't there a change regarding icons and spashscreens being
 moved?
  I
   have no idea if we want to add that, or if adding that should happen
  after
   the release?
  
   On Wed, Apr 8, 2015 at 7:09 PM Andrew Grieve agri...@chromium.org
  wrote:
  
CB-8684 is now merged and I've updated the targetSdk (and made a
  couple
other changes).
   
I'll start the release process in the morning as long as there no
objections.
   
   
On Tue, Apr 7, 2015 at 2:20 PM, Andrew Grieve agri...@chromium.org
 
wrote:
   
 I'll start on it once CB-8684 lands (Tony - assuming you'll have
  this
done
 shortly and would prefer it lands?)

 On Tue, Apr 7, 2015 at 1:33 PM, Jesse purplecabb...@gmail.com
  wrote:

 Sweet!

 @purplecabbage
 risingj.com

 On Tue, Apr 7, 2015 at 8:35 AM, Andrew Grieve 
  agri...@chromium.org
 wrote:

  Let's do it!
 
  On Mon, Apr 6, 2015 at 7:33 PM, Joe Bowser bows...@gmail.com
   wrote:
 
   So, I think we should put off the embedder's guide until
 after
  the
   release.  A lot of it has changed, and since we're still
   technically
   obligated to support the 3.x release tree for six months,
 that
should
 buy
   us some time to figure out how that is going to work.
 Getting
 Cordova to
   work with a vanilla Android Studio project is a non-trivial
  task.
  
   Given that everything else appears to be done, should we
 start
voting
 on
  an
   RC for this?   What do people think?
  
  
  
   On Thu, Mar 19, 2015 at 10:31 AM Andrew Grieve 
agri...@chromium.org
   wrote:
  
Here's issues:
https://issues.apache.org/jira/browse/CB-8715 (docs)
https://issues.apache.org/jira/browse/CB-8716 (whitelist)
https://issues.apache.org/jira/browse/CB-8717 (write
 RELEASENOTES.md)
   
On Tue, Mar 17, 2015 at 10:15 AM, Carlos Santana 
 csantan...@gmail.com
  
wrote:
   
 I would say let's start RC testing and voting, But not
 pin
  the
  version
   in
 Cordova CLI until the tasks that Andrew mentioned are
 done.
 Andrew can you create the JIRA Items for the tasks that
  need
   to
be
   done.
I
 thought

[Vote] 4.0.0 Android Release

2015-04-09 Thread Andrew Grieve

Please review and vote on this 4.0.0 Android Release.

Release issue: https://issues.apache.org/jira/browse/CB-8833

Repos ready to be released have been published to dist/dev:
https://dist.apache.org/repos/dist/dev/cordova/CB-8833

The package was published from its corresponding git tag:
cordova-android: 4.0.0 (f224b1f2d4)

Note that you can test it out via:

cordova platform add https://github.com/apache/cordova-android#4.0.0

Blog post to review is here:


https://github.com/cordova/apache-blog-posts/blob/master/2015-04-10-cordova-android-4.0.0.md

Upon a successful vote I will upload the archive to dist/, publish it to
NPM, and post the corresponding blog post.

Voting guidelines:
https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md

Voting will go on for a minimum of 48 hours.

I vote +1:
* Ran coho audit-license-headers over the relevant repos
* Ran coho check-license to ensure all dependencies and subdependencies
have Apache-compatible licenses
* Ran mobilespec and only expected failures were happening
* Verified contents of archive

Re: Does Cordova have a problem making developers happy?

2015-04-08 Thread Andrew Grieve

Fun survey! Other highlights:

The more things change, the more likely it is those things are written in
JavaScript with NotePad++ on a Windows machine (theme: dark) using Git, and
tabs instead of spaces.

users who have 10,000 rep or more prefer spaces to tabs at a ratio of 3 to
1.

On Wed, Apr 8, 2015 at 11:01 AM, Treggiari, Leo leo.treggi...@intel.com
wrote:

 The data below is from a StackOverflow Developer Survey (
 http://stackoverflow.com/research/developer-survey-2015).

 Most Dreaded technologies:
 Salesforce   73.2%
 Visual Basic72.0%
 Wordpress 68.2%
 Matlab 65.6%
 Sharepoint 62.8%
 LAMP62.2%
 Perl59.2%
 Cordova   58.8%  **
 Coffeescript   54.7%
 Other57.3%
 % of devs who are developing with the language or tech but have not
 expressed interest in continuing to do so.

 Any ideas on what the problem is?  Here are some possible answers.  I'm
 not suggesting that any of these are true, but rather looking for feedback
 from those who have heard developers express frustration with Cordova:


 *There is no problem - unclear question led to the answer

 *The problem is really about creating native apps in JavaScript +
 HTML5

 *Cordova CLI has a quality problem (learnability | usability |
 reliability)

 o   Too hard to set up development environment

 o   The command CLI is too complicated

 o   Not enough learning material (documentation, articles, books)

 o   Too many bugs

 o   Changes too frequently

 Leo

cordova-vm.apache.org

2015-04-08 Thread Andrew Grieve

We got a VM a while ago with the idea to use it for BuildBot / cordova-docs
ruby environment.

I don't think either of these are still applicable (http://ci.cordova.io is
*awesome*!!!)

Any reason to not ask for it to be decommissioned?

Re: cordova-vm.apache.org

2015-04-08 Thread Andrew Grieve

Sounds good!

Here's the thread where I got myself access:
http://markmail.org/thread/ee4ujznt6lhw6ug5#query:+page:1+mid:aqjyawmztdbnb2bf+state:results

My notes from before:
1. Make sure you have an SSH key registered on id.apache.org (ssh'ing to
the machine should work)
2. Install an OPIE (one-time-password) client
http://apache.org/dev/freebsd-jails#opie
3. email r...@apache.org asking them to add you to the VM
4. Wait for access to the machine
5. Set up OPIE via `opiepasswd`  -- DO NOT ENTER YOUR APACHE PASSWORD, it
wants your client's generated password.
6. Request sudo access from #infra


On Wed, Apr 8, 2015 at 2:13 PM, Steven Gill stevengil...@gmail.com wrote:

 yes, it would be great if we could get access to it and setup a couchdb
 instance that replicates CPR

 On Wed, Apr 8, 2015 at 10:57 AM, Nikhil Khandelwal nikhi...@microsoft.com
 
 wrote:

  Yes, we need it to setup an instance of CouchDB. Our longstanding INFRA
  ticket on this subject has not received much love. Having the VM should
  unblock us. What are the next steps to get access to it to setup a
 couchDB
  instance?
 
  Thanks,
  Nikhil
 
 
  -Original Message-
  From: Parashuram N (MS OPEN TECH) [mailto:panar...@microsoft.com]
  Sent: Wednesday, April 8, 2015 8:57 AM
  To: dev@cordova.apache.org
  Subject: Re: cordova-vm.apache.org
 
  If we still have the machine, we could still use it. I think we are still
  working on getting CouchDB setup on Apache, or we could use this as a
 slave.
 
 
  On 4/8/15, 8:35 AM, Andrew Grieve agri...@chromium.org wrote:
 
  We got a VM a while ago with the idea to use it for BuildBot /
  cordova-docs ruby environment.
  
  I don't think either of these are still applicable
  (http://ci.cordova.io is
  *awesome*!!!)
  
  Any reason to not ask for it to be decommissioned?
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
  For additional commands, e-mail: dev-h...@cordova.apache.org
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
  For additional commands, e-mail: dev-h...@cordova.apache.org

Re: cordova-vm.apache.org

2015-04-08 Thread Andrew Grieve

Although - could you remind me why we need a couchdb? It's a hasstle and
will require maintentance.
The logs from the builders seem sufficient to me (they show which tests
fail). Effort might be better spent improving the tests  fixing bugs.

On Wed, Apr 8, 2015 at 2:53 PM, Andrew Grieve agri...@chromium.org wrote:

 Sounds good!

 Here's the thread where I got myself access:

 http://markmail.org/thread/ee4ujznt6lhw6ug5#query:+page:1+mid:aqjyawmztdbnb2bf+state:results

 My notes from before:
 1. Make sure you have an SSH key registered on id.apache.org (ssh'ing to
 the machine should work)
 2. Install an OPIE (one-time-password) client
 http://apache.org/dev/freebsd-jails#opie
 3. email r...@apache.org asking them to add you to the VM
 4. Wait for access to the machine
 5. Set up OPIE via `opiepasswd`  -- DO NOT ENTER YOUR APACHE PASSWORD, it
 wants your client's generated password.
 6. Request sudo access from #infra


 On Wed, Apr 8, 2015 at 2:13 PM, Steven Gill stevengil...@gmail.com
 wrote:

 yes, it would be great if we could get access to it and setup a couchdb
 instance that replicates CPR

 On Wed, Apr 8, 2015 at 10:57 AM, Nikhil Khandelwal 
 nikhi...@microsoft.com
 wrote:

  Yes, we need it to setup an instance of CouchDB. Our longstanding INFRA
  ticket on this subject has not received much love. Having the VM should
  unblock us. What are the next steps to get access to it to setup a
 couchDB
  instance?
 
  Thanks,
  Nikhil
 
 
  -Original Message-
  From: Parashuram N (MS OPEN TECH) [mailto:panar...@microsoft.com]
  Sent: Wednesday, April 8, 2015 8:57 AM
  To: dev@cordova.apache.org
  Subject: Re: cordova-vm.apache.org
 
  If we still have the machine, we could still use it. I think we are
 still
  working on getting CouchDB setup on Apache, or we could use this as a
 slave.
 
 
  On 4/8/15, 8:35 AM, Andrew Grieve agri...@chromium.org wrote:
 
  We got a VM a while ago with the idea to use it for BuildBot /
  cordova-docs ruby environment.
  
  I don't think either of these are still applicable
  (http://ci.cordova.io is
  *awesome*!!!)
  
  Any reason to not ask for it to be decommissioned?
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
  For additional commands, e-mail: dev-h...@cordova.apache.org
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
  For additional commands, e-mail: dev-h...@cordova.apache.org

Re: proposed utility

2015-04-08 Thread Andrew Grieve

I think my reservation about this tool is that I'm afraid that adding yet
another command to the mix of options will add more confusion than it's
worth.

Those that know the difference between npm local vs. global can trivially
create an npm run command (or batch script, or alias, or gulp task) that
calls into node_modules/.bin/cordova.

I think that the clearest guidance we can give is to focus on promoting
just two workflows:
1. Use CLI globally
2. Use cordova-lib locally and call it with gulp/grunt

That said, feel free to post cordova-local to npm :). It's obvious that
some will find it useful.


On Wed, Apr 8, 2015 at 3:42 PM, Parashuram N (MS OPEN TECH) 
panar...@microsoft.com wrote:

 Looks like a good candidate to discuss at the monthly hangouts ?

 -Original Message-
 From: Staci Cooper [mailto:staci@gmail.com]
 Sent: Wednesday, April 8, 2015 11:05 AM
 To: dev@cordova.apache.org
 Subject: Re: proposed utility

 Did anything ever come of this?

 I'd be happy to do some work on this if the consensus is that the
 implementation needs to be changed.

 On Tue, Jan 13, 2015 at 2:10 PM, Staci Cooper staci@gmail.com wrote:

  When I was implementing this I initially did add it as a '--local / -l'
  option to the cli. My concern was that it requires the developer to
  have a global installation of Cordova even if all they want is the local
 command.
  And assuming the user's global and local installs have different
  version numbers, all they would have to do is accidentally omit the -l
  and they would unwittingly use the wrong version of Cordova.
 
  I could add it back in as a flag, or have separate 'cordova' and
  'cordova-local' commands in the cli. Or were you suggesting changing
  the default behavior of the cordova command to shell out to local? In
  which case we could have a flag to turn that behavior off for
  backwards compatibility... or to fallback to the global version if no
  local version is found. Hm, I'm not sure..
 
  On Fri, Jan 9, 2015 at 4:35 PM, Jesse purplecabb...@gmail.com wrote:
 
  Do we need to start a discussion around cordova-cli plugins?
 
  Personally I prefer keeping this in a separate repo.
 
  @purplecabbage
  risingj.com
 
  On Fri, Jan 9, 2015 at 1:08 PM, Tommy Williams to...@devgeeks.org
  wrote:
 
   Just as an aside, I have resorted to:
  
   alias cdv=./node_modules/.bin/cordova
  
   Heh.
   On 10/01/2015 8:06 am, Tommy Williams to...@devgeeks.org wrote:
  
+1 for what Michal describes. Better going forward as well as
  backwards
compatibility.
   
Win win?
On 10/01/2015 7:54 am, Michal Mocny mmo...@chromium.org wrote:
   
I like the way gulp works: the same package acts different when
   installed
globally/locally.  Namely, the global always shells work off to
the
   local.
   
So, instead of a separate cordova-local utility (akin to grunt
and grunt-cli), perhaps we just add your feature directly into
  cordova-cli?
   
For backwards compat, I think we should still allow the global
   cordova-cli
to do work as we do now (i.e. we don't *require* local
installs), but
   if a
local install happens to exist it would shell out to that.
   
Anyway, neat that you've implemented this already!
   
On Fri, Jan 9, 2015 at 3:41 PM, Staci Cooper
staci@gmail.com
   wrote:
   
 A while ago I made a utility called cordova-local for managing
   multiple
 local Cordova installations. It's similar to how
 grunt/grunt-cli
   works;
 once installed globally, you run 'cordova-local' instead of
  'cordova'
and
 it will locate and pass its arguments off to the closest
  installation.

 It's kept and installed independently of the cli but my
 initial
  idea
was to
 keep it in the cordova-cli repo. Since that would complicate
 the tools-release/versioning process I closed that PR and
 would like to
propose
 including it as a new repo. I added some specs and docs and
 put it
  in
   a
 utilities repo that could be used for similar cli-independent
  tools,
 currently here: https://github.com/stacic/cordova-utility. I
 added
   some
 tests to it and also made PRs for documenting the utility in
cordova-docs
 https://github.com/apache/cordova-docs/pull/259 and adding
 it to
   the
 tools release in cordova-coho
 https://github.com/apache/cordova-coho/pull/61.

 Opinions? Concerns?

Re: [DISCUSS] Cordova-Android 4.0.0 Release

2015-04-08 Thread Andrew Grieve

CB-8684 is now merged and I've updated the targetSdk (and made a couple
other changes).

I'll start the release process in the morning as long as there no
objections.


On Tue, Apr 7, 2015 at 2:20 PM, Andrew Grieve agri...@chromium.org wrote:

 I'll start on it once CB-8684 lands (Tony - assuming you'll have this done
 shortly and would prefer it lands?)

 On Tue, Apr 7, 2015 at 1:33 PM, Jesse purplecabb...@gmail.com wrote:

 Sweet!

 @purplecabbage
 risingj.com

 On Tue, Apr 7, 2015 at 8:35 AM, Andrew Grieve agri...@chromium.org
 wrote:

  Let's do it!
 
  On Mon, Apr 6, 2015 at 7:33 PM, Joe Bowser bows...@gmail.com wrote:
 
   So, I think we should put off the embedder's guide until after the
   release.  A lot of it has changed, and since we're still technically
   obligated to support the 3.x release tree for six months, that should
 buy
   us some time to figure out how that is going to work.  Getting
 Cordova to
   work with a vanilla Android Studio project is a non-trivial task.
  
   Given that everything else appears to be done, should we start voting
 on
  an
   RC for this?   What do people think?
  
  
  
   On Thu, Mar 19, 2015 at 10:31 AM Andrew Grieve agri...@chromium.org
   wrote:
  
Here's issues:
https://issues.apache.org/jira/browse/CB-8715 (docs)
https://issues.apache.org/jira/browse/CB-8716 (whitelist)
https://issues.apache.org/jira/browse/CB-8717 (write
 RELEASENOTES.md)
   
On Tue, Mar 17, 2015 at 10:15 AM, Carlos Santana 
 csantan...@gmail.com
  
wrote:
   
 I would say let's start RC testing and voting, But not pin the
  version
   in
 Cordova CLI until the tasks that Andrew mentioned are done.
 Andrew can you create the JIRA Items for the tasks that need to be
   done.
I
 thought there was a discussion about creating JIRA Items to help
  track
and
 know what's left for release something.

 - upgrade guide,
 - publishing whitelist plugins,
 - and making it so that the default project template includes
 plugin
 name=cordova-plugin-whitelist /)


 On Mon, Mar 16, 2015 at 11:21 PM, Ian Clelland 
  iclell...@chromium.org
   
 wrote:

  We'll probably need at least an RC for the whitelist plugin, if
  not a
 vote,
  to be able to vote on this.
 
  Or can we just include instructions like Use
  cordova-plugin-whitelist@f70b1bc for testing while we start
 the
 official
  release process for the plugins?
 
  On Mon, Mar 16, 2015 at 11:17 PM, Ian Clelland 
   iclell...@chromium.org

  wrote:
 
   +1 -- Let's get this out the door :)
   I'll see what I can get done to move it in that direction.
  
   On Mon, Mar 16, 2015 at 7:51 PM, Andrew Grieve 
   agri...@chromium.org

   wrote:
  
   Everything's ready afaik (minus upgrade guide, publishing
   whitelist
   plugins, and making it so that the default project template
   includes
   plugin name=cordova-plugin-whitelist /). Maybe let's do
 a RC
while
  we
   wait on these things being finished up?
  
   If anyone wants to take on any of these tasks, that would be
awesome.
  
   On Mon, Mar 16, 2015 at 4:57 PM, Shazron shaz...@gmail.com
   wrote:
  
+1 for vote thread, let's get this thing out so people
 (that
  are
not
us) can test...
   
   
On Mon, Mar 16, 2015 at 1:41 PM, Joe Bowser 
  bows...@gmail.com
  wrote:
 OK, this is a three month old thread, and we're waiting
 on a
   discussion
 before we release something? I really think we should go
 to
  a
vote
   thread
 now that we have a legacy whitelist plugin and a new
 style
 whitelist
 plugin.  We shouldn't keep constantly delaying this
 release
 because
  of
 what's happening on other platforms, especially since we
   already
pluginized
 the whitelist.

 Can we please release soon?

 On Thu, Mar 12, 2015 at 2:20 PM Nikhil Khandelwal 
nikhi...@microsoft.com
 wrote:

 I know we discussed a couple of approaches implementing
 the
 default
 whitelist policy for Android/iOS - either every app
 would
  be
   required to
 include the whitelist plugin or have it have smart
 defaults
   in
 the
platform
 implementation and the plugin being able to override
 them.

 I don’t think that thread closed with any conclusions.

 Thanks,
 Nikhil


 -Original Message-
 From: Joe Bowser [mailto:bows...@gmail.com]
 Sent: Thursday, March 12, 2015 11:23 AM
 To: dev
 Subject: Re: [DISCUSS] Cordova-Android 4.0.0 Release

 OK, so right now it's just docs? How soon can we get a
 VOTE
 thread
started
 for 4.0.0

Re: Who Runs cordova.io?

2015-04-07 Thread Andrew Grieve

Yep, change away! David used to maintain this for us, and we haven't picked
it up again since he left the team.

On Mon, Apr 6, 2015 at 5:02 PM, Dmitry Blotsky dblot...@microsoft.com
wrote:

 Hi Michael,

 Thank you for making the change! Sorry for my lack of input: I was offline
 for a week. I was going to mention that perhaps some of Google's Cordova
 folks (Andrew Grieve, Ian Clelland, et al.) might have had issues with
 changing the domain from their Buildbot installation, but they haven't
 responded, so I guess we can presume that they don't mind. However, I think
 now it would be worth the effort to port the Chrome Mobile Apps platform
 stuff to the master medic. @AGrieve, @IClelland: thoughts? Is mobilespec
 the way you folks test the platform?

 Also, I just realized that the redirect URI we provided was a bit rigid
 since it has verbatim builder names. I'll look into how to configure it so
 that the redirect URI becomes:
 http://ci.apache.org/waterfall?project=cordova. I will send a mail once
 that's done. If it's convenient for you, once I make that change, may we
 please have the redirect switch to that URI?

 And thanks again for making the change! Now the Cordova project has a
 unified and easy-to-access CI on Apache infrastructure! :D

 Kindly,
 Dmitry

 -Original Message-
 From: mikeywbro...@gmail.com [mailto:mikeywbro...@gmail.com] On Behalf Of
 Michael Brooks
 Sent: Wednesday, April 1, 2015 11:49 AM
 To: dev@cordova.apache.org
 Subject: Re: Who Runs cordova.io?

 Since there were no objections, I've updated ci.cordova.io to 302
 redirect to the Apache CI service:

 http://ci.apache.org/waterfall?builder=cordova-iosbuilder=cordova-android-osxbuilder=cordova-windowsbuilder=cordova-wp8builder=cordova-android-winbuilder=cordova-blackberry-osxbuilder=cordova-blackberry-win

 Cheers,
 Michael

 On Mon, Mar 30, 2015 at 4:32 PM, Jesse purplecabb...@gmail.com wrote:

  +1 to the redirect, and doing it on April Fools Day!
 
 
  @purplecabbage
  risingj.com
 
  On Mon, Mar 30, 2015 at 4:25 PM, Michael Brooks
  mich...@michaelbrooks.ca
  wrote:
 
   Hi Nikhil,
  
   I can update the DNS to redirect ci.cordova.io to the Apache hosted
  setup.
   This would be more aligned with their desire to ensure that all URLs
   (and
   infra) are of Apache ownership.
  
   Anyone object with updating ci.cordova.io? I'll do the update on
  Wednesday
   if there is no objection.
  
   Cheers,
   Michael
  
   On Fri, Mar 27, 2015 at 5:33 PM, Nikhil Khandelwal 
  nikhi...@microsoft.com
   
   wrote:
  
Thanks, Michael for the detailed information. On a related note,
who
  owns
http://ci.cordova.io/ ?
   
It seems to be running an old/stale version of medic + BuildBot.
There
  is
a newer version now hosted on Apache Infra but it's got a long url :
   
  
  http://ci.apache.org/waterfall?builder=cordova-iosbuilder=cordova-and
  roid-osxbuilder=cordova-windowsbuilder=cordova-wp8builder=cordova-a
  ndroid-winbuilder=cordova-blackberry-osxbuilder=cordova-blackberry-w
  in
   
Wonder if there is a way for ci.cordova.io to point to the above
  version
instead?
   
Thanks,
Nikhil
   
   
-Original Message-
From: mikeywbro...@gmail.com [mailto:mikeywbro...@gmail.com] On
Behalf
   Of
Michael Brooks
Sent: Friday, March 27, 2015 4:18 PM
To: dev@cordova.apache.org
Subject: Re: Who Runs cordova.io?
   
Hi Dmitry,
   
I own and pay for the cordova.io domain. When it comes to domains,
the general rules within Apache are:
   
1. cordova.io URLs that point to official Apache resources (e.g.
cordova.apache.org) must redirect to the official URL and not mask
 it.
This ensures that the project is recognized as an official Apache
   project.
We do this for cordova.io, docs.cordova.io, and issues.cordova.io
   
2. Apache prefers to not have the word apache in the third-party
  domain
because ownership can be deceiving. cordova.io is okay.
  apachecordova.io
is misleading.
   
For those interested, I'll describe some of the history of
 cordova.io.
During the donation of PhoneGap to Apache, I registered the
cordova.io domain. In my naivety, I thought we could use it as the
official Apache Cordova domain (CNAME style like Github Page).
However, after talking
   with
our Apache mentor, I learned what I stated above (redirect and
make it clear that the domain is not apache property). Regardless,
I decided to keep the domain around because it's shorter, verbally
easier to spread
  by
word-of-mouth (e.g. docs.cordova.io), and cleaner for presentation
  slide
decks.
   
The entire Adobe team has access to the DNS management of the domain.
  If
anyone else on the Apache Cordova project would like to add a
  subdomain,
I'm all for it! Likewise, if you want a subdomain removed, let's
talk
   about
i!
   
Cheers,
Michael
   
On Thu, Mar 26, 2015 at 11:44

Re: [DISCUSS] Cordova-Android 4.0.0 Release

2015-04-07 Thread Andrew Grieve

Let's do it!

On Mon, Apr 6, 2015 at 7:33 PM, Joe Bowser bows...@gmail.com wrote:

 So, I think we should put off the embedder's guide until after the
 release.  A lot of it has changed, and since we're still technically
 obligated to support the 3.x release tree for six months, that should buy
 us some time to figure out how that is going to work.  Getting Cordova to
 work with a vanilla Android Studio project is a non-trivial task.

 Given that everything else appears to be done, should we start voting on an
 RC for this?   What do people think?



 On Thu, Mar 19, 2015 at 10:31 AM Andrew Grieve agri...@chromium.org
 wrote:

  Here's issues:
  https://issues.apache.org/jira/browse/CB-8715 (docs)
  https://issues.apache.org/jira/browse/CB-8716 (whitelist)
  https://issues.apache.org/jira/browse/CB-8717 (write RELEASENOTES.md)
 
  On Tue, Mar 17, 2015 at 10:15 AM, Carlos Santana csantan...@gmail.com
  wrote:
 
   I would say let's start RC testing and voting, But not pin the version
 in
   Cordova CLI until the tasks that Andrew mentioned are done.
   Andrew can you create the JIRA Items for the tasks that need to be
 done.
  I
   thought there was a discussion about creating JIRA Items to help track
  and
   know what's left for release something.
  
   - upgrade guide,
   - publishing whitelist plugins,
   - and making it so that the default project template includes plugin
   name=cordova-plugin-whitelist /)
  
  
   On Mon, Mar 16, 2015 at 11:21 PM, Ian Clelland iclell...@chromium.org
 
   wrote:
  
We'll probably need at least an RC for the whitelist plugin, if not a
   vote,
to be able to vote on this.
   
Or can we just include instructions like Use
cordova-plugin-whitelist@f70b1bc for testing while we start the
   official
release process for the plugins?
   
On Mon, Mar 16, 2015 at 11:17 PM, Ian Clelland 
 iclell...@chromium.org
  
wrote:
   
 +1 -- Let's get this out the door :)
 I'll see what I can get done to move it in that direction.

 On Mon, Mar 16, 2015 at 7:51 PM, Andrew Grieve 
 agri...@chromium.org
  
 wrote:

 Everything's ready afaik (minus upgrade guide, publishing
 whitelist
 plugins, and making it so that the default project template
 includes
 plugin name=cordova-plugin-whitelist /). Maybe let's do a RC
  while
we
 wait on these things being finished up?

 If anyone wants to take on any of these tasks, that would be
  awesome.

 On Mon, Mar 16, 2015 at 4:57 PM, Shazron shaz...@gmail.com
 wrote:

  +1 for vote thread, let's get this thing out so people (that are
  not
  us) can test...
 
 
  On Mon, Mar 16, 2015 at 1:41 PM, Joe Bowser bows...@gmail.com
wrote:
   OK, this is a three month old thread, and we're waiting on a
 discussion
   before we release something? I really think we should go to a
  vote
 thread
   now that we have a legacy whitelist plugin and a new style
   whitelist
   plugin.  We shouldn't keep constantly delaying this release
   because
of
   what's happening on other platforms, especially since we
 already
  pluginized
   the whitelist.
  
   Can we please release soon?
  
   On Thu, Mar 12, 2015 at 2:20 PM Nikhil Khandelwal 
  nikhi...@microsoft.com
   wrote:
  
   I know we discussed a couple of approaches implementing the
   default
   whitelist policy for Android/iOS - either every app would be
 required to
   include the whitelist plugin or have it have smart defaults
 in
   the
  platform
   implementation and the plugin being able to override them.
  
   I don’t think that thread closed with any conclusions.
  
   Thanks,
   Nikhil
  
  
   -Original Message-
   From: Joe Bowser [mailto:bows...@gmail.com]
   Sent: Thursday, March 12, 2015 11:23 AM
   To: dev
   Subject: Re: [DISCUSS] Cordova-Android 4.0.0 Release
  
   OK, so right now it's just docs? How soon can we get a VOTE
   thread
  started
   for 4.0.0?
  
   On Wed, Mar 4, 2015 at 10:47 AM Andrew Grieve 
agri...@chromium.org
   wrote:
  
mobilespec is now working again... Took longer than I would
   have
liked, but did you know that on Android FileReader triggers
shouldInterceptRequest() with Blob URLs!?
   
Separate thread is already happening re: whitelists, so
 once
that's
figured out, it's just docs afaict.
   
On Mon, Mar 2, 2015 at 10:52 PM, Ian Clelland 
 iclell...@chromium.org
  
wrote:
   
 On Mon, Mar 2, 2015 at 6:00 PM, Jesse 
   purplecabb...@gmail.com

  wrote:

  We should start a new whitelist plugin related thread.
 
  Why is a plugin blocking a release?  Default (aka
   no-plugin)
  behavior should be to allow all network requests
  shouldn't

Re: [DISCUSS] Cordova-Android 4.0.0 Release

2015-04-07 Thread Andrew Grieve

I'll start on it once CB-8684 lands (Tony - assuming you'll have this done
shortly and would prefer it lands?)

On Tue, Apr 7, 2015 at 1:33 PM, Jesse purplecabb...@gmail.com wrote:

 Sweet!

 @purplecabbage
 risingj.com

 On Tue, Apr 7, 2015 at 8:35 AM, Andrew Grieve agri...@chromium.org
 wrote:

  Let's do it!
 
  On Mon, Apr 6, 2015 at 7:33 PM, Joe Bowser bows...@gmail.com wrote:
 
   So, I think we should put off the embedder's guide until after the
   release.  A lot of it has changed, and since we're still technically
   obligated to support the 3.x release tree for six months, that should
 buy
   us some time to figure out how that is going to work.  Getting Cordova
 to
   work with a vanilla Android Studio project is a non-trivial task.
  
   Given that everything else appears to be done, should we start voting
 on
  an
   RC for this?   What do people think?
  
  
  
   On Thu, Mar 19, 2015 at 10:31 AM Andrew Grieve agri...@chromium.org
   wrote:
  
Here's issues:
https://issues.apache.org/jira/browse/CB-8715 (docs)
https://issues.apache.org/jira/browse/CB-8716 (whitelist)
https://issues.apache.org/jira/browse/CB-8717 (write
 RELEASENOTES.md)
   
On Tue, Mar 17, 2015 at 10:15 AM, Carlos Santana 
 csantan...@gmail.com
  
wrote:
   
 I would say let's start RC testing and voting, But not pin the
  version
   in
 Cordova CLI until the tasks that Andrew mentioned are done.
 Andrew can you create the JIRA Items for the tasks that need to be
   done.
I
 thought there was a discussion about creating JIRA Items to help
  track
and
 know what's left for release something.

 - upgrade guide,
 - publishing whitelist plugins,
 - and making it so that the default project template includes
 plugin
 name=cordova-plugin-whitelist /)


 On Mon, Mar 16, 2015 at 11:21 PM, Ian Clelland 
  iclell...@chromium.org
   
 wrote:

  We'll probably need at least an RC for the whitelist plugin, if
  not a
 vote,
  to be able to vote on this.
 
  Or can we just include instructions like Use
  cordova-plugin-whitelist@f70b1bc for testing while we start the
 official
  release process for the plugins?
 
  On Mon, Mar 16, 2015 at 11:17 PM, Ian Clelland 
   iclell...@chromium.org

  wrote:
 
   +1 -- Let's get this out the door :)
   I'll see what I can get done to move it in that direction.
  
   On Mon, Mar 16, 2015 at 7:51 PM, Andrew Grieve 
   agri...@chromium.org

   wrote:
  
   Everything's ready afaik (minus upgrade guide, publishing
   whitelist
   plugins, and making it so that the default project template
   includes
   plugin name=cordova-plugin-whitelist /). Maybe let's do a
 RC
while
  we
   wait on these things being finished up?
  
   If anyone wants to take on any of these tasks, that would be
awesome.
  
   On Mon, Mar 16, 2015 at 4:57 PM, Shazron shaz...@gmail.com
   wrote:
  
+1 for vote thread, let's get this thing out so people (that
  are
not
us) can test...
   
   
On Mon, Mar 16, 2015 at 1:41 PM, Joe Bowser 
  bows...@gmail.com
  wrote:
 OK, this is a three month old thread, and we're waiting
 on a
   discussion
 before we release something? I really think we should go
 to
  a
vote
   thread
 now that we have a legacy whitelist plugin and a new style
 whitelist
 plugin.  We shouldn't keep constantly delaying this
 release
 because
  of
 what's happening on other platforms, especially since we
   already
pluginized
 the whitelist.

 Can we please release soon?

 On Thu, Mar 12, 2015 at 2:20 PM Nikhil Khandelwal 
nikhi...@microsoft.com
 wrote:

 I know we discussed a couple of approaches implementing
 the
 default
 whitelist policy for Android/iOS - either every app would
  be
   required to
 include the whitelist plugin or have it have smart
 defaults
   in
 the
platform
 implementation and the plugin being able to override
 them.

 I don’t think that thread closed with any conclusions.

 Thanks,
 Nikhil


 -Original Message-
 From: Joe Bowser [mailto:bows...@gmail.com]
 Sent: Thursday, March 12, 2015 11:23 AM
 To: dev
 Subject: Re: [DISCUSS] Cordova-Android 4.0.0 Release

 OK, so right now it's just docs? How soon can we get a
 VOTE
 thread
started
 for 4.0.0?

 On Wed, Mar 4, 2015 at 10:47 AM Andrew Grieve 
  agri...@chromium.org
 wrote:

  mobilespec is now working again... Took longer than I
  would
 have
  liked, but did you know that on Android FileReader
  triggers

Re: Platform guides update

2015-04-07 Thread Andrew Grieve

These changes all sound great!

On Tue, Apr 7, 2015 at 3:01 PM, Sergey Grebnov (Akvelon) 
v-seg...@microsoft.com wrote:

 Hi guys, I see that some docs are outdated or not actual anymore so I want
 to improve this. Please let me know if someone already working on this or
 going to take a look. I've listed below some things I want to update, could
 you please review them before I stared working on this (additional
 suggestions and ideas are very welcome)

 iOS:
 1. Xcode 4.x-5.x
 2. Add information about ios-sim required to deploy app from command
 line
 3. Add information how to list available deploy targets and run app on
 specific target/device

 Android:
1. Add changes in favor of replacing Ant w/ Gradle
a. Remove Ant from requirements
b. Replace Eclipse example w/ Android Studio as officially
 recommended option/tool
2.  Add more details about particular Android packages/components
 required to be installed.
 Android 5.0.1 (API 21) platform SDK
 Android SDK Build-tools version 19.1.0 or higher
 Android Support Repository (Extras)
 3. Add information how to list available deploy targets and run app on
 specific target/device

 Windows:
 1. Remove 'To develop apps for Windows 8.0 only:'
 2. Hardware requirements to run Windows Phone emulator (Client Hyper-V
 and Second Level Address Translation (SLAT))
 3. Add information how to list available deploy targets and run app on
 specific target/device

 Thx!
 Sergey

 -
 To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
 For additional commands, e-mail: dev-h...@cordova.apache.org

Re: Platform guides update

2015-04-07 Thread Andrew Grieve

Perhaps the quote is out of context (I'm too lazy to check), but it's
certainly the recommended option for debugging native code.

On Tue, Apr 7, 2015 at 3:47 PM, Raymond Camden raymondcam...@gmail.com
wrote:

 Replace Eclipse example w/ Android Studio as officially recommended
 option/tool
 Do we really recommend this over CLI + your favorite editor ?

 On Tue, Apr 7, 2015 at 2:35 PM, Jesse purplecabb...@gmail.com wrote:
  +1000
 
  @purplecabbage
  risingj.com
 
  On Tue, Apr 7, 2015 at 12:31 PM, Andrew Grieve agri...@chromium.org
 wrote:
 
  These changes all sound great!
 
  On Tue, Apr 7, 2015 at 3:01 PM, Sergey Grebnov (Akvelon) 
  v-seg...@microsoft.com wrote:
 
   Hi guys, I see that some docs are outdated or not actual anymore so I
  want
   to improve this. Please let me know if someone already working on
 this or
   going to take a look. I've listed below some things I want to update,
  could
   you please review them before I stared working on this (additional
   suggestions and ideas are very welcome)
  
   iOS:
   1. Xcode 4.x-5.x
   2. Add information about ios-sim required to deploy app from
 command
   line
   3. Add information how to list available deploy targets and run
 app
  on
   specific target/device
  
   Android:
  1. Add changes in favor of replacing Ant w/ Gradle
  a. Remove Ant from requirements
  b. Replace Eclipse example w/ Android Studio as officially
   recommended option/tool
  2.  Add more details about particular Android packages/components
   required to be installed.
   Android 5.0.1 (API 21) platform SDK
   Android SDK Build-tools version 19.1.0 or higher
   Android Support Repository (Extras)
   3. Add information how to list available deploy targets and run
 app
  on
   specific target/device
  
   Windows:
   1. Remove 'To develop apps for Windows 8.0 only:'
   2. Hardware requirements to run Windows Phone emulator (Client
  Hyper-V
   and Second Level Address Translation (SLAT))
   3. Add information how to list available deploy targets and run
 app
  on
   specific target/device
  
   Thx!
   Sergey
  
   -
   To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
   For additional commands, e-mail: dev-h...@cordova.apache.org
  
  
 



 --
 ===
 Raymond Camden, Developer Advocate for MobileFirst at IBM

 Email : raymondcam...@gmail.com
 Blog : www.raymondcamden.com
 Twitter: raymondcamden

 -
 To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
 For additional commands, e-mail: dev-h...@cordova.apache.org

Re: Jira CB-831: File transfer tests crash on Android L

2015-04-07 Thread Andrew Grieve

- In 4.0.0, we remove OkHttp from our code, but Android L starts including
it for its own network stack (crazy coincidence!)
- We're not sure how frequent the crash happens - just that MobileSpec's
use of FileTransfer triggers it every time
- It is fixed by replacing the network stack with a newer version of OkHttp
- I've published cordova-plugin-okhttp to npm, so it's installable via
cordova-cli@master
- Bug says it's fixed in Android 5.1.1 (API level 22). (thanks for finding
that okio issue!)

On a side note - should we switch our targetSdk to 22? Probably...?



On Tue, Apr 7, 2015 at 9:14 PM, Nikhil Khandelwal nikhi...@microsoft.com
wrote:

 Why am I seeing this crash with the latest master on the BuildBot CI?

 I understand that we're not bundling OkHttp, but it's being used with the
 File Transfer plugin on an emulator for Android 5.0.1 (API 21).

 The crash is happening with the stack at
 com.android.okio.OkBuffer.write(OkBuffer.java:574) and not
 com.squareup.okhttp which Android 3.7.1 platform used to package.

 Does Android ship with a version okhttp? Here's the issue description and
 a fix for it in Okio: https://github.com/square/okio/issues/79. It does
 not look like this fix is part of Android 5.0.1 - the emulator that was
 being used to run tests on our CI server.

 (I'm quite new to Android development - bear with me if I'm missing
 something obvious here).

 Thanks,
 Nikhil


 -Original Message-
 From: Joe Bowser [mailto:bows...@gmail.com]
 Sent: Tuesday, April 7, 2015 5:29 PM
 To: dev@cordova.apache.org
 Subject: Re: Jira CB-831: File transfer tests crash on Android L

 This is a Won't Fix because we're not bundling OkHttp anymore.  This will
 be resolved when we release Cordova-Android 4.0.0

 On Tue, Apr 7, 2015 at 5:27 PM Nikhil Khandelwal nikhi...@microsoft.com
 wrote:

  The JIRA which was marked as 'Won't fix' is currently blocking Android
  test runs on http://ci.cordova.io:  https://issues.apache.org/
  jira/browse/CB-8431.
 
  It looks like Android L's implementation of OkHttp has a race
  condition which hits quite consistently with our current file transfer
  tests. There is a comment by Andrew in the bug that points to using
  this plugin on Android L:
 https://github.com/MobileChromeApps/cordova-plugin-okhttp.
 
  Should this plugin be a dependency to the file transfer plugin? Or the
  code for it be rolled in as part of file transfer plugin itself?
 
  For the short term I'm leaning towards working around this issue, by
  using an older AVD (instead of Android L) on our CI setup. However,
  there is a chance developers running Cordova apps on Android L will
  run into this and would expect some guidance here.
 
  Thanks,
  Nikhil

Re: Platform guides update

2015-04-07 Thread Andrew Grieve

AFAIK, Eclipse doesn't work with Gradle, and so won't work with
cordova-android@4.0.0

On Tue, Apr 7, 2015 at 4:58 PM, Parashuram N (MS OPEN TECH) 
panar...@microsoft.com wrote:

 I also think that apart for API/Reference like docs, it may help the
 community to have detailed guide, tutorials, etc. I understand that some
 of them may be hard, but do you guys see value in putting up something
 like a ³course² for using Cordova, tutorial for building sample apps,
 using Cordova with JS frameworks, etc - things that would help a beginner
 get started quickly.

 On 4/7/15, 1:41 PM, Raymond Camden raymondcam...@gmail.com wrote:

 Fair enough. I think my concern is overwhelming new users - but - I'll
 stand back and wait for these new docs to go up before I complain/nag
 anymore. :)
 
 On Tue, Apr 7, 2015 at 3:34 PM, Brian LeRoux b...@brian.io wrote:
  I humbly submit that we want very detailed documentation to turn those
  lower numbers into more involved community members. (Ideally
 contributing
  code and docs themselves!)
 
  On Tue, Apr 7, 2015 at 1:24 PM, Raymond Camden raymondcam...@gmail.com
 
  wrote:
 
  That makes sense - I just worry that if that use case (extending
  Cordova) is 10% of the reader base than it should not (imo) be 50% of
  the docs. Btw - totally guessing at those numbers as I haven't seen
  the changes. :)
 
  On Tue, Apr 7, 2015 at 2:58 PM, Brian LeRoux b...@brian.io wrote:
   We recommend using the thing that works best for you for building
 apps
  BUT
   if you are extending Cordova you'll need to run with Android Studio,
  Xcode
   and friends. We support both.
  
   On Tue, Apr 7, 2015 at 12:47 PM, Raymond Camden
 raymondcam...@gmail.com
  
   wrote:
  
   Replace Eclipse example w/ Android Studio as officially recommended
   option/tool
   Do we really recommend this over CLI + your favorite editor ?
  
   On Tue, Apr 7, 2015 at 2:35 PM, Jesse purplecabb...@gmail.com
 wrote:
+1000
   
@purplecabbage
risingj.com
   
On Tue, Apr 7, 2015 at 12:31 PM, Andrew Grieve
 agri...@chromium.org
   wrote:
   
These changes all sound great!
   
On Tue, Apr 7, 2015 at 3:01 PM, Sergey Grebnov (Akvelon) 
v-seg...@microsoft.com wrote:
   
 Hi guys, I see that some docs are outdated or not actual
 anymore
  so I
want
 to improve this. Please let me know if someone already working
 on
   this or
 going to take a look. I've listed below some things I want to
  update,
could
 you please review them before I stared working on this
 (additional
 suggestions and ideas are very welcome)

 iOS:
 1. Xcode 4.x-5.x
 2. Add information about ios-sim required to deploy app
 from
   command
 line
 3. Add information how to list available deploy targets
 and run
   app
on
 specific target/device

 Android:
1. Add changes in favor of replacing Ant w/ Gradle
a. Remove Ant from requirements
b. Replace Eclipse example w/ Android Studio as
 officially
 recommended option/tool
2.  Add more details about particular Android
  packages/components
 required to be installed.
 Android 5.0.1 (API 21) platform SDK
 Android SDK Build-tools version 19.1.0 or higher
 Android Support Repository (Extras)
 3. Add information how to list available deploy targets
 and run
   app
on
 specific target/device

 Windows:
 1. Remove 'To develop apps for Windows 8.0 only:'
 2. Hardware requirements to run Windows Phone emulator
 (Client
Hyper-V
 and Second Level Address Translation (SLAT))
 3. Add information how to list available deploy targets
 and run
   app
on
 specific target/device

 Thx!
 Sergey


  -
 To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
 For additional commands, e-mail: dev-h...@cordova.apache.org


   
  
  
  
   --
  
 
 
 ===
   Raymond Camden, Developer Advocate for MobileFirst at IBM
  
   Email : raymondcam...@gmail.com
   Blog : www.raymondcamden.com
   Twitter: raymondcamden
  
  
 -
   To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
   For additional commands, e-mail: dev-h...@cordova.apache.org
  
  
 
 
 
  --
 
 
 ===
  Raymond Camden, Developer Advocate for MobileFirst at IBM
 
  Email : raymondcam...@gmail.com
  Blog : www.raymondcamden.com
  Twitter: raymondcamden
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
  For additional commands, e-mail: dev-h...@cordova.apache.org

Re: ApacheCon NA, Austin, April 13-16

2015-04-02 Thread Andrew Grieve

Can't speak for everyone obviously, but looking at the schedule I'd be
happy to miss Tuesday afternoon or any of Wednesday in favour of a Cordova
coding session / social time.

On Thu, Apr 2, 2015 at 5:54 PM, Homer, Tony tony.ho...@intel.com wrote:

 I hadn¹t been planning on attending ApacheCon, but I just found out that I
 need to go to Austin in April!
 Currently I am scheduled to be there April 21-22, but I might be able to
 bump that up a week.
 Would it be worth it to be in Austin during ApacheCon even if I am not
 able to actually attend ApacheCon?

 Tony

 On 3/24/15, 1:51 PM, Victor Sosa sosah.vic...@gmail.com wrote:

 Welcome aboard!!
 
 2015-03-24 11:47 GMT-06:00 Andrew Grieve agri...@chromium.org:
 
  Woohoo! Glad to hear more are coming!
 
  On Sat, Mar 21, 2015 at 11:51 AM, Ross Gardler (MS OPEN TECH) 
  ross.gard...@microsoft.com wrote:
 
   Some of my day job colleagues have signed up to organize both a BoF
 and a
   hack season (not me, although I will be there). The focus will be
 rolling
   and getting started. Brian has agreed to help out and there are a
 couple
  of
   other folks with tooling expertise signed up.
  
   I confirmed room availability yesterday, so it would be great if this
   group can help out and spread the word.
  
   Ross
  
   Sent from my Windows Phone
   
   From: Brian LeRouxmailto:b...@brian.io
   Sent: 3/21/2015 7:48 AM
   To: dev@cordova.apache.orgmailto:dev@cordova.apache.org
   Subject: Re: ApacheCon NA, Austin, April 13-16
  
   I am!
   On Fri, Mar 20, 2015 at 5:13 PM Nikhil Khandelwal 
  nikhi...@microsoft.com
   wrote:
  
I'll be there. It would be great to meet others who are going.
   
Thanks,
Nikhil
   
   
-Original Message-
From: Anis KADRI [mailto:anis.ka...@gmail.com]
Sent: Friday, March 20, 2015 3:04 PM
To: dev@cordova.apache.org
Subject: Re: ApacheCon NA, Austin, April 13-16
   
Reviving this thread. Other than Andrew, Mark and Hazem. Anybody
 else
going ? I plan to attend.
   
On Sat, Jan 31, 2015 at 6:46 PM, Andrew Grieve
 agri...@chromium.org
wrote:
   
 Submitted a talk proposal:

 Abstract:
 The Cordova project can sometimes be hard to contribute to given
 the
 large number of pieces that make it up. There are a few tools that
 make it much more manageable though. In this session, Andrew will
 cover many of the tools and techniques that make developing on
  Cordova
 a more coherent experience.


 Going to cover git workflow, coho commands, --link and IDEs, CIs,
 Testing via windows VM.


 On Fri, Jan 9, 2015 at 11:39 AM, Joe Bowser bows...@gmail.com
  wrote:

  Is this a troll post?
 
  On Fri, Jan 9, 2015, 8:21 AM Andrew Grieve
 agri...@chromium.org
wrote:
 
   http://events.linuxfoundation.org//events/apachecon-north-
   america/program/cfp
  
   Last year we had about a days worth of Cordova talks and ran a
 hackathon
   (thanks to IBM)! For me, the real value was in learning more
  about
  Apache,
   and getting to spend time with other committers.
  
   So... I still think it'd be good to do a few presentations.
 CFP
  is
   open until the end of the month. Audience is mostly enterprise
   types, Apache committers, and of course, ourselves. Talks on
   Cordova or on Apache processes would be good (e.g. a talk on
   setting up github PRs with
  Travis 
   AppVeyor, hint hint).
  
   Even more though, I think we should take the opportunity to do
   some
 work
   while co-located. There's always a lot of value in face time,
 and
   I
 think
   the venue suits it well (there were lots of hackathon-type
 rooms
   available).
  
   So, concretely - anyone want to state their intention of
 giving a
   talk,
  or
   attending? I know at least a few of us from Google are
 planning
  on
 going.
  
 

   
  
 
 
 
 
 --
 Victor Adrian Sosa Herrera
 IBM Software Engineer
 Guadalajara, Jalisco


 -
 To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
 For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [proposal] [ANDROID] move inAppBrowser intents from onPageStarted to shouldOverrideUrlLoading

2015-04-02 Thread Andrew Grieve

shouldOverrideUrlLoading is what the main cordova webview uses,  so that's
certainly the right approach. I believe it should also add
CATEGORY_BROWSABLE to the intent to ensure that the user is prompted to
confirm whether they actually want to make the call.

On Thu, Apr 2, 2015 at 7:07 PM, julio cesar sanchez jcesarmob...@gmail.com
wrote:

 I've been looking into issues and I have seen this one:
 https://issues.apache.org/jira/browse/CB-8180

 Right now the code to handle the tel links is inside the onPageStarted

 if (url.startsWith(WebView.SCHEME_TEL)) {
 try {
 Intent intent = new Intent(Intent.ACTION_DIAL);
 intent.setData(Uri.parse(url));
 cordova.getActivity().startActivity(intent);
 } catch (android.content.ActivityNotFoundException e) {
 LOG.e(LOG_TAG, Error dialing  + url + :  +
 e.toString());
 }
 }

 But the problem is, it launchs the intent and try to open the web page, so
 when you come back from the intent you see a couldn't load the url page
 on the app.

 I've tried to use the view.stopLoading() but it doesn't seem to stop it.
 The issue only talks about the tel links, but I suppose that will happen
 with sms, mailto and some other links.


 So, I think a solution might be to move that code to
 shouldOverrideUrlLoading function.

 Is there any reason of doing this on the onPageStarted instead of using the
 shouldOverrideUrlLoading?

Re: Camera: When was Crop added and why?

2015-04-01 Thread Andrew Grieve

My 2c on this is that camera is a mess and I doubt it'd be worth time
looking at it (beyond fixing bugs from PRs).

Instead, it would be better to invest in chopping it up into several
usefull-on-their-own plugins. E.g.:
- A plugin that can fire intents and receive the result via
onActivityResult (even after app eviction)
   - This could then be used to implement starting the camera / gallery, as
well as to implement CROP if desired
- A plugin that can do simple image manipulation
   - E.g. resize, downsample (canvas isn't very good at this still thanks
to a lack of toBlob())
- A plugin for moving files around... oh wait, we already have this :)

On Wed, Apr 1, 2015 at 9:27 AM, Ian Clelland iclell...@chromium.org wrote:

On Tue, Mar 31, 2015 at 10:38 AM, Joe Bowser bows...@gmail.com
  wrote:
 Hey

 I'm working on Camera plugin issues in JIRA, and I noticed that
 we
   added
 Crop to the Camera plugin.  I'm wondering when this was done,
 and
   where
the
 JIRA issue or discussion of adding this feature took place.  I'm
   pretty
 sure this feature wasn't added properly to Android, since it
  seems to
 interrupt how the camera works pretty substantially.

 Can anyone direct me to where any of this took place so that I
 can
   read
the
 justification as to why we added it?  If it doesn't exist, I'm
   probably
 going to create a JIRA issue for putting it in properly, since
 I'm
   sure
 some users are expecting it.

 Joe

 A little bit of git-blame work brings up this JIRA issue:
 https://issues.apache.org/jira/browse/CB-6546

 Which is tied to this GitHub pull request from an outside contributor:
 https://github.com/apache/cordova-plugin-camera/pull/12

 from just over a year ago.

 It looks like it was merged in on April 29 last year, and first released
 with 0.3.0 (June 2014).

 On Tue, Mar 31, 2015 at 6:58 PM, Joe Bowser bows...@gmail.com wrote:

  OK, so here's the problem with allowEdit/Crop on Android as it's
 currently
  implemented:
 
  1. The results aren't handled correctly when using handleCrop and
  saveImageToGallery
  2. The cropped image isn't saved to the gallery when we're saving the
 image
  3. I have no idea where the resizing should happen when we're allowing
 the
  edit, currently it happens BEFORE Crop, which I don't think is right.
  4. Saving the image to the gallery happens BEFORE the Crop, which seems
  like the incorrect behaviour
 
  Since this code is really old, I'm thinking that we're stuck with it
 since
  it'll probably be as much work to rip the damn thing out as it would be
 to
  fix it, but I'm not sure what fixed even means in this context since I
  didn't even really know this feature existed until today when I decided
 to
  adopt a bunch of Camera bugs and try to reproduce and fix them.  I was
  hoping that we had these conversations before cramming this feature into
  Cordova, but apparently we haven't.
 
  There's also the fact that Crop makes this plugin handle three different
  types of intents, which I'm not super happy about, especially since I
 have
  no idea what happens to the Exif when it goes into the Crop Intent and
 when
  it comes out.
 
  Then there's the fact that this feature was an API change that broke
  semver.  Does anyone know how semver works for plugins? Does each
 plugin's
  version need to be updated if we muck about with the API? Would our users
  notice if we did that? I'm hoping they would, but I'm not sure.
 
  On Tue, Mar 31, 2015 at 2:24 PM Raymond Camden raymondcam...@gmail.com
  wrote:
 
   Oh sorry - your last paragraph makes it clear that it is a doc issue
   w/ Android then. (Possibly anyway.)
  
   On Tue, Mar 31, 2015 at 4:22 PM, Raymond Camden 
 raymondcam...@gmail.com
  
   wrote:
I'm confused. The docs say allowEdit is ignored for Android (and
 every
other platform but iOS I believe). Are you saying allowEdit does
something for Android?
   
On Tue, Mar 31, 2015 at 4:15 PM, Jesse purplecabb...@gmail.com
  wrote:
To be correct, it is not disabled anywhere, it was previously
   implemented
for iOS only.
The iOS native camera/capture view has an additional boolean
 property
  to
allow the user to crop+pan a photo in place before returning to the
  app.
This was exposed in the cordova camera api on iOS only. In like
 2011.
   
More recently ( last year [1] ) the same feature landed in Android,
however, it is not exactly the same thing.
On Android, there is no guarantee that the Crop-Intent exists, in
  which
case it doesn't matter if the cordova-camera getPicture method was
   called
with allowEdit or not.  Also, on some devices, there are multiple
 apps
providing a Crop-Intent, so the user will have to choose one.
   
There are tests for it, but of course, they are manual ...
Should we update the docs and claim Android support for it, or does
 it
   have
usability/implementation issues that

Re: Keyboard plugin

2015-03-30 Thread Andrew Grieve

I definitely agree that KeyboardShrinksView makes a tonne more sense for
apps (as opposed to webpages), and it's what we use on Android. Shame they
reversed the decision (I didn't actually realize that).

One reason to keep it as a plugin is that the logic seems to be hard to get
right and so needs to be tweaked frequently. Plugins let you iterate faster
than if it were built-in.

Still, I think we're hoping to reduce the number of plugins that we
maintain as a part of the core Cordova project, since we really don't do a
great job at giving them the attention that they deserve (just have a look
at all the unaddressed PRs against them).

One of the intended goals (at least IMO) of moving plugins to npm and
npm-style-naming, is to make less distinction between core cordova
plugins and community-maintained plugins, so that the higher-quality
community-maintained plugins get more usage.

Interested in what others think.

On Mon, Mar 30, 2015 at 1:07 PM, Connor Pearson cjp...@gmail.com wrote:

 Hi All,

 It's been a while since the keyboard plugin was discussed. As I understand
 it, the plugin was moved to Cordova labs after iOS 7 made
 KeyboardShrinksView the default behavior. Since iOS 7.1 and 8 have reversed
 this decision, could we revisit this?

 I've done some work to re-enable KeyboardShrinksView for iOS  7.0 and fix
 some bugs, but is there any support for continuing to maintain this plugin?
 If not, is there any way to merge the KeyboardShrinksView preference back
 into cordova-ios? I think it's more commonly used and much more stable than
 the HideKeyboardFormAccessoryBar preference. As a Cordova user, our app
 depends on the shrink view behavior. Any thoughts?

 Thanks,
 Connor

Re: Question about plugin/platform --save: src vs version?

2015-03-30 Thread Andrew Grieve

I don't think we'd want to try a fallback in this case. Better to fail
loudly if the plugin can't be found where it's expected to be.

I think since NPM uses only a single field (although theirs isn't labeled),
we should do likewise. Don't feel strongly about it though.

On Mon, Mar 30, 2015 at 4:04 PM, Edna Y Morales eymor...@us.ibm.com wrote:

 It could make sense to store both for the case where restoring from src
 fails. For example, if the path to a local folder no longer exists, what do
 you use to restore? In that case you could use the version as a fallback?

 Thanks,
 Edna Morales

 [image: Inactive hide details for Gorkem Ercan ---03/30/2015 10:45:03
 AM--- On 29 Mar 2015, at 23:11, Tim Barham wrote:]Gorkem Ercan
 ---03/30/2015 10:45:03 AM---On 29 Mar 2015, at 23:11, Tim Barham wrote:

 From: Gorkem Ercan gorkem.er...@gmail.com
 To: dev ‎[dev@cordova.apache.org]‎ dev@cordova.apache.org
 Date: 03/30/2015 10:45 AM
 Subject: Re: Question about plugin/platform --save: src vs version?
 --





 On 29 Mar 2015, at 23:11, Tim Barham wrote:

  Hi - I'm looking for input on this issue: For the plugin/platform
  --save feature, there's currently an inconsistency between how we
  store the information in config.xml for platforms vs plugins.
 
 
 
  For platforms, we have a 'version' attribute where we store either the
  source location or the version: if the platform was added by
  specifying a specific location (git repository, local folder, package
  file etc), we store that in the 'version' attribute. Otherwise we
  store the actual version.
 
 
 
  For plugins, these two values are stored separately - source location
  in the 'src' attribute and version in the 'version' attribute. Note
  however that when we restore a plugin, we ignore the 'version'
  attribute if there is a 'src' attribute.
 
 
 This comes from the history of the implementation ( as these things do).
 In the old experimental save implementation, we had 3 parameters,
 namely, version, url and installPath, and for every plugin we expected
 one of them to exist. During the effort for npmizing the save
 functionality the contribution for platforms and plugins were done
 separately hence the unmatching attributes. So there is no real
 technical reason for doing one way or the other and if you are willing
 to unify them that is fantastic.


 
  I'd like to make these consistent. My first thought was to support
  'version' and 'src' for platforms like we currently do for plugins.
  But since we always ignore the version if we have a src, I'm not sure
  we actually gain anything by doing that. Storing them in different
  attributes is perhaps clearer, but storing both implies we make use of
  both, which we don't. Also, the code ends up being simpler overall if
  we just store whichever we care about in the version attribute.
 

 I personally prefer to clearly label data in case user needs to
 read/modify the config.xml, seeing a git url on the version attribute
 still puzzles me. But I am fine with either way. Whatever you decide
 please remember to support/migrate the current attributes so that we do
 not end up with stale entries on config.xml

 
 
  Any thoughts either way?
 
 
 
  Thanks!
 
 
 
  Tim

 -
 To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
 For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [VOTE] Cordova-Plugin-Whitelist and Cordova-Plugin-Legacy-Whitelist Plugins Release (attempt 2)

2015-03-30 Thread Andrew Grieve

Mark - I like that idea as well.

On Mon, Mar 30, 2015 at 6:33 PM, Ian Clelland iclell...@chromium.org
wrote:

 On 30 Mar 2015 4:52 pm, Mark Koudritsky kam...@google.com wrote:
 
  Another quick option for now: we can pin hello-world version in
  cordova-lib's package.json to 3.8.0 which doesn't use the whitelist
  plugin.  Later, when we release the tools pinned to cordova-android 4.0
 we
  will have to change the hello-world dep to ^3.9.0.

 That's a good idea.

 I'll validate the plug-ins and vote later tonight.

 Ian
  This way it's a minimal change to cordova-lib and we can go ahead with
 this
  vote.
 
  On Mon, Mar 30, 2015 at 3:49 PM, Ian Clelland iclell...@chromium.org
  wrote:
 
   So this isn't a -1, unless we can't fix the problem in cordova-lib. And
   it's okay, I think, to fix it in cordova-lib/master and release that as
   well. Nothing is actually broken by publishing either app-hello-world
 or
   plugin-whitelist until we release a version of tools that is pinned to
 the
   new hello-world.
  
  
   On Mon, Mar 30, 2015 at 3:40 PM, Mark Koudritsky kam...@google.com
   wrote:
  
Looks like this breaks on cordova-android 3.7.1 (currently latest
   released)
   
cordova-app-hello-world requires the whitelist plugin
whitelist plugin depends on cordova-android 4.0 via the engine tag
engine name=cordova-android version==4.0.0-dev /
The resulting error message is
Plugin doesn't support this project's cordova-android version.
cordova-android: 3.7.1, failed version requirement: =4.0.0-dev
   
Simply removing the engine tag results in compile errors. (change
in CustomConfigXmlParser.parse() signature).
   
Any ideas on how to solve this would be appreciated. Ideas we came up
   with
in a quick discussion:
   
1. Add ignore attribute to the engine tag that would result in
 plugin
being silently ignored for incompatible engines rather than going
 down in
flames.
2. Add either version child or version attribute to the
 platform
   tag
in plugin.xml
   
  
   This is my favorite idea so far -- I think we could do something like
 this:
   plugin ... 
 platform name=android
   version match==4.0.0
 !-- tags --
   /version
 /platform
   /plugin
  
   I think this is overdue, and we'll find it useful as we move from 3.x
 to
   4.x on other platforms as well. We would allow multiple version tags
   inside of each platform, and any tags outside of the version tags
 are
   the default if nothing matches.
  
   In this case, there won't be any tags outside of the version tag, so
 the
   fallback for 3.x is to install nothing, but succeed.
  
   Ian
  
  
   
On Fri, Mar 27, 2015 at 4:31 PM, Andrew Grieve agri...@chromium.org
 
wrote:
   
 +1

 * Tested that both plugins compile on Android
 * Tested that the non-legacy plugin does what its supposed to on
   Android

 On Thu, Mar 26, 2015 at 7:46 PM, Steven Gill 
 stevengil...@gmail.com
 
 wrote:

  Please review and vote on the releases of
 cordova-plugin-whitelist
   and
  cordova-plugin-legacy-whitelist plugins.
 
  Release issue: https://issues.apache.org/jira/browse/CB-8739
 
  The plugins have been published to
  dist/dev:https://dist.apache.org/repos/dist/dev/cordova/CB-8739/
 
  The packages were published from their corresponding git tags:
  cordova-plugin-whitelist: 1.0.0
  (38f5a9fa2c)cordova-plugin-legacy-whitelist: 1.0.0 (1ce26eba64)
 
  Upon a successful vote I will upload the archives to dist/ and
 upload
  them to npm.
 
  Voting guidelines:
 

   
  
 https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md
 
  Voting will go on for a minimum of 48 hours.
 
  I vote +1:
  * Ran coho audit-license-headers over the relevant repos
  * Ran coho check-license to ensure all dependencies and
  subdependencies have Apache-compatible licenses

Re: introduction

2015-03-27 Thread Andrew Grieve

Welcome Serge! Just merged your PR (
https://github.com/apache/cordova-android/pull/169) Great stuff!

On Fri, Mar 27, 2015 at 9:08 AM, Victor Sosa sosah.vic...@gmail.com wrote:

 Welcome aboard, Serge!
 On Mar 27, 2015 3:36 AM, Serge Huijben s.huij...@gmail.com wrote:

  Hi Everybody,
 
  I am a developer in the Netherlands working on a Mobile app development
  team.
  Our primary focus is on delivering a uniform user experience across at
  least the two major platforms (Android and iOS).
  We therefore chose to use Cordova as our base and we’re pretty happy with
  it. so happy in fact that I would really like to help make it even
 better.
  so expect to see a few PR’s from me (or my  alias thehuijb) soon.
 
  regards,
  Serge Huijben (aka thehuijb)

Re: [VOTE] Cordova-Plugin-Whitelist and Cordova-Plugin-Legacy-Whitelist Plugins Release (attempt 2)

2015-03-27 Thread Andrew Grieve

+1

* Tested that both plugins compile on Android
* Tested that the non-legacy plugin does what its supposed to on Android

On Thu, Mar 26, 2015 at 7:46 PM, Steven Gill stevengil...@gmail.com wrote:

 Please review and vote on the releases of cordova-plugin-whitelist and
 cordova-plugin-legacy-whitelist plugins.

 Release issue: https://issues.apache.org/jira/browse/CB-8739

 The plugins have been published to
 dist/dev:https://dist.apache.org/repos/dist/dev/cordova/CB-8739/

 The packages were published from their corresponding git tags:
 cordova-plugin-whitelist: 1.0.0
 (38f5a9fa2c)cordova-plugin-legacy-whitelist: 1.0.0 (1ce26eba64)

 Upon a successful vote I will upload the archives to dist/ and upload
 them to npm.

 Voting guidelines:
 https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md

 Voting will go on for a minimum of 48 hours.

 I vote +1:
 * Ran coho audit-license-headers over the relevant repos
 * Ran coho check-license to ensure all dependencies and
 subdependencies have Apache-compatible licenses

Re: Introduction

2015-03-26 Thread Andrew Grieve

Welcome Alex! Thanks for wanting to make Cordova better for everyone! :)



On Wed, Mar 25, 2015 at 11:33 PM, Alex Talis alex.ta...@yahoo.com.invalid
wrote:

 Hi guys,

 I’m planning to submit a pull request and so following the instructions in
 the “Process of Contributing” and introducing myself!

 My name is Alex Talis. I’ve been using Cordova to develop apps for iOS and
 Android since version 0.9, so for quite a while now. On occasion I’ve had
 to make some quick hacks to Cordova-generated code to make it do what I
 needed it to do, but the problem with those is that they usually break when
 updating Cordova. Now I have a large enough enhancement that I would like
 to contribute and I hope will be useful to others, so here I am!


 -
 To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
 For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [VOTE] Cordova-Plugin-Whitelist and Cordova-Plugin-Legacy-Whitelist Plugins Release

2015-03-26 Thread Andrew Grieve

That'd be pretty sad if it were expected :P.

Totally my bad on this one. I've committed a fix.

On Thu, Mar 26, 2015 at 9:40 AM, Alexander Sorokin (Akvelon) 
v-als...@microsoft.com wrote:

 Hi guys,

 I am getting the following error when trying to build a project with
 legacy-whitelist plugin installed for android@4.0.0-dev:

 C:\Projects\Cordova\mobspec-android\platforms\android\src\org\apache\cordova\whitelist\LegacyWhitelistPlugin.java:44:
 error: cannot find symbol
 public void handleStartTag(XmlPullParser xml) {
^
   symbol: class XmlPullParser
 C:\Projects\Cordova\mobspec-android\platforms\android\src\org\apache\cordova\whitelist\LegacyWhitelistPlugin.java:68:
 error: cannot find symbol
 public void handleEndTag(XmlPullParser xml) {
  ^
   symbol: class XmlPullParser


 Is this expected?

 Thanks,
 Alexander Sorokin

 -Original Message-
 From: Steven Gill [mailto:stevengil...@gmail.com]
 Sent: Wednesday, March 25, 2015 23:23
 To: dev@cordova.apache.org
 Subject: [VOTE] Cordova-Plugin-Whitelist and
 Cordova-Plugin-Legacy-Whitelist Plugins Release

 Please review and vote on the releases of cordova-plugin-whitelist and
 cordova-plugin-legacy-whitelist plugins.

 Release issue: https://issues.apache.org/jira/browse/CB-8739

 The plugins have been published to
 dist/dev:https://dist.apache.org/repos/dist/dev/cordova/CB-8739/

 The packages were published from their corresponding git tags:
 cordova-plugin-whitelist: 1.0.0 (38f5a9fa2c)
 cordova-plugin-legacy-whitelist: 1.0.0 (b4e1b3726a)

 Upon a successful vote I will upload the archives to dist/ and upload them
 to npm.

 Voting guidelines:
 https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md

 Voting will go on for a minimum of 48 hours.

 I vote +1:
 * Ran coho audit-license-headers over the relevant repos
 * Ran coho check-license to ensure all dependencies and subdependencies
 have Apache-compatible licenses

 -
 To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
 For additional commands, e-mail: dev-h...@cordova.apache.org

Re: 'cordova plugin save' should also save plugin versions

2015-03-25 Thread Andrew Grieve

That's what we already do (CPR *is* an npm database)

On Wed, Mar 25, 2015 at 12:00 AM, Michal Mocny mmo...@chromium.org wrote:

 ..Also with the move to put plugins in npm, I think we would be directly
 using npm's resolution of the version?

 On Tue, Mar 24, 2015 at 8:48 PM, Andrew Grieve agri...@chromium.org
 wrote:

  On Tue, Mar 24, 2015 at 7:48 PM, Gorkem Ercan gorkem.er...@gmail.com
  wrote:
 
  
  
   On 24 Mar 2015, at 18:38, Tim Barham wrote:
  
+1 from me too (always save version, and allow automatic minor version
   upgrades).
  
I like Andrew's idea, my only concern is implementing only a portion
 of
   the semver syntax. I personally would assume full semver support after
   seeing ^1.2.3 notation on config.xml
 
  I think we do already support all semver? Just tried:
 cordova plugin add cordova-plugin-okhttp@1 3
   and it worked fine.
 
 
  
  
Gorkem - I'm currently doing some work in this area - I'm happy to
 make
   this change while I'm there.
  
Sure, go ahead. I would not be able to get to it until next week.
  
  

   From: Steven Gill [stevengil...@gmail.com]
   Sent: Wednesday, March 25, 2015 7:20 AM
   To: dev@cordova.apache.org
   Subject: Re: 'cordova plugin save' should also save plugin versions
  
   Definitely agree with alignment with npm's save! :D
  
   On Tue, Mar 24, 2015 at 1:46 PM, Nikhil Khandelwal 
   nikhi...@microsoft.com
   wrote:
  
I'm in favor of alignment of 'plugin save' behavior with npm's as we
   expect developers to already familiar with that and in future, we
 plan
  to
   move to npm.
  
   I liked Andrew's idea of adding a specific version with allowing
 minor
   version upgrades to be automatic.
  
   As for shrink wrapping, for npm this means locking down the version
   numbers of all modules and their dependencies:
   https://docs.npmjs.com/cli/shrinkwrap . It does not look our
   --shrinkwrap
   option does that.
  
   -Nikhil
  
   -Original Message-
   From: So, Byoungro [mailto:byoungro...@intel.com]
   Sent: Tuesday, March 24, 2015 12:40 PM
   To: dev@cordova.apache.org
   Subject: Re: 'cordova plugin save' should also save plugin versions
  
   +1 for making the shrinkwrap as the default for the save.
   This makes sure the users will restore the same version they saved
   before.
  
   Byoungro So
   SSG / DPD / Mobile Computing and Compilers Intel Corporation
  
  
  
  
  
  
   On 3/24/15, 12:31 PM, Gorkem Ercan gorkem.er...@gmail.com wrote:
  
  
   I think the problem here is shrinkwrap behaviour is the expected
   because platforms behave that way. I guess we could just make
   shrinkwrap default and change the flag to --noshrinkwrap.
   --
   Gorkem
  
   On 24 Mar 2015, at 13:58, Andrew Grieve wrote:
  
On Tue, Mar 24, 2015 at 11:49 AM, Gorkem Ercan
   gorkem.er...@gmail.com
   wrote:
  
They are related but not same.
  
   CB-8594 asks to save the plugin version information during
 cordova
   plugin add --save. Right now we do not save version unless the
   command is cordova plugin add --save --shrinkwrap. This
 behaviour
   allows plugins to be restored to the latest possible version
   available if they are not explicitly shrinkwrapped.
  
  
   How about doing what npm does, and always save the version, but
 save
   it as ^1.0.3, so that you still get updates, but not major
 version
   changes?
  
  
  
  
   As for CB-8733, cordova plugin save command can not save the
   version information even if it had wanted to because fetch.json is
   missing that information. It is a bug.
   --
   Gorkem
  
   On Tue, Mar 24, 2015 at 11:29 AM, Raymond Camden
   raymondcam...@gmail.com
   wrote:
  
Is that a dupe of https://issues.apache.org/jira/browse/CB-8594?
  
   On Tue, Mar 24, 2015 at 10:19 AM, Edna Y Morales
   eymor...@us.ibm.com
   wrote:
  
  
  
   Currently, version info is not saved for plugins in the
  fetch.json.
  
   That
  
   needs to be added so that plugin version can be saved in the
  
   config.xml.
  
   It
  
   should follow what 'cordova platform save' does. I created a
 jira
   item
  
   for
  
   this: https://issues.apache.org/jira/browse/CB-8733 and opened
 a
   pull
   request: https://github.com/apache/cordova-lib/pull/189. If
   someone
  
   could
  
   review it and provide any feedback.
  
   Thanks,
   Edna Morales
  
  
  
  
   --
  
  
  
  =
   ===
   ===
  
   Raymond Camden, Developer Advocate for MobileFirst at IBM
  
   Email : raymondcam...@gmail.com
   Blog : www.raymondcamden.com
   Twitter: raymondcamden
  
  
 ---
   -- To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
   For additional commands, e-mail: dev-h...@cordova.apache.org
  
  
  
  
  
 -
   To unsubscribe, e-mail: dev-unsubscr

Re: crosswalk engine plugin for Cordova Android 4.0.0 release

2015-03-25 Thread Andrew Grieve

Published it to npm!

https://www.npmjs.com/package/cordova-plugin-crosswalk-webview

Once a CLI release happens, we can update the docs to install it via plugin
ID.

On Wed, Mar 25, 2015 at 8:56 AM, Ian Clelland iclell...@chromium.org
wrote:

 Once we publish this to npm (or the Cordova plugin registry) it will be
 much smaller; just containing the code that is absolutely required for the
 current version.

 I think that the only reasonable way to make the git repo itself smaller
 would be to move it to a new location (new name or new organization).

 We (Google's team) have used cordova-crosswalk-engine as a git submodule
 dependency for some time, in our mobile-chrome-apps repo, and I don't think
 we can just rewrite all of the old commits without also breaking all of our
 historical dependencies as well. (Filtering the repo like this will rewrite
 a large number of commits, which will certainly change their hashes,
 unfortunately).

 I'll do a bit more investigation today, but I think that the best solution,
 for almost all users, is to publish just the current source as a real
 cordova plugin, and not worry too much about the size of the git repo, as
 it only affects people who are actively developing on it. (And the size is
 no longer growing at that rate, so it is really only a one-time checkout
 cost)

 Ian

 On Wed, Mar 25, 2015 at 1:09 AM, Hu, Ningxin ningxin...@intel.com wrote:

  
   Could this be fixed on plugman's side with git clone --depth 1?
 
  It still downloads 63MB.
 
  In my experiment, I delete all unused branches, tags, and remove related
  git objects. It can shrink the repo to 340KB with full history of master
  branch.
 
  There is a good reference for git repo shrinking:
 
 https://www.rallydev.com/community/engineering/shrinking-git-repository-move-githubcom
 
  Thanks,
  -ningxin
 
  
   On Tue, Mar 24, 2015 at 9:02 AM, Ian Clelland iclell...@chromium.org
   wrote:
  
On Tue, Mar 24, 2015 at 6:15 AM, Hu, Ningxin ningxin...@intel.com
   wrote:
   
 Crosswalk engine plugin is expected to work with upcoming Cordova
 Android
 4.0.0 release.

 As I investigate, there are some issues need to be fixed:
 1.  Update the README.md of cordova-crosswalk-engine. E.g no
fetch_libs.sh
 anymore. I managed to create a PR for this:
 https://github.com/MobileChromeApps/cordova-crosswalk-
   engine/pull/20

   
 Thanks, Ningxin -- that's great! I'll merge it in.
   
2. Shrink the repo size: e.g remove unnecessary  libxwalkcore.so
 etc.,
It
 impacts the plugin installation performance from github.com.
 Please
refer
 to https://github.com/huningxin/cordova-crosswalk-engine-1. It
 shrinks from 118MB to 340KB.

   
I'll have to filter-repo on this; I'm not sure if there will be any
disruption to the GitHub repository because of it, but I'll do my
 best
to minimize that. I agree that it has become unnecessarily large
because of the included (and often updated) binary packages.
   
   

 Any other issues?

 Thanks,
 -ningxin



 
 - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
 For additional commands, e-mail: dev-h...@cordova.apache.org


   
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
  For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [Vote] 3.9.0 Cordova App Hello World Release

2015-03-25 Thread Andrew Grieve

+1

On Tue, Mar 24, 2015 at 9:29 AM, Ian Clelland iclell...@google.com wrote:

 +1

 * Checked signatures and checksums
 * Verified contents against Git repo at 3.9.0 tag
 * Successfully built and ran hello world with Cordova-Android 3.7.1 and
 4.0.0-dev (master)

 On Mon, Mar 23, 2015 at 8:13 PM, Steven Gill stevengil...@gmail.com
 wrote:

  Please review and vote on this 3.9.0 Cordova App Hello World Release.
 
  Release issue: https://issues.apache.org/jira/browse/CB-8731
 
  Repos ready to be released have been published to
  dist/dev:https://dist.apache.org/repos/dist/dev/cordova/CB-8731
 
  The package was published from its corresponding git tag:
  cordova-app-hello-world: 3.9.0 (fb3150bf76)
 
  Upon a successful vote I will upload the archive to dist/ and publish it
  to NPM.
 
  Voting guidelines:
 
 https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md
 
  Voting will go on for a minimum of 48 hours.
 
  I vote +1:
  * Ran coho audit-license-headers over the relevant repos
  * Ran coho check-license to ensure all dependencies and
  subdependencies have Apache-compatible licenses
  * Built a hello world app using the CLI

Re: 'cordova plugin save' should also save plugin versions

2015-03-24 Thread Andrew Grieve

On Tue, Mar 24, 2015 at 7:48 PM, Gorkem Ercan gorkem.er...@gmail.com
wrote:



 On 24 Mar 2015, at 18:38, Tim Barham wrote:

  +1 from me too (always save version, and allow automatic minor version
 upgrades).

  I like Andrew's idea, my only concern is implementing only a portion of
 the semver syntax. I personally would assume full semver support after
 seeing ^1.2.3 notation on config.xml

I think we do already support all semver? Just tried:
   cordova plugin add cordova-plugin-okhttp@1 3
 and it worked fine.




  Gorkem - I'm currently doing some work in this area - I'm happy to make
 this change while I'm there.

  Sure, go ahead. I would not be able to get to it until next week.


  
 From: Steven Gill [stevengil...@gmail.com]
 Sent: Wednesday, March 25, 2015 7:20 AM
 To: dev@cordova.apache.org
 Subject: Re: 'cordova plugin save' should also save plugin versions

 Definitely agree with alignment with npm's save! :D

 On Tue, Mar 24, 2015 at 1:46 PM, Nikhil Khandelwal 
 nikhi...@microsoft.com
 wrote:

  I'm in favor of alignment of 'plugin save' behavior with npm's as we
 expect developers to already familiar with that and in future, we plan to
 move to npm.

 I liked Andrew's idea of adding a specific version with allowing minor
 version upgrades to be automatic.

 As for shrink wrapping, for npm this means locking down the version
 numbers of all modules and their dependencies:
 https://docs.npmjs.com/cli/shrinkwrap . It does not look our
 --shrinkwrap
 option does that.

 -Nikhil

 -Original Message-
 From: So, Byoungro [mailto:byoungro...@intel.com]
 Sent: Tuesday, March 24, 2015 12:40 PM
 To: dev@cordova.apache.org
 Subject: Re: 'cordova plugin save' should also save plugin versions

 +1 for making the shrinkwrap as the default for the save.
 This makes sure the users will restore the same version they saved
 before.

 Byoungro So
 SSG / DPD / Mobile Computing and Compilers Intel Corporation






 On 3/24/15, 12:31 PM, Gorkem Ercan gorkem.er...@gmail.com wrote:


 I think the problem here is shrinkwrap behaviour is the expected
 because platforms behave that way. I guess we could just make
 shrinkwrap default and change the flag to --noshrinkwrap.
 --
 Gorkem

 On 24 Mar 2015, at 13:58, Andrew Grieve wrote:

  On Tue, Mar 24, 2015 at 11:49 AM, Gorkem Ercan
 gorkem.er...@gmail.com
 wrote:

  They are related but not same.

 CB-8594 asks to save the plugin version information during cordova
 plugin add --save. Right now we do not save version unless the
 command is cordova plugin add --save --shrinkwrap. This behaviour
 allows plugins to be restored to the latest possible version
 available if they are not explicitly shrinkwrapped.


 How about doing what npm does, and always save the version, but save
 it as ^1.0.3, so that you still get updates, but not major version
 changes?




 As for CB-8733, cordova plugin save command can not save the
 version information even if it had wanted to because fetch.json is
 missing that information. It is a bug.
 --
 Gorkem

 On Tue, Mar 24, 2015 at 11:29 AM, Raymond Camden
 raymondcam...@gmail.com
 wrote:

  Is that a dupe of https://issues.apache.org/jira/browse/CB-8594?

 On Tue, Mar 24, 2015 at 10:19 AM, Edna Y Morales
 eymor...@us.ibm.com
 wrote:



 Currently, version info is not saved for plugins in the fetch.json.

 That

 needs to be added so that plugin version can be saved in the

 config.xml.

 It

 should follow what 'cordova platform save' does. I created a jira
 item

 for

 this: https://issues.apache.org/jira/browse/CB-8733 and opened a
 pull
 request: https://github.com/apache/cordova-lib/pull/189. If
 someone

 could

 review it and provide any feedback.

 Thanks,
 Edna Morales




 --


 =
 ===
 ===

 Raymond Camden, Developer Advocate for MobileFirst at IBM

 Email : raymondcam...@gmail.com
 Blog : www.raymondcamden.com
 Twitter: raymondcamden

 ---
 -- To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
 For additional commands, e-mail: dev-h...@cordova.apache.org




 -
 To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
 For additional commands, e-mail: dev-h...@cordova.apache.org



 -
 To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
 For additional commands, e-mail: dev-h...@cordova.apache.org


 -
 To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
 For additional commands, e-mail: dev-h...@cordova.apache.org


  -
 To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
 For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [DISCUSS] Whitelist Legacy Whitelist Plugins Release @1.0.0

2015-03-24 Thread Andrew Grieve

that grep looks fine to me.

On Tue, Mar 24, 2015 at 5:13 PM, Steven Gill stevengil...@gmail.com wrote:

 Leo, the whitelist plugin will only start being used after the next tools
 release. So timing should be fine.

 Andrew, I did a quick grep search for org.apache.cordova for both whitelist
 plugins. Do any of these values need to be updated before releasing?

 cordova-plugin-whitelist
 grep -R org.apache.cordova *
 plugin.xml:param name=android-package
 value=org.apache.cordova.whitelist.WhitelistPlugin/
 plugin.xml:source-file src=src/android/WhitelistPlugin.java
 target-dir=src/org/apache/cordova/whitelist /
 src/android/WhitelistPlugin.java:package org.apache.cordova.whitelist;
 src/android/WhitelistPlugin.java:import org.apache.cordova.CordovaPlugin;
 src/android/WhitelistPlugin.java:import org.apache.cordova.ConfigXmlParser;
 src/android/WhitelistPlugin.java:import org.apache.cordova.Whitelist;

 cordova-plugin-legacy-whitelist
 grep -R org.apache.cordova *
 plugin.xml:param name=android-package
 value=org.apache.cordova.whitelist.LegacyWhitelistPlugin/
 plugin.xml:source-file
 src=src/android/LegacyWhitelistPlugin.java
 target-dir=src/org/apache/cordova/whitelist /
 src/android/LegacyWhitelistPlugin.java:package
 org.apache.cordova.whitelist;
 src/android/LegacyWhitelistPlugin.java:import
 org.apache.cordova.CordovaInterface;
 src/android/LegacyWhitelistPlugin.java:import
 org.apache.cordova.CordovaPlugin;
 src/android/LegacyWhitelistPlugin.java:import
 org.apache.cordova.CordovaWebView;
 src/android/LegacyWhitelistPlugin.java:import
 org.apache.cordova.ConfigXmlParser;
 src/android/LegacyWhitelistPlugin.java:import org.apache.cordova.Whitelist;

 On Tue, Mar 24, 2015 at 12:14 PM, Treggiari, Leo leo.treggi...@intel.com
 wrote:

  Is there a timing issue here?  How can a plugin be published to npm when
  there is no tools release that will fetch from npm?
 
  Leo
 
  -Original Message-
  From: iclell...@google.com [mailto:iclell...@google.com] On Behalf Of
 Ian
  Clelland
  Sent: Tuesday, March 24, 2015 6:42 AM
  To: dev@cordova.apache.org
  Subject: Re: [DISCUSS] Whitelist  Legacy Whitelist Plugins Release
 @1.0.0
 
  We should definitely do that -- and I think we should release them
  simultaneously with cordova-app-hello-world, since it now references
  cordova-plugin-whitelist by that name (I had to install it from local git
  repo, but it still wasn't a perfectly smooth experience).
 
  On Mon, Mar 23, 2015 at 7:18 PM, Steven Gill stevengil...@gmail.com
  wrote:
 
   I'd like to start a vote thread for both plugins. I'm thinking they
 will
   only be published to npm and dist (no CPR).
  
   Thoughts?
  
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
  For additional commands, e-mail: dev-h...@cordova.apache.org

Re: ApacheCon NA, Austin, April 13-16

2015-03-24 Thread Andrew Grieve

Woohoo! Glad to hear more are coming!

On Sat, Mar 21, 2015 at 11:51 AM, Ross Gardler (MS OPEN TECH) 
ross.gard...@microsoft.com wrote:

 Some of my day job colleagues have signed up to organize both a BoF and a
 hack season (not me, although I will be there). The focus will be rolling
 and getting started. Brian has agreed to help out and there are a couple of
 other folks with tooling expertise signed up.

 I confirmed room availability yesterday, so it would be great if this
 group can help out and spread the word.

 Ross

 Sent from my Windows Phone
 
 From: Brian LeRouxmailto:b...@brian.io
 Sent: ‎3/‎21/‎2015 7:48 AM
 To: dev@cordova.apache.orgmailto:dev@cordova.apache.org
 Subject: Re: ApacheCon NA, Austin, April 13-16

 I am!
 On Fri, Mar 20, 2015 at 5:13 PM Nikhil Khandelwal nikhi...@microsoft.com
 wrote:

  I'll be there. It would be great to meet others who are going.
 
  Thanks,
  Nikhil
 
 
  -Original Message-
  From: Anis KADRI [mailto:anis.ka...@gmail.com]
  Sent: Friday, March 20, 2015 3:04 PM
  To: dev@cordova.apache.org
  Subject: Re: ApacheCon NA, Austin, April 13-16
 
  Reviving this thread. Other than Andrew, Mark and Hazem. Anybody else
  going ? I plan to attend.
 
  On Sat, Jan 31, 2015 at 6:46 PM, Andrew Grieve agri...@chromium.org
  wrote:
 
   Submitted a talk proposal:
  
   Abstract:
   The Cordova project can sometimes be hard to contribute to given the
   large number of pieces that make it up. There are a few tools that
   make it much more manageable though. In this session, Andrew will
   cover many of the tools and techniques that make developing on Cordova
   a more coherent experience.
  
  
   Going to cover git workflow, coho commands, --link and IDEs, CIs,
   Testing via windows VM.
  
  
   On Fri, Jan 9, 2015 at 11:39 AM, Joe Bowser bows...@gmail.com wrote:
  
Is this a troll post?
   
On Fri, Jan 9, 2015, 8:21 AM Andrew Grieve agri...@chromium.org
  wrote:
   
 http://events.linuxfoundation.org//events/apachecon-north-
 america/program/cfp

 Last year we had about a days worth of Cordova talks and ran a
   hackathon
 (thanks to IBM)! For me, the real value was in learning more about
Apache,
 and getting to spend time with other committers.

 So... I still think it'd be good to do a few presentations. CFP is
 open until the end of the month. Audience is mostly enterprise
 types, Apache committers, and of course, ourselves. Talks on
 Cordova or on Apache processes would be good (e.g. a talk on
 setting up github PRs with
Travis 
 AppVeyor, hint hint).

 Even more though, I think we should take the opportunity to do
 some
   work
 while co-located. There's always a lot of value in face time, and
 I
   think
 the venue suits it well (there were lots of hackathon-type rooms
 available).

 So, concretely - anyone want to state their intention of giving a
 talk,
or
 attending? I know at least a few of us from Google are planning on
   going.

Re: Cordova Monthly Hangouts

2015-03-24 Thread Andrew Grieve

+1!

On Tue, Mar 24, 2015 at 1:23 PM, Jesse purplecabb...@gmail.com wrote:

 +1 asap, thanks Parash!

 We are much more coherent when we meet.



  On Mar 24, 2015, at 10:02 AM, Parashuram N (MS OPEN TECH) 
 panar...@microsoft.com wrote:
 
  Hi,
 
  I was wondering if folks would be interested in doing a hangout to
 quickly resolve some of the outstanding issues that we have been talking on
 the mailing list. I think we could talk about the following
 
 
   *   Androind 4.0 release
   *   Medic/ParaMedic/Mobile Spec - progress and next steps
   *   Finalize Save/Restore discussions
   *   ApacheCon ?
 
  I can volunteer to help set this up if we think there are items that we
 would like to discuss and close on.

 -
 To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
 For additional commands, e-mail: dev-h...@cordova.apache.org

Re: Introduction

2015-03-24 Thread Andrew Grieve

Welcome!

On Fri, Mar 20, 2015 at 3:20 PM, Shazron shaz...@gmail.com wrote:

 Welcome Karen! Glad to have you on board.

 On Fri, Mar 20, 2015 at 12:12 PM, Karen Tran ktop...@gmail.com wrote:
  Hello,
 
  My name is Karen. I am a new addition to the Cordova team at IBM and will
  be focusing on android. I spent the last month learning about cordova and
  working through a few issues so I look forward to contributing soon.
 
  Regards,
  Karen Tran

 -
 To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
 For additional commands, e-mail: dev-h...@cordova.apache.org

Re: gradleReference feature and gradle build

2015-03-24 Thread Andrew Grieve

Totally agree with your concern, and on Android master / tools master this
is already fixed. When Android 4.0.0 ships (and is the case with master
right now), Android Studio will work out-of-the-box without the need for a
command-line build.

On Mon, Mar 23, 2015 at 1:37 PM, Nell Gawor nga...@gmail.com wrote:

 I had been looking at using gradleReference for my plugin to contribute a
 dependency to the gradle build.  I had some trouble figuring out how to get
 it to work because I kept looking for the section of the build.gradle file
 labeled // PLUGIN GRADLE EXTENSIONS START to be modified.

 Finally I figured out there was an additional commit that changed the
 gradleReference to use project.properties instead.  However I'm wondering
 if this way of doing things makes it harder to have the plugin's
 contributions respected by Android studio?  If added to the standard
 build.gradle file, the extra dependencies would be recognized by Android
 studio when doing the gradle build.  But since project.properties is (as
 far as I know) only used by Cordova build, Android studio doesn't know
 anything about the plugin's contributions nor would a standard gradle
 build.

 I'm a newbie to Cordova, so there's probably a lot I'm missing here.  Any
 suggestions for getting gradleReference to work well w/Android
 Studio/standard gradle build?

Re: [DISCUSS] Whitelist Legacy Whitelist Plugins Release @1.0.0

2015-03-24 Thread Andrew Grieve

+1! Excited to have some npm-only plugins!

On Tue, Mar 24, 2015 at 9:42 AM, Ian Clelland iclell...@chromium.org
wrote:

 We should definitely do that -- and I think we should release them
 simultaneously with cordova-app-hello-world, since it now references
 cordova-plugin-whitelist by that name (I had to install it from local git
 repo, but it still wasn't a perfectly smooth experience).

 On Mon, Mar 23, 2015 at 7:18 PM, Steven Gill stevengil...@gmail.com
 wrote:

  I'd like to start a vote thread for both plugins. I'm thinking they will
  only be published to npm and dist (no CPR).
 
  Thoughts?

Re: crosswalk engine plugin for Cordova Android 4.0.0 release

2015-03-24 Thread Andrew Grieve

Could this be fixed on plugman's side with git clone --depth 1?

On Tue, Mar 24, 2015 at 9:02 AM, Ian Clelland iclell...@chromium.org
wrote:

 On Tue, Mar 24, 2015 at 6:15 AM, Hu, Ningxin ningxin...@intel.com wrote:

  Crosswalk engine plugin is expected to work with upcoming Cordova Android
  4.0.0 release.
 
  As I investigate, there are some issues need to be fixed:
  1.  Update the README.md of cordova-crosswalk-engine. E.g no
 fetch_libs.sh
  anymore. I managed to create a PR for this:
  https://github.com/MobileChromeApps/cordova-crosswalk-engine/pull/20
 

  Thanks, Ningxin -- that's great! I'll merge it in.

 2. Shrink the repo size: e.g remove unnecessary  libxwalkcore.so etc., It
  impacts the plugin installation performance from github.com. Please
 refer
  to https://github.com/huningxin/cordova-crosswalk-engine-1. It shrinks
  from 118MB to 340KB.
 

 I'll have to filter-repo on this; I'm not sure if there will be any
 disruption to the GitHub repository because of it, but I'll do my best to
 minimize that. I agree that it has become unnecessarily large because of
 the included (and often updated) binary packages.


 
  Any other issues?
 
  Thanks,
  -ningxin
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
  For additional commands, e-mail: dev-h...@cordova.apache.org

Re: 'cordova plugin save' should also save plugin versions

2015-03-24 Thread Andrew Grieve

On Tue, Mar 24, 2015 at 11:49 AM, Gorkem Ercan gorkem.er...@gmail.com
wrote:

 They are related but not same.

 CB-8594 asks to save the plugin version information during cordova plugin
 add --save. Right now we do not save version unless the command is
 cordova plugin add --save --shrinkwrap. This behaviour allows plugins to
 be restored to the latest possible version available if they are not
 explicitly shrinkwrapped.


How about doing what npm does, and always save the version, but save it as
^1.0.3, so that you still get updates, but not major version changes?




 As for CB-8733, cordova plugin save command can not save the version
 information even if it had wanted to because fetch.json is missing that
 information. It is a bug.
 --
 Gorkem

 On Tue, Mar 24, 2015 at 11:29 AM, Raymond Camden raymondcam...@gmail.com
 wrote:

  Is that a dupe of https://issues.apache.org/jira/browse/CB-8594?
 
  On Tue, Mar 24, 2015 at 10:19 AM, Edna Y Morales eymor...@us.ibm.com
  wrote:
  
  
   Currently, version info is not saved for plugins in the fetch.json.
 That
   needs to be added so that plugin version can be saved in the
 config.xml.
  It
   should follow what 'cordova platform save' does. I created a jira item
  for
   this: https://issues.apache.org/jira/browse/CB-8733 and opened a pull
   request: https://github.com/apache/cordova-lib/pull/189. If someone
  could
   review it and provide any feedback.
  
   Thanks,
   Edna Morales
 
 
 
  --
 
 ===
  Raymond Camden, Developer Advocate for MobileFirst at IBM
 
  Email : raymondcam...@gmail.com
  Blog : www.raymondcamden.com
  Twitter: raymondcamden
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
  For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [cordova.plugins.io] Dump of all plugin ids

2015-03-19 Thread Andrew Grieve

a plugin.xml with deps will fetch and install them all, and will almost
certainly fail to install due to missing params, or conflicting files.
Better to have a text file with all the IDs and a script that just fetches
 unpacks them all.

On Wed, Mar 18, 2015 at 8:45 PM, Shazron shaz...@gmail.com wrote:

 Nice! I'll create a script to generate the plugin.xml automatically
 for anyone else that needs it for testing. Thanks Anis!

 On Wed, Mar 18, 2015 at 5:43 PM, Anis KADRI anis.ka...@gmail.com wrote:
  http://plugins.cordova.io/_view/searcher
 
  returns all plugins you'd have to filter/parse JSON you get back to get
 the
  ID
 
  Reference:
 
  http://goo.gl/alPWzY
 
  On Wed, Mar 18, 2015 at 5:28 PM, Shazron shaz...@gmail.com wrote:
 
  Oops its http://plugins.cordova.io/
 
  On Wed, Mar 18, 2015 at 5:27 PM, Shazron shaz...@gmail.com wrote:
   I don't suppose someone has a plugin.xml with dependencies for all the
   plugins in cordova.plugins.io do they? ;)
  
   Is there a way to have a text dump of all plugins available in c.p.r?
  
   This is for testing cordova-ios 4.0.x
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
  For additional commands, e-mail: dev-h...@cordova.apache.org
 
 

 -
 To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
 For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [DISCUSS] Cordova-Android 4.0.0 Release

2015-03-19 Thread Andrew Grieve

Here's issues:
https://issues.apache.org/jira/browse/CB-8715 (docs)
https://issues.apache.org/jira/browse/CB-8716 (whitelist)
https://issues.apache.org/jira/browse/CB-8717 (write RELEASENOTES.md)

On Tue, Mar 17, 2015 at 10:15 AM, Carlos Santana csantan...@gmail.com
wrote:

 I would say let's start RC testing and voting, But not pin the version in
 Cordova CLI until the tasks that Andrew mentioned are done.
 Andrew can you create the JIRA Items for the tasks that need to be done. I
 thought there was a discussion about creating JIRA Items to help track and
 know what's left for release something.

 - upgrade guide,
 - publishing whitelist plugins,
 - and making it so that the default project template includes plugin
 name=cordova-plugin-whitelist /)


 On Mon, Mar 16, 2015 at 11:21 PM, Ian Clelland iclell...@chromium.org
 wrote:

  We'll probably need at least an RC for the whitelist plugin, if not a
 vote,
  to be able to vote on this.
 
  Or can we just include instructions like Use
  cordova-plugin-whitelist@f70b1bc for testing while we start the
 official
  release process for the plugins?
 
  On Mon, Mar 16, 2015 at 11:17 PM, Ian Clelland iclell...@chromium.org
  wrote:
 
   +1 -- Let's get this out the door :)
   I'll see what I can get done to move it in that direction.
  
   On Mon, Mar 16, 2015 at 7:51 PM, Andrew Grieve agri...@chromium.org
   wrote:
  
   Everything's ready afaik (minus upgrade guide, publishing whitelist
   plugins, and making it so that the default project template includes
   plugin name=cordova-plugin-whitelist /). Maybe let's do a RC while
  we
   wait on these things being finished up?
  
   If anyone wants to take on any of these tasks, that would be awesome.
  
   On Mon, Mar 16, 2015 at 4:57 PM, Shazron shaz...@gmail.com wrote:
  
+1 for vote thread, let's get this thing out so people (that are not
us) can test...
   
   
On Mon, Mar 16, 2015 at 1:41 PM, Joe Bowser bows...@gmail.com
  wrote:
 OK, this is a three month old thread, and we're waiting on a
   discussion
 before we release something? I really think we should go to a vote
   thread
 now that we have a legacy whitelist plugin and a new style
 whitelist
 plugin.  We shouldn't keep constantly delaying this release
 because
  of
 what's happening on other platforms, especially since we already
pluginized
 the whitelist.

 Can we please release soon?

 On Thu, Mar 12, 2015 at 2:20 PM Nikhil Khandelwal 
nikhi...@microsoft.com
 wrote:

 I know we discussed a couple of approaches implementing the
 default
 whitelist policy for Android/iOS - either every app would be
   required to
 include the whitelist plugin or have it have smart defaults in
 the
platform
 implementation and the plugin being able to override them.

 I don’t think that thread closed with any conclusions.

 Thanks,
 Nikhil


 -Original Message-
 From: Joe Bowser [mailto:bows...@gmail.com]
 Sent: Thursday, March 12, 2015 11:23 AM
 To: dev
 Subject: Re: [DISCUSS] Cordova-Android 4.0.0 Release

 OK, so right now it's just docs? How soon can we get a VOTE
 thread
started
 for 4.0.0?

 On Wed, Mar 4, 2015 at 10:47 AM Andrew Grieve 
  agri...@chromium.org
 wrote:

  mobilespec is now working again... Took longer than I would
 have
  liked, but did you know that on Android FileReader triggers
  shouldInterceptRequest() with Blob URLs!?
 
  Separate thread is already happening re: whitelists, so once
  that's
  figured out, it's just docs afaict.
 
  On Mon, Mar 2, 2015 at 10:52 PM, Ian Clelland 
   iclell...@chromium.org

  wrote:
 
   On Mon, Mar 2, 2015 at 6:00 PM, Jesse 
 purplecabb...@gmail.com
  
wrote:
  
We should start a new whitelist plugin related thread.
   
Why is a plugin blocking a release?  Default (aka
 no-plugin)
behavior should be to allow all network requests shouldn't
  it?
  
  
   Well, that just might be a blacklist then :)
  
  
  This thread is a
month long, and not the first discussion of 4.0.0 for
  Android.
   
  
   Seriously, though -- the whitelist discussion is much longer
  than
   that,
  and
   this isn't the first time that the default no-network-access
   policy
   has been brought up:
  
   (Here's the first question, from *July*:
   http://markmail.org/message/t4vj4saisem2mcgw
   Here's where I mentioned what the implemented policy was:
   http://markmail.org/message/s4necfnh4hnblpjm
   And in another discussion:
   http://markmail.org/message/ap7syhqysizmsvrz)
  
   If we want to reconsider that decision, then we should
  certainly
   do
   so before we cut a release. I think it would be a real
 problem
  to
   change it afterwards, so let's get it right

Re: (Mobile spec) Replace dependency plugin with plugin list parameter in createmobilespec

2015-03-18 Thread Andrew Grieve

I've wanted to do this a few times (or implement plugin rm -f). +1 and
thanks!

On Wed, Mar 18, 2015 at 7:54 AM, Alexander Sorokin (Akvelon) 
v-als...@microsoft.com wrote:

 Hi guys,

 I would like to introduce a little improvement for mobile spec.

 Currently createmobilespec uses dependency plugin to specify the list of
 plugins to install. This approach has some limitations, for example after
 the app is created the user cannot remove particular plugin because they
 all are listed as dependencies of dependency plugin.

 Developers may want to add custom plugin(s) to mobile spec for testing.
 Also some plugins could not be supported under particular platform and
 should not be installed.

 I've replaced dependency plugin with new command line parameter for
 createmobilespec to specify plugin list through CLI. If the parameter is
 not passed, createmobilespec will use default list of plugins.

 This change would affect anyone who uses dependency plugin, though, so I
 ask a community to review my PR:
 https://github.com/apache/cordova-mobile-spec/pull/123/files

 Thanks,
 Alexander Sorokin

Re: Build signed archives using CLI

2015-03-18 Thread Andrew Grieve

Left some comments on the PR.

On Tue, Mar 17, 2015 at 5:04 PM, Nikhil Khandelwal nikhi...@microsoft.com
wrote:

 I just submitted a PR for this for Android:
 https://github.com/apache/cordova-android/pull/164

 Here's the rough design:

 - Build.json or command line args can be used to specify details required
 for packaging:
 - Keystore
 - Alias
 - Keystore password
 - Password
 - Keystore type.
 - Debug-signing.properties or release-signing.properties is created at
 prepare time to allow gradle or Ant build systems to pick up those
 properties and generate a signed archive.
 - ‘Clean’ will delete these autogenerated .properties files.
 - If no password is specified for release signing, Ant  gradle will
 prompt for passwords.

 I will shortly have a PR to update the docs.

 Thanks,
 Nikhil


 -Original Message-
 From: Carlos Santana [mailto:csantan...@gmail.com]
 Sent: Friday, February 13, 2015 2:28 PM
 To: dev@cordova.apache.org
 Subject: Re: Build signed archives using CLI

 Thanks Nikhil I see this as a very good and important feature to have in
 our CLI stack

 On Fri, Feb 13, 2015 at 4:48 PM, Nikhil Khandelwal nikhi...@microsoft.com
 
 wrote:

  I'm taking this over from Dan. I like the idea of having the release
  signing information persisted in a json file.
 
  I have made some updates on the specific issue of how keys/passwords
  can be passed through CLI and JSON:
 
  https://docs.google.com/document/d/1tJQ9OoGrrMhZcLI3mg46rGzAfbiQu9PuNB
  L1auAMGFM/edit#
 
  I'm still going through the details of packaging requirements of each
  platform. I expect to add some more details on how the packaging
  process will work with individual platform build systems in the coming
  days. I will update this thread when I do so.
 
  Here's the main JIRA with platform specific tasks here:
  https://issues.apache.org/jira/browse/CB-8483. I would love to
  collaborate with others who are interested in this area. Specifically,
  I plan to take up the task of implementing this for Android first.
 
  Thanks,
  Nikhil
 
 
  -Original Message-
  From: Victor Sosa [mailto:sosah.vic...@gmail.com]
  Sent: Tuesday, February 10, 2015 2:29 PM
  To: dev@cordova.apache.org
  Subject: Re: Build signed archives using CLI
 
  I'm leaning to Andrew and Omar's idea. I like the idea of having a
  file where all the platform-specific information will be stored, then
  each platform will take that information to sign the archive and
  produce a usable, I mean ready-to-distribute, binary.
 
  As for Omar's comment, I also concur there. If a user has the signing
  info in gradle or ant properties and that info is also provided in the
  new file discussed here, then it should take precedence and override
  the platform-specific one.
 
  Wondering if Dan is feeling OK now and ready to be back in the game :D
 
  2015-02-02 14:58 GMT-06:00 Mefire O. ommen...@microsoft.com:
 
   +1 for having an additional file to abstract away all the platform
   specific stuff. Currently, we support both gradle and ant for
   android for example, I think it wouldn't make sense for end-users to
   have to change their specs depending on what specific tool is used
   behind the
  scenes.
   Maybe we could also copy those properties to specific files during
   build or prepare ? [copy from cordova's to ant.properties]
  
  
   Thanks,
   Mefire
  
   -Original Message-
   From: Chuck Lantz [mailto:cla...@microsoft.com]
   Sent: Wednesday, January 28, 2015 10:30 AM
   To: dev@cordova.apache.org
   Subject: RE: Build signed archives using CLI
  
   Yeah personally I am thinking that - particularly if we treat
   platforms as dependencies in package.json as proposed - we'll need
   some facility to set native build settings. We may be able to come
   up with some sort of abstraction for this part, but I'm kind of
   thinking we'll ultimately want a facility to include native build
   property files (ant/gradle.properties, things like the signing
   identity in build.xcconfig, etc) in the CLI project.  That said, we
   could have another facility for common settings like certs.
  
   -Chuck
  
   -Original Message-
   From: agri...@google.com [mailto:agri...@google.com] On Behalf Of
   Andrew Grieve
   Sent: Wednesday, January 28, 2015 10:18 AM
   To: dev
   Subject: Re: Build signed archives using CLI
  
   Sounds good, let's wait until Dan is back to discuss. The main point
   I'd like to cover is whether it'd be good to have layer of
   indirection between cordova and the platform-specific files that
   dictate signing
  info.
  
   E.g.:
   Instead of using ant.properties / gradle.properties /
   build.xcconfig,
  have:
  
   cordova-keys.json
{
   ios: { identity: , provisioning_profile:  },
   android-debug: { keystore: , alias: , password: , type:  },
   android-release: { keystore: , alias: , password: , type: 
 }
   ...
   }
  
   Then, have a prepare step

Re: Deprecation of Config and the embedded use case (4.0.x related)

2015-03-17 Thread Andrew Grieve

On Tue, Mar 17, 2015 at 10:10 AM, Carlos Santana csantan...@gmail.com
wrote:

 @Michal
 I would get together with Marcel and Martin, they are our Android goto SME

 @Joe
 Do we have all the test cases  created now are some missing?
 How do you run this specific test cases on Android Studio? Google team any
 help on gradle to run this test cases on CI I think is very important to
 have a healhty CI running test cases on every pull request or commit

I've already ported the unit test over to gradle and they are easy to run
in Android Studio. There are some instructions in the test/README.md

To be clear, the embedding ability was *improved* in 3.7.0, in that you can
now control all configurations directly from Java.




 Hum I don't know how I feel about the Plugins not working, I think this is
 the key on using Cordova.
 If I'm just going to have a Web View with no Cordova then I would use In
 App Browser.

 The whole purpose of Including a Cordova Web View in to a full Native
 Android App, It's the Cordova functionality which resides mostly in the
 Plugins!
 Maybe I misunderstood your statements about plugins not working.



 On Mon, Mar 16, 2015 at 9:31 PM, Joe Bowser bows...@gmail.com wrote:

  Well, this feature was tested using TDD, and when the tests were
 re-written
  I assumed that they would be run.  In this case, I'll blame Android
 Studio,
  since we're still battling with the learning curve on that one.  (I have
 no
  clue how to run the new tests from Gradle on the command line, only in
  Android Studio).
 
  The thing is that another refactor removing layouts broke the tests,
 which
  is how I know that they weren't run.  So, I landed a couple of commits to
  refactor the unit tests so that they test this use case with the new API
  and the tests now pass.  This works again, and we can update the
  documentation,
 
  There's still the matter of getting the plugins to work, but I'm fine
 with
  leaving that to be an exercise for the downstreams that support this, and
  not Cordova itself.
 
 
 
  On Mon, Mar 16, 2015 at 6:27 PM Michal Mocny mmo...@chromium.org
 wrote:
 
   Carlos, thats great, then perhaps you could give 4.0 embedded webview a
   shot to confirm that it is still adequately supported for your
 customers?
  
   I think this thread has been too much talk and not enough trying it out
  in
   practice.  Everyone agrees the use case is important, what's left is to
   confirm we got it right.
  
   -Michal
  
   On Mon, Mar 16, 2015 at 8:58 PM, Carlos Santana csantan...@gmail.com
   wrote:
  
I just want to add that Joe is not alone on thinking that are
  developers
with this use case.
For us we have customers that start with Native Android alone, and
 then
later want to add a Cordova Web View to a portion of their App.
And they want an easy way to add a Cordova Web View.
For 4.x, I would assume that the developer can choose to make this
   embedded
Cordova Web View CrossWalk based.
   
   
On Wed, Mar 11, 2015 at 10:24 AM, Joe Bowser bows...@gmail.com
  wrote:
   
 That's why we have tests! I just changed the activity and saw that
 we
have
 one failure.  I'm not sure why this test in particular is failing,
   since
 there's too many assertions in one method, so I'll have to try and
   debug
it
 today.

 The thing is that if we're deprecating something and replacing it
  with
 something else, we should write tests for it.  Releasing a 4.0.x
 and
 changing how we embed a WebView by changing class names but not
  fixing
   up
 the deprecation is bizzare.

 On Wed, Mar 11, 2015 at 7:15 AM Andrew Grieve 
 agri...@chromium.org
 wrote:

  I wanted to make sure that I didn't break the old way of doing
   things.
 
  On Tue, Mar 10, 2015 at 2:24 PM, Joe Bowser bows...@gmail.com
   wrote:
 
   The main issue is that this isn't documented anywhere, and this
  is
   necessary for people to use a Third Party WebView.  Also, why
   didn't
 you
   bother updating the test with the new API?
  
   On Mon, Mar 9, 2015 at 5:19 PM Andrew Grieve 
  agri...@chromium.org
   
  wrote:
  
Here's an example:
   
ConfigXmlParser parser = new ConfigXmlParser();
parser.parse(activity);
webView.init(cordova, parser.getPluginEntries(),
   parser.getPreferences());
   
Feel free to iterate if you think the API is too obtuse, but
 I
think
  it's
good to allow a file-less mode, and to allow different
 WebViews
   to
 have
different settings.
   
   
   
   
On Mon, Mar 9, 2015 at 8:08 PM, Joe Bowser 
 bows...@gmail.com
 wrote:
   
 Do you have an example of how this would work? This seems
 to
   be a
 lot
more
 complex than it needs to be.

 On Mon, Mar 9, 2015 at 5:05 PM Andrew Grieve 
agri...@chromium.org

1 2 3 4 5 6 7 8 9 10 >

1 - 100 of 2036 matches

Mail list logo