cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse MacFadyen <purplecabb...@gmail.com>
Subject Re: Proposition to split cordova-blackberry into two separate plugins
Date Fri, 22 Feb 2013 20:39:54 GMT
I agree with Brian, single repo, multiple sub-projects.
The windows repo contains win7 and win8 and there is absolutely no
code shared between them. Conceivably wp7+8 could be merged in the
same way.

Cheers,
  Jesse

Sent from my iPhone5

On 2013-02-22, at 12:02 PM, Brian LeRoux <b@brian.io> wrote:

Perhaps code on Github can clear this up, but given the discussion so
far, I am unconvinced. Creating a new Git repo isn't solving any of
the problems described below. This should be sub folder of
./cordova-blackberry.

We currently have 20+ repos. Once we push everything to plugins that
will be 40+ repos. We need to keep things clear for our developer
community and especially so for new committers. Best way to do this is
to continue to putting BlackBerry code under the BlackBerry repo.

We can evolve that repo to include the enhancements you describe below
without a new repository to do it. Rather a clean room I would ask you
guys pull request the existing repo w/ a new folder and lets move the
conversation to JIRA on how to best clean up.



On Fri, Feb 22, 2013 at 7:34 AM, Jeffrey Heifetz <jheifetz@rim.com> wrote:
> Hey Brian,
>
> BB10 is not just  a specific version number of an SDK like BBOS v 10, its a brand new
OS. Like Mac OSX vs Classical Mac OS. But independent of the technology differences I believe
this approach will improve things for cordova developers targeting blackberry by making it
more consistent with the approach taken with other platforms.
>
> Firstly the developer experience for developers targeting both BB10 and one of BBOS and
PBOS. The current implementation based on 3 slightly different versions of webworks means
that there are similar things that end up acting quite differently. One example is the config.xml.
Currently the solution is that Cordova populates one massive config.xml that attempts to satisfy
all 3 sub-platforms and cordova at large as well. Unfortunately the SDKS are quite different
offering very different functionalities through the config, and there is currently no way
to handle these differences in the sub-platforms.
> By splitting we can handle these in the same way all other cordova platforms do (unsure
what this is) and once the core plugins are split accurately let the individual plugins add
these values accordingly (something that may not be possible when BBOS and PBOS share a config
entry but BB10 does not).
>
> Even developer experience for developers making cross platform plugins thinking to add
support for blackberry. Currently blackberry has a unique structure requiring plugins to have
their code in a specific way for 3 different platforms. While adding support for just one
is not difficult, its different from any other platform (to my knowledge).
>
> Another example will be simple performance. The way the repo is architected right now,
javascript is loaded that runs for all 3 platforms and it runtime detects which one to use.
Its not even clear how this will work once all of the plugins are split into their own repos,
but having this adds unnecessary complications that can be removed.
>
> We're in the midst of getting our code up on github, maybe it'll be clearer what we want
to do when there's code to see.
>
> On 2013-02-20, at 12:47 PM, Brian LeRoux wrote:
>
>> Hey Jeffrey, I'm sorry but I'm not convinced by 'its cleaner' as an
>> argument. Its not. Its a specific version number to a specific SDK. I
>> understand that you have more than one SDK: this is common in mobile
>> platforms, and addressed by the current repo.
>>
>> Can you be more precise and explain exactly what you envision this new
>> repo to contain, and specifically why it can't come as a pull request
>> to the existing repo/codebase?
>>
>>
>> On Tue, Feb 19, 2013 at 5:47 PM, Jeffrey Heifetz <jheifetz@rim.com> wrote:
>>> Sharzon, sorry I have no clue when BB10 will be making its way to playbook.
>>>
>>> Bryan, whatever the next version is called BB11 or not, that would still be within
the same repo. Conceptually BB10 is a brand new platform based on a very different SDK and
unless I'm mistaken BlackBerry is the only platform to have 3 different SDKS within one repo
(BBOS java, AIR, and BB10 C++).  I know windows phone is separated. Plus we feel this way
it will be cleanest for our developers and more conformant with the cordova dev experience.
>>>
>>> Tim  we're in the midst of creating a much more CLI friendly (Not ANT)  repo
right now that would be based on our last webworks packager and framework but would be built
directly on the NDK.
>>>
>>> As per the plugins, I'll take a look tomorrow but it's impressive when anyone
makes a plugin for bb1010. Current docs are definitely lacking.
>>>
>>> Sent from my BlackBerry 10 smartphone.
>>>
>>> From: Tim Kim
>>> Sent: Tuesday, February 19, 2013 7:11 PM
>>> To: dev@cordova.apache.org
>>> Reply To: dev@cordova.apache.org
>>> Subject: Re: Proposition to split cordova-blackberry into two separate plugins
>>>
>>>
>>> I don't mind either way, but I think we should have at least an idea what
>>> the cordova-blackberry10 repo should look like before we create it.
>>> To separate them right now would mean creating two very similar
>>> cordova-blackberry repos (everything the same except some build scripts).
>>> And then later on, reconfiguring the cordova-blackberry10 repo to be
>>> whatever.
>>>
>>> So I'm basically for less work now :)
>>>
>>> Also, on the topic of plugins for BlackBerry 10, I've done some work
>>> recently on this that you can check out:
>>>
>>> Here's my simple plugin that shows the structure for a BB10 plugin with
>>> native code:
>>> https://github.com/timkim/cordova.echo
>>>
>>> A tool to build the C++ code from command line:
>>> https://github.com/timkim/Renton
>>>
>>> And plugman now has bb10 support so it should be able to install the
>>> cordova.echo plugin:
>>> https://github.com/imhotep/plugman
>>>
>>>
>>>
>>>
>>> On 19 February 2013 14:55, Brian LeRoux <b@brian.io> wrote:
>>>
>>>> I'm a little uncertain about the reasoning here. What happens when BB11
>>>> ships? New repo?
>>>>
>>>> Generally we try to keep things in a vendor directory with
>>>> the pertinent SDK's within. What is wrong w/ the current structure for
>>>> contribution?
>>>>
>>>>
>>>>
>>>> On Tue, Feb 19, 2013 at 2:45 PM, Shazron <shazron@gmail.com> wrote:
>>>>
>>>>> +1
>>>>> Also, any news when BB10 comes to Playbook, ballpark? --> "once BB10
is
>>>>> ported to playbook"
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Feb 19, 2013 at 1:24 PM, Filip Maj <fil@adobe.com> wrote:
>>>>>
>>>>>> Sounds fine to me.
>>>>>>
>>>>>> As for process, assuming there are no objections (would wait a couple
>>>>>> days), file a JIRA issue on the INFRA project
>>>>>> (issues.apache.org/jira/browser/INFRA)
>>>>>>
>>>>>> On 2/19/13 1:15 PM, "Jeffrey Heifetz" <jheifetz@rim.com> wrote:
>>>>>>
>>>>>>> With all this talk of re-organizing cordova plugins we here at
>>>>> BlackBerry
>>>>>>> (RIM no more) have been discussing better alleging ourselves
with the
>>>>>>> approach by splitting our existing cordova-blackberry platform
into
>>>> two
>>>>>>> separate platforms. (I saw a similar call here as well
>>>> http://callback.markmail.org/thread/xnhpidbnxg5ps7zr#query:+page:1+mid:xnh
>>>>>>> pidbnxg5ps7zr+state:results)
>>>>>>>
>>>>>>> We propose adding a new platform, "blackberry10" with the longterm
>>>>>>> understanding that once BB10 is ported to playbook the original
repo
>>>>>>> would only be for BBOS. Ideally the end result of this is that
we
>>>> would
>>>>>>> have an up to date cordova-blackberry10 platform following all
of the
>>>>>>> best practices (plugins moved into their own repos, etc) and
we can
>>>>>>> better contribute resources to Cordova in general.
>>>>>>>
>>>>>>> Hopefully no one has any objections to this as structurally they
are
>>>>>>> really separate platforms. Additionally it'll make the flow within
>>>> CLI a
>>>>>>> lot cleaner.
>>>>>>>
>>>>>>> If everyone agrees, what is the process for getting a new apache
repo
>>>>> for
>>>>>>> it?
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> 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.
>>>
>>>
>>>
>>> --
>>> Timothy Kim
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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.
>
>
> ---------------------------------------------------------------------
> 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