incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian LeRoux...@brian.io>
Subject Re: Supporting multiple projects on iOS
Date Mon, 01 Oct 2012 10:32:33 GMT
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