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 Fri, 05 Oct 2012 13:56:49 GMT
Will do :)


On Thu, Oct 4, 2012 at 5:27 PM, Shazron <shazron@gmail.com> wrote:

> Awesome - thanks Andrew, now to document the new process and update the
> docs ;)
>
> On Tue, Oct 2, 2012 at 11:20 AM, 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