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" <agri...@chromium.org> wrote: > > > 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 > > > >>> > > > > > >
