THANK YOU! I was getting tired of running both scripts! :-b On Thu, Oct 4, 2012 at 4:36 PM, Andrew Grieve <agri...@chromium.org> wrote:
> This has already started to annoy me as a Cordova developer since now when > I create a new project and edit some native files, those files are not the > ones in my git repo, but rather they are copies. > > So, I added a flag to the create script --shared, that will do the old > behaviour of not using a copy. Probably this will be used only by Cordova > devs. > > > On Tue, Oct 2, 2012 at 3:30 PM, Becky Gibson <gibson.be...@gmail.com> > wrote: > > > Ok, I guess one can't be slow in responding to these threads. I would > have > > preferred to get Shaz's input on these changes as he is most aware of the > > issues and for the reasons why things have been done this way. I guess > a > > change / build script isn't that hard to change if he has issues when he > > returns. > > > > -becky > > > > On Tue, Oct 2, 2012 at 2:20 PM, 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 > > > >> > > >>> > > > >> > > > > > >> > > > > >> > > > > > > > > > > > > > >
