cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lorin Beer <lorin.beer....@gmail.com>
Subject Re: Cordova BlackBerry project structure
Date Tue, 14 May 2013 22:58:26 GMT
that's my idea, Jeffrey, to route to sub platform bin scripts. The original
create tool would create a project which could target any blackberry
platform, not just one. The idea would be that the root bin calls the
platform bin scripts and creates a single project again which can target
the individual platforms.

The only item that requires appreciable work is the root bin folder, we can
scope what that would require separately.



On Tue, May 14, 2013 at 3:35 PM, Jeffrey Heifetz <jheifetz@blackberry.com>wrote:

> If bin is top level, it requires a non-standard first parameter to
> distinguish sub-platform. I know this is the same as the old way, but it's
> very unique to the BlackBerry implementation.
>
> Perhaps if this just routed to sub platform bin scripts it would be ideal.
>
> Sent from my BlackBerry 10 smartphone on the Rogers network.
> From: Ken Wallis
> Sent: Tuesday, May 14, 2013 6:21 PM
> To: dev@cordova.apache.org; dev
> Reply To: dev@cordova.apache.org
> Subject: Re: Cordova BlackBerry project structure
>
>
> +1
>
> Sent from my BlackBerry Z10 smartphone
> From: Lorin Beer
> Sent: Tuesday, May 14, 2013 6:17 PM
> To: dev
> Reply To: dev@cordova.apache.org
> Subject: Re: Cordova BlackBerry project structure
>
>
> ok, final word on this is to not break out the BlackBerry platforms into
> separate repos. However, they will break out into subdirectories in the
> root of the blackberry repo:
>
> apache/cordova-blackberry/blackberry7
> apache/cordova-blackberry/blackberry10
> apache/cordova-blackberry/playbook
> apache/cordova-blackberry/bin
>
> bin will provide a uniform tooling interface for creating projects, just a
> simple shim script to delegate to the platform tool scripts, which have
> diverged.
>
> This means duplicating the playbook/bb7 scripts, but bb7 will be removed by
> 3.0, so this is a short term duplication.
>
>
> I think this solution minimizes the amount of work while adopting a project
> structure that makes the most sense for our developers.
>
> vote now or forever hold your peace.
>
> - Lorin
>
>
>
> On Fri, May 10, 2013 at 10:09 AM, Brian LeRoux <b@brian.io> wrote:
>
> > yes, exactly that
> >
> > On Fri, May 10, 2013 at 9:39 AM, Lorin Beer <lorin.beer.dev@gmail.com>
> > wrote:
> > > that confused me too,
> > >
> > > windows phone already has separate repos. apache/wp7 and apache/wp8. If
> > we
> > > stick with the "os vendor" organization, should we refactor those repos
> > > into a single "windowsphone" repo?
> > >
> > >
> > >
> > > On Fri, May 10, 2013 at 9:09 AM, Filip Maj <fil@adobe.com> wrote:
> > >
> > >> Which repos would need refactoring, Brian?
> > >>
> > >> On 5/9/13 2:56 PM, "Brian LeRoux" <b@brian.io> wrote:
> > >>
> > >> >I'm a no on this. Conceptually grouping by operating system vendor
> > >> >makes more sense (to me). If we're going down this path the other
> > >> >repos need to be refacored to reflect it: cordova-platform-* (and
> > >> >Windows will need breaking out).
> > >> >
> > >> >(Also I'm not a fan of mixing pascal case with camel case but thats
a
> > >> >separate issue!)
> > >> >
> > >> >On Thu, May 9, 2013 at 10:50 AM, Lorin Beer <
> lorin.beer.dev@gmail.com>
> > >> >wrote:
> > >> >> Currently, BlackBerry exists as a single repository containing
3
> > >> >>different
> > >> >> implementations of Cordova: BB7, PlayBook and BB10.
> > >> >>
> > >> >> This has been great from a user perspective: the cordova create
> tool
> > >> >> allowed you to specify which target you wanted to build/run to
> once a
> > >> >> project has been created.
> > >> >>
> > >> >> However, BlackBerry has split the new BB10 implementation off
from
> > the
> > >> >> previous project structure: it now lives in a separate tree, and
> runs
> > >> >>with
> > >> >> it's own implementation of the tools.
> > >> >>
> > >> >> With the decision to send BB7 off to the farm getting positive
> > >> >>feedback, I
> > >> >> want to reopen the discussion of BlackBerry's project structure.
> > >> >>
> > >> >> Proposition:
> > >> >> split the BB platform implementations, with 3 repositories:
> > >> >> apache/Cordova-BlackBerry7
> > >> >> apache/Cordova-BlackBerryPlaybook
> > >> >> apache/Cordova-BlackBerry10
> > >> >>
> > >> >> we let the CLI provide the uniform interface between platforms,
and
> > >> >>treat
> > >> >> these as separate implentations. It also gets ahead of the work
to
> > drop
> > >> >>BB7
> > >> >> and avoids o "re-integrate" task for BB10 which sounds like a
waste
> > of
> > >> >>time.
> > >> >>
> > >> >> - Lorin
> > >>
> > >>
> >
>
> ---------------------------------------------------------------------
> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message