Subscribe to WebSphere: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get WebSphere: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

IBM WebSphere software products Authors: Liz McMillan, Pat Romanski, Yeshim Deniz, hyper filter, Timothée Bensimon

Related Topics: Software Configuration Management, WebSphere

SCM: Article

Teamwork in WebSphere Studio - Software configuration management makes it easy

Teamwork in WebSphere Studio - Software configuration management makes it easy

So what does teamwork in WebSphere Studio mean anyway? At one level it means being able to work on code within a shared environment through which your application can be executed and tested. WebSphere Studio already has great support for the deployment and testing of such shared development. At another level, however, it means being able to share the development effort itself.

Software configuration management (SCM) is one means through which development effort can be shared. Even prior to deployment and testing, developers can become aware of other developers' changes and assess their impact. With a good SCM tool, this form of interaction can take place between developers even in separate geographic locations and time zones - all in a controlled manner. Along with actual code changes, the history and the design reasoning can be preserved, and there is an overall improved sense of communication between all developers.

State of Play
As the adoption rate of WebSphere Studio tools continues to climb, so do the number of plug-ins available from independent software vendors (ISVs). This highly flexible and adaptable interface has allowed everyone who ever said "I wish it could do this, in this fashion" to go ahead and add useful and productive tools to the WebSphere Studio family of products.

See the Resources section for the link to IBM's Plug-in Central, which offers a complete list of IBM "Ready For WebSphere" Certified plug-ins.

Some of the earliest adopters of WebSphere Studio were SCM companies. Historically, integrated development environments have had many different ways to access source code controlled in repositories. Some of these methods include standard and custom APIs or script/command line-based access. All SCM integrations out there do pretty much the same thing in very similar ways. They allow complex development teams to manage and develop multiple projects by sharing the code base in a controlled manner. Developers have access to the tools they need to perform their day-to-day activities within the WebSphere Studio interface, reducing the amount of application and window switching. This helps them stay organized and efficient because they can get all of their information on the projects they are working on from within one tool. So, how do SCM plug-ins help developers?

Access to SCM Commands
While exploring the WebSphere Studio context menus you may have noticed a Team menu. You probably just scratched your head and thought, "I wonder what this is for? All of the options are grayed out anyway." "Team" is what the WebSphere Studio interface calls source configuration management. Once you have installed an SCM plug-in, this is where all of your source code control menu items will be located. Most likely the list includes Check Out, Check In, Add, Drop, Resynchronize, and many others (see Figure 1).


Many providers will also include a menu in the main toolbar, or a set of buttons to access the tool. As with other features of WebSphere Studio, this is totally configurable on a perperspective basis. For more information, see the WebSphere Studio help on how to customize a perspective.

Text/Label Decorators
Who doesn't love pretty little pictures? If a plug-in offers this feature (see Figure 2), it means that it enhances (or replaces) the existing file icons in any view that shows resources (files, folders, and projects). There is also the capability to append the filename with more information in a textual format. The types of questions this information can answer include:

  • Do I have the most recent version of this file?
  • If so, what version am I working on?
  • If not, how far behind am I?
  • Is the file locked?
  • If so, by whom?
  • Does my local file differ from the archived version?

    This information is helpful for many reasons. Perhaps you run a build of your project and get some compile errors in files you haven't touched recently. Perhaps those files are simply out of date because another user has changed them. You can quickly see which files have changed in your workspace and evaluate which you may (or may not) need to resynchronize to get a successful build. Locking a file (which will show in other users' workspaces) informs developers that they may wish to wait to make changes to a specific file.

    There are also different locking styles that SCM vendors use. One of these models is optimistic locking. You can get any file at any time and conflicts are resolved on check-in by performing merges. Optimistic models require what is known as "conflict resolution."

    The contrast to this is pessimistic locking, which means that once a file is locked by a user, all other users are made aware ahead of time that if they make a change to that file they will need to do a merge later. A pessimistic model is often referred to as a "conflict avoidance" approach. Some SCM tools allow you to see what you have locked, as well as what files are currently locked by other users. This allows the user to decide whether to perform a merge once changes have been made, or to just wait until the file is checked in by the previous user and then make changes (see Figure 2).


    Team Project Sets
    The Import item under the File menu houses many different ways to get files, folders, and projects into the workspace. One of the options is to import a Team Project Set. What this command allows you to do is to import an entire workspace at one time. So if you have a complicated application structure with many related projects, you can import all of them at once! This is an extremely powerful feature that can be used to replicate workspaces on any computer in a single step.

    The way this works is your team lead sets up his or her workspace and all of the project relationships, classpath, compile options, and other WebSphere Studio-specific project information. Then they create a Team Project Set file (.psf extension) from the File menu by choosing Export. This file is really just XML-formatted instructions that tell the application how to re-create the workspace. Don't worry if you don't see everything in there that you think it should have. This information is cryptic and meant to be read by the application and not by the user. All of the project metadata and relationship information is kept in the .project file that WebSphere Studio creates for each project. When the workspace is populated during an import, all of that information is still there because the .project file is archived.

    Preferences Are Your Friends
    There is also a section labeled Team in the main WebSphere Studio preferences panel. Here you can find some generic preferences that can affect how SCM plug-ins behave, as well as specific team provider preferences. Many SCM vendors allow you to tell the backing repository how to store files. The two most common options are as text files and as binary files. The File Content preference page allows you to specify which of the two options you would like to use based on file extension.

    Another vendor-generic page is the Ignored Resources page. This page allows you to use regular expressions to specify files or directories that you would like the SCM system to ignore completely. Common things to specify here are bin directories and test file extensions (.bak, for example). This can be an incredibly useful tool when performing large operations.

    Some of the vendor-specific information that may also be here includes things such as connection and server information, and behavior specifics. You may choose to have every action in the workspace echoed directly in the repository, for example.

    SCM plug-ins allow developers to access everything they require - from a source standpoint - from within a single interface. The aforementioned features highlight some of the principal ways that these plug-ins assist users with their daily development activities. Enterprises are looking more and more for interconnected solutions to standardize on across an organization, and the WebSphere Studio architecture has allowed for tight integrations to seamlessly incorporate applications.


  • WebSphere Studio Plug-in Central: www7b.software.ibm.com/wsdd/downloads/plugin/index.html
  • Ready for IBM WebSphere Studio software validation: www.developer.ibm.com/websphere/ready.html

    Tips for Developers Using an SCM Tool
    1.  Check in changes often to preserve a development history. This also allows others to integrate your changes.

    2.  Integrate early and often. Incorporate others' changes to stay current.

    3.  Mark milestones (checkpoint) via your SCM tool. This also allows you to roll back to a stable state in the future, if needed. Milestones also provide a basis for branching and parallel development.

    4.  Use SCM to implement process-driven change management. Other things to consider are notifications, integrations, and administration with tools and defect-tracking systems.

  • More Stories By Adam Terrenzio

    Adam Terrenzio is a lead application developer on the product integrations team at MKS Inc., an enterprise software configuration management vendor (www.mks.com), primarily responsible for the IBM WebSphere Studio products and other IDE integrations. Adam works at the MKS Inc. worldwide headquarters in Waterloo, Ontario, Canada. Contact Adam at [email protected]

    Comments (0)

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.