incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: Supporting multiple projects on iOS
Date Tue, 02 Oct 2012 18:20:25 GMT
Done and done!

The update_cordova_subproject script can now take in a 2nd param for the
path to the CordovaLib project, and the create script now copies the
CordovaLib into new projects.




On Mon, Oct 1, 2012 at 2:13 PM, Andrew Grieve <agrieve@chromium.org> wrote:

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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message