As we transition to Google Project Hosting, one thing we need to be particularly careful about is uploading of third party libraries into SVN. In general, try to avoid doing this. There are two reasons for this. First, there is limited disk space in Google Project Hosting, and its easy to burn up your space with libraries (remember that since SVN never deletes, libraries that need updating frequently will burn through your space quickly.) Second, different services will often share the same library. For example, most of our Java-based services will probably want to use the Restlet framework. It is generally better to install that in one place as a developer.
To avoid uploading libraries to SVN, you can generally do one of the following alternatives:
- Instruct your developers in the installation guide to download the library to a local directory, create an environment variable called {LIBRARY}_HOME, and point to those jar files from your Eclipse classpath or Ant environment variable.
- For files that need to be in a specific location in your project, such as GWT, download the GWT to a local directory, then copy the relevant subdirectories into your project.
Binary distributions of releases is a different situation. In that case, we will typically want to bundle the libraries into the binary distribution. That will cause its own difficulties, since Google Project Hosting limits us to 10MB files for the download section, but we'll cross that bridge when we come to it.
2 comments:
The pros of avoiding third party libraries are obvious. But I am thinking of the cons. We could end up with dependency conflict someday. For instance, Eclipse 3.3 might not be appropriate for building current Eclipse sensor. If a person wants to build the Eclipse sensor, he/she may has to get an older version of Eclipse. It will be worse if another project such as Jupiter sensor needs a different version of Eclipse.
I feel that we might need a protocol on selecting/using libraries.
Good point, Hongbing.
I think it's important to distinguish between: (1) our code depends upon a specific version of a library, and (2) our code _includes_ a specific version of a library.
If someone wants to build our system, and cannot obtain an older version of a library, then that raises the issue of what good the system will be to them if the library doesn't exist anywhere else. It also means that perhaps we should have upgraded our code to use a newer version of the library, or moved to a different library that is better supported.
Post a Comment