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