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
