Return-Path: X-Original-To: apmail-incubator-callback-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-callback-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id E061CDA61 for ; Sun, 30 Sep 2012 12:11:01 +0000 (UTC) Received: (qmail 63969 invoked by uid 500); 30 Sep 2012 12:11:01 -0000 Delivered-To: apmail-incubator-callback-dev-archive@incubator.apache.org Received: (qmail 63739 invoked by uid 500); 30 Sep 2012 12:10:59 -0000 Mailing-List: contact callback-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: callback-dev@incubator.apache.org Delivered-To: mailing list callback-dev@incubator.apache.org Received: (qmail 63710 invoked by uid 99); 30 Sep 2012 12:10:58 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 30 Sep 2012 12:10:58 +0000 X-ASF-Spam-Status: No, hits=0.3 required=5.0 tests=FREEMAIL_REPLY,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of piotr.walczyszyn@gmail.com designates 209.85.160.175 as permitted sender) Received: from [209.85.160.175] (HELO mail-gh0-f175.google.com) (209.85.160.175) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 30 Sep 2012 12:10:52 +0000 Received: by ghbz2 with SMTP id z2so1298893ghb.6 for ; Sun, 30 Sep 2012 05:10:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=HakB43cvm0ihr8jWOWktJnIR/xmwRBykUalSEtrOkYY=; b=sMKQwM0Br5DEQ0y+YIgkoG8AaohzyeLnnE+DSm49pi5zY2t35y+oHQ0BatEsTJvqyD fy3pvrJwXX3L4Lu5/6EMnp+daDO6C4NG3Zy19qwYsK4uDsYSEjNUxQpDOOBdLAkfcDUT 5lTAsDrUFgm9UQgNPlCoXz+KzuAaZ+9iOrD4zc2L7uaPD3ShqYqMMT3TG00HZFi5gOZf kIGD+czLotXYWTJ9p2/hfNWqLwUN5Jf0iQIDrD8VybGSEbJ1sbiDir8hjmOfSxEPb5/n ZX20rJsc9hdobhxno+wqxUJmN82hDAh2fZcTv7GkcYY0TqkrcQnjgWPNUqi8isfQmjC5 C9Jw== MIME-Version: 1.0 Received: by 10.236.115.41 with SMTP id d29mr12189564yhh.125.1349007031669; Sun, 30 Sep 2012 05:10:31 -0700 (PDT) Received: by 10.100.245.17 with HTTP; Sun, 30 Sep 2012 05:10:31 -0700 (PDT) In-Reply-To: References: <-8529420762969790261@unknownmsgid> Date: Sun, 30 Sep 2012 14:10:31 +0200 Message-ID: Subject: Re: Supporting multiple projects on iOS From: Piotr Walczyszyn To: callback-dev@incubator.apache.org Content-Type: text/plain; charset=ISO-8859-1 Andrew I see your point, and yes it may solve the concerns I mentioned previously, just few additional things I want to throw in: 1) I believe most of the users will download Cordova as a whole package, zipped as a distribution with all other platforms support (like it is now @ phonegap.com). This way it may not be obvious to the users what they should extract from that package to get what they really need. If I didn't have enough experience with the framework I would be really concerned if what I really need from a distribution package is only CordovaLib or maybe also other files and folders that come with the distribution like: bin, Make, Uninstall Cordova.applescript... . 2) Another thought I have is how it is handled for other platforms and if we shouldn't try to make it consistent as much as it is possible of course. I know in case of Android when you create new project it actually copies cordova.jar into project libs folder. 3) What about having additional argument in bin/create script that would allow users to decide how they want to include the framework? One option to embed the whole thing under project directory and second to have a relative reference to it. From the experience I have with the projects I worked on I wouldn't be upgrading the framework that often if everything was working fine, or I wasn't forced because of new features or some security patches. So I would definitely pick first option. 4) Lastly I just played around with Xcode and tried to relink (visually) the CordovaLib to a different path by deleting a reference from my project and adding it back again using "Add Files to MyProject" option. The only two things I had to do at the end was to add CordovaLib to Target Dependencies and to Link Binary With Libraries. This was something I didn't figure out before that is why I modified the upgrade script. I think if we had that process document well, then we wouldn't really need the upgrade script anymore ;) p. 2012/9/29 Andrew Grieve : > On Sat, Sep 29, 2012 at 4:57 AM, Piotr Walczyszyn < > piotr.walczyszyn@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 : >> > would different versions will work ok? >> > >> > On Sat, Sep 29, 2012 at 2:33 AM, Andrew Grieve >> 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 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 >> 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 >> >>> > wrote: >> >>> >> an upgrade script would be really helpful as well. >> >>> >> >> >>> >> -Mike >> >>> >> >> >>> >> On Thu, Sep 27, 2012 at 12:44 PM, Piotr Walczyszyn < >> >>> >> piotr.walczyszyn@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 : >> >>> >>> > 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.johnson@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 > >>> >>> > >> >>> >>> >> > 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 >> >>> >>