Well, it really depends on where you want to call it.
If it's to be run locally with file system visibility to the codebase (and possibly WT_HOME/lib as well, as some classes depend on jars therein, not just jars in WEB-INF/lib), then you can just put WT_HOME/codebase, WT_HOME/codebase/WEB-INF/lib/*, and WT_HOME/lib in your classpath and go.
If it's to be run remotely, then you can use a URL classloader with URLs to Windchill's server codebase and codebase/lib/*, but if this loads any substantive number of classes there will be a performance penalty for loading the classes on demand on each startup of your remote application. If that is problematic, then at that point you need to look into using Java Web Start or the Windchill bootstrap classloader to download and cache jars, updating them only when they change on the server.
What you should not do is copy Windchill server classes and/or jars somewhere else and assume they will not change. They can change in any patch or MOR, so you should have a plan for ensuring that they remain up-to-date, hence the use of Java Web Start or the bootstrap classloader.