Sun Java Studio Creator 2 and Version Control: Part 2

Sun Java Studio Creator 2 and Version Control: Part 2


In my blog entry, "Sun Java Studio Creator 2 and Version Control: Part 1, I discussed how to get started using Java Studio Creator 2 and CVS.  In this blog I'll show you how to checkout a module. I will also discuss some of the common project artifacts and scenarios for version control including JSP files, Java backing beans files, and the navigation file.

Checking Out a Project

In CVS, to get started with something you need to do a "check out".  You check out at the module level.  As you've probably guessed by now, a CVS module is a Java Studio Creator 2 project.  To check out a project, you first need to set up a CVS working directory.  This is the directory that you will contain all your CVS controlled Java Studio Creator 2 projects.

First, from the "Versioning" menu, choose "CVS->Check Out...".  When the CVS Check Out" dialog opens fill in the details pointing to a directory that you want to be a working directory.

working directory

You will have to type the module name in because there is currently a defect in the "Select..." button functionality causing no modules to be found.  I've filed a defect and hope to get this fixed very soon.  Remember the module name is the project name.  While the defect makes this process less convenient, typing in the project name isn't lots of work.

Now from the "View" menu, choose "Versioning->Versioning".  You'll see something similar to the following diagram with all the working directories you've defined.  When you create a new project that will be controlled via CVS, you should create use the working directory as the root for the project.  This will allow you to keep all your shared projects in the same working directory.  If you don't follow this practice, you might have several working directories making tracking project versions very difficult.

working directories

The Versioning window reflects entries in a files in your user directory called "userdir/config/VCSMount/org-netbeans-modules-vcs-advanced-CommandLineVcsFileSystemXX.xml".  This means if you ever delete your user directory, you will loose these Versioning mount points.  There will be one file for each mount point.

Working With JSP Files

Scenario 1 - One user changes a component on the JSP page

Description: User1 has Page1 open that shows a static text field saying "Hello World".  User2 opens Page1 of the same project, changes "Hello World" to "I like Ice Cream".  User2 then "commits" the change through CVS in Creator.

Result:  If User1 does a CVS "update", when they do any action in the visual designer that requires a refresh, they will see the static text saying "I like Ice Cream".  User1 can also refresh the page to see the changes.

Tips: User2 must "Save" his changes before committing.  The CVS commit action will not automatically save everything changed.

Scenario 2 - Two users change the same component on the JSP page

Description: User1 has Page1 open that shows a static text field saying "Hello World".  User2 opens Page1 of the same project, changes "Hello World" to "I like Ice Cream".  User2 then "commits" the change through CVS in Creator.  User1 changes the Page1 static text field to say "I hate Ice Cream".  User1 then "commits" the change through CVS in Creator.

Result:  User1 will see the following log.

cvs commit: Examining sharedapplication1
cvs commit: Examining sharedapplication1/conf
cvs commit: Examining sharedapplication1/nbproject
cvs commit: Examining sharedapplication1/src
cvs commit: Examining sharedapplication1/src/sharedapplication1
cvs commit: Examining sharedapplication1/web
cvs commit: Up-to-date check failed for `sharedapplication1/web/Page1.jsp'
cvs commit: Examining sharedapplication1/web/WEB-INF
cvs commit: Examining sharedapplication1/web/resources
cvs [commit aborted]: correct above errors first!

The key is "Up-to-date check failed for `sharedapplication1/web/Page1.jsp". User1 needs to do a CVS "update" to get past this problem.  When User1 does an update, they'll see output similar to this.

conflict window

There will be a conflict "C" between the changes.  To resolve the conflict, on the "Versioning" window, select the file in question, right-click and choose "Resolve Conflicts".  You'll be presented with a window like the following.

jsp with conflict

User1 needs to choose which change they want from the right or left window and select "Accept" in that window.

Tips:
  • The conflict resolution and merging happen on a line by line basis.  This means making two different changes, like different style changes (e.g. bold,italic), to the same component will not result in a merge but rather a conflict.
  • If User1 makes a cosmetic change in the visual designer to a button and User2 double-clicks the button, adds backing bean action code and then commits the change, User1 will get a conflict on the button.  The conflict will arise because double-clicking on the button in the visual designer adds an "action" attribute.


Java Backing Bean Files


Scenario 3 - One user changes Page1.java

Description: User1 has Page1.java open.  User2 opens Page1.java and adds a method "getIceCream()". User2 commits the changes.

Result:  If User1 does a CVS "update", they will see the method "getIceCream()" in Page1.java.

Tips:
  • User2 must "Save" his changes before committing.  The CVS commit action will not automatically save everything changed.
  • If User1 has been making modifications via the visual designer that impact the Java backing bean Page1.java, User1 may get a conflict when they do an "update" than can easily be fixed with a "Resolve Conflicts".




Scenario 4 - Two users changes Page1.java

