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 <agri...@chromium.org> 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 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, which had an exception about missing a manifest > permission for simulating events. Trying to add that permission gave me an > error that said only system apps are allowed to have the permission. Is > that what you're seeing? > > > On Mon, Jul 15, 2013 at 3:58 PM, Joe Bowser <bows...@gmail.com> wrote: > >> 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 jUnit test fail when I was in the tests >> directory working with Robotium (which now works with Cordova), which >> is why I'm wondering why we're talking about polish. >> >> >> >> On Mon, Jul 15, 2013 at 12:46 PM, Andrew Grieve <agri...@chromium.org> >> wrote: >> > 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 <f...@adobe.com> wrote: >> > >> >> 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 PM, "Andrew Grieve" <agri...@chromium.org> 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 namespaces. >> >> > >> >> >Replace-all on the package statement at the top of the file, and change >> >> >the >> >> >reference in plugin.xml. I'd put this change in the "polish" category. >> >> >That's what we should be doing now, no? >> >> > >> >> > >> >> > >> >> > >> >> >On Mon, Jul 15, 2013 at 2:49 PM, Filip Maj <f...@adobe.com> wrote: >> >> > >> >> >> +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" <simon.macdon...@gmail.com> >> >> >>wrote: >> >> >> >> >> >> >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 Mac Donald >> >> >> >http://hi.im/simonmacdonald >> >> >> > >> >> >> > >> >> >> >On Mon, Jul 15, 2013 at 2:07 PM, Brian LeRoux <b...@brian.io> wrote: >> >> >> > >> >> >> >> 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 we change? >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Mon, Jul 15, 2013 at 10:43 AM, Anis KADRI < >> anis.ka...@gmail.com> >> >> >> >>wrote: >> >> >> >> > 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 < >> m...@chromium.org> >> >> >> >> wrote: >> >> >> >> > >> >> >> >> >> 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 bundled in one >> >> >>package. >> >> >> >> It's >> >> >> >> >> not a giant change. >> >> >> >> >> >> >> >> >> >> On Mon, Jul 15, 2013 at 1:16 PM, Brian LeRoux <b...@brian.io> >> wrote: >> >> >> >> >> >> >> >> >> >> > 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 >> >> >><m...@chromium.org> >> >> >> >> wrote: >> >> >> >> >> > > 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 two plugins have a file with the same name, we'll >> >> >>avoid >> >> >> >> >> > > collisions. For instance, core Cordova has >> >> >>FileHelper.java. >> >> >> >> This >> >> >> >> >> is >> >> >> >> >> > the >> >> >> >> >> > > wrong place for it in 3.0 and we'd like to move it to >> the >> >> >> >>plugins >> >> >> >> >> > that use >> >> >> >> >> > > it (removing unused methods in each plugin's version). >> >> >> >>However, >> >> >> >> >> this >> >> >> >> >> > will >> >> >> >> >> > > lead to a collision in apps that use two of these >> plugins, >> >> >> >>since >> >> >> >> >> > they'll >> >> >> >> >> > > both be in the same package. >> >> >> >> >> > > 2. All plugin files will be separated into their >> packages >> >> >>in >> >> >> >>your >> >> >> >> >> IDE. >> >> >> >> >> > > This makes working on an individual plugin easier‹you >> can >> >> >>see >> >> >> >> the >> >> >> >> >> > > associated files at a glance. If I'm working on a >> plugin >> >> >>with >> >> >> >> >> > multiple >> >> >> >> >> > > files, I shouldn't have to hunt for related files to >> ensure >> >> >> >>I'm >> >> >> >> not >> >> >> >> >> > missing >> >> >> >> >> > > anything. >> >> >> >> >> > > 3. Since our plugins will be used as starting points for >> >> >> >> third-party >> >> >> >> >> > > plugins, we won't accidentally encourage plugin >> developers >> >> >>to >> >> >> >>use >> >> >> >> >> the >> >> >> >> >> > same >> >> >> >> >> > > namespace. >> >> >> >> >> > > >> >> >> >> >> > > I would propose something like >> >> >> >> org.apache.cordova.plugin.<plugin_name>. >> >> >> >> >> > >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >>
