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 piotr.walczyszyn@gmail.com
 designates 209.85.220.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CADVgkyM1CFvduc6J-7AT_Ssx-mK=Aj+SLT--8yPdikoT_JwXDg@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>
Date: Sat, 29 Sep 2012 10:57:22 +0200
Message-ID: 
 <CAFjK2RbpFMRDXZWm1ay4TOg9=q8UNJBEBe-qAYyAgz1A6H4ZxQ@mail.gmail.com>
Subject: Re: Supporting multiple projects on iOS
From: Piotr Walczyszyn <piotr.walczyszyn@gmail.com>
To: callback-dev@incubator.apache.org
Content-Type: text/plain; charset=ISO-8859-1

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.

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