incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shazron <shaz...@gmail.com>
Subject Re: Supporting multiple projects on iOS
Date Thu, 04 Oct 2012 21:27:04 GMT
Awesome - thanks Andrew, now to document the new process and update the docs ;)

On Tue, Oct 2, 2012 at 11:20 AM, Andrew Grieve <agrieve@chromium.org> wrote:
> Done and done!
>
> The update_cordova_subproject script can now take in a 2nd param for the
> path to the CordovaLib project, and the create script now copies the
> CordovaLib into new projects.
>
>
>
>
> On Mon, Oct 1, 2012 at 2:13 PM, Andrew Grieve <agrieve@chromium.org> wrote:
>
>> Started a new new thread about going forward with option #2. Besides you
>> both being in favour of this option, it also aligns with the structure
>> described by https://github.com/filmaj/cordova-client, so I think it's
>> definitely the way to go :).
>>
>>
>> On Mon, Oct 1, 2012 at 6:32 AM, Brian LeRoux <b@brian.io> wrote:
>>
>>> Seems a little bit too brittle requiring users to install Cordova in order
>>> to share code they created with Cordova. (Which could cause good old
>>> fashioned path issues.) Again, would prefer libs live under the project
>>> they are dependencies for (as we do w/ Android).
>>>
>>>
>>> On Sep 29, 2012 8:32 PM, "Andrew Grieve" <agrieve@chromium.org> wrote:
>>>
>>> > On Sat, Sep 29, 2012 at 4:57 AM, Piotr Walczyszyn <
>>> > piotr.walczyszyn@gmail.com> wrote:
>>> >
>>> > > I think having a reference just to a project file doesn't solve 2
>>> > > common scenarios:
>>> > >
>>> > > 1) multi developer environment, in this case all application
>>> > > developers need to have same directory structure, so the relative path
>>> > > to CordovaLib is the same
>>> >
>>> >
>>> > > 2) CordovaLib versioning, often you want to version the framework you
>>> > > are building on top of, together with the project source code. Having
>>> > > CordovaLib under project structure makes it whole easier.
>>> > >
>>> > > p.
>>> > >
>>> >
>>> > I think this does address both of these concerns. Here's an example
>>> > directory structure with three projects and two versions of cordova:
>>> >
>>> > SourceControlRoot/
>>> > -- incubator-cordova-lib-version-2.1.0
>>> > ----- CordovaLib
>>> > ----- bin
>>> > -- incubator-cordova-lib-version-2.2.0
>>> > ----- CordovaLib
>>> > ----- bin
>>> > -- Project1
>>> > ---- Project1.xcodeproj
>>> > ---- CordovaLib-2.1.0.xcodeproj (points to files within
>>> > //incubator-cordova-lib-version-2.1.0/CordovaLib)
>>> > -- Project2
>>> > ---- Project2.xcodeproj
>>> > ---- CordovaLib-2.1.0.xcodeproj (points to files within
>>> > //incubator-cordova-lib-version-2.1.0/CordovaLib)
>>> > -- Project3
>>> > ---- Project3.xcodeproj
>>> > ---- CordovaLib-2.2.0.xcodeproj (points to files within
>>> > //incubator-cordova-lib-version-2.2.0/CordovaLib)
>>> >
>>> >
>>> > To update Project2 from CordovaLib-2.1.0 to CordovaLib-2.2.0, you would
>>> run
>>> > (from the SourceControlRoot directory):
>>> > ./incubator-cordova-lib-version-2.2.0/bin/update_cordova_subproject.sh
>>> > Project2/Project2.xcodeproj
>>> >
>>> >
>>> > Piotr - I think it would still be fair to add an optional param
>>> > to update_cordova_subproject.sh to specify which CordovaLib directory
>>> you
>>> > want it to point at. I do like this idea of having one
>>> CordovaLib.xcodeproj
>>> > file per-project though, since it means not requiring a copy of
>>> CordovaLib
>>> > into each project. The "upgrade script" in this case will just be the
>>> same
>>> > as the update_cordova_subproject.sh script, and it won't have to delete
>>> any
>>> > source files, but just the xcodeproj files.
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > > 2012/9/29 Brian LeRoux <b@brian.io>:
>>> > > > would different versions will work ok?
>>> > > >
>>> > > > On Sat, Sep 29, 2012 at 2:33 AM, Andrew Grieve <
>>> agrieve@chromium.org>
>>> > > wrote:
>>> > > >> Another options I've now thought of, and I think I like this
one
>>> the
>>> > > best
>>> > > >> :).
>>> > > >>
>>> > > >> Instead of copying the entire CordovaLib directory into each
>>> project,
>>> > > just
>>> > > >> copy the CordovaLib.xcodeproj file. This will allow each project
>>> to be
>>> > > open
>>> > > >> at the same time, since they will technically reference different
>>> > > projects,
>>> > > >> but they will all reference the same source files. To upgrade
>>> cordova
>>> > > >> versions, our update_cordova_subproject.sh script can clobber
the
>>> > > >> .xcodeproj proj file with the newer one.
>>> > > >>
>>> > > >>
>>> > > >> On Fri, Sep 28, 2012 at 6:42 AM, Brian LeRoux <b@brian.io>
wrote:
>>> > > >>
>>> > > >>> thinking a bundled upgrade cli command in all the projects
is a
>>> good
>>> > > >>> idea... something that automates whatever we document
in the
>>>  upgrade
>>> > > >>> guide
>>> > > >>>
>>> > > >>>
>>> > > >>>
>>> > > >>> On Thu, Sep 27, 2012 at 6:58 PM, Jesse <purplecabbage@gmail.com>
>>> > > wrote:
>>> > > >>> > Mis-understood some of the finer points, thanks for
the
>>> > clarification
>>> > > >>> > and patience all.
>>> > > >>> >
>>> > > >>> > I agree that option 2 makes the most sense.
>>> > > >>> >
>>> > > >>> > On Thu, Sep 27, 2012 at 9:52 AM, Mike Reinstein
>>> > > >>> > <reinstein.mike@gmail.com> wrote:
>>> > > >>> >> an upgrade script would be really helpful as
well.
>>> > > >>> >>
>>> > > >>> >> -Mike
>>> > > >>> >>
>>> > > >>> >> On Thu, Sep 27, 2012 at 12:44 PM, Piotr Walczyszyn
<
>>> > > >>> >> piotr.walczyszyn@gmail.com> wrote:
>>> > > >>> >>
>>> > > >>> >>> As I suggested in the pull request comments,
this would really
>>> > make
>>> > > >>> >>> sense to update bin/create script either
by enhancing it with
>>> > > >>> >>> additional argument to embed the CordovaLib
with newly created
>>> > > >>> >>> projects or even make this behavior a default
one.
>>> > > >>> >>>
>>> > > >>> >>> p.
>>> > > >>> >>>
>>> > > >>> >>> 2012/9/27 Andrew Grieve <agrieve@chromium.org>:
>>> > > >>> >>> > Suppose you have 5 projects that depend
on 2.1, and 3 that
>>> > > depend on
>>> > > >>> 2.0.
>>> > > >>> >>> >
>>> > > >>> >>> > One big difference between the two options
is that for the
>>> 2nd
>>> > > >>> option,
>>> > > >>> >>> > you'd have 8 copies of Cordova, whereas
for the first option
>>> > > you'd
>>> > > >>> have
>>> > > >>> >>> > only two.
>>> > > >>> >>> >
>>> > > >>> >>> > I think getting the correct workflow
set up with Xcode
>>> > workspaces
>>> > > >>> will be
>>> > > >>> >>> > quite cumbersome though, and not something
that will be easy
>>> > for
>>> > > us
>>> > > >>> to do
>>> > > >>> >>> > with tooling. We'd pretty much have
to rely on
>>> documentation to
>>> > > tell
>>> > > >>> >>> people
>>> > > >>> >>> > how to drag multiple projects into their
own workspace.
>>> > > >>> >>> >
>>> > > >>> >>> > I think maybe another key point is that
CordovaLib is really
>>> > > small,
>>> > > >>> and
>>> > > >>> >>> > will get even smaller if/when we remove
the core plugins
>>> from
>>> > > it. In
>>> > > >>> this
>>> > > >>> >>> > model, the majority of the code will
be pluginstalled into
>>> > users'
>>> > > >>> >>> projects
>>> > > >>> >>> > anyways, so it won't be a bit deal to
have a bunch of
>>> copies of
>>> > > >>> >>> CordovaLib
>>> > > >>> >>> > around.
>>> > > >>> >>> >
>>> > > >>> >>> > The model that pwalczyszyn is using
is to copy the
>>> CordovaLib
>>> > > >>> directory
>>> > > >>> >>> > into each project's directory, similar
to how we have a
>>> > "cordova"
>>> > > >>> >>> directory
>>> > > >>> >>> > that we copy into it. Taken from his
pull requests comments:
>>> > > >>> >>> >
>>> > > >>> >>> > MyProject
>>> > > >>> >>> >> -- cordova
>>> > > >>> >>> >> -- MyProject
>>> > > >>> >>> >> ---- CordovaLib
>>> > > >>> >>> >> ------ CordovaLib.xcodeproj
>>> > > >>> >>> >> ---- Plugins
>>> > > >>> >>> >> ---- Resources
>>> > > >>> >>> >> ---- ....
>>> > > >>> >>> >> -- MyProject.xcodeproj
>>> > > >>> >>> >> -- www
>>> > > >>> >>> >
>>> > > >>> >>> >
>>> > > >>> >>> > Having CordovaLib a sibling of Plugins
does make sense in
>>> this
>>> > > model
>>> > > >>> I
>>> > > >>> >>> > think. Either that, or have it up one
level.
>>> > > >>> >>> >
>>> > > >>> >>> >
>>> > > >>> >>> > To implement this, we'll need to change
our bin/create
>>> script
>>> > to
>>> > > >>> copy in
>>> > > >>> >>> > the CordovaLib directory. Not too hard.
>>> > > >>> >>> >
>>> > > >>> >>> > For upgrades, how will we address this
though? Just add
>>> > > documentation
>>> > > >>> >>> > telling users to delete the old directory
and copy over the
>>> new
>>> > > one?
>>> > > >>> The
>>> > > >>> >>> > steps would be:
>>> > > >>> >>> > cp -r path/to/new/cordova/CordovaLib
MyProject
>>> > > >>> >>> > path/to/new/cordova/bin/update_cordova_subproject
MyProject
>>> > > >>> >>> > MyProject/CordovaLib
>>> > > >>> >>> >
>>> > > >>> >>> >
>>> > > >>> >>> >
>>> > > >>> >>> >
>>> > > >>> >>> >
>>> > > >>> >>> >
>>> > > >>> >>> >
>>> > > >>> >>> >
>>> > > >>> >>> > On Thu, Sep 27, 2012 at 10:16 AM, Dave
Johnson <
>>> > > >>> dave.c.johnson@gmail.com
>>> > > >>> >>> >wrote:
>>> > > >>> >>> >
>>> > > >>> >>> >> +1
>>> > > >>> >>> >>
>>> > > >>> >>> >> On Thursday, September 27, 2012,
Mike Reinstein wrote:
>>> > > >>> >>> >>
>>> > > >>> >>> >> > Agree on all points with Brian.
>>> > > >>> >>> >> >
>>> > > >>> >>> >> > On Thu, Sep 27, 2012 at 6:34
AM, Brian LeRoux <
>>> b@brian.io
>>> > > >>> >>> <javascript:;>>
>>> > > >>> >>> >> > wrote:
>>> > > >>> >>> >> >
>>> > > >>> >>> >> > > > Global dependancies?
It's a library, why would you
>>> not
>>> > be
>>> > > >>> >>> dependent
>>> > > >>> >>> >> on
>>> > > >>> >>> >> > > it?
>>> > > >>> >>> >> > > >
>>> > > >>> >>> >> > >
>>> > > >>> >>> >> > > We're talking about global
deps vs local deps. Not
>>> whether
>>> > > or
>>> > > >>> not
>>> > > >>> >>> >> you'll
>>> > > >>> >>> >> > > have a dependency!
>>> > > >>> >>> >> > >
>>> > > >>> >>> >> > >
>>> > > >>> >>> >> > > > Standardize on the
apis and not the files.
>>> > > >>> >>> >> > > >
>>> > > >>> >>> >> > >
>>> > > >>> >>> >> > > Uh, ok sure, not sure
I understand?
>>> > > >>> >>> >> > >
>>> > > >>> >>> >> > > It only takes a few weeks
of ruby (and/or python) dev
>>> to
>>> > see
>>> > > >>> where
>>> > > >>> >>> >> global
>>> > > >>> >>> >> > > packages become ambushes
for epic fail. Node learned
>>> from
>>> > > this
>>> > > >>> and
>>> > > >>> >>> >> > > explicitly created lexically
scoped packages. Typically
>>> > > when you
>>> > > >>> >>> ship
>>> > > >>> >>> >> > > projects you want to have
the dependencies bundled to
>>> > > minimize
>>> > > >>> >>> issues.
>>> > > >>> >>> >> > >
>>> > > >>> >>> >> > > See http://en.wikipedia.org/wiki/Dependency_hell
>>> > > >>> >>> >> > >
>>> > > >>> >>> >> > >
>>> > > >>> >>> >> > > Not to mention the extra
complexity of #2, and multiple
>>> > out
>>> > > of
>>> > > >>> sync
>>> > > >>> >>> >> > > > project issues.
>>> > > >>> >>> >> > > >
>>> > > >>> >>> >> > >
>>> > > >>> >>> >> > > I do not see where this
creates complexity. It reduces
>>> > it. I
>>> > > >>> have a
>>> > > >>> >>> >> > project
>>> > > >>> >>> >> > > that I want up-do-date.
It has a dependency on 2.1.0. I
>>> > have
>>> > > >>> another
>>> > > >>> >>> >> > > project I do not want
to update running 2.0.0: no
>>> problem.
>>> > > If I
>>> > > >>> >>> have a
>>> > > >>> >>> >> > > global dependency: problem!
>>> > > >>> >>> >> > >
>>> > > >>> >>> >> > > The other issue here is
the requirement of having your
>>> > > library
>>> > > >>> >>> >> > > a separate concern for
the end user project. When I
>>> want
>>> > to
>>> > > >>> build a
>>> > > >>> >>> >> > project
>>> > > >>> >>> >> > > from another repo it requires
me to install the correct
>>> > > version
>>> > > >>> of
>>> > > >>> >>> the
>>> > > >>> >>> >> > > dependency. With option
2 the library is a part of the
>>> > > project
>>> > > >>> and
>>> > > >>> >>> no
>>> > > >>> >>> >> > > installer step is required.
Again: reduced complexity.
>>> > > >>> >>> >> > >
>>> > > >>> >>> >> > >
>>> > > >>> >>> >> > >
>>> > > >>> >>> >> > > I originally moved the
codebase to a library and
>>> created
>>> > the
>>> > > >>> >>> template
>>> > > >>> >>> >> > > > over 2 years ago,
so I may be blind to the benefits
>>> of
>>> > #2,
>>> > > >>> but to
>>> > > >>> >>> me
>>> > > >>> >>> >> > > > this makes our library
become a boilerplate... am I
>>> > wrong?
>>> > > >>> >>> >> > > >
>>> > > >>> >>> >> > >
>>> > > >>> >>> >> > > Do not see how this is
related either.
>>> > > >>> >>> >> > >
>>> > > >>> >>> >> >
>>> > > >>> >>> >>
>>> > > >>> >>>
>>> > > >>> >
>>> > > >>> >
>>> > > >>> >
>>> > > >>> > --
>>> > > >>> > @purplecabbage
>>> > > >>> > risingj.com
>>> > > >>>
>>> > >
>>> >
>>>
>>
>>

Mime
View raw message