Level: Intermediate Colin Yu (coliny@ca.ibm.com), Software Engineer, IBM Toronto Lab
18 Feb 2002 This article, Part 1, introduces the team development environment and describes common team development scenarios with WebSphere Studio Application Developer 4.0.
Introduction One of the great features of WebSphereTM Studio Application
Developer (hereafter called Application Developer) 4.0 is its team development
environment. It adds version and configuration management capabilities to workspace
projects, and gives you multiple views of team features. Application Developer 4.0 supports three software configuration
management (SCM) products -- the open-source version control system known as
Concurrent Versions System (CVS), Rational ClearCase LT, and the full version
of Rational ClearCase. ClearCase LT is packaged with Application Developer 4.0,
and upgrades to the full version of ClearCase are available from Rational. Future
releases of Application Developer will support additional SCM products, with
direct connection between their repository clients and the workspace. This series of articles shows you how to do team development
with Application Developer. This article (Part 1) introduces the team development
environment and describes common team development scenarios. Part 2
shows you how to install and configure CVS as an SCM repository with Application Developer.
Team terminology in Application Developer Workspace The Application Developer workspace is a private work
area for the individual developer. It contains the folder structure of the projects
you're working on, which reside in the file system. It also contains the logs
and the plugin metadata. Application Developer can store a history of locally made
changes to files in the file system. You specify this option in the Workbench
preferences. The files are stored in a non-editable format in the directory
workspace/.metadata/.plugins/org.eclipse.core.resources/.history.
Figure 1.
To view the history of a file, select Compare with
or Replace with => Local history from the files context menu.
Figure 2.
Unlike with VisualAgeTM for JavaTM, when you delete files from
the workspace, you cannot recover them from the local history. The default location of the workspace is Program
Files\IBM\Application Developer\workspace. You may wish to configure
multiple workspaces to handle different development projects. Each workspace
is created as a folder in the file system where the source code will reside.
To start the IDE with a different workspace, execute this command: wsappdev
-data myworkspacedir where myworkspacedir
is the absolute path to the workspace folder. If you have enough memory, you can open multiple IDEs simultaneously
against different workspaces. If a workspace is not defined when you start an
IDE, it uses the default workspace in the installation directory. Repository A repository is a persistent store that coordinates
multi-user access to projects and team streams. VisualAge for Java users are
probably familiar with repositories. The only difference in Application Developer
is that repositories are managed by SCM products such as CVS or Rational ClearCase
LT. SCM vendors provide plugins that enable Application Developer to communicate
with their repository client. Communication between Application Developer and
the repository server is via TCP/IP. In ClearCase terminology, a repository
is a VOB. Stream A stream is a shared work area that lets team member
release their work and use code updates from others. The stream represents the
current state of a shared project. A repository can contain multiple streams
for different projects or different development stages, such as one stream for
new development and another stream for maintenance. In CVS terminology, a stream
is a branch. Synchronizing When you make changes in the workbench, resources are saved
in the local workspace. You need to release resources in order for other team
members to access them. At the same time, other team members may have released
updates to the stream, which you can access with Application Developer. Conflicts
arise when you modify a resource and try to release it when there is a more
recent version in the stream. In this situation, you can either catch up the
resource from the stream, release your version of the resource to the stream,
or merge your work and the stream resource. Branching A repository can branch into multiple streams, which
are distinguished by name. In a CVS repository, for example, a stream maps to
the main trunk HEAD or to a branch. When the same project appears in different
streams, the resources evolve independently. Changes released in one stream
have no effect on other streams until they are merged. Versions A version of a file resource captures the content of
the file. A version of a project captures the configuration of folders and files
as well as their specific versions. You can create new project versions as a
snapshot of the current configuration of a project either in a stream, or in
the workspace. In the team environment, you cannot explicitly version resources
other than projects, such as files or folders. However, they are automatically
and implicitly versioned when they are released to the stream.
Team perspective views in Application Developer Here are the default team perspective views in Application
Developer: Navigator The Navigator view shows all files in the workspace
except those defined by the assigned filters. The default filter removes all
.class files from the view. To turn this off,
choose Filters from the drop-down menu in the Navigator toolbar.
Figure 3.
Properties The Properties view shows properties of the currently selected
file in the workspace, including the time it was last modified and its size.
If an item in a repository is selected, this view shows the author, version
number, and comments. Repositories The Repositories view shows all repository connections and
their contained streams and versions. Synchronize The Synchronize view performs release and catch-up operations
and lets you view differences between files. Tasks The Tasks view displays the standard task window. Resource history The Resource history view displays the version history of
the selected item. By Default, Class files are excluded from version
control. You can add or remove filters using the Workbench Preferences.
Figure 4.
Team development scenarios This section explains typical team development scenarios with
Application Developer. You can choose the one best suited to your team, project,
and development process. Sequential development Sequential development is the simplest scenario. It assumes
only one developer working on a file at one time:
Figure 5.
In Figure 5 above, Developer 1 creates a file, FILEA, and
releases it to the stream. Developer 2 catches up the new version of FILEA in
his workspace from the stream, modifies the file, and releases it to the stream.
Now Developer 1 catches up the change of FILEA by developer 2, modifies it and
again releases to the stream. This cycle continues until FILEA is finalized. Parallel development in a single stream Sequential development is not realistic for most projects.
Usually, more than one developer works on a file in a single stream at the same
time, which is called parallel development. See Figure 6 below.
Figure 6.
Both Developer 1 and Developer 2 catch up version 1.3 of FILEA
from the stream. Developer 1 modifies it and releases it to the stream. At the
same time, Developer 2 modifies the file and is ready to release it, but first
must merge the changes by Developer 1 with his changes before he can release
it. Application Developer can automatically detect the conflict, compare the
files, and merge the changes. Branching using multiple streams If you're building and maintaining an application at the same
time, you don't want to release changes back into the main stream immediately.
The solution is to create a branch in the development process. The following
example shows how two developers create a branch. Developer 1 maintains the current version of the project,
while Developer 2 is working on new function. Developer 1 creates a new stream
(Stream 2) and copies Version 1 of the project into it from Stream 1. Developer
1 catches up version 1.5 of FILEA from Stream 2 into his workspace, fixes the
bugs, and releases Version 1.5.2.1 of FILEA to Stream 2. At the same time, he
versions the project as 1.1. Developer 2 catches up Version 1.5 of FILEA from
Stream 1, adds new function, and releases it to Stream 1 as Version 1.6. Now
Developer 2 should merge the change by Developer 1 in Stream 2 between Version
1 and Version 2 to Stream 1, and create Version 1.7 of FILEA. After the merge,
Developer 1 can delete Stream 2. See Figure 7 below.
Figure 7.
Acknowledgment The author wishes to thank Ying Zhao and Leying Zhu, Software
Development Analysts, IBM Toronto Lab, for reviewing this article.
Conclusion The Application Developer IDE includes a convenient team development
environment that can communicate with different SCM systems and support various
team development scenarios. I hope you have found this article helpful and I
welcome all feedback.
Resources
About the author  | 
| |
Colin Yu
is currently working with the IBM VisualAge for Java Technical Support group. He earned a Master's of Applied Science degree at the University of Waterloo, Ontario, and is Sun Java 2 Certified Programmer. He is also IBM Certified Specialist of WebSphere Application Server, VisualAge for Java, and IBM Certified Solutions Expert of WebSphere Studio. You can reach Colin at
coliny@ca.ibm.com
.
|
Rate this page
| 
