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 Sat, 29 Sep 2012 08:21:53 GMT
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
View raw message