On Sat, Sep 29, 2012 at 4:57 AM, Piotr Walczyszyn < piotr.walczys...@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 <agri...@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 <purplecabb...@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.m...@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.walczys...@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 <agri...@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.john...@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 > >>> >
