I guess this is part of the reality of living in an OSGi, module-focused world. That approach leads to multiple, smaller JARs rather than fewer, more monolithic ones. Because GlassFish v2 made appserv-rt.jar available for this purpose we've kept a file of the same name and same function - but different content - in v3. It's better this way than to package the same classes into multiple JARs - appserv-rt.jar and the one where it reside in the v3 packaging.
There is some help, though. The package-appclient script will create a JAR file which contains all the runtime JARs a Java EE app client - or a Java SE client - will need. Run that command on a system with a full GlassFish installation, then copy the JAR to each remote system that needs to launch a client, expand it, and you should have what you need.
An alternative (shameless plug ahead) is to write your client as a Java EE application client and use the built-in automatic support for launching app clients using Java Web Start. This approach completely relieves the developer or administrator from preparing client systems to launch clients. The first client launch from a given system triggers the download of the GlassFish JARs needed as well as the JARs for that app client. Subsequent launches just use the locally cached copies of those files.
[Message sent by forum member 'tjquinn' (timothy.quinn_at_sun.com)]
http://forums.java.net/jive/thread.jspa?messageID=378685