HomeDigital EditionSys-Con RadioSearch Java Cd
Advanced Java AWT Book Reviews/Excerpts Client Server Corba Editorials Embedded Java Enterprise Java IDE's Industry Watch Integration Interviews Java Applet Java & Databases Java & Web Services Java Fundamentals Java Native Interface Java Servlets Java Beans J2ME Libraries .NET Object Orientation Observations/IMHO Product Reviews Scalability & Performance Security Server Side Source Code Straight Talking Swing Threads Using Java with others Wireless XML
 

Using a software configuration management (SCM) system is an integral part of any development project. Source code is your most valuable resource and must be protected. However, with the large number of products available from many different vendors, it's essential that you choose an SCM system that will work with your favorite development tools.

The External Version Control tool in VisualAge for Java, version 3.5, allows you to interact with several external SCM systems from within the integrated development environment (IDE). Once you've used the tool to associate a project in VisualAge for Java with a group of files in the SCM system, you can add and remove classes from the SCM system, as well as check classes in and out. In Part 1 of this article (JDJ, Vol. 6, issue 3) we discussed several aspects of this tool, including:

  • Using the team server instead of the External Version Control tool
  • Automatic versioning of your SCM files
  • Merging changes
  • Working with class groups and resource files
In Part 2 we expand on this topic by discussing two additional aspects of the External Version Control tool:
  • Refreshing your SCM files in the IDE
  • Manipulating path prefixes
Refreshing Your SCM Files in the IDE
To refresh a project that's been revised, version control will compare your workspace contents with the contents of the SCM server and allow you to synchronize your project in a customized way. Files will be refreshed only if their contents have changed since you created the project or since they were last refreshed. Many different types of inconsistencies are detected during a refresh operation, such as file deletions, new versions of files created by your teammates, and potential conflicts in which changes have occurred both inside the IDE and on the SCM server. You control how these inconsistencies are dealt with and choose the course of action in each case.

Depending on which SCM system you're working with, you may be able to refresh your files directly from your SCM system, or you may first have to ensure that your working directory is synchronized with the server, then refresh the files in the IDE. This process varies depending on the capabilities and versions of the particular SCM system you're using.

If you were prompted to import your SCM files from your working directory when you added your project to version control, you might need to extract the latest copies of your files from your SCM system and place them in your working directory before you try to refresh your project. Otherwise, you won't be able to refresh your project properly because your workspace will appear to be synchronized with the working directory.

It's usually preferable to have the refresh operation use the SCM server as its source of file information rather than the working directory. Unfortunately, this is not always possible, as it depends on the SCM system's capabilities. In most cases, the EVC tool will be able to detect the best way to refresh files and you won't typically need to adjust it.

Manipulating Path Prefixes
When you import Java source or compiled class files into the IDE, they're loaded into the appropriate package in the workspace. Resources, however, are handled differently. They're loaded into the associated project_resources/<project_name> directory, which is automatically included in the project's classpath at execution time. The directory structure within the project's resource directory will be preserved when importing resources. This becomes a problem if the original file in your SCM server has any extra subdirectory levels, as those levels will be mirrored and may leave your resources inaccessible to your programs without modifying the classpath. For example, consider a file in your SCM system that's stored as:

data/translatable/com/mystuff/labels.properties

When you import this file, you'll also import by default the data/translatable directories. When your code attempts to load the com.mystuff.labels resource bundle, it won't be able to find it.

To help avoid this situation, External Version Control lets you specify a path prefix that's removed during import and replaced during export. In the above example, setting the path prefix string to data/translatable will cause your resources to strip off these directories when importing. That means labels.properties will appear on disk as:

ide/project_resources/<project_name>/com/mystuff/labels.properties

This lets you use the files within the VisualAge for Java IDE without abandoning the organizational structure you've created on the SCM system.

The path prefix you specify in this window will be saved and listed in the Details page of the Version Control Properties window and in the Refresh Items page of the Refresh window. The prefix will automatically be removed from any files you import using the Refresh window when they're placed in the project_resources directory.

When you import a non-Java resource file into VisualAge for Java from your SCM system, you can elect to remove some or all of its path before it's copied into the project_resources subdirectory. Enter the name of the path prefix as it's displayed in the list of available files. For example, if you import a file that's stored on the SCM server as \Source\Resources\mypackage\mine.properties, and type \Source\Resources\ into this field, the file will be imported to the following directory (which will be created, if necessary): project_resources\projectname\mypackage.properties. If you're using the SCCI handler, you must also type the name of the drive on which the file is residing.

You might remove part of or the entire path prefix for the following reasons:

  • To avoid creating extra, unnecessary subdirectories
  • To control the directory structure of the resource files that will later be loaded from the SCM server

When you export a file to your SCM system from VisualAge for Java you can select to add a path prefix to it before it's copied into your SCM system. For example, if you're adding a file called mypackage/myfile.properties to the SCM server, and you enter resources into the prefix field, the file will be exported as:

resources/mypackage/myfile.properties

You may want to add a path prefix for the following reasons:

  • To create a special subdirectory for resource files to reside in
  • To control the directory structure of resource files that are added to the SCM server or loaded from it later
All .java and .class files are automatically imported directly into your project and placed into packages. The path prefix doesn't affect the names of these file types except when adding new types to the SCM server, in which case the path prefix will prepend the file name.

Conclusion
Source code control is an integral part of the code development cycle. There are numerous software configuration management tools available to help developers track and store their source code. This availability means that developers must determine not only which SCM tool is best for their use, but also how to make that tool work with other development products.

The External Version Control tool in VisualAge for Java, version 3.5, allows you to interact with several external software configuration management systems, enabling you to take advantage of VisualAge for Java's powerful development environment while enjoying the benefits provided by your SCM tool.

Author Bios
Tim deBoer is developing tools to build applications that run on the WebSphere Application Server. He previously worked with the VisualAge for Java technical support group, providing support to enterprise developers. [email protected]

Steve Francisco is a software developer with IBM Canada and is currently working on the architecture and development of VisualAge for Java. [email protected]

Ellen McKay is an information developer at IBM. Currently, she writes online help for various VisualAge for Java components, including the IDE, team programming, and external version control. [email protected]

 

All Rights Reserved
Copyright ©  2004 SYS-CON Media, Inc.
  E-mail: [email protected]

Java and Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. SYS-CON Publications, Inc. is independent of Sun Microsystems, Inc.