Supporting multiple projects on iOS

[Andrew Grieve <ag...@google.com>]

There are a lot of users that are not loving the fact that Xcode can't open
two different projects that include the same sub-project (mostly on the
phonegap google group).

This is something that worked before the move to a subproject in 2.0.0.

We've also got an outstanding pull request:
https://github.com/apache/incubator-cordova-ios/pull/52

Which addresses bug: https://issues.apache.org/jira/browse/CB-1526

So... I'm hoping we can a bit of a discussion of how to address these
concerns.

Work-arounds I can think of:
1. Encourage users to use XCode workspaces so that multiple projects can be
open at the same time that use the *same* version of CordovaLib. We could
change our project template to use a workspace, but that just has them end
up with multiple workspaces they can't open at the same time...

2. Copy the entire CordovaLib directory into their project, so that each
project uses a different copy of CordovaLib.

Re: Supporting multiple projects on iOS

[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

[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

[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

[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

[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

[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

[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
> > > >>>
> > >
> >
>

Re: Supporting multiple projects on iOS

[Brian LeRoux <b...@brian.io>]

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

[Piotr Walczyszyn <pi...@gmail.com>]

Andrew I see your point, and yes it may solve the concerns I mentioned
previously, just few additional things I want to throw in:

1) I believe most of the users will download Cordova as a whole
package, zipped as a distribution with all other platforms support
(like it is now @ phonegap.com). This way it may not be obvious to the
users what they should extract from that package to get what they
really need. If I didn't have enough experience with the framework I
would be really concerned if what I really need from a distribution
package is only CordovaLib or maybe also other files and folders that
come with the distribution like: bin, Make, Uninstall
Cordova.applescript... .

2) Another thought I have is how it is handled for other platforms and
if we shouldn't try to make it consistent as much as it is possible of
course. I know in case of Android when you create new project it
actually copies cordova.jar into project libs folder.

3) What about having additional argument in bin/create script that
would allow users to decide how they want to include the framework?
One option to embed the whole thing under project directory and second
to have a relative reference to it. From the experience I have with
the projects I worked on I wouldn't be upgrading the framework that
often if everything was working fine, or I wasn't forced because of
new features or some security patches. So I would definitely pick
first option.

4) Lastly I just played around with Xcode and tried to relink
(visually) the CordovaLib to a different path by deleting a reference
from my project and adding it back again using "Add Files to
MyProject" option. The only two things I had to do at the end was to
add CordovaLib to Target Dependencies and to Link Binary With
Libraries. This was something I didn't figure out before that is why I
modified the upgrade script. I think if we had that process document
well, then we wouldn't really need the upgrade script anymore ;)

p.


2012/9/29 Andrew Grieve <ag...@chromium.org>:
> 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

[Andrew Grieve <ag...@chromium.org>]

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

[Piotr Walczyszyn <pi...@gmail.com>]

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.

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

[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

[Andrew Grieve <ag...@chromium.org>]

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

[Brian LeRoux <b...@brian.io>]

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

[Jesse <pu...@gmail.com>]

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

[Piotr Walczyszyn <pi...@gmail.com>]

Well, for upgrades the modified bin/update_cordova_subproject that
I've sent pull request with could work. Only the users would have to
copy CordovaLib to their projects directory.

p.


2012/9/27 Mike Reinstein <re...@gmail.com>:
> 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.
>> >> > >
>> >> >
>> >>
>>

Re: Supporting multiple projects on iOS

[Mike Reinstein <re...@gmail.com>]

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.
> >> > >
> >> >
> >>
>

Re: Supporting multiple projects on iOS

[Piotr Walczyszyn <pi...@gmail.com>]

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 <da...@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.
>> > >
>> >
>>

Re: Supporting multiple projects on iOS

[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 <da...@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.
> > >
> >
>

Re: Supporting multiple projects on iOS

[Dave Johnson <da...@gmail.com>]

+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.
> >
>

Re: Supporting multiple projects on iOS

[Mike Reinstein <re...@gmail.com>]

Agree on all points with Brian.

On Thu, Sep 27, 2012 at 6:34 AM, Brian LeRoux <b...@brian.io> 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.
>

Re: Supporting multiple projects on iOS

[Brian LeRoux <b...@brian.io>]

> 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.

Re: Supporting multiple projects on iOS

[Jesse MacFadyen <pu...@gmail.com>]

Option 1

Global dependancies? It's a library, why would you not be dependent on it?
Standardize on the apis and not the files.

Not to mention the extra complexity of #2, and multiple out of sync
project issues.

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?

Cheers,
  Jesse



On 2012-09-26, at 8:55 AM, Mike Reinstein <re...@gmail.com> wrote:

> +1 on this. I'm assuming doing this also means being able to upgrade
> projects independently of each other?
>
> -Mike
>
> On Wed, Sep 26, 2012 at 11:02 AM, Brian LeRoux <b...@brian.io> wrote:
>
>> Option #2 makes the most sense to me. Global dependencies tend to fall
>> into the Bad Idea category from my perspective.
>>
>> On Wed, Sep 26, 2012 at 4:38 PM, Andrew Grieve <ag...@google.com> wrote:
>>> There are a lot of users that are not loving the fact that Xcode can't
>> open
>>> two different projects that include the same sub-project (mostly on the
>>> phonegap google group).
>>>
>>> This is something that worked before the move to a subproject in 2.0.0.
>>>
>>> We've also got an outstanding pull request:
>>> https://github.com/apache/incubator-cordova-ios/pull/52
>>>
>>> Which addresses bug: https://issues.apache.org/jira/browse/CB-1526
>>>
>>> So... I'm hoping we can a bit of a discussion of how to address these
>>> concerns.
>>>
>>> Work-arounds I can think of:
>>> 1. Encourage users to use XCode workspaces so that multiple projects can
>> be
>>> open at the same time that use the *same* version of CordovaLib. We could
>>> change our project template to use a workspace, but that just has them
>> end
>>> up with multiple workspaces they can't open at the same time...
>>>
>>> 2. Copy the entire CordovaLib directory into their project, so that each
>>> project uses a different copy of CordovaLib.
>>

Re: Supporting multiple projects on iOS

[Mike Reinstein <re...@gmail.com>]

+1 on this. I'm assuming doing this also means being able to upgrade
projects independently of each other?

-Mike

On Wed, Sep 26, 2012 at 11:02 AM, Brian LeRoux <b...@brian.io> wrote:

> Option #2 makes the most sense to me. Global dependencies tend to fall
> into the Bad Idea category from my perspective.
>
> On Wed, Sep 26, 2012 at 4:38 PM, Andrew Grieve <ag...@google.com> wrote:
> > There are a lot of users that are not loving the fact that Xcode can't
> open
> > two different projects that include the same sub-project (mostly on the
> > phonegap google group).
> >
> > This is something that worked before the move to a subproject in 2.0.0.
> >
> > We've also got an outstanding pull request:
> > https://github.com/apache/incubator-cordova-ios/pull/52
> >
> > Which addresses bug: https://issues.apache.org/jira/browse/CB-1526
> >
> > So... I'm hoping we can a bit of a discussion of how to address these
> > concerns.
> >
> > Work-arounds I can think of:
> > 1. Encourage users to use XCode workspaces so that multiple projects can
> be
> > open at the same time that use the *same* version of CordovaLib. We could
> > change our project template to use a workspace, but that just has them
> end
> > up with multiple workspaces they can't open at the same time...
> >
> > 2. Copy the entire CordovaLib directory into their project, so that each
> > project uses a different copy of CordovaLib.
>

Re: Supporting multiple projects on iOS

[Brian LeRoux <b...@brian.io>]

Option #2 makes the most sense to me. Global dependencies tend to fall
into the Bad Idea category from my perspective.

On Wed, Sep 26, 2012 at 4:38 PM, Andrew Grieve <ag...@google.com> wrote:
> There are a lot of users that are not loving the fact that Xcode can't open
> two different projects that include the same sub-project (mostly on the
> phonegap google group).
>
> This is something that worked before the move to a subproject in 2.0.0.
>
> We've also got an outstanding pull request:
> https://github.com/apache/incubator-cordova-ios/pull/52
>
> Which addresses bug: https://issues.apache.org/jira/browse/CB-1526
>
> So... I'm hoping we can a bit of a discussion of how to address these
> concerns.
>
> Work-arounds I can think of:
> 1. Encourage users to use XCode workspaces so that multiple projects can be
> open at the same time that use the *same* version of CordovaLib. We could
> change our project template to use a workspace, but that just has them end
> up with multiple workspaces they can't open at the same time...
>
> 2. Copy the entire CordovaLib directory into their project, so that each
> project uses a different copy of CordovaLib.