Awesome - thanks Andrew, now to document the new process and update the docs ;)
On Tue, Oct 2, 2012 at 11:20 AM, Andrew Grieve <agri...@chromium.org> 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 <agri...@chromium.org> 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 <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 >>> > > >>> >>> > > >>> > >>> >> >>
