Announcing Eclipse Labs

Many of us here at Google, along with the open source community, use the Eclipse IDE when we develop for Android, App Engine, and Google Chrome. We also have a lot of Google engineers that use Eclipse to build our own internal products. So, when the Eclipse Foundation approached us with an idea to encourage the Eclipse ecosystem, we were very happy to help.

Today, we’re excited to announce the result of our collaboration: a Beta version of Eclipse Labs powered by Google Project Hosting, a single place where anyone can start and maintain their open source projects based on the Eclipse platform with just a few clicks.

The goal of Eclipse Labs is to improve the visibility of unofficial add-on projects. We hope that this will help Eclipse users find those projects quickly and that it will help popular projects get on the path to becoming Eclipse Foundation projects. For more information, see the Eclipse Foundation’s blog post.

To get this community started, we’re eager to seed Eclipse Labs with Eclipse add-on projects currently on Google Code. If you have an add-on for Eclipse that you would like to move to Eclipse Labs from Google Code, please let us know by filing a migration request.

Here are a few projects that have already migrated:

• Workspace Mechanic - Workspace Mechanic for Eclipse
• Project Hosting Connector for Mylyn - Eclipse plug-in for Google Project Hosting issue tracker

Let us know what you think in our developer forum and if you’re attending Google I/O, be sure to drop by the Developer Sandbox for Eclipse or visit the Google Project Hosting team during office hours.

By Ali Pasha, Product Manager, Google Project Hosting

Faster Subversion Hosting for Project Hosting on Google Code

When we launched our first Subversion-on-Bigtable service in 2006 our goal was to scale to support hundreds of thousands of projects, with the idea that we could continue to improve the service over time. A year ago, however, we realized that we would have to rebuild our Subversion service to make dramatic improvements in performance. So, we did what we had to do: we rebuilt our service from the ground up, focusing on speed and reliability.

We are now happy to announce that we have rolled out our new service to all our Subversion users. As a result, most common Subversion operations are about 3 times faster than they used to be.

One of the features of Subversion's HTTP-based protocol is that anyone can browse repositories through a normal web browser. Many open source projects hosted on Google Code use this feature to host websites for their project or post the latest versions of their software. We didn't anticipate how popular this would be when we designed our first Subversion service, but our new system has special optimizations for browser access. Latency for these pages are much lower and international users will see a dramatic improvement. We also set the appropriate caching headers, which can be manually controlled with the google-cache-control Subversion property.

To improve our reliability, our new service now has a custom replication system based on the Paxos algorithm. Whenever you make a change to your repository, the new data is now copied to several different data centers before our service reports that the commit has succeeded --- so you can code in peace knowing that your data is stored safely in multiple locations.

If you haven’t already, we encourage you to try out our new Subversion service and let us know what you think.

By Jon Trowbridge and Tony Zale, Google Project Hosting

Happy 5th Birthday Google Code!

How time flies! It was about five years ago that we launched Google Code to the world. When we launched Google Code, we wanted to make code.google.com a great resource where developers could learn about our vision for open source and the open web. We started in 2005 with a handful of our own open source projects, links to just eight APIs and an announcement of the first ever Google Summer of Code, our now-annual program that introduces university students to open source development. By 2006 our API list had grown to 21, in 2007 there were 37, and today our collection of more than 60 APIs receive over four billion hits per day. Check out the changing face of Google Code below -- from 2005, 2007 to the present.



With the meaning of open in mind, Google Code set out to foster best practices in developer documentation, build a community around web and open source development and demonstrate the power of Google technologies. Over the past five years code.google.com has come a long way from eight APIs, maturing into a destination for developers to explore our growing family of APIs and developer products, whether they speed up the web, alleviate cross-browser issues, make hosting web applications easy and scalable or make the web a more social place.

Google Code has also become an interactive place to share ideas. Not only can developers prototype their work in a Code Playground, they can also use Project Hosting on Google Code, a fast, reliable and easy way for developers to host all kinds of open source projects. Today, there are more than 240,000 projects registered, with commits coming in at about 17,000 per day...about 1 every 5 seconds. We also host 800 open source projects of our own, including four projects (Android, Chrome, Chrome OS and GWT) with over a million lines of code each.

