incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Becky Gibson <gibson.be...@gmail.com>
Subject Re: Supporting multiple projects on iOS
Date Thu, 04 Oct 2012 21:44:00 GMT
THANK YOU!  I was getting tired of running both scripts!
:-b

On Thu, Oct 4, 2012 at 4:36 PM, Andrew Grieve <agrieve@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 <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