Understanding the Build Process

Building your WebLogic Workshop application can be a time-consuming part of the iterative development process. By understanding when and how to build your application and its respective projects, you can streamline the build process for your application.

When Do I Need to Build My Project?

How often you need to build your project depends on what type of project you are using and what you are doing, but you may not need to build the project as often as you think.

Web Service, Page Flow, JSP, and JPD Files

If you are developing and testing web service (JWS), page flow (JPF), JSP, and JPD files in a Web or Web Service project, you don't need to build the project that contains them at all until you are ready to deploy the project. You can simply run the file in Test View to build and test them iteratively. WebLogic Workshop will automatically build any dependencies of that file for you on an as-needed basis.

Web and Web Service Projects

You only need to build Web and Web Service projects when you are ready to deploy those projects to a server that is not running in iterative development mode (that is, a server that was started with the noiterativedev flag passed to the startWebLogic command).

You can specify that Web and Web Service projects be built incrementally when you do build, rather than cleaning the project each time, by setting the Use Incremental Build property for the project. This can speed up the process of making changes to a web application that is running on a production server. Note that there are a small number of situations where incremental build will not detect file changes (e.g. final static variables, changes in external XML files). In those cases, a clean build will be necessary to reflect the current state of the project.

For information on setting the Use Incremental Build property, see Using the Build Process More Efficiently.

Java, Control, EJB, and Schema Projects

Java projects, Control projects, EJB projects, and Schema projects are similar in that the result of building any of these projects is a JAR file that is written to the application's APP-INF/lib folder, or in some cases, the APP-INF/classes folder. These JAR files can then be used by other projects within the application. You should build these projects when you need to update the JAR files so that the latest changes are available to any projects that are using them.

When you build one of these projects, WebLogic Workshop checks to see that the JAR file is indeed out-of-date. If the JAR file is up-to-date, WebLogic Workshop doesn't build the project.

When Do I Need to Build My Application?

You need to build the entire application only when you are ready to deploy your application to a server that is not running in iterative development mode (that is, a server that was started with the noiterativedev flag passed to the startWebLogic command).

Production Build

When you are ready to deploy your application to a production server, you most likely want to perform a clean operation and then build the full application to generate an EAR file. This approach ensures that you have a consistent means of controlling the quality of your production application, and that you will not deploy unnecessary build artifacts to the production server. To perform a production build, you can use the Build->Build EAR command in the IDE, or the wlwBuild command from the command line.

The Build EAR menu command and the wlwBuild command perform a clean operation and build the complete application as they did in prior releases. If a project has enabled incremental build or disabled JSP pre-compilation, those settings are ignored when building an EAR using Build EAR or wlwBuild.

Developer Testing

If you are developing your application iteratively and testing it in a local or shared environment, you may want to build the EAR file incrementally in order to save time when testing frequent changes. Building an EAR incrementally affects only Web and Web Service projects. When you build the EAR file incrementally, only those files and dependencies that have changed since your last build are built. No clean operation is performed, and existing build artifacts are not removed. Incremental build can speed up the process of deploying and testing changes to a Web or Web Service project.

Incremental build applies only to Web and Web Service projects where the Use Incremental Build property for the project is set to true. To build an EAR file where projects are built incrementally, use Build->Build EAR (Incremental) from the IDE, or specify the –incremental command line option when building from the command line with the wlwBuild command.

For more information on building incrementally, see Using the Build Process More Efficiently.

When Do I Need to Clean Before Building?

The clean operation cleans all build artifacts resulting from a previous build of a project or application. It's a good way to "start over" so that you know that your build output includes only the most up-to-date files based on your source code. However, you don't need to perform a clean operation every time you build. You should clean your project or application in the following scenarios:

Streamlining Project and Application Size

When you rename or delete files in your application, the corresponding build artifacts are not deleted until you perform a clean operation. These extraneous build artifacts are generally harmless, but it's a good idea to clear them out now and then so that they don't slow down server startup and redeployment.

Building the Production Quality Application

Before you deploy your application to a production environment, you will probably want to perform a clean operation followed by a complete build in a controlled environment. In this way you can ensure that you have a formal, repeatable build process that you use every time you deploy an application to production.

Restoring the Server State

Occasionally a project can get out of sync with the server, and not function properly. When this happens, you should perform a clean operation to restore the state of the server.

Related Topics

Using the Build Process More Efficiently

Customizing the Build Process