Mailing-List: contact callback-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: callback-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of gibson.becky@gmail.com
 designates 209.85.220.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CABiQX1Xn8qSAKU6_eippgYxXBUKTRPYutLpwg1uspZ-=hGDK6w@mail.gmail.com>
References: 
 <CABiQX1Vm72ARZ5Sf4RaZFYxsGwYTEAG1Zv4vVosqSRMzWDKVKA@mail.gmail.com>
	<CADVgkyOWnDRN62HdRqKPk5kw-gd0R2EP+msmOnHdOTsnKBqBJg@mail.gmail.com>
	<CAM-DUcPx9L_ruf-Cio6c-7jXSKTy74V5t_wc6QzEuzyWgHnNug@mail.gmail.com>
	<-8529420762969790261@unknownmsgid>
	<CADVgkyOqV8G-MXKWFMsctvzNJu03STDKmScup7zEhr8U75+rgw@mail.gmail.com>
	<CAM-DUcMb_dWTc+zsXQya=-797xeuaaYoZqg6u65F6N6ZjTtFLA@mail.gmail.com>
	<CADq=2H7BwbhfishX9iLP3uz=unpODXF6B2E6tJjknQ23JfWXOQ@mail.gmail.com>
	<CABiQX1U2kg=3Tp0DUsKbYo1pkuYjwaDWBPKb2w3G6+SvdRCg8Q@mail.gmail.com>
	<CAFjK2RbdjsR9MgA_X8A4QQC892omYst=Fg+BNbSXL-9jsPmZRg@mail.gmail.com>
	<CAM-DUcNbsoUgrku5MG084Tgx35878YR9nPWF19KLfPtOwApzqA@mail.gmail.com>
	<CAKP6k2tYJ23X8boe=P3TuNoHEO22-MPKLkm-Oru3n+zVNO0B1Q@mail.gmail.com>
	<CADVgkyOkH02dycAEdwrZ_S_ys+u_-x9TY-Se=kYYHgXZ9LzREg@mail.gmail.com>
	<CABiQX1XtQLHAnV9HsvEW3xR4b7Fa2ctXyF5T7j1pKRRR6gvLfA@mail.gmail.com>
	<CADVgkyM1CFvduc6J-7AT_Ssx-mK=Aj+SLT--8yPdikoT_JwXDg@mail.gmail.com>
	<CAFjK2RbpFMRDXZWm1ay4TOg9=q8UNJBEBe-qAYyAgz1A6H4ZxQ@mail.gmail.com>
	<CABiQX1UtWC2vSXL8cqY4cvZtEb72EbZU0t8Ozdq8AORMQG7wsw@mail.gmail.com>
	<CADVgkyPPUS6QpMqYNYg6ZJec4-Pb_2OUgzb4VZdukmtnx+nBFg@mail.gmail.com>
	<CABiQX1VsM15XvTn=rA6rCy41nDThAY+vnbfYWW5kDCWM0WnMfw@mail.gmail.com>
	<CABiQX1Xn8qSAKU6_eippgYxXBUKTRPYutLpwg1uspZ-=hGDK6w@mail.gmail.com>
Date: Tue, 2 Oct 2012 15:30:04 -0400
Message-ID: 
 <CADjNb+k=B3kKF4Wrf3GT8XAfwCEXrsy5BWpGBXqTh55PtEJjmg@mail.gmail.com>
Subject: Re: Supporting multiple projects on iOS
From: Becky Gibson <gibson.becky@gmail.com>
To: callback-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=20cf3071d01c90d02904cb188cfa

--20cf3071d01c90d02904cb188cfa
Content-Type: text/plain; charset=ISO-8859-1

Ok, I guess one can't be slow in responding to these threads.  I would have
preferred to get Shaz's input on these changes as he is most aware of the
issues and for the reasons why things have been done this way.   I guess a
change / build script isn't that hard to change if he has issues when he
returns.

-becky

On Tue, Oct 2, 2012 at 2:20 PM, Andrew Grieve <agrieve@chromium.org> wrote:

> Done and done!
>
> The update_cordova_subproject script can now take in a 2nd param for the
> path to the CordovaLib project, and the create script now copies the
> CordovaLib into new projects.
>
>
>
>
> On Mon, Oct 1, 2012 at 2:13 PM, Andrew Grieve <agrieve@chromium.org>
> wrote:
>
> > Started a new new thread about going forward with option #2. Besides you
> > both being in favour of this option, it also aligns with the structure
> > described by https://github.com/filmaj/cordova-client, so I think it's
> > definitely the way to go :).
> >
> >
> > On Mon, Oct 1, 2012 at 6:32 AM, Brian LeRoux <b@brian.io> wrote:
> >
> >> Seems a little bit too brittle requiring users to install Cordova in
> order
> >> to share code they created with Cordova. (Which could cause good old
> >> fashioned path issues.) Again, would prefer libs live under the project
> >> they are dependencies for (as we do w/ Android).
> >>
> >>
> >> On Sep 29, 2012 8:32 PM, "Andrew Grieve" <agrieve@chromium.org> wrote:
> >>
> >> > On Sat, Sep 29, 2012 at 4:57 AM, Piotr Walczyszyn <
> >> > piotr.walczyszyn@gmail.com> wrote:
> >> >
> >> > > I think having a reference just to a project file doesn't solve 2
> >> > > common scenarios:
> >> > >
> >> > > 1) multi developer environment, in this case all application
> >> > > developers need to have same directory structure, so the relative
> path
> >> > > to CordovaLib is the same
> >> >
> >> >
> >> > > 2) CordovaLib versioning, often you want to version the framework
> you
> >> > > are building on top of, together with the project source code.
> Having
> >> > > CordovaLib under project structure makes it whole easier.
> >> > >
> >> > > p.
> >> > >
> >> >
> >> > I think this does address both of these concerns. Here's an example
> >> > directory structure with three projects and two versions of cordova:
> >> >
> >> > SourceControlRoot/
> >> > -- incubator-cordova-lib-version-2.1.0
> >> > ----- CordovaLib
> >> > ----- bin
> >> > -- incubator-cordova-lib-version-2.2.0
> >> > ----- CordovaLib
> >> > ----- bin
> >> > -- Project1
> >> > ---- Project1.xcodeproj
> >> > ---- CordovaLib-2.1.0.xcodeproj (points to files within
> >> > //incubator-cordova-lib-version-2.1.0/CordovaLib)
> >> > -- Project2
> >> > ---- Project2.xcodeproj
> >> > ---- CordovaLib-2.1.0.xcodeproj (points to files within
> >> > //incubator-cordova-lib-version-2.1.0/CordovaLib)
> >> > -- Project3
> >> > ---- Project3.xcodeproj
> >> > ---- CordovaLib-2.2.0.xcodeproj (points to files within
> >> > //incubator-cordova-lib-version-2.2.0/CordovaLib)
> >> >
> >> >
> >> > To update Project2 from CordovaLib-2.1.0 to CordovaLib-2.2.0, you
> would
> >> run
> >> > (from the SourceControlRoot directory):
> >> > ./incubator-cordova-lib-version-2.2.0/bin/update_cordova_subproject.sh
> >> > Project2/Project2.xcodeproj
> >> >
> >> >
> >> > Piotr - I think it would still be fair to add an optional param
> >> > to update_cordova_subproject.sh to specify which CordovaLib directory
> >> you
> >> > want it to point at. I do like this idea of having one
> >> CordovaLib.xcodeproj
> >> > file per-project though, since it means not requiring a copy of
> >> CordovaLib
> >> > into each project. The "upgrade script" in this case will just be the
> >> same
> >> > as the update_cordova_subproject.sh script, and it won't have to
> delete
> >> any
> >> > source files, but just the xcodeproj files.
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > > 2012/9/29 Brian LeRoux <b@brian.io>:
> >> > > > would different versions will work ok?
> >> > > >
> >> > > > On Sat, Sep 29, 2012 at 2:33 AM, Andrew Grieve <
> >> agrieve@chromium.org>
> >> > > wrote:
> >> > > >> Another options I've now thought of, and I think I like this one
> >> the
> >> > > best
> >> > > >> :).
> >> > > >>
> >> > > >> Instead of copying the entire CordovaLib directory into each
> >> project,
> >> > > just
> >> > > >> copy the CordovaLib.xcodeproj file. This will allow each project
> >> to be
> >> > > open
> >> > > >> at the same time, since they will technically reference different
> >> > > projects,
> >> > > >> but they will all reference the same source files. To upgrade
> >> cordova
> >> > > >> versions, our update_cordova_subproject.sh script can clobber the
> >> > > >> .xcodeproj proj file with the newer one.
> >> > > >>
> >> > > >>
> >> > > >> On Fri, Sep 28, 2012 at 6:42 AM, Brian LeRoux <b@brian.io>
> wrote:
> >> > > >>
> >> > > >>> thinking a bundled upgrade cli command in all the projects is a
> >> good
> >> > > >>> idea... something that automates whatever we document in the
> >>  upgrade
> >> > > >>> guide
> >> > > >>>
> >> > > >>>
> >> > > >>>
> >> > > >>> On Thu, Sep 27, 2012 at 6:58 PM, Jesse <purplecabbage@gmail.com
> >
> >> > > wrote:
> >> > > >>> > Mis-understood some of the finer points, thanks for the
> >> > clarification
> >> > > >>> > and patience all.
> >> > > >>> >
> >> > > >>> > I agree that option 2 makes the most sense.
> >> > > >>> >
> >> > > >>> > On Thu, Sep 27, 2012 at 9:52 AM, Mike Reinstein
> >> > > >>> > <reinstein.mike@gmail.com> wrote:
> >> > > >>> >> an upgrade script would be really helpful as well.
> >> > > >>> >>
> >> > > >>> >> -Mike
> >> > > >>> >>
> >> > > >>> >> On Thu, Sep 27, 2012 at 12:44 PM, Piotr Walczyszyn <
> >> > > >>> >> piotr.walczyszyn@gmail.com> wrote:
> >> > > >>> >>
> >> > > >>> >>> As I suggested in the pull request comments, this would
> really
> >> > make
> >> > > >>> >>> sense to update bin/create script either by enhancing it
> with
> >> > > >>> >>> additional argument to embed the CordovaLib with newly
> created
> >> > > >>> >>> projects or even make this behavior a default one.
> >> > > >>> >>>
> >> > > >>> >>> p.
> >> > > >>> >>>
> >> > > >>> >>> 2012/9/27 Andrew Grieve <agrieve@chromium.org>:
> >> > > >>> >>> > Suppose you have 5 projects that depend on 2.1, and 3 that
> >> > > depend on
> >> > > >>> 2.0.
> >> > > >>> >>> >
> >> > > >>> >>> > One big difference between the two options is that for the
> >> 2nd
> >> > > >>> option,
> >> > > >>> >>> > you'd have 8 copies of Cordova, whereas for the first
> option
> >> > > you'd
> >> > > >>> have
> >> > > >>> >>> > only two.
> >> > > >>> >>> >
> >> > > >>> >>> > I think getting the correct workflow set up with Xcode
> >> > workspaces
> >> > > >>> will be
> >> > > >>> >>> > quite cumbersome though, and not something that will be
> easy
> >> > for
> >> > > us
> >> > > >>> to do
> >> > > >>> >>> > with tooling. We'd pretty much have to rely on
> >> documentation to
> >> > > tell
> >> > > >>> >>> people
> >> > > >>> >>> > how to drag multiple projects into their own workspace.
> >> > > >>> >>> >
> >> > > >>> >>> > I think maybe another key point is that CordovaLib is
> really
> >> > > small,
> >> > > >>> and
> >> > > >>> >>> > will get even smaller if/when we remove the core plugins
> >> from
> >> > > it. In
> >> > > >>> this
> >> > > >>> >>> > model, the majority of the code will be pluginstalled into
> >> > users'
> >> > > >>> >>> projects
> >> > > >>> >>> > anyways, so it won't be a bit deal to have a bunch of
> >> copies of
> >> > > >>> >>> CordovaLib
> >> > > >>> >>> > around.
> >> > > >>> >>> >
> >> > > >>> >>> > The model that pwalczyszyn is using is to copy the
> >> CordovaLib
> >> > > >>> directory
> >> > > >>> >>> > into each project's directory, similar to how we have a
> >> > "cordova"
> >> > > >>> >>> directory
> >> > > >>> >>> > that we copy into it. Taken from his pull requests
> comments:
> >> > > >>> >>> >
> >> > > >>> >>> > MyProject
> >> > > >>> >>> >> -- cordova
> >> > > >>> >>> >> -- MyProject
> >> > > >>> >>> >> ---- CordovaLib
> >> > > >>> >>> >> ------ CordovaLib.xcodeproj
> >> > > >>> >>> >> ---- Plugins
> >> > > >>> >>> >> ---- Resources
> >> > > >>> >>> >> ---- ....
> >> > > >>> >>> >> -- MyProject.xcodeproj
> >> > > >>> >>> >> -- www
> >> > > >>> >>> >
> >> > > >>> >>> >
> >> > > >>> >>> > Having CordovaLib a sibling of Plugins does make sense in
> >> this
> >> > > model
> >> > > >>> I
> >> > > >>> >>> > think. Either that, or have it up one level.
> >> > > >>> >>> >
> >> > > >>> >>> >
> >> > > >>> >>> > To implement this, we'll need to change our bin/create
> >> script
> >> > to
> >> > > >>> copy in
> >> > > >>> >>> > the CordovaLib directory. Not too hard.
> >> > > >>> >>> >
> >> > > >>> >>> > For upgrades, how will we address this though? Just add
> >> > > documentation
> >> > > >>> >>> > telling users to delete the old directory and copy over
> the
> >> new
> >> > > one?
> >> > > >>> The
> >> > > >>> >>> > steps would be:
> >> > > >>> >>> > cp -r path/to/new/cordova/CordovaLib MyProject
> >> > > >>> >>> > path/to/new/cordova/bin/update_cordova_subproject
> MyProject
> >> > > >>> >>> > MyProject/CordovaLib
> >> > > >>> >>> >
> >> > > >>> >>> >
> >> > > >>> >>> >
> >> > > >>> >>> >
> >> > > >>> >>> >
> >> > > >>> >>> >
> >> > > >>> >>> >
> >> > > >>> >>> >
> >> > > >>> >>> > On Thu, Sep 27, 2012 at 10:16 AM, Dave Johnson <
> >> > > >>> dave.c.johnson@gmail.com
> >> > > >>> >>> >wrote:
> >> > > >>> >>> >
> >> > > >>> >>> >> +1
> >> > > >>> >>> >>
> >> > > >>> >>> >> On Thursday, September 27, 2012, Mike Reinstein wrote:
> >> > > >>> >>> >>
> >> > > >>> >>> >> > Agree on all points with Brian.
> >> > > >>> >>> >> >
> >> > > >>> >>> >> > On Thu, Sep 27, 2012 at 6:34 AM, Brian LeRoux <
> >> b@brian.io
> >> > > >>> >>> <javascript:;>>
> >> > > >>> >>> >> > wrote:
> >> > > >>> >>> >> >
> >> > > >>> >>> >> > > > Global dependancies? It's a library, why would you
> >> not
> >> > be
> >> > > >>> >>> dependent
> >> > > >>> >>> >> on
> >> > > >>> >>> >> > > it?
> >> > > >>> >>> >> > > >
> >> > > >>> >>> >> > >
> >> > > >>> >>> >> > > We're talking about global deps vs local deps. Not
> >> whether
> >> > > or
> >> > > >>> not
> >> > > >>> >>> >> you'll
> >> > > >>> >>> >> > > have a dependency!
> >> > > >>> >>> >> > >
> >> > > >>> >>> >> > >
> >> > > >>> >>> >> > > > Standardize on the apis and not the files.
> >> > > >>> >>> >> > > >
> >> > > >>> >>> >> > >
> >> > > >>> >>> >> > > Uh, ok sure, not sure I understand?
> >> > > >>> >>> >> > >
> >> > > >>> >>> >> > > It only takes a few weeks of ruby (and/or python) dev
> >> to
> >> > see
> >> > > >>> where
> >> > > >>> >>> >> global
> >> > > >>> >>> >> > > packages become ambushes for epic fail. Node learned
> >> from
> >> > > this
> >> > > >>> and
> >> > > >>> >>> >> > > explicitly created lexically scoped packages.
> Typically
> >> > > when you
> >> > > >>> >>> ship
> >> > > >>> >>> >> > > projects you want to have the dependencies bundled to
> >> > > minimize
> >> > > >>> >>> issues.
> >> > > >>> >>> >> > >
> >> > > >>> >>> >> > > See http://en.wikipedia.org/wiki/Dependency_hell
> >> > > >>> >>> >> > >
> >> > > >>> >>> >> > >
> >> > > >>> >>> >> > > Not to mention the extra complexity of #2, and
> multiple
> >> > out
> >> > > of
> >> > > >>> sync
> >> > > >>> >>> >> > > > project issues.
> >> > > >>> >>> >> > > >
> >> > > >>> >>> >> > >
> >> > > >>> >>> >> > > I do not see where this creates complexity. It
> reduces
> >> > it. I
> >> > > >>> have a
> >> > > >>> >>> >> > project
> >> > > >>> >>> >> > > that I want up-do-date. It has a dependency on
> 2.1.0. I
> >> > have
> >> > > >>> another
> >> > > >>> >>> >> > > project I do not want to update running 2.0.0: no
> >> problem.
> >> > > If I
> >> > > >>> >>> have a
> >> > > >>> >>> >> > > global dependency: problem!
> >> > > >>> >>> >> > >
> >> > > >>> >>> >> > > The other issue here is the requirement of having
> your
> >> > > library
> >> > > >>> >>> >> > > a separate concern for the end user project. When I
> >> want
> >> > to
> >> > > >>> build a
> >> > > >>> >>> >> > project
> >> > > >>> >>> >> > > from another repo it requires me to install the
> correct
> >> > > version
> >> > > >>> of
> >> > > >>> >>> the
> >> > > >>> >>> >> > > dependency. With option 2 the library is a part of
> the
> >> > > project
> >> > > >>> and
> >> > > >>> >>> no
> >> > > >>> >>> >> > > installer step is required. Again: reduced
> complexity.
> >> > > >>> >>> >> > >
> >> > > >>> >>> >> > >
> >> > > >>> >>> >> > >
> >> > > >>> >>> >> > > I originally moved the codebase to a library and
> >> created
> >> > the
> >> > > >>> >>> template
> >> > > >>> >>> >> > > > over 2 years ago, so I may be blind to the benefits
> >> of
> >> > #2,
> >> > > >>> but to
> >> > > >>> >>> me
> >> > > >>> >>> >> > > > this makes our library become a boilerplate... am I
> >> > wrong?
> >> > > >>> >>> >> > > >
> >> > > >>> >>> >> > >
> >> > > >>> >>> >> > > Do not see how this is related either.
> >> > > >>> >>> >> > >
> >> > > >>> >>> >> >
> >> > > >>> >>> >>
> >> > > >>> >>>
> >> > > >>> >
> >> > > >>> >
> >> > > >>> >
> >> > > >>> > --
> >> > > >>> > @purplecabbage
> >> > > >>> > risingj.com
> >> > > >>>
> >> > >
> >> >
> >>
> >
> >
>

--20cf3071d01c90d02904cb188cfa--