Binary project support

Because binary projects only exist in the workspace for reference during compilation and build, using binary projects can optimize your development of large enterprise applications. If it takes more than a few minutes to build everything in your workspace, binary projects might be helpful for your team.

For example, if your enterprise application consists of twenty EJB modules and one Web module, the Web module provider may work more efficiently if all the EJB modules are not built every time you compile the Web module. Binary projects work well if you have clear lines of separation within your development team. Note that the use of binary projects adds complexity to the development process, and therefore is most useful for large scale applications. If you have smaller applications where build time is not a problem, then keep your projects as source.

Binary projects are created when you import an EAR that was exported with the Include project build paths and meta-data files option selected. If during import you select the Import for partial EAR development, you can choose which projects you want to import as binary projects. For binary Web projects the Java source in a Web project is still expanded in the workspace. Binary projects have the validation builder disabled by default. Binary Web projects have the links builder and validation builder disabled by default.

For more information about binary project creation during import, see Importing an enterprise application EAR file.

Binary project structure

The following rules define a binary project:

• Java build path has no source container

• Project has exactly one JAR in the project, on the build path, and exported.

• For EJB and application client modules, the meta-data resources (e.g., ejb-jar.xml), are loaded for the JAR for display in the Project Explorer view or a read-only editor.

• For Web projects, the structure is the same, as for source projects, except the validators are turned off.

Process flow for using binary projects

For teams using source control (for example, CVS), a normal process might include:

1. Run a nightly build or export an EAR file that contains source code. During export, the option is selected to include the project build paths and meta-data files. This will preserve the mappings between the module and the JAR names, as well as external dependencies. For instance, suppose you have a Java project which depends on an external JAR files such as xerces.jar, and this JAR is on the build path. You can ensure that mapping is retained by selecting the include option.

2. Individual developers can then import the EAR into their workspace using the Import for partial EAR development option.

3. Each developer can then choose to import only certain modules into their workspace, assuming that the projects that they do not import are attached to a repository. Otherwise, a developer can replace binary projects with the appropriate source (source that the developer is actively developing) from the repository.

Features and limitations of binary projects

• Modification of resources within the application client or EJB modules will be disabled. For example, you cannot edit the deployment descriptor in a binary project. You can still open the resources with the applicable editor, however, the file will be read-only and the widgets will be disabled.

• Binary projects created by EAR import (available as an option on the import wizard) are intended to be read-only. You should not try to modify the contents of a binary project. You can, however, delete the binary project and replace it with a source version from a repository. Most actions should be disabled for binary projects. If you use binary projects, try to avoid any actions which modify the contents of the project or JAR.