I agree with all that Marcel said, and I think most of the points he
outlined are well under way. So, I vote we just revisit this once those
are done and we have some time to ingest the changes, and see if we still
have a use case for this.
For the example of 2 year old plugin, it seems unlikely to me that a 2 year
old unmaintained precompiled plugin is going to work well, anyway (I don't
think we have that sort of api consistency, yet).
Fot the plugin's marketplace example, this does sound potentially
compelling. Is anyone specifically requesting this already? Or, do we
want to build it, so that they will come?
-Michal
On Mon, Feb 25, 2013 at 9:11 AM, Braden Shepherdson <bra...@chromium.org>wrote:
> 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
> > > >
> > >
> >
>
