WebSphere Studio Application Developer Version 5 Programming Guide part 76 pot

Second developer creates the TransRecord beanCreate the TransRecord entity bean with three CMP fields and no extra logic: ? timeStamp—java.util.Date, key attribute ? transType—String, pr

Second developer creates the TransRecord bean

Create the TransRecord entity bean with three CMP fields and no extra logic:

򐂰 timeStamp—java.util.Date, key attribute

򐂰 transType—String, promote to local

򐂰 transAmt—int, promote to local

Second developer synchronizes with repository

To update the repository, select the ItsoProGuideCVS project and then Team -> Synchronize with Repository from its context menu The project is then

compared with the repository, and the differences shown in the Synchronize

view

There are still no conflicts, because the first developer has not yet synchronized the changes Add the new files to version control and commit the changes to the repository When asked, enter the commit comment:

Added TransRecord bean

Resolving conflicts (step 5 - stade1)

In this step, we will have the first developer synchronize the changes to the repository This time around, though, some conflicts will arise These conflicts are related to files that both developers changed

Open the J2EE Navigator view and select the ItsoProGuideCVS project Select

Team -> Synchronize with Repository from its context menu to open the

Synchronize view

The Synchronize view lets you inspect the changes to both the workspace and the repository By clicking the mode buttons on the view’s toolbar, you can limit what it displays The available modes are:

򐂰 Incoming mode—Shows changes to the repository that have to be copied to

the workspace, as well as conflicts

򐂰 Outgoing mode—Shows local changes to the workspace that have to be

copied to the repository, as well as conflicts

򐂰 Incoming / outgoing mode—Shows both workspace and repository

changes, as well as conflicts

򐂰 Conflicts only—Shows only the conflicts

Click Incoming / Outgoing Mode in the toolbar (Figure 22-26)

Figure 22-26 Synchronize view showing conflicts

Note that we have three steps to take to synchronize the first developer’s

workspace with the repository:

򐂰 Add the Account bean related files to the repository (outgoing)

򐂰 Retrieve the TransRecord bean related files from the repository (incoming)

򐂰 Resolve conflicts with the deployment descriptor (ejb-jar.xml) and the WebSphere extensions descriptor (ibm-ejb-jar-bnd.xmi)

Select the itso folder and select Commit from its context menu When asked, enter the Commit comment:

Added Account bean

Note that the files related to the Account bean have disappeared from the Synchronize view, because they are now synchronized with the repository Select the itso folder again, but this time select Update from Repository from its context menu The whole folder is removed from the Synchronize view

We now have to handle the conflicts Double-click the ejb-jar.xml file (the EJB deployment descriptor) to open the Text Compare pane, which shows you the differences between the file in the workspace and in the repository

Incoming / Outgoing Mode

Conflicts

Mode buttons

Outgoing

Incoming

Figure 22-27 Resolving conflicts with the EJB deployment descriptor (step 1)

Merging the changes

Our task is to merge the changes of both developers:

򐂰 The left-hand side shows the file as it is in the workspace, with two entity EJBs: Customer and Account

򐂰 The right-hand side shows the file as it is in the workspace, with another pair

of EJBs: Customer and TransRecord

򐂰 The only difference between the files is that one has a TransRecord bean declared exactly where the other declares an Account bean The compare tool perceives this as a change, and not as a parallel addition We have to make up for it manually

In the right-hand pane, select the TransRecord bean declaration, that spans from the <entity id="TransRecord"> tag to the </entity> tag, and select Copy from its context menu

Workspace Repository

Now position your cursor right before the </enterprise-beans> tag on the left-hand panel Select Paste from the panel’s context menu and format the addition as shown in Figure 22-28

Figure 22-28 Resolving conflicts with the EJB deployment descriptor (step 2)

Now click Save on the left-hand pane’s context menu to save the changes Application Developer informs you that the changes have been saved and that you should select Mark as Merged to make this file an outgoing change

(Figure 22-29)

Figure 22-29 Mark as merged informational dialog

This means that Application Developer is assuming, as you have saved the local file, that you have manually corrected the conflicts that were displayed Thus, the next step is to copy the local file over the file in the repository., but first you must mark the file as merged

