We Keep Coding

Does the Google-Eclipse plugin autogenerate war directory contents?

I just created my first Web Application Project using the Google-Eclipse plugin. Amongst other artifacts, it autogenerated a war/ directory with several subdirectories and many files, including:
war/
WEB-INF/
lib/
<Lots of JARs here>
web.xml
appengine-web.xml
etc.
Several times now I've cleared out certain parts of this war/ directory (messing around with buildscripts and other Google-Eclipse plugin features - this is just a test/temp project for getting used to the plugin), and they magically reappear at some point in the future.
I'm wondering if, because I set this up as a Web Application Project (and it is thus managed by the Google-Eclipse plugin), is the plugin trying to preserve the structure of the war/, and as such, continuing to auto-generate any missing files?
If so, why? Exactly (which files/directories) what is it trying to preserve? Can I disable it?
And if not, then I obviously have something else going on here. In which case, has anybody else ever experienced this with the Google-Eclipse plugin, or just Eclipse in general? Thanks in advance.

This plugin only updates war/lib directory by adding dependencies. Actually it just copies jar files when you switch to a another version of Google App Engine SDK.

This should not be a problem.
War folder is the exploded package that later on you need to deploy to Google App Engine.
When you build or deploy file to GAE, this folder will be re-created/updated, and it contains the newly compiled jar and the necessary libs.
Read this.

War folder contains the generated javascript files which are deployed to the app engine.

HTTPClient on Tomcat

I really apologize if this is a silly question.
I have a tomcat server running on a unix machine. I want to use the HTTPClient library. Does it come pre-bundled with tomcat or do you need to install it?
If people say to just add it to your class path. Should I download the source or the binary from here:
http://hc.apache.org/downloads.cgi
Once downloaded is there a way to auto install it using a .tar.gz as I think I have done this in the past. If not is it just a case of putting the folder on the drive and adding it to the classpath?
TIA

Each web application is supposed to package its own dependencies inside the deployable WAR file. It is an ill-advised practice to extend Tomcat's global library with any library an application might need.
On the WAR building front, the common practice you should stick to is not to manage dependencies on your own; it quickly turns into a nightmare. Configure your project with Maven , which will both manage the dependencies and build the WAR for you.

Just look for httpclient....jar file in the Tomcat directory. If there is none there, then put it inside the lib directory :)
You should download the appropriate jar file. It contains portable library code. Once placed in the classpath, Tomcat will find it. Tomcat directory has a lib subdirectory. This is global classpath part for all web applications.

Build Path Issue

In Eclipse we have a project where we reference an external jar in the build path. When I upload my project to the repository and my colleagues check it out, the build path looks for the jar file in the same place. One of us uses a Mac so doesn't even have a C: drive and my other colleague has a different partition containing the jar, so it always breaks.
How do we fix this issue? Ideally the jar file would be included as part of the project but it seems that the svn commit doesn't include the referenced library.
Thanks

I would suggest you use a build tool (maven, ant/ivy, gradle, etc) along with a repository manager (such as nexus or archiva), depending on what you use to build your project. These store libraries in a central location(s) and then users get the libraries from there.
In eclipse, when you include your .classpath file in the checkin, you will have the issues you are describing, since the .classpath file will contain the path to the file, and then you all must have the files in the same locations. A workaround for this is to create a "lib" directory and put all of the libraries in there. Each of the users can then add all of the libraries in that directory to their path (but do not checkin the .classpath file). This is an older way of doing things before the concept of dependency managers.

Add the jar as part of the project (say in a lib folder in your project) and commit it to svn.

Start using Maven, to resolve your dependencies.
Worst case : Commit the external jar into another project called MyProjectDependencies

You can use Apache Maven to avoid incident like this and to get many others pluses.
You can find many guides on maven, for example this one.
Eclipse has integration with maven.

1.) Check in JAR in a directory inside the project.
2.) Use Maven (or something similar) to manage your dependencies.
3.) Create a User Library referencing the JAR and refer to it this way in your project. Each user will need to create the User Library in their install of Eclipse, but it sounds like you're already doing something similar by referencing the library externally anyway.