Description: User1 has Page1.jsp open in the visual designer.  User2 opens Page1.java and adds a method "getIceCream()". User2 commits the changes.   User1 double-clicks a button and is looking at the action method for the button in Page1.java.  User1 adds code to the action method and commits the change.

Result:  If User1 does a CVS "commit", they will see the following in the output window.

cvs commit: Up-to-date check failed for `Page1.java'
cvs [commit aborted]: correct above errors first!
 If User1 does a CVS "update", they'll see something like the following.

merged

You'll notice the changes were "Merged" in Page1.java.



The JavaServer Faces Navigation File (navigation.xml)


Scenario 5 - One user changes page navigation

Description: User1 has the navigation editor open.  User2 adds  "Page2" and adds a navigation rule from the button on "Page1" to "Page2".  User2 then does a CVS "add" for Page2.jsp and Page2.java.  User2 then does a CVS "commit".

Result:  Three files will be modified;
  • managed-beans.xml - Page2.java will be added as a JavaServer Faces managed bean
  • Page1.jsp - the button used to navigate will have the "action" property added.
  • navigation.xml - a <navigation-rule> will be added for navigating from Page1 to Page2.

If User1 does a CVS "update",  the will see the new page in the navigation rule in the navigation editor.
Tips:
  • When doing a CVS "update", do it from the project directory level so you get all affected files.  Since Java Studio Creator can change many files with a single visual action like adding a page navigation, you will miss added/modified files if you try to only update at the file level or a directory within the project directory.


Scenario 5 - Two  users changes page navigation

Description: User1 has the navigation editor open and adds "Page3".  User1 then adds a button to "Page2" and draws a navigation from "Page2" button to "Page3". User2 has the navigation editor open and adds "Page4".  User2 adds a navigation rule from the "Page2" button  to "Page4".  User2 then does a CVS "add" for Page4.jsp and Page4.java.  User2 then does a CVS "commit".

Result:  Three files will be modified;
  • managed-beans.xml - Page4.java will be added as a JavaServer Faces managed bean
  • Page2.jsp - a button was added. 
  • navigation.xml - a <navigation-rule> will be added for navigating from Page2 to Page4.

If User1 does a CVS "commit",  the will see an up-to-date error.  User1 will then have to do a CVS "update".  After doing the CVS "update", User1 will see the following in the VCS output window.

navigation conflicts


As you can see, there will be conflicts in the managed-beans.xml as well as the navigation.xml.  Also, the merge last the navigation User2 put in going from "Page2" to "Page4".

If you "Resolve Conflicts" on the managed-beans.xml, you'll see the this dialog.

conflict resolution1

Resolving the managed-beans.xml Conflicts

You can see that the merge couldn't distinguish that both User1 and User2 added a page.  To get out of this situation, User1 will need to "Accept" the "Working File", the one on the left, then re-add the managed-bean entry for Page4.  Before User1 accepts, User1 must copy the "Revision x.x" pink highlighted text by highlighting the text and hitting "CTL-C".  User1 must then open the "managed-beans.xml" file from the "Files" window under "web->WEB-INF" and near the end of the right before the </faces-config> tag and do a paste "CTL-V".

Resolving the navigation.xml Conflicts

The merge also leaves the navigation.xml file broken.  To fix this, User1 will need to accept the "working file" changes then re-add the navigation link from a new button on "Page2" to "Page4".

Tips:
  • Restrict Page Navigation Editing By Assigning "Keeper" - Since the merging and conflict resolution don't work that well when page navigation is changed by multiple users, assign a page navigation "keeper".  The keeper will be solely responsible for editing the page navigation. 
  • Specify Multiple Navigation Files -  


This technique involves having multiple navigation files.  The problem with this solution is that Java Studio Creator will only recognize the "navigation.xml" file when the visual navigation editor is opened.  This means only one developer will be able to visually edit the navigation file.

Steps to create multiple navigation files.

  1. For the user who will NOT have the "navigation.xml" file,  from the "Files" window, right-click on the "navigation.xml" file and do a "copy".
  2. Select the "web/WEB-INF" folder and do a "paste".
  3. You will now have "navigation_1.xml".
  4. Edit "navigation_1.xml" by double-clicking on it and choosing the "Source" view.
  5. Manually change the navigation rules to only include the rules you will be adding/maintaining.
  6. Edit the "web.xml" file by double-clicking on it.
  7. Expand the "Context Parameters" node.
  8. Select the "javax.faces.CONFIG_FILES" line and select "Edit".
  9. In the "Param Value:", add ",/WEB-INF/navigation_1.xml" to the end of the string.  Don't forget the comma separating the entries.
editing web.xml

Comments:

Post a Comment:
  • HTML Syntax: NOT allowed
About

David Botterill

Search

Archives
« April 2015
SunMonTueWedThuFriSat
   
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
  
       
Today