I'm working on our prototype for automatic installation of Javascript from plugins in cordova-cli. We already have installation for native code and non-JS www assets. I don't see anything to be gained from precompiled libraries, since a user of Cordova already has the device SDK in place and is using either our scripts (cordova build, bin/emulate, etc.) or Eclipse/Xcode/etc. to build the deployable application.
Switching to libraries loses us transparency for bugfixes ("make this change in some/plugin/File.java and see if that fixes your bug") and error messages, and it's not like we've got closed-source products we want to make sure people can't read. Braden On Sat, Feb 23, 2013 at 10:07 PM, Simon MacDonald <simon.macdon...@gmail.com > wrote: > The other issue with jars on Android is they will be unable to refer to > anything in the res folder. That's basically why Android library projects > exist as conventional jars just don't cut it. Luckily since most Cordova > plugins will do their UI in HTML the likelihood of the plugin needing to > access the res folder is very low. > > > Simon Mac Donald > http://hi.im/simonmacdonald > > > On Fri, Feb 22, 2013 at 7:33 PM, Michael Brooks <mich...@michaelbrooks.ca > >wrote: > > > Sweet, thanks for the Android input Joe! > > > > It's awesome to see such detailed responses for Android, BlackBerry, iOS, > > and Windows! > > > > I suppose we can proceed as Marcel suggestion? Create JIRA issue, link to > > this thread, but keep our vision forward by finishing source-code > > distributed plugins. > > > > Michael > > > > On Fri, Feb 22, 2013 at 4:23 PM, Joe Bowser <bows...@gmail.com> wrote: > > > > > Hey > > > > > > I'm definitely a fan of pre-compiled libraries for plugins. The main > > > reason I like JARs instead of Java files is because of the following: > > > > > > * Cleaner projects > > > * Installation is extremely easy for non-Activity plugins (drop in the > > > libs directory) > > > > > > The downsides on Android: > > > > > > * You can't verify a JAR - Have to trust that the JAR isn't sketchy, > > > signatures can mitigate this, but not eliminate it > > > * JARs can't transport assets, assets would have to be transported > > > separately > > > > > > Overall, if you sign the JARs and allow for a mechanism for our users > > > to check the signature of the JAR, I'm cool with this approach. We > > > should remember that our users aren't the type of people who will > > > check a Java file to make sure the plugin does what it says it does, > > > and it would be nice to be able to have a tool to give them some > > > assurance that the plugin does only what they think it does. > > > > > > Joe > > > > > > > > > On Fri, Feb 22, 2013 at 1:30 PM, Michael Brooks > > > <mich...@michaelbrooks.ca> wrote: > > > > Great responses everyone. We've now got a decent overall of the iOS > and > > > WP > > > > landscape, not to mention use-cases of other projects such Google > Maps. > > > > > > > > tl;dr: IMHO, those three things listed above is where we should put > our > > > >> effort to make plugins easier, then see where that gets us. I think > it > > > will > > > >> drive us the furthest forward. Then go back an reevaluate whether or > > > not to > > > >> provide precompiled libs to see if it truly makes life easier for > the > > > user, > > > >> or if it complicates life for the user. > > > > > > > > > > > > Marcel, this is the feedback that I was hoping to see! Thanks a bunch > > for > > > > the analysis. > > > > > > > > The project is always driven by what gives ours users the most value. > > So, > > > > it makes sense to not lose sight of our goal - offering plugins to > > users. > > > > If the first phase is source-code only, then so be it. > > > > > > > > The intention of packaging plugins as libraries is entirely around > > making > > > > the users' life less painful. I was reminded of this problem last > > night, > > > > when I had to compile a 2 year old OS X library because the developer > > did > > > > not publish the .framework. Unsurprisingly, it failed to build > because > > > > Xcode no longer bundles the necessary libraries. Similarly, if I > needed > > > to > > > > a use a JPG or MP3 library, I would not want to include the source > code > > > in > > > > my project simply because it takes too long to compile (assume it > does > > > > compile). > > > > > > > > Michael > > > > > > > > On Fri, Feb 22, 2013 at 12:38 PM, Marcel Kinard <cmarc...@gmail.com> > > > wrote: > > > > > > > >> So if I back up for a moment and look at the bigger picture, it > looks > > > like > > > >> what you are going for is to make it easier for Cordova users to > pick > > up > > > >> plugins, either base ones or third-party ones. There are many ways > to > > do > > > >> that, providing precompiled code is one way. > > > >> > > > >> If I were to step into the shoes of a relatively new Cordova user > who > > > >> wanted to pick up a plugin for my app, I don't think the compilation > > is > > > >> difficult enough to warrant some workaround such as providing > > > libraries. My > > > >> [admitedly, limited] understanding is that as a Cordova user I > always > > > need > > > >> to use the device SDK to build my app. Therefore the compiler is > right > > > >> there and it's not difficult to invoke (i.e., iOS always needs > > > compilation). > > > >> > > > >> While still in the shoes of that Cordova user, what appears to be > more > > > >> challenging in that role is figuring out what files are needed, > where > > to > > > >> put them, and what to edit (i.e., config.xml). Basically, getting > the > > > >> environment and content setup for the SDK to run against. After > that, > > > >> running the SDK/compiler is easy. So for this difficulty, the kinds > of > > > >> helps could include: > > > >> - docs: overall on how to install/remove plugins, and > plugin-specific > > > docs > > > >> on their specific requirements/quirks > > > >> - tooling: a CLI (i.e., plugman) that could make it as easy as npm > > > >> - verification: help me as a user understand if the plugin is in > there > > > >> correctly, (i.e., smoke test or something like 'rpm -V') > > > >> > > > >> tl;dr: IMHO, those three things listed above is where we should put > > our > > > >> effort to make plugins easier, then see where that gets us. I think > it > > > will > > > >> drive us the furthest forward. Then go back an reevaluate whether or > > > not to > > > >> provide precompiled libs to see if it truly makes life easier for > the > > > user, > > > >> or if it complicates life for the user. > > > >> > > > >> The library idea is neat, it ought be captured in Jira while these > > other > > > >> things are worked on first. > > > >> > > > >> -- Marcel Kinard > > > > > >