incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Becky Gibson <gibson.be...@gmail.com>
Subject Re: Supporting multiple projects on iOS
Date Tue, 02 Oct 2012 19:30:04 GMT
Ok, I guess one can't be slow in responding to these threads.  I would have
preferred to get Shaz's input on these changes as he is most aware of the
issues and for the reasons why things have been done this way.   I guess a
change / build script isn't that hard to change if he has issues when he
returns.

-becky

On Tue, Oct 2, 2012 at 2:20 PM, Andrew Grieve <agrieve@chromium.org> wrote:

> Done and done!
>
> The update_cordova_subproject script can now take in a 2nd param for the
> path to the CordovaLib project, and the create script now copies the
> CordovaLib into new projects.
>
>
>
>
> On Mon, Oct 1, 2012 at 2:13 PM, Andrew Grieve <agrieve@chromium.org>
> wrote:
>
> > 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