Click OK to close the dialog The Synchronize view shows you that the EJB deployment descriptor have been saved and should be marked as merged by placing an asterisk right next to the file name (Figure 22-30)

Figure 22-30 Marking the EJB deployment descriptor as merged Select the ejb-jar.xml file and select Mark as Merged from its context menu The Synchronize view is updated to reflect an outgoing change (Figure 22-31)

Figure 22-31 EJB deployment descriptor marked as merged

We now have to apply a similar procedure to the WebSphere extensions descriptor Double click the ibm-ejb-jar-bnd.xmi to open the Text Compare

pane (Figure 22-32)

Figure 22-32 Resolving conflicts with the WebSphere extensions descriptor (step 1) Similarly to the deployment descriptor, the file in the workspace declares JNDI bindings for the Customer and Account beans The file in the repository declares JNDI bindings for the Customer and TransRecord beans These three bindings have to be combined in the workspace

Select the binding declaration for the TransRecord bean on the right-hand pane, copy it and paste it on the left pane after the binding declaration for the Account

bean (Figure 22-33)

Save your changes by selecting Save from the left-hand pane’s context menu Mark the file as merged just like you did before

Finally, select the META-INF folder and select Commit from its context menu Enter the commit comment: Added Account bean

The Synchronize view should go empty because there are no more differences between the workspace and the repository, and the J2EE Navigator view should

be updated as shown in Figure 22-34

Figure 22-34 J2EE navigator view showing all the entity beans synchronized

Versioning (step 6 - stade1)

Now that all the changes are synchronized with the repository, we want to create

a version to milestone our work

Select the ItsoProGuideCVS project in the J2EE Navigator view and select Team -> Tag as Version from its context menu The Tag Resources dialog opens (Figure 22-35)

Figure 22-35 Tagging the project as a version Type EntityBeansCreated as the version tag and click OK If you now switch to the CVS Repository Exploring perspective, you can see the version in the CVS Repositories view (Figure 22-36)

Figure 22-36 Project version

If you expand the ItsoProGuideCVS project you can also see the versions of all the files

CVS resource history

At any time, a developer that has the shared project in their workspace can view the resource history of a file This is the list of all the revisions of a resource in the repository, shown in the CVS Resource History view From this view you can compare two revisions, replace or revert the corresponding workspace file to the revision, or open an editor on a revision

Select the ejb-jar.xml file in the J2EE Navigator view and Team -> Show in Resource History (context) The CVS Resource History view opens (if not already open) and shows the change history of the file (Figure 22-37)

project version

Figure 22-37 CVS Resource History view For each resource the table displays:

򐂰 Revision—The revision number of the revision in the history A * in this

column indicates that this is the current revision in the workspace

򐂰 Tags—The tags that are associated with the revision Selecting a revision line

will list the tags in the lower left pane of the view

򐂰 Date—The date and time when the revision was created.

򐂰 Author—The name of the person who created and authored the revision.

򐂰 Comment—The comment (if any) supplied for this revision at the time it was

committed Selecting a revision line displays the complete comment in the lower right pane of the view

In our case, the developer has version 1.3 of the resource, as indicated by the *

in the Revision column

To compare differences between revision 1.3 and 1.4, select both lines and

Compare (context) The compare view is displayed (Figure 22-38)

We can see the differences between the two revisions: the Account entity was added to the XML file

Note: Figure 22-37 displays the resource history for developer 2, who has not

synchronized with the repository to pick up the merge done by developer 1 The same resource history for developer 1 would mark revision 1.4 as current

Figure 22-38 Compare ejb-jar.xml version 1.3 to version 1.4

Branches in CVS

In CVS, teams share and integrate their ongoing work in branches Think of a branch as a shared work area that can be updated at any time by team members In this way, individuals can work on a team project, share their work with others on the team, and access the work of others during all stages of the project The branch effectively represents the current shared state of the project Resources can be changed in the Workbench without affecting the branch Individuals must explicitly provide their changed resources to the branch Every CVS repository has at least one branch, referred to as HEAD Under certain conditions, more than one branch may exist in a repository For example, one branch may be for ongoing work, and another branch may be for maintenance work