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