if you don't want to use a dependency management tool like Maven, a simple solution in your case would be to use an Eclipse Classpath Variable. All projects can reference the variable, but it will have a different value for each developer.
Set up a Classpath Variable with:
Right click on the Project, select Project Properties
Click Add Variable
Configure Variables
New...
Name the variable and point to a Folder
Now commit your .classpath file. The variable will be referenced in the .classpath. Each developer can configure to their particular directory, and Extend the variable to a specific jar file.

Should I commit WEB-INF into version control, or rather construct it with Ant?

The Ant "war" task does just that - creates WEB-INF along with META-INF, depending on task attributes.
What is considered a best practice?
Keeping all my libs elsewhere for re-use, like log4j and then build them with "war" task?
Or have everything (including jars) checked-in under WEB-INF?
I have multiple apps that could re-use same libs, images, htmls, etc. Our developers use RAD7/Eclipse.
I'd appreciate any examples with opensource Java Web Apps repo layouts.

If you can reliably, dynamically create it, the don't check it in. That's going to cause confusion. In this situation it's analogous to checking in .class files.
Rather, check in the build file and the artifacts you use to create it, and let the build take care of it.

I'd appreciate any examples with
opensource Java Web Apps repo layouts.
Here's an example of web application which is using a classic Maven directory layout:
hifaces20-demo-messageboard-0.1.0-project.zip
src
main
java
resources
webapp
WEB-INF
web.xml
test
java
resources
pom.xml

We work with Eclipse. I have found that having the files that Eclipse do not hide checked in work well for us. You check out the project, and you are ready to go. No further ant stuff to run or remember to run.
If you build with ant always (e.g. if you come from a Netbeans shop) then check in only those files which are original. All those that are copied from elsewhere, should explicitly be not checked in.

I generally do check in the WEB-INF folder but exclude the lib and classes folder. When I need the libs I retrieve them using Maven or Ivy (ant tasks). Seems to work well, I only check in the libs if it's an extreme case where it's likely I wont have an Ivy cache or the lib is 'special' and doesn't exist anywhere else.

How to use common libraries for multiple Java web project

I am having four different project, and i am using Weblogic to deploy my projects. There are several libraries ( jar files ) which are common for all projects. Currently each of my project are having lib directory and have almost same set of libraries. Now, is it possible to have this lib directory outside WAR files and access them.

Resist the temptation of putting the jar files in the "shared" folder of your container. It is better to keep the jar files where they are now. It may sound a good idea to use a shared folder now, but in the future you may need to deploy an application that requires a shared library, but a different version.
That being said, I have no experience with WebLogic. In Tomcat there is a shared folder with libraries common for all deployed applications. It is not a good idea to use this. If WebLogic can be configured to use a shared folder per a set of applications (and not for all deployed applications) you could go for it.

Do you want to do this ? Unless you're stuck for deployment space, I would (perhaps) advise against it.
Why ? At the moment you have 4 solutions running off these libs. If you have to upgrade one of the libs (say, if you discover a bug, or if you require a new feature), then you're going to have to test compatibility and functionality for all 4 solutions. If each solution has its own set of libs, then they're sandboxed and you don't have to move all 4 in step.
Note that all this hinges on how easy it is to regression-test your solutions. You may find it easy, in which case using the same set of libs is feasible.

Don't do that.
The whole idea of WAR files is that they are self-contained units. This makes deployment so much easier.
In addition to the possible version conflicts that others have pointed out, putting jar files in /shared can have very nested consequences for class visibility. They will be on a separate classloader, and be unable to see the classes in the WAR file. If you use libraries that rely on Class.forName() to work (and there are plenty), this could get very painful.
If you really, really cannot afford the extra disk space and memory look at OSGi or Spring DM. They have solved this problem, but at the price of increased complexity.

Put all the shared jar files under common\lib folder of weblogic. common\lib is accessible by all the deployed apps.

Well first of all you can put your libs all on the same place and have your build process import the ones needed.
Has for on deploy the new Weblogic 10 has a lib folder in each domain where you can put shared libs. i dont think that is possible before Weblogic 10

You can put the jars in their own ear file and deploy it as a shared library.
You can also put the wars in an ear and add the shared jars to APP-INF/lib. This is a Weblogic extension of J2EE, so it won't work on other servers.

I'm currently using another approach.
Create a central repository folder and put all common libraries in there.
In each project you can create a reference to all needed libraries. In Subversion it works with externals
Everytime, the local working copy is updated, the externals are updated to, so you just need to commit to the central folder and it's automatically distributed to all projects.