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 Sat, 29 Sep 2012 00:33:04 GMT
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