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 Sun, 30 Sep 2012 12:10:31 GMT
Andrew I see your point, and yes it may solve the concerns I mentioned
previously, just few additional things I want to throw in:

1) I believe most of the users will download Cordova as a whole
package, zipped as a distribution with all other platforms support
(like it is now @ phonegap.com). This way it may not be obvious to the
users what they should extract from that package to get what they
really need. If I didn't have enough experience with the framework I
would be really concerned if what I really need from a distribution
package is only CordovaLib or maybe also other files and folders that
come with the distribution like: bin, Make, Uninstall
Cordova.applescript... .

2) Another thought I have is how it is handled for other platforms and
if we shouldn't try to make it consistent as much as it is possible of
course. I know in case of Android when you create new project it
actually copies cordova.jar into project libs folder.

3) What about having additional argument in bin/create script that
would allow users to decide how they want to include the framework?
One option to embed the whole thing under project directory and second
to have a relative reference to it. From the experience I have with
the projects I worked on I wouldn't be upgrading the framework that
often if everything was working fine, or I wasn't forced because of
new features or some security patches. So I would definitely pick
first option.

4) Lastly I just played around with Xcode and tried to relink
(visually) the CordovaLib to a different path by deleting a reference
from my project and adding it back again using "Add Files to
MyProject" option. The only two things I had to do at the end was to
add CordovaLib to Target Dependencies and to Link Binary With
Libraries. This was something I didn't figure out before that is why I
modified the upgrade script. I think if we had that process document
well, then we wouldn't really need the upgrade script anymore ;)

p.


2012/9/29 Andrew Grieve <agrieve@chromium.org>:
> On Sat, Sep 29, 2012 at 4:57 AM, Piotr Walczyszyn <
> piotr.walczyszyn@gmail.com> wrote:
>
>> 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.
>>
>
> I think this does address both of these concerns. Here's an example
> directory structure with three projects and two versions of cordova:
>
> SourceControlRoot/
> -- incubator-cordova-lib-version-2.1.0
> ----- CordovaLib
> ----- bin
> -- incubator-cordova-lib-version-2.2.0
> ----- CordovaLib
> ----- bin
> -- Project1
> ---- Project1.xcodeproj
> ---- CordovaLib-2.1.0.xcodeproj (points to files within
> //incubator-cordova-lib-version-2.1.0/CordovaLib)
> -- Project2
> ---- Project2.xcodeproj
> ---- CordovaLib-2.1.0.xcodeproj (points to files within
> //incubator-cordova-lib-version-2.1.0/CordovaLib)
> -- Project3
> ---- Project3.xcodeproj
> ---- CordovaLib-2.2.0.xcodeproj (points to files within
> //incubator-cordova-lib-version-2.2.0/CordovaLib)
>
>
> To update Project2 from CordovaLib-2.1.0 to CordovaLib-2.2.0, you would run
> (from the SourceControlRoot directory):
> ./incubator-cordova-lib-version-2.2.0/bin/update_cordova_subproject.sh
> Project2/Project2.xcodeproj
>
>
> Piotr - I think it would still be fair to add an optional param
> to update_cordova_subproject.sh to specify which CordovaLib directory you
> want it to point at. I do like this idea of having one CordovaLib.xcodeproj
> file per-project though, since it means not requiring a copy of CordovaLib
> into each project. The "upgrade script" in this case will just be the same
> as the update_cordova_subproject.sh script, and it won't have to delete any
> source files, but just the xcodeproj files.
>
>
>
>
>
>
>> 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