Will do :)
On Thu, Oct 4, 2012 at 5:27 PM, Shazron <[email protected]> wrote: > Awesome - thanks Andrew, now to document the new process and update the > docs ;) > > On Tue, Oct 2, 2012 at 11:20 AM, Andrew Grieve <[email protected]> > 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 <[email protected]> > 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 <[email protected]> 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" <[email protected]> wrote: > >>> > >>> > On Sat, Sep 29, 2012 at 4:57 AM, Piotr Walczyszyn < > >>> > [email protected]> 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 <[email protected]>: > >>> > > > would different versions will work ok? > >>> > > > > >>> > > > On Sat, Sep 29, 2012 at 2:33 AM, Andrew Grieve < > >>> [email protected]> > >>> > > 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 <[email protected]> > 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 < > [email protected]> > >>> > > 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 > >>> > > >>> > <[email protected]> wrote: > >>> > > >>> >> an upgrade script would be really helpful as well. > >>> > > >>> >> > >>> > > >>> >> -Mike > >>> > > >>> >> > >>> > > >>> >> On Thu, Sep 27, 2012 at 12:44 PM, Piotr Walczyszyn < > >>> > > >>> >> [email protected]> 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 <[email protected]>: > >>> > > >>> >>> > 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 < > >>> > > >>> [email protected] > >>> > > >>> >>> >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 < > >>> [email protected] > >>> > > >>> >>> <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 > >>> > > >>> > >>> > > > >>> > > >>> > >> > >> >
