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, 27 Sep 2012 16:35:59 GMT
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.
> > >
> >
>

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