(Caveat: I don't actually know if this matters with the Jar design element in 9.0+, since the only times I've needed it are with clients using obsolete versions)

Updated: See Below.

If you use Jar files stored in an NSF in your build path with XPages apps, you've likely noticed that it makes your build times interminable, particularly if it's a large library. From what I can tell, Designer seems convinced that it must download the entire Jar file during every build, in order to find out what's inside of it.

After waiting through enough of these ridiculous build times, I figured I'd try something: extract the .class files inside into a binary class folder. And, lo and behold, it works: if you follow this process, Designer no longer downloads everything, since it can see what classes are available using the NSF's VFS normally.

The process is straightforward if you're used to Eclipse-isms, and isn't too bad generally. All of this happens from Package Explorer:

1. Put the Jar file on the local filesystem somewhere - if you just have it in the NSF, you can extract it via right-click -> Export... -> File System
2. Create a folder in your NSF's VFS. WebContent/WEB-INF is a good spot for this. I tend to name the folders the same as the Jar file, minus ".jar", so that the same name and any in-name version info is retained
3. Import the class files from the Jar into that folder. Do this by right-clicking the folder in Designer and going to Import... -> Archive File -> select the Jar from the filesystem -> make sure everything is checked
4. Add the folder to the build path. You can do this by right-clicking basically anything in the NSF's VFS tree and going to Build Path -> Configure Build Path... -> Libraries tab -> Add Class Folder.... In that dialog, pick the newly-created folder in WebContent/WEB-INF

And with that, you should be able to delete the original Jar while still having the class files available, along with faster build times.

Update: It looks like there's a minor caveat: the class files are available for Designer, but not the server. Fortunately, it's not as bleak as that makes it sound: if you keep the Jar file in the NSF in the specific path WebContent/WEB-INF/lib (without adding it to the build path), then you can use the class-folder trick for Designer, but the server will pick up the classes from the attached Jar. So that's a drag from the cleanliness perspective, but still gets the job done. That may also mean things get muckier on 9.0+, since I believe that's the location it uses for Jar File resources.