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 Mon, 01 Oct 2012 18:13:48 GMT
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" <agrieve@chromium.org> wrote:
>
> > 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