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

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