Superbil / gdata-objectivec-client

Automatically exported from code.google.com/p/gdata-objectivec-client
Other
1 stars 0 forks source link

Failed to checkout the source #135

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
It failed at asking password for the 'json-framework':

$ svn checkout http://gdata-objectivec-client.googlecode.com/svn/trunk/ 
gdata-objectivec-client-read-only

Fetching external item into 
'gdata-objectivec-client-read-only/Source/HTTPFetcher'
Checked out external at revision 100.

Fetching external item into 'gdata-objectivec-client-read-only/Source/OAuth2'
Checked out external at revision 82.

Authentication realm: <http://json-framework.googlecode.com:80> Google Code 
Subversion Repository
Password for 'xxx': ..

And currently you will see a 403 error when you visit this page: 
http://code.google.com/p/json-framework/

Original issue reported on code.google.com by tszm...@gmail.com on 31 Mar 2012 at 4:54

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
Issue 136 has been merged into this issue.

Original comment by grobb...@google.com on 3 Apr 2012 at 4:45

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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