It’s been an amazing five years, but there’s still a lot of work ahead. We’re dedicated to helping the developer and open source communities thrive in as many ways as we can. To celebrate our birthday and thank everyone for supporting code.google.com over the years we’re rolling out a new, faster Subversion server, which will double the source code storage for Project Hosting on Google Code from 1GB to 2GB. Happy coding!

By Chris DiBona, Open Source Programs Manager

Mercurial Now Available to All Open Source Projects

About a month ago we announced Mercurial support for early testers. Today, we are happy to announce that all Project Hosting users can create a new Mercurial project and convert their existing projects from Subversion to Mercurial. 

We also want to thank the projects that helped us test support for Mercurial. Projects like Clojure-Dev and Spice of Creation helped us discover new usage patterns and fix several unforeseen issues. Unlike our mature Subversion implementation, there are still a few issues/features that we are working on. 

We therefore encourage everyone to be familiar with what is supported before picking Mercurial.

Please let us know if you have any feedback or find any issues. If you're coming to Google I/O, be sure to come meet us in person and hear our talk about Mercurial on Bigtable this Thursday at 3:45pm-4:45pm in Moscone West - Room 5. We have Mercurial SWAG!

By Ali Pasha, Google Code Team

Closing the Loop - Version Control and Issue Tracker Integration

If you are a developer on an open source project hosted on Google Code, and you are committing a change that fixes a known defect or adds a requested enhancement, you will want to update the associated issue. You could do that by first committing the change, and then using the web UI to update the issue. But, now there is a more convenient way to close the loop: you can update an issue by putting an issue tracker command in your commit-log message.

There are commit-log commands to:

• Easily set an issue's status to Fixed.
• Update any aspect of the issue, and add a comment.
• Enter a new issue.
• Request a code review.

The most common case is to close the issue as Fixed. For example, your commit-log message might be:


Now, your commit links to the issues, the issues are closed, and a back-link is added from each issue to the revision.

Updating an issue, without closing it, can be useful when a commit partially resolves the issue. And, opening a new issue is useful when you know that follow-up work will be needed. For more information and examples, see our issue tracker documentation.

By Jason Robbins, Google Code Team

Mercurial support for Project Hosting on Google Code

We are happy to announce that Project Hosting on Google Code now supports the Mercurial version control system in addition to Subversion. This is being initially rolled out as a preview release to a few invited users on a per-project basis, so that we can iron out the kinks before making this available to the general public.


Mercurial, like Git and Bazaar, is a distributed version control system (DVCS) that enables developers to work offline and define more complex workflows such as peer-to-peer pushing/pulling of code. It also makes it easier for outside contributors to contribute to projects, as cloning and merging of remote repositories is really easy.

While there were several DVCSs that we could support, our decision to support Mercurial was based on two key reasons. The primary reason was to support our large base of existing Subversion users that want to use a distributed version control system. For these users we felt that Mercurial had the lowest barrier to adoption because of its similar command set, great documentation (including a great online book), and excellent tools such as Tortoise Hg. Second, given that Google Code's infrastructure is built for HTTP-based services, we found that Mercurial had the best protocol and performance characteristics for HTTP support. For more information, see our analysis.

If you would like to help us launch Mercurial and to try out the features as an invited user, please fill out the following form. We are currently looking for active projects with more than two users that are willing to try out Mercurial and work with us to identify issues and resolve them. For projects that plan on migrating from Subversion, see our conversion docs for the steps required for this process.

Our implementation of Mercurial is built on top of Bigtable, making it extremely scalable and reliable just like our Subversion on Bigtable implementation. For more information on our Mercurial implementation, we will have a TechTalk at Google IO that will be led by Jacob Lee, one of the core engineers working on Mercurial support. Let us know if you plan on attending and we'll give you access to Mercurial ahead of the talk.

By David Baum, Software Engineer

Custom Logos for Open Source Projects

Open source projects now have customizable logos! You can use this to maintain consistency with your other websites or just for fun. Here's an example of a project with its own logo. To update the logo on your project, click on the Administer tab (as long as you're a project owner) and upload an image. It will automatically be resized. You can switch back the default logo or upload a new logo at any point.

Google projects such as Chromium will retain the large Google logo.

For other notable changes, see our groups post.

By Andy Chu, Software Engineer, Google Code

Staying up to date with Google Code

By Ali Pasha & Jacob Moon, Google Code

As the number of developers and projects have grown on Google Code, we've started thinking about how to get projects to learn from and work with each other. Today, we're happy to announce that we have made a few steps towards that goal.

First, we've added user update streams to make it easy to see what a particular user has been doing across Project hosting on Google Code. As an example, take a look at Ben Collins-Sussman's activities on his profile page. Ben works on Google Code, but it's obvious that he has other interests as well.

In addition, tracking open source projects and other developers is as easy as starring a project or a developer profile. Starring a project or developer adds a link in your new "Starred Projects" and "Starred Developers" section of your profile page, making it really easy to find those projects or developers again. Starred projects are also added to the new "My projects" drop-down, which makes it easy to navigate to a project from anywhere on the site.

Once a project or a developer is starred, all updates from starred projects and developers can be tracked by looking at your personalized updates.

For those that prefer to use their feed reader, use the following new feeds:

• Updates for a user - http://code.google.com/feeds/u/{username}/updates/user/basic
• Developers a user is tracking - http://code.google.com/feeds/u/{username}/updates/projects/basic
• Projects a user is tracking - http://code.google.com/feeds/u/{username}/updates/developers/basic

As always, we look forward to your feedback.

Project Hosting Upgraded to Subversion 1.5

By Ben Collins-Sussman, Google Code Project Hosting

We're pleased to announce that the Subversion component of Google Code Project Hosting has been upgraded to version 1.5. What does this mean to users? If you're using a Subversion 1.5 client, you can now take advantage of Subversion's improved "merge tracking" feature to manage branches.

Prior to Subversion 1.5, branching wasn't very friendly to users. A developer had to manually keep track of the revision from which a branch was copied. She also had to keep track of exactly which changes had been merged into a branch already (to avoid repeated application of changesets), and to always specify the exact range of revisions to merge next. Merging a branch back to trunk was even more difficult, since it required comparing two precise URLs in a very specific way.

With improved merge-tracking, users never have to type a single revision number. Here's a basic example of branch workflow.

1. Make a branch for your experimental work:
   $ cd trunk-working-copy
$ svn cp trunkURL branchURL
$ svn switch branchURL



2. Work on the branch for a while:
   # ...edit files
$ svn commit
# ...edit files
$ svn commit



3. Sync your branch with the trunk, so it doesn’t fall behind:
   $ svn merge trunkURL
--- Merging r3452 through r3580 into '.':
U button.c
U integer.c
...
$ svn commit



4. Repeat the prior two steps until you’re done coding.


5. Merge your branch back into the trunk:
   $ svn switch trunkURL
$ svn merge --reintegrate branchURL
--- Merging differences between repository URLs into '.':
U button.c
U integer.c
...
$ svn commit

For a more detailed discussion of merge-tracking (and its limitations), see chapter 4 of the online Subversion Book. Live in fear of branches no more!

Playing around with Google's AJAX APIs

By Ben Lisbakken, Developer Programs Engineer

For me, documentation isn't always enough to learn about APIs; I need examples that I can play with. That's why I started a fun project recently--a tool for teaching developers how to use Google's JavaScript APIs: the AJAX API Playground. I have been working on this in my 20% time and today I am proud to announce that we are launching the AJAX API Playground as the official way that Google will show JavaScript samples!

The AJAX API Playground is currently loaded with over 170 samples for 8 Google JavaScript APIs (Maps, Search, Feeds, Calendar, Visualization, Language, Blogger, Libraries and Earth) that you can edit and run to help you explore what Google's APIs have to offer. There are also save and export features. The save feature allows you to hold onto an edited sample so you can continue working on it later, while export lets you modify a sample and publish the code to a permanent url.

As the AJAX API Playground is built on App Engine, you can create your own App Engine instance to show off your code samples. The code is open sourced under an Apache 2.0 license and uses several open source libraries and tools, including jQuery, jQuery UI, YUI Compressor, and CodeMirror. You can find the code on Google Project Hosting and learn about adding samples on the project wiki.

Stay tuned for more samples for more APIs. Enjoy!

Happy holidays from Google Code!

By Matt Hansen, Google Developer Programs

At Google Code, we are getting into the holiday spirit early. To thank open source developers for their support, I'm happy to announce that we are giving every project on Google Code a whole lot more quota!

We're increasing the maximum file sizes from 20MB to 40MB, Subversion quotas from 100MB to 1GB, and download quotas from 100MB to 2GB.

Happy holidays!

P.S. If you need more space, let us know!

Adding some style to the wiki on Google Code

By Nathan Ingersoll and Jason Robbins, Google Code

Based on user feedback, we added a few highly requested features to the project hosting wiki on Google Code.

To improve navigation from one wiki page to another, we added side navigation across wiki pages (e.g doctype docs). You can add a 'Wiki sidebar' by specifying the wiki file that describes your side navigation in the Administration tab under Wiki settings.

To help navigate a wiki page, we added the ability to add a generated table of contents. To add a table of contents, just copy the following syntax to your wiki page.

<wiki:toc max_depth="1" />

Finally, to improve the style of your wiki pages we have added some html support. For more information on what html is supported, take a look at the documentation.

As always, we look forward to your feedback.

Introducing Content Licenses on Google Code

By DeWitt Clinton, Google Developer Programs

The Google Code team is pleased to announce the availability of content licenses for projects hosted on code.google.com. Projects owners may now select from either the Creative Commons Attribution license or the Creative Commons Attribution-Share Alike license to indicate the terms under which their non-source code materials may be distributed.



While this may seem like a minor change, it reflects the continued evolution of our mission to support best practices in open source software development.  As the open web increasingly relies on protocols and formats that reach beyond source code, we encourage authors to apply an explicit copyright license to the data, documentation, and related media that complements their work.

Please join us in the project hosting discussion group if you have any questions.

New feeds for Project hosting on Google Code

By Andy Chu, Google Code Team

We get a lot of feedback on Google Code and one of the biggest requests have been for feeds (as you can see in issue 8, issue 131, or issue 190). Therefore, I'm happy to announce that we now have Atom feed available for you to track issues, downloads, Subversion changes, and Wiki updates.

As an example, you can take a look at feeds for Google Web Toolkit:

• Issues feed at http://code.google.com/feeds/p/google-web-toolkit/issueupdates/basic
• Downloads feed at http://code.google.com/feeds/p/google-web-toolkit/downloads/basic
• Subversion changes feed at http://code.google.com/feeds/p/google-web-toolkit/svnchanges/basic
• Wiki changes feed at http://code.google.com/feeds/p/google-web-toolkit/svnchanges/basic?path=/wiki/

For the SVN changes feed you can add '?path=/path/' to the end of the url to filter the changes by path -- for example, '?path=/trunk/' or '?path=/wiki/'. Simply substitute 'google-web-toolkit' for your project to see your feeds.

As always, if you have any feedback please do not hesitate to let us know.

SSL Certificate Renewal for Project Hosting on Google Code

By Ben Collins-Sussman, Open Source Team

If you have open source projects hosted on Google Code, you may have noticed that the SSL certificate changed for the googlecode.com domain. (The old certificate expired, and a new one was generated.) In particular, your Subversion client may have yelled about the certificate not being recognized:

Error validating server certificate for
'https://projectname.googlecode.com:443':
- The certificate is not issued by a trusted authority. Use the
 fingerprint to validate the certificate manually!
Certificate information:
- Hostname: googlecode.com
- Valid: from Wed, 28 May 2008 16:48:13 GMT until Mon, 21 Jun 2010 14:09:43 GMT
- Issuer: Certification Services Division, Thawte Consulting cc, Cape
Town, Western Cape, ZA
- Fingerprint: b1:3a:d5:38:56:27:52:9f:ba:6c:70:1e:a9:ab:4a:1a:8b:da:ff:ec
(R)eject, accept (t)emporarily or accept (p)ermanently?

Just like a web browser, your Subversion client needs to know whether or not you trust particular SSL certificates coming from servers. You can verify the certificate using the fingerprint above, or you can choose to permanently accept the certificate, whichever makes you feel most comfortable. To permanently accept the certificate, you can simply choose the (p)ermanent option, and Subversion will trust it forever.

Thawte is a large certifying authority, and it's very likely that the OpenSSL libraries on your computer automatically trust any certificate signed by Thawte. However, if you want your Subversion client to inherit that same level of automatic trust, you'll need to set an option in your ~/.subversion/servers file:

[global]
ssl-trust-default-ca = true

If you set this option, then your client will never bug you again about any certificate signed by the "big" authorities.

Happy hacking!

Using Git with Google Code Project Hosting

By Benjamin Lynn, Google Developer Programs

Git is a popular member of the latest generation of version control systems. Learn why at our Open Source Blog, where we show how to use Git with Google Code Project Hosting.

Come on over, the Open Source Programs Office has its own blog

By Chris DiBona, Open Source Team

When we first launched code.google.com (webarchive), it was largely a site for documenting our open source activities and had some details about Google's supported APIs and file formats. In the ensuing 3 years, code has grown to encompass protocol documentation, project hosting and even a mobile operating system. Similarly, the activities of the Open Source Team have grown from simple license compliance to the aforementioned hosting, releasing massive amounts of code and introducing student programs like the Summer of Code and its high school cousin, the Highly Open Participation Contest. Since we've grown so much, we felt it was well past time to spin off a blog that specifically covers the open source activities of the company. So that's just what we've done. Come check it out, and if you like, subscribe!

ZXing 1d/2d Barcode decoding source code released

By Sean Owen, Google Print Ads Team

Recently in the New York Times, we placed a small graphic as part of a Google Print Ad. You aren't looking at one of those eye focus games (It's a sailboat! Or a shark!) but a two-dimensional barcode. Those of us who already know what it is pulled out our phones and "clicked" it with the camera, and were connected to the advertiser's web site. "Wha?", you say? See http://www.google.com/printads/barcode. While this kind of thing has been a common sight in Asia for years, this ad is one of many signs that the technology is arriving in Europe and North America.

But Advertising is only part of the story here. Engineering is also involved and we want to improve the quality and availability of barcode reader software available to developers and end users. So today I would like to announce the "ZXing" (from: "zebra crossing") project, an open-source, Java, multi-format 1D/2D barcode reader which can be built into a reader application for Java and Java ME -- and later, Android.

This project began as a 20% project and is not yet complete, so opening it up is a bit of an experiment. It's not yet the Best Barcode Reader Ever, but it's looking pretty good. For now we want to find those those who can make use of and help improve what's here, so that those good ideas are shared to all developers and everybody wins.

Developers can find the ZXing project on Google Code, and we hope you'll join us on our Google Group and tell us about what you like and don't like about the code.

Class projects and science on Google Code

Posted by Brian Fitzpatrick, Open Source Team

I'm always tickled when someone finds a creative use for one of our products that never even occurred to me. So when George K. Thiruvathukal told me that he is having his Open Source Practicum students use Google Code to host their projects for his class this semester, I had one of those "Why of course!" moments.

George is a Computer Science professor at Loyola University of Chicago (my alma mater!) and he felt that using Google Code would be an ideal way to introduce his students to open source best practices, software development tools, and collaborative software development at the same time--a perfect match for a class on writing open source software. He also had his students label their projects with comp412.cs.luc.edu, so he just has to search for label:comp412.cs.luc.edu on Google Code and he can quickly find out what his students have been up to (although maybe that's not so good if anyone has been procrastinating!).

But George had some other ideas--he also wrote an article for Computing in Science & Engineering (CiSE) magazine called Project Hosting: Expanding the Scientific Programmer's Toolbox (pdf). His article encourages scientists to consider sharing software in the manner that open source communities do, and he uses Project Hosting at Google Code as an example of how to do it.

I think that these are both great ideas and we'd love to see more classes and scientists using Google Code for their open source work. If you're using Google Code for something interesting or unusual (and open source!), be sure to let us know.