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 Sat, 29 Sep 2012 08:57:22 GMT
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.

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
View raw message