The build classpath in Eclipse is what Eclipse uses to resolve class references when it runs its editor/compiler. It's often a good idea to make a source project self-contained, so you'd place copies of any additional jars you need in the project. Whether that's in a directory named "lib" or somewhere else doesn't matter to Eclipse, but the jar has to be in the build classpath for its resources to be visible to the editor/compiler.
Some jars aren't worth including in the project. For example, I don't include
Tomcat's api library jars in a project - I'd be wasting space on my disk if every web project had its own copy, and they'd all go obsolete when I installed a new version of Tomcat. So I set up the project to refer to the Tomcat api jars as external jars. I do a lot of
Maven projects these days, and Maven does much the same thing.
Being in the build classpath doesn't mean that the jars will automatically be included in the executable output. Although the Eclipse debugger inherits the build classpath, that only works inside Eclipse. If you want the libraries accessible when you're not running Eclipse, you have to construct an executable environment that includes those libraries. Eclipse itself won't do that, although some of the extensions will for specific kinds of projects.
Overall, however, it is NOT a good idea to make Eclipse an integral part of your production build process.
I've been burned 2 different ways by projects that could only be built via an
IDE - by being handed projects that would only built if my IDE setup EXACTLY matched the setup of whoever originally worked on the program and by installing a new version of the IDE that worked differently than the old one did. For production builds I recommend that you always be able to build without running an IDE at all. Ant and Maven are both good for this, and they'll work with Eclipse while you're doing the development.
