You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Brian LeRoux <b...@brian.io> on 2012/10/01 12:32:33 UTC
Re: Supporting multiple projects on iOS
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" <ag...@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 <ag...@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 <pu...@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
> > >>> > <re...@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 <ag...@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
> > >>>
> >
>
Re: Supporting multiple projects on iOS
Posted by Andrew Grieve <ag...@chromium.org>.
Will do :)
On Thu, Oct 4, 2012 at 5:27 PM, Shazron <sh...@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 <ag...@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 <ag...@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" <ag...@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
> >>> > > >>> > <re...@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 <ag...@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
> >>> > > >>>
> >>> > >
> >>> >
> >>>
> >>
> >>
>
Re: Supporting multiple projects on iOS
Posted by Shazron <sh...@gmail.com>.
Awesome - thanks Andrew, now to document the new process and update the docs ;)
On Tue, Oct 2, 2012 at 11:20 AM, Andrew Grieve <ag...@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 <ag...@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" <ag...@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 <pu...@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
>>> > > >>> > <re...@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 <ag...@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
>>> > > >>>
>>> > >
>>> >
>>>
>>
>>
Re: Supporting multiple projects on iOS
Posted by Becky Gibson <gi...@gmail.com>.
THANK YOU! I was getting tired of running both scripts!
:-b
On Thu, Oct 4, 2012 at 4:36 PM, Andrew Grieve <ag...@chromium.org> wrote:
> This has already started to annoy me as a Cordova developer since now when
> I create a new project and edit some native files, those files are not the
> ones in my git repo, but rather they are copies.
>
> So, I added a flag to the create script --shared, that will do the old
> behaviour of not using a copy. Probably this will be used only by Cordova
> devs.
>
>
> On Tue, Oct 2, 2012 at 3:30 PM, Becky Gibson <gi...@gmail.com>
> wrote:
>
> > 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 <ag...@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 <ag...@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" <ag...@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
> > > >> > > >>> > <re...@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 <ag...@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
> > > >> > > >>>
> > > >> > >
> > > >> >
> > > >>
> > > >
> > > >
> > >
> >
>
Re: Supporting multiple projects on iOS
Posted by Andrew Grieve <ag...@chromium.org>.
This has already started to annoy me as a Cordova developer since now when
I create a new project and edit some native files, those files are not the
ones in my git repo, but rather they are copies.
So, I added a flag to the create script --shared, that will do the old
behaviour of not using a copy. Probably this will be used only by Cordova
devs.
On Tue, Oct 2, 2012 at 3:30 PM, Becky Gibson <gi...@gmail.com> wrote:
> 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 <ag...@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 <ag...@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" <ag...@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
> > >> > > >>> > <re...@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 <ag...@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
> > >> > > >>>
> > >> > >
> > >> >
> > >>
> > >
> > >
> >
>
Re: Supporting multiple projects on iOS
Posted by Becky Gibson <gi...@gmail.com>.
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 <ag...@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 <ag...@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" <ag...@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
> >> > > >>> > <re...@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 <ag...@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
> >> > > >>>
> >> > >
> >> >
> >>
> >
> >
>
Re: Supporting multiple projects on iOS
Posted by Andrew Grieve <ag...@chromium.org>.
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 <ag...@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" <ag...@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 <pu...@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
>> > > >>> > <re...@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 <ag...@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
>> > > >>>
>> > >
>> >
>>
>
>
Re: Supporting multiple projects on iOS
Posted by Andrew Grieve <ag...@chromium.org>.
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" <ag...@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 <pu...@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
> > > >>> > <re...@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 <ag...@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
> > > >>>
> > >
> >
>