incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <...@adobe.com>
Subject Re: Cordova BlackBerry WebWorks SDKs (5.0 / 6.0 / 7.0 / 10 / PlayBook)
Date Tue, 15 May 2012 20:24:37 GMT

>>> 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!


Mime
View raw message