Well, for upgrades the modified bin/update_cordova_subproject that I've sent pull request with could work. Only the users would have to copy CordovaLib to their projects directory.
p. 2012/9/27 Mike Reinstein <reinstein.m...@gmail.com>: > 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. >> >> > > >> >> > >> >> >>
