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