incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Drew Walters <deedu...@gmail.com>
Subject Re: Cordova BlackBerry WebWorks SDKs (5.0 / 6.0 / 7.0 / 10 / PlayBook)
Date Tue, 22 May 2012 19:01:24 GMT
No problem. Thanks.

On Tue, May 22, 2012 at 1:49 PM, Ken Wallis <kwallis@rim.com> wrote:
> Sorry, you are right, currently you do not have everything you need.  Ultimately this
will all be available, but not just yet.
>
> ----- Original Message -----
> From: Drew Walters [mailto:deedubbu@gmail.com]
> Sent: Tuesday, May 22, 2012 02:47 PM
> To: callback-dev@incubator.apache.org <callback-dev@incubator.apache.org>
> Subject: Re: Cordova BlackBerry WebWorks SDKs (5.0 / 6.0 / 7.0 / 10 / PlayBook)
>
> Ken,
>
> 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:
>
> gtest
> jnext
>
> 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
> http://www.jnext.org/.  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 <fil@adobe.com> 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
>>>>of
>>>> 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
>>>>the
>>>> 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
>>>project.
>>
>> 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
>>>platforms.
>>
>> 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!
>>
>
> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential information, privileged
material (including material protected by the solicitor-client or other applicable privileges),
or constitute non-public information. Any use of this information by anyone other than the
intended recipient is prohibited. If you have received this transmission in error, please
immediately reply to the sender and delete this information from your system. Use, dissemination,
distribution, or reproduction of this transmission by unintended recipients is not authorized
and may be unlawful.

Mime
View raw message