incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: Supporting multiple projects on iOS
Date Sat, 29 Sep 2012 19:24:33 GMT
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 <b@brian.io>:
> > would different versions will work ok?
> >
> > On Sat, Sep 29, 2012 at 2:33 AM, Andrew Grieve <agrieve@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 <purplecabbage@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.mike@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.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 <agrieve@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.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
<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
> >>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message