As your application grows, it may not be practical nor desirable to keep your entire application in source form in your workspace. Large workspaces can include more than a hundred projects. It is very unlikely that every developer will need to change every one of those projects every day. A better approach is to keep only the projects or modules that you intend to changing in source form and keep the projects or modules that you are using in binary form. Doing this will greatly reduce the memory footprint of IBM® Rational® Application Developer and greatly speed up many common development tasks. You will still be able to view the source code in the binary projects and do most of the productivity operations, such as Open Declaration (F3), that you have come to depend on often.
As an example, one of the customer workspaces that we use takes 27 minutes to build when the entire workspace is in source form. When most of the modules are in binary form, the build time drops to less than 3 minutes. Please see the Real-world test section at the end of this article for more details about this example.
This article provides step-by-step instructions on how you can exploit binary modules in your environment. It assumes that you are developing an EAR project and that you are using source control. This article applies to version 188.8.131.52 of Rational Application Developer and later. The new shared EAR file support was not included until version 184.108.40.206.
Many of the tips here apply to other IBM Rational products, including Rational® Software Architect, Rational® Software Modeler, and Rational® Web Developer.
The basic practice is for only one developer to change a subset of the projects at any one time. They still may need to see all parts of the application in source form. The list of projects that they need to change can change, so that at any point in time they can add to the list of projects that they can change.
The basic approach is quite simple:
- Start with an EAR file that contains the complete application, including the source code.
- Import this EAR file, and this becomes your base. Typically, this EAR file comes from a nightly or weekly build process.
- You then import from source control the projects or modules that you expect to change.
This article uses a running example (see Downloads) that has each of the main types of projects that you might encounter while developing a Java™ 2 Platform, Enterprise Edition (J2EE) application:
- SampleEAR: The EAR itself, which also contains a binary third-party Java Archive (JAR) file called SampleThirdParty.jar
- SampleEJB: An EJB project example
- SampleEJBClient: The client part of the EJB project example
- SampleWeb: An Web project example
- SampleUtility: An utility project example
Your application will usually have many more projects, but this example includes the main type of J2EE projects (Figure 1).
Figure 1. Example application
Creating the EAR
Normally, you would create the EAR through some sort of automated build process. Typically, most customers do either nightly or weekly builds, but this example will show you how to create the EAR manually.
- If the application includes EJBs, then you need to ensure that the EAR has been prepared for deployment before the export (Figure 2).
- Export the EAR file by using the Export Shared EAR file wizard, as Figure 3 shows.
Figure 2. Prepare for deployment
Figure 3. Exporting the shared EAR file
- As you see by Figure 3, the new shared EAR file menu item has been added by the helper plug-in.
If you want to incorporate this as part of your automated build process, you will need to perform these additional steps. (If you are using the Export > Shared EAR file menu item, then you do not need to do these steps.)
- In Rational Application Developer V220.127.116.11, manually add two these special files to the EAR after it has been exported:
- .settings\com.ibm.etools.j2ee.teamshare: This is a marker file, the contents don't matter. I put the word "marker" in the file just so it wouldn't be an empty file.
- .settings\org.eclipse.wst.common.component: This needs to come from your EAR project in the source workspace.
- You can copy these two files to anywhere in your file system (see Figure 4).
- Then use a file compression utility to compress them into the EAR file. You can use something like this command:
zip -r SampleEAR.ear .settings/*.
Your EAR file now contains the original files and the two files that you added manually (Figure 4).
Figure 4. Modified EAR file in the workspace
Importing the EAR
In a team setting, each developer would start by importing the previously exported EAR file.
- Select Import in the J2EE screen (Figure 5).
- In the Import window, select your Shared EAR file (Figure 6).
- Use the arrows in the Shared EAR import window to select the name of the file, the name of the project, and the runtime target server (Figure 7).
Figure 5. To begin, select Import
Figure 6. Select the file that you want to import
Figure 7. Select the file name, project name, and runtime server
- Close and then re-open the SampleEAR project. (This is to get around a synchronization bug in Rational Application Developer).
- After re-opening the project, your workspace should look like Figure 8. You can see that all of the modules are binary modules.
Figure 8. Screen view after importing your project
- You are ready to deploy and run the application.
Switching a binary module to become a source module
Now that you have a base in place, you will need to import the projects that you want to change.
- Web modules
- Use your normal technique for importing a Web module from source control. For this example, we used the open source Concurrent Version System (CVS), as you'll see in Figures 9 and 10.
- Make whatever changes that you want to make to your Web project. Your changes will be reflected in your running application.
- You can check your changes into your source control system, if you wish, so that they can be picked up by others and by your build process.
Figure 9. Select Projects from CVS under the CVS folder
Figure 10. Select the module to check out from the CVS
- EJB modules
The approach for Enterprise Java™Beans (EJB) projects is similar to the approach for Web projects. You simply check out your projects.
- Utility projects
The approach for utility projects is similar to the approach for Web projects. You simply check out your projects.
Switching from a source module to a binary module
Switching back to a binary module is quite simple. Simply delete the source project from your workspace, and then request the server to republish. You are now back to using the binary form of the module.
Workaround for deleting the Web project
Because the IBM® WebSphere® Application Server had a lock on some of the Web library files, we couldn't delete the Web project. This is the solution:
- Stop the WebSphere server, and then delete the Web project.
- After restarting the server, you need to also restart the EAR to be able to use the binary version of the Web archive (WAR) file.
Ad hoc fixes
You can also change code without having to import the project from your source control system. Imagine that you are working late at night, and you want to temporarily fix someone else's code. You don't intend to check this code back in; you merely want to make some temporary changes so that, perhaps, you can finish testing your code.
You can convert any of the binary modules to source modules directly from the EAR.
- Right-click on a shared EAR project, and then select Shared EAR > Extract Binary Modules to Projects (Figure 11).
Figure 11. Extract Binary Modules to Projects
- Check the box next to the binary module associated with the shared EAR file (the SampleUtility.jar file, in this case) to extract it to your project *Figure 12)
Figure 12. Select the binary module associated with the shared EAR
- After the import action, you will have a normal source project where you can test your changes, as you see in Figure 13. (But remember: Because this project didn't come from your source control system, you will not be able to check your changes in to save them.)
Figure 13. Normal source project
- When you are finished using the modified source project, simply delete it to revert back to the original binary version.
- It is also possible to replace the binary version of the module with the modified source project by using the Shared EAR > Repackage Projects to Binary Modules action.
We took a large workspace that had 6 EJB modules, 5 Web modules, and 29 utility projects. We first did a clean build when all of the projects were in source form. This was performed on a Pentium 4, 3 GHz machine with 2 GB of memory. We then switched to using binary modules, except for one Web project. Again, we did a clean build. Here is what we measured for the two different approaches:
Table 1. Table using a heading tag for the caption, all columns left-aligned (recommended style)
|Source workspace||Binary workspace|
|Elapsed time||29.9 minutes||2.7 minutes|
|CPU time||30.5 minutes||3.9 minutes|
|Number of bytes read||1.9 GB||0.25 GB|
|Page faults||443 K||22 K|
|Peak working set||931 MB||318 MB|
As you can see the savings are dramatic.
This article shows how you can keep some of your projects in source form, and others in binary form, to improve the speed of many of the day-to-day operations that you perform in Rational Application Developer. If there are other tips that you know of, that have been effective in your environment, we would love to hear from you.
|The sample application used for this article.||SampleEAR.zip||10KB|
- Rational Application Developer Performance Tips
- Eclipse FAQ - Performance Tips
- Eclipse Performance page
- For technical resources, visit the developerWorks Rational Application Developer area. You'll find technical documentation, how-to articles, education, downloads, product information, and more.
- Subscribe to the developerWorks Rational zone newsletter. Keep up with developerWorks Rational content. Every other week, you'll receive updates on the latest technical resources and best practices for the Rational Software Delivery Platform.
- Browse the technology bookstore for books on these and other technical topics.
- Stay current with developerWorks technical events and Webcasts.
Get products and technologies
- Download a free trial version of Rational Application Developer.
- Download IBM product evaluation versions and get your hands on application development tools and middleware products from DB2®, Lotus®, Rational®, Tivoli®, and WebSphere®.
- Check out developerWorks blogs and get involved in the developerWorks community.
- Rational Software Architect, Data Architect, Software Modeler, Application Developer and Web Developer forum: Ask questions about Rational Application Developer.
Dig deeper into Rational software on developerWorks
Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.
Experiment with new directions in software development.
Software development in the cloud. Register today to create a project.
Evaluate IBM software and solutions, and transform challenges into opportunities.