Closed GoogleCodeExporter closed 9 years ago
[deleted comment]
It's not clear if the json-framework project will be coming back or not.
If you're targeting iOS 5 or Mac OS X 10.7, then there's no need for the
external source files, as JSON parsing is built into the system and will be
used by the GData library.
As a workaround for supporting older OSes for now, you can pull the JSON
sources into a directory called JSON with
svn checkout https://github.com/stig/json-framework.git/tags/v2.3.2/Classes JSON
and put that JSON directory inside of the GData library's Source directory.
Then add the JSON source files to your project.
Original comment by grobb...@google.com
on 31 Mar 2012 at 9:21
I downloaded the JSON folder through
svn checkout https://github.com/stig/json-framework.git/tags/v2.3.2/Classes JSON
However, xcode still complains
Source/JSON/SBJSON.h: No such file or directory
It is a reasonable complaint, since the framework v2.3.2 does not come with
SBJSON.h at all.
Is there another way to find out the orignal framework used in GData? or am I
just simply doing the right thing.
Original comment by tzuyangni@gmail.com
on 2 Apr 2012 at 12:45
For now, you'll have to replace the JSON files in the project with ones checked
out from the github repository.
Original comment by grobb...@google.com
on 2 Apr 2012 at 1:25
Issue 136 has been merged into this issue.
Original comment by grobb...@google.com
on 3 Apr 2012 at 4:45
I am the author of SBJson. The project moved to Github over 2 years ago, and
the svn checkout on google code has not been updated since. The google code
project page has been an empty shell pointing people to github for all that
time, but judging by the questions I get this doesn't seem to deter people from
trying to use the old versions from google code. Version 3.0 was released in
June 2011, and version 3.1 last month. You really should upgrade to 3.1 if you
can use ARC, or to 3.0.4 if you cannot use ARC.
Original comment by sbrautaset@gmail.com
on 3 Apr 2012 at 6:09
We have to keep the libraries used in Google's open-source projects in sync
with the versions that are used in Google's own public and internal apps. Use
of any external software in our own apps requires the we evaluate the
reliability and security of the libraries in a variety of ways, so we're
conservative about migrating to newer versions. We don't have enough engineers
to reevaluate every updated version of each open-source package.
SBJSON is used now just for backwards compatibility with older systems, so it
is not a hard dependency of our projects. We long ago found the old version
that was hosted on code.google.com to be sufficient, so have been happy to
continue relying on it for when applications are running on older systems.
Github does now offer good support for svn, so we'll probably update our
projects in subversion to pull SBJSON via svn:externals from github once we can
reconcile our internal requirements and the needs of our open-source projects.
Minimizing the number of external source files needed is a goal for our
open-source projects, though unfortunately SBJSON seems to be requiring that an
increasing number of source files be added to projects. One of the original
reasons for SBJSON's appeal was the simplicity of including its source file.
Our open-source libraries will need to support non-ARC projects for years to
come, so the ARC requirement will preclude adoption of SBJSON 3.1.
Original comment by grobb...@google.com
on 3 Apr 2012 at 8:10
Hi grobbins,
In contrast to GC the nice thing about ARC is that it actually generates the
retain/release calls for you in the binary. So you can enable it on a
file-by-file or library-by-library basis and use it in conjunction with non-ARC
code in the same project. I understand that it's difficult to find resources to
upgrade to a new version if the old one is deemed good enough. But please
understand that it's impossible for me as a single developer to support ancient
versions.
Though I sympathise with the desire to minimise the number of external
dependencies, minimising the number of source files in each external dependency
seems an ill-judged metric. That seems like a prejudice against well-structured
and maintainable code. (Although more files does not necessarily guarantee
this, I have seen more unmaintainable horrors of the monolithic variety. And I
broke my project up because it became unmaintainable as it was.)
PS: Thanks for using my library ;)
Original comment by sbrautaset@gmail.com
on 3 Apr 2012 at 9:02
The project has been updated to pull the JSON parser from the git repository.
Thanks for the issue reports.
Original comment by grobb...@google.com
on 3 Apr 2012 at 10:37
Is the problem really fixed?
I just downloaded the latest version with "svn checkout
http://gdata-objectivec-client.googlecode.com/svn/trunk/
gdata-objectivec-client-read-only"
and I still get the errors like "GData/JSON/SBJsonParser.h: No such file or
directory" with the latest version (this month). The "Headers" folder also
doesn't contain any SBJson header files.
Original comment by hiroyuki...@googlemail.com
on 9 Apr 2012 at 11:27
The change for the new pull of the parser is visible in the diff at
http://code.google.com/p/gdata-objectivec-client/source/detail?r=719
The inclusion of the new parser files in the project is visible in the diff at
http://code.google.com/p/gdata-objectivec-client/source/detail?r=720
I just confirmed this with a clean check-out and build, both of the DocsSample
example app, and of the iOS static library. The headers folder for the static
library was present in the DerivedData directory, and included the SBJson
headers.
Original comment by grobb...@google.com
on 10 Apr 2012 at 1:35
Thanks! It seems I didn't react to the github.com certificate accept question
while checking out from svn. (Default is no?) Therefore JSon-files weren't
downloaded.
Sorry for the trouble.
Original comment by hiroyuki...@googlemail.com
on 10 Apr 2012 at 8:03
Original issue reported on code.google.com by
tszm...@gmail.com
on 31 Mar 2012 at 4:54