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 Wed, 15 May 2013 15:39:56 GMT
I like blackberryOS, that work for everybody?

to cut down on redundant naming:

cordova-blackberry/bbos
cordova-blackberry/playbook
cordova-blackberry/bb10


On Wed, May 15, 2013 at 5:38 AM, Bryan Higgins <bryan@bryanhiggins.net>wrote:

> +1
>
> Except the name for the BBOS folder doesn't capture support for OS5&6. Can
> we name it blackberry5-7 or blackberryOS ?
>
>
> On Tue, May 14, 2013 at 6:58 PM, Lorin Beer <lorin.beer.dev@gmail.com
> >wrote:
>
> > 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