Santosh has given the correct response, but let me clarify some issues about weblogic vs jboss.
JBOSS and WebLogic have different classoader mechanism. Let me clarify:
1. why manifest?
Java-Oracle reply: You may need to reference classes in other JAR files from within a JAR file.
2. why manifest on EAR/WAR application?
Oracle Weblogic reply: WebLogic Server supports optional packages as described in the Java EE 5.0 Specification, Section 8.2 Optional Package Support, with versioning described in Optional Package Versioning. Optional packages provide similar functionality to Java EE libraries, allowing you to easily share a single JAR file among multiple applications. As with Java EE libraries, optional packages must first be registered with WebLogic Server by deploy the associated JAR file as an optional package. After registering the package, you can deploy Java EE modules that reference the package in their manifest files.
Optional packages differ from Java EE libraries because optional packages can be referenced from any Java EE module (EAR, JAR, WAR, or RAR archive) or exploded archive directory. Java EE libraries can be referenced only from a valid Enterprise Application.
[...]
Any Java EE application or module can reference an optional package (using META-INF/MANIFEST.MF), whereas only Enterprise Applications and Web applications can reference a shared Java EE library (using weblogic-application.xml or weblogic.xml)
3. then why we have to no declare java-ee-api.jar, jsf, jsp, ...
Jboss reply: The following table lists the modules that are automatically added to deployments as dependencies and the conditions that trigger the dependency.
Implicit_Module_Dependencies
4. are not all modules loaded by JBOSS?
Jboss reply: this chapter will talk about how applications packaged as jars can declare that they depend on one or more modules:
Dependencies: oracle.sql, another.module.with.version:1.0
Manifest module information
4.1 alternatively define the jboss-deployment-structure.xml
<jboss-deployment-structure>
<deployment>
<dependencies>
<module name="oracle.sql" export="TRUE" />
</dependencies>
</deployment>
</jboss-deployment-structure>
Add anExplicit Module Dependency to a Deployment
4.2 with maven
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<configuration>
<archive>
<manifestEntries>
<Dependencies>org.javassist, org.apache.velocity</Dependencies>
</manifestEntries>
</archive>
</configuration>
</plugin>
</plugins>
see: Generate MANIFESTMF entries using Maven
see: How do you generate module dependencies in MANIFEST.MF for JBoss AS 7 with maven?
7. why we didn't get this important information before?
With the new organizational model JBOSS 7/8 abandons the famous classloading hierarchy to switch to a simpler model based on the use of modular units (JBoss Modules Project) . The introduction of the architecture modules (in addition to the forthcoming introduction in the JDK, much in vogue at this time thanks to external projects such as OSGi) actually extends the model in use for the packaging of Java EE applications; a module can then be a library, a collection of classes, or more generally a collection of resources associated with a single classloader: therefore, unlike the past, where the classloader that was collected under a hierarchical organization of a set of classes, the point here of view is exactly reversed.
see: Class Loading in WildFly