Re: Plugin packages on Android

I think this is the wrong thread! On Tue, Jul 30, 2013 at 11:52 AM, Filip Maj wrote: > It seems like removal of the "org.apache.cordova.api" namespace happened > in 3.0 anyways, even though there was no consensus on this thread for it, > with the big one being CordovaPlugin (moved to org.apache.c

Re: Plugin packages on Android

It seems like removal of the "org.apache.cordova.api" namespace happened in 3.0 anyways, even though there was no consensus on this thread for it, with the big one being CordovaPlugin (moved to org.apache.cordova), and no shims were put in place. No surprise, users are confused and angry. I would

Re: Plugin packages on Android

ftr phonegap predates semver which is basically a reaction to ruby's globally installed package legacy that said, its a neat system On Tue, Jul 16, 2013 at 12:22 AM, Filip Maj wrote: > We definitely do not follow semver > > http://wiki.apache.org/cordova/DeprecationPolicy > > > On 7/16/13 12:15

Re: Plugin packages on Android

We definitely do not follow semver http://wiki.apache.org/cordova/DeprecationPolicy On 7/16/13 12:15 AM, "David Pfahler" wrote: >What or where exactly is the deprecation policy? It's probably not >semver, >because breaking changes need a major version update in semver. Henc

Re: Plugin packages on Android

What or where exactly is the deprecation policy? It's probably not semver, because breaking changes need a major version update in semver. Hence, breaking these plugins would require 4.0, not 3.1. But I guess this is just not how you have set it up. On Tue, Jul 16, 2013 at 1:1

Re: Plugin packages on Android

On Mon, Jul 15, 2013 at 5:23 PM, Brian LeRoux wrote: > A package namespace is not a part of the API? Are we saying we in > Cordova draw the semantic line at a method signature? (Its certainly > not a normal view on what defines an API. Anyhow! Super not > important.) > > One more time! Specifics.

Re: Plugin packages on Android

A package namespace is not a part of the API? Are we saying we in Cordova draw the semantic line at a method signature? (Its certainly not a normal view on what defines an API. Anyhow! Super not important.) One more time! Specifics. What packages are changing in precisely what files? Right now we'

Re: Plugin packages on Android

OK, Test killed. I get the same thing on this end. Let's close that bug off! On Mon, Jul 15, 2013 at 2:04 PM, Joe Bowser wrote: > I'm going to kill that test! This is the Cordova project, not JQMobile. > > On Mon, Jul 15, 2013 at 1:45 PM, Andrew Grieve wrote: >> Awesome. So for UriResolvers, I

Re: Plugin packages on Android

I'm going to kill that test! This is the Cordova project, not JQMobile. On Mon, Jul 15, 2013 at 1:45 PM, Andrew Grieve wrote: > Awesome. So for UriResolvers, I just checked in another revision today, and > I'm not happy with it and all that's left is documentation. If you wanted > to do a code re

Re: Plugin packages on Android

Awesome. So for UriResolvers, I just checked in another revision today, and I'm not happy with it and all that's left is documentation. If you wanted to do a code review on it, that would be cool too. I also ran the junit tests (as of an hour ago), and the only test that fails is the JQMTabTest, w

Re: Plugin packages on Android

I feel like Android is in good shape for the most part, but I can't say the same about the plugins or the CLI that I'm currently using to load them, since I haven't tested today's changes yet. That being said, I think you guys have some open issues still, like the UriResolvers, and I did see a jUn

Re: Plugin packages on Android

Joe - what non-polish items are left for Android? If you're feeling like you have too much to do this week, maybe you can delegate some tasks? On Mon, Jul 15, 2013 at 3:27 PM, Filip Maj wrote: > I think what you're saying Andrew is true under the assumption that > plugins are ONLY consumed via

Re: Plugin packages on Android

I think what you're saying Andrew is true under the assumption that plugins are ONLY consumed via the JS api. I'm not sure whether that assumption is correct in all cases. In any case, clarifying this point (dependency "scope" we could call it, perhaps?) seems like a good idea. On 7/15/13 12:14 P

Re: Plugin packages on Android

On Mon, Jul 15, 2013 at 12:14 PM, Andrew Grieve wrote: > -1 to shims. A plugin's java package name shouldn't be considered a part of > its API. That's why there is a mapping in the config.xml. > > Shouldn't have to change any require() statements, or any JS at all. Those > use plugin IDs, not java

Re: Plugin packages on Android

-1 to shims. A plugin's java package name shouldn't be considered a part of its API. That's why there is a mapping in the config.xml. Shouldn't have to change any require() statements, or any JS at all. Those use plugin IDs, not java namespaces. Replace-all on the package statement at the top of

Re: Plugin packages on Android

+1 wait until 3.1. +1 add shims for less breakage Also worth pointing out that we'll need to add this to the deprecation list on the wiki On 7/15/13 11:30 AM, "Simon MacDonald" wrote: >The reason things broke back then was we didn't leave in shims to point >anyone compiling against com.phonega

Re: Plugin packages on Android

The reason things broke back then was we didn't leave in shims to point anyone compiling against com.phonegap.api to org.apache.cordova.api. That was quickly corrected. I agree with the package name change but with 3.0 shipping this week(?). It should probably wait until the next version. Simon

Re: Plugin packages on Android

Yea, to be clear, I'm in favor of namespaces. They're a honking good idea. But lets push this to 3.1 and leave shims around until 3.5/3.6 as per our deprecation policy. On Mon, Jul 15, 2013 at 11:16 AM, Steven Gill wrote: > This will involve changing all of the plugin.xml files as well as any >

Re: Plugin packages on Android

If you guys are uncomfortable with it, it should wait. I don't think it's a huge priority anyway. On Mon, Jul 15, 2013 at 11:16 AM, Steven Gill wrote: > This will involve changing all of the plugin.xml files as well as any > require statements in the javascript files of those plugins. Seems like

Re: Plugin packages on Android

This will involve changing all of the plugin.xml files as well as any require statements in the javascript files of those plugins. Seems like a lot of work to squeeze in for 3.0 On Mon, Jul 15, 2013 at 11:14 AM, Joe Bowser wrote: > Can we NOT do this now? We have in reality three days of dev l

Re: Plugin packages on Android

Can we NOT do this now? We have in reality three days of dev left before we release 3.0. We don't have time for these last minute changes, no matter how trivial. On Mon, Jul 15, 2013 at 11:12 AM, Max Woghiren wrote: > I am proposing we change all of the Android plugins in Cordova 3.0 to > belon

Re: Plugin packages on Android

I am proposing we change all of the Android plugins in Cordova 3.0 to belong in individual packages. For instance, the FileTransfer plugin, which currently exists in the org.apache.cordova.core package, should be moved to, say, org.apache.cordova.plugin.filetransfer. Every plugin should be moved

Re: Plugin packages on Android

No. You are proposing an API change. A package is most certainly a part of the API! When we moved from `com.phonegap` to `org.apache` there was a huge outcry b/c it broke all existing community plugins. I'm completely open to changing stuff for 3.0 but, again, what specifically are you proposing w

Re: Plugin packages on Android

I agree. The only downside I see is that it will be hard to dissociate core plugins from other but I don't think it's really that important. Also because it's not a giant change it could happen for 3.0. On Mon, Jul 15, 2013 at 10:33 AM, Max Woghiren wrote: > I'm not proposing any API changes in

Re: Plugin packages on Android

I'm not proposing any API changes in this email; example (1) does mention the relocation of FileHelper.java, but that's more to illustrate the benefits of repackaging the plugins. I would think the plugin package change should happen *for* 3.0, before people actually start using the plugins all bu

Re: Plugin packages on Android

I think all of this makes good sense but will have to land sometime post 3.0 as that we're pretty much in the final stretch now anyhow. Which APIs are you specifically proposing we change? On Mon, Jul 15, 2013 at 9:14 AM, Max Woghiren wrote: > On Android, all Cordova plugins are in the package

Plugin packages on Android

On Android, all Cordova plugins are in the package org.apache.cordova.core. It makes sense to put each plugin into its own package. Aside from 3.0's conceptual shift into "plugins as completely individual entities" and the fact that plugins aren't really "core", here's some rationale: 1. If t