incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Drew Walters <>
Subject Re: Cordova BlackBerry WebWorks SDKs (5.0 / 6.0 / 7.0 / 10 / PlayBook)
Date Tue, 22 May 2012 18:47:04 GMT

I spent some time looking through the blackberry-webworks next tree
that you referenced but I'm unable to build it locally since it is
dependent on some repositories hosted internally at RIM. The
dependencies at issue are:


I was able to find a gtest for BlackBerry 10 repo on github and point
at that but the jnext repo does not appear to be open sourced. I'm
assuming jnext refers to a BlackBerry 10 port of  Is the jnext port available somewhere
currently or do I need to wait a little longer?  Since jnext appears
to be at the core of creating native extensions on BB 10 it or some
abstraction of it will obviously be required at some point but I
understand if that point is not now :-)

On Tue, May 15, 2012 at 3:24 PM, Filip Maj <> wrote:
>>>> If we separate into three repos (java, air, c++), what does the
>>>> distribution look like?  Would there still be a single sample project
>>>> that is capable of building the different versions or would there be
>>>> independent build implementations?
>>> This is a point that we should discuss more. Regardless of how the
>>> repositories / distributions are structured, the user will need to be
>>> educated on which binary supports which BlackBerry OS. Also, regardless
>>> structure, each implementation (java, air, c++) will use a different CLI
>>> build implementation. Currently, we've duct-taped Java and Air under one
>>> ANT file, but even that is a stretch and user must still configure their
>>> system appropriately. What are the advantages to keeping a single
>>> repository? Having a single repository does not mean we need to share
>>> ANT script (I'd prefer to not) and the README can help educate users on
>>> which SDK targets which OS.
>>If we were to restructure the java implementation how I laid out in my
>>investigation of making everything pluggable, I think it would
>>mitigate some of the issues since it removes platform specific code
>>(native and js) from the project. Assuming the Air and QNX
>>implementations could also be implemented using the same pattern, then
>>after installing Cordova into the respective WebWorks SDK(s) the end
>>user could just use the WebWorks provided packager to build their
> True. This approach can be described in the README, along with the
> CLI-based approach.
>>Now, as a value add, we could continue to provide some build
>>automation tools, but I'm beginning to think that those would live
>>outside the project and be common across all Cordova supported
> The way we are going is to have each platform implement the necessary CLI
> tooling, with whatever language/scripts/build tooling that comes with or
> is generally associated with that platform. Ant for Android, make for iOS
> and webos, etc etc. Eventually, once we unify the CLI stuff, the
> abstraction will simply call into each platform's existing CLI tools. We
> already have issues laid out for this and we are going this route!

View raw message