Mailing-List: contact callback-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: callback-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of brian.leroux@gmail.com
 designates 74.125.83.47 as permitted sender)
MIME-Version: 1.0
Sender: brian.leroux@gmail.com
In-Reply-To: 
 <CABiQX1UtWC2vSXL8cqY4cvZtEb72EbZU0t8Ozdq8AORMQG7wsw@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>
Date: Mon, 1 Oct 2012 12:32:33 +0200
Message-ID: 
 <CADVgkyPPUS6QpMqYNYg6ZJec4-Pb_2OUgzb4VZdukmtnx+nBFg@mail.gmail.com>
Subject: Re: Supporting multiple projects on iOS
From: Brian LeRoux <b@brian.io>
To: callback-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=047d7b62207a67829b04cafcec77

--047d7b62207a67829b04cafcec77
Content-Type: text/plain; charset=ISO-8859-1

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

--047d7b62207a67829b04cafcec77--