incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Piotr Walczyszyn <piotr.walczys...@gmail.com>
Subject Re: Supporting multiple projects on iOS
Date Thu, 27 Sep 2012 16:58:31 GMT
Well, for upgrades the modified bin/update_cordova_subproject that
I've sent pull request with could work. Only the users would have to
copy CordovaLib to their projects directory.

p.


2012/9/27 Mike Reinstein <reinstein.mike@gmail.com>:
> 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.
>> >> > >
>> >> >
>> >>
>>

Mime
View raw message