For smaller dependencies that’re private to a deployment, keep ’em in WEB-INF/lib in your .war, that’s what it’s for. If you’re using Maven that should be pretty much automatic and transparent for anything in the <compile/> scope.
For big, complex dependencies or dependencies that’ll be shared between several apps, use option (4):
Deploy each logical library (like “OpenJPA” or “Log4J”) as a module, including its api and impl jars and any dependency JARs that aren’t already provided by other AS7 modules. If there’s already a module add a dependency on it rather than adding a JAR to your module. If several different libraries share some common dependencies, split them out into modules and add them as module dependencies in module.xml.
Use jboss-deployment-structure.xml to have your deployment .war / .ear / whatever declare a dependency on the module if it isn’t autodetected and autoloaded.
I find this to be a medium-to-low-hassle approach that works well. It’s more hassle than dumping everything into WEB-INF/lib inside the deployment, which is the Java EE standard thing to do. It speeds redeploys and it saves lots of deploy/testing time by reducing class/version conflicts.
You can use Maven and the maven-dependency-plugin to produce modules with the transitive dependencies already included if you’re willing to do a bit of work. You can see one example of that in a module I wrote for EclipseLink integration in AS 7. I automate the creation of AS7 modules whenever possible.