The J2EE specification defines the Enterprise Archive (EAR) file as a standard structure for developing and packaging J2EE applications. EARs are useful for application development, in that the application may, for example, include both a Web application (Webapp) and an Enterprise Java Bean (EJB), which will be packaged into the EAR. However, while this works well for completed applications, it isn't very convenient for application development.
In a typical application server development environment that uses EARs, a build structure similar to that shown in FIG. 1 is often used. As shown in FIG. 1, the directories for the /myapp application 10 include, for example, a /myejb subdirectory 12, for storing both ejb source files and XML descriptors 16. Similarly /myapp may include a /webapp directory 14, for storing JSPs, html files, and images 18, etc. All of this code is stored in the developer's source control system for use by the developer in building the application.
To deploy the application, a number of steps must be performed, namely compiling the Java files, generating any servlets or container classes, and packaging the whole lot in an EAR. The EAR adheres to a format wherein the top level includes an EAR descriptor/META-INF/application.xml, and all of the other components are listed underneath. This approach works well when the application has been fully completed and ready for installation in the production environment. However it's less useful for application development.
A problem with the traditional approach is that the developer will usually have both the source files and system-generated output in the same directory, which can be confusing. It is also difficult to generate a clean build of the application since it is difficult to delete only the system-generated files.
In addition, it is desirable to provide a flexible means by which the actual build structure can be laid out. For example, in a traditional system the build structure must usually mirror the corresponding EAR structure. However, in some instances the developer may wish to use a different build structure. A mechanism that allows application development while maintaining some separation between the user-coded and system-generated files, together with providing flexibility in how the build structure can be laid out, would be useful in addressing these problems.