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 <bows...@gmail.com> 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 <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>. >>> >> >> >> >> > >>> >> >> >> >> >>> >> >> >> >>> >> >> >>> >> >> >>> >> >>> >> >>>
