Tips for using CVS with JDeveloper

Versions
Server: Linux OS, CVS Version 1.11.1p1
Client: Windows XP, JDeveloper 10.1.3.1 using ADF BC / Faces
Other tools (non-mandatory but good to have), PuTTy, PAgent, PGen PSftp

Overview of the Setup Process
Create a generic user to own the CVS Repositry and a group which all the CVS users will belong. Create a user for each developer and add them to the same group.
To create a server repository as the generic user the command is:
cvs -d /oracle/cvs/CVSROOT init

JDeveloper uses a private public key pair and SSH2 (other protocols available) to connect to the CVS. The key pair is generated in JDeveloper and the public key has to be manually added to the users authorized_keys file in the .ssh directory within the users home directory. The CVSROOT is the root directory of the CVS repository which is created by the CVS owner mentioned above.

Key Points About Using JDeveloper with CVS
Using JDeveloper with a CVS will break dependencies within the project which are normally enforced by JDeveloper in single user mode. When updating your project from the CVS the dependencies between objects are not enforced resulting in objects becoming out of sync. For instance a standard ADF BC View Object may consist of two files, its XML definition and View implementation file. It will also be referenced by one or more Application Module(s) and possibly a Viewlink. To prevent missing references and broken dependencies all the referenced / referencing objects must be included when committing and updating the CVS.
Open and close the project if there are dependency errors that do not seem to be correct.
CVS does not implement locking, it is the developers responsibility to make sure that the files they wish to work on are up to date. If two developers have worked on a file simultaneously a merge will be required when synchronising the CVS.

How do I know if my source is up to date with the CVS?
The key to getting the CVS JDev integration working properly is using the Pending Changes window effectively. Within this window are three tabs, Outgoing, Incoming and Candidates. Outgoing contains changed items which are not up to date with the CVS. Incoming displays items are new or the local copy is out of date with the CVS. Candidates are files not yet checked in with the CVS. The most important tab in the Pending Changes window is the Incoming Tab. Watch this one with care as incoming changes are NOT reflected in the Application Navigator unlike other file statuses. New files are not shown in the Application Navigator because they are not in the project but may be referenced by existing objects updated from the CVS. Using the Incoming tab is key to keeping the project in sync.

Minimising Pain and Suffering with CVS
Develop your model first and view second. If the model is not complete before development of the user interface it is worth finalising it first. The reason being is that the user interface (JSP's, pageDef's and Databindings.cpx) are a lot easier to fix than the data model when the project gets out of date and or needs to be merged. Most people will do this anyway, but it not always the case that the model is completed first.
Commit all changes regularly and especially before leaving at the end of the day. In the morning check the Incoming tab and update as necessary.
Occasionally perform a full checkout of your project from the CVS. This will cause any synchronisation issues to come to the surface and recover any missing files from backup if necessary.
Have the Li/Unix administrator include the CVS in the server backups.

Project Files and the CVS
The project JPR files often report conflicts which cannot be resolved by merging or committing changes. Fortunately JDeveloper is smart enough to pick up any stray/new files and add them to the project. Close and open the project and if all files are present force an unchanged commit of the project JPR file.

Bugs and Annoyances
View link files are continually 'touched' when the AM is updated resulting in them being in changed status continually even though they are not out of date with the CVS. This also clutters the Outgoing tab which is a pain if some of them are legitimately updated.
JDeveloper occasionally hangs when performing some CVS actions from the navigator. CVS actions issued from the Pending Changes window seem to be more reliable.
Occasionally some files are not recognised as an Object (such as a VO) and are displayed as their individual files in the Application Navigator. If this happens close and reopen your project and the object will reappear and its supporting files will be attached.

Further Reading
Oracle® Application Development Framework Developer’s Guide For Forms/4GL Developers (chapter 32 Working Productively in Teams) This manual can be downloaded from otn.oracle.com

ADF Faces – First Impressions

The much anticipated JDeveloper 10.1.3 was released at the end of January 2006 and definitely lived up to expectations among the JDeveloper community. The slick new interface boasts some really great features including significant enhancements in the code editor and overall feel of the IDE.

So what about Faces? ADF Faces is based on the JavaServer Faces industry standard framework. An open source implementation of JavaServer Faces called MyFaces has been [donated] to the Apache Foundation by Oracle.

The persistence layers offered by JDeveloper are ADF Business Components and Toplink. Oracle has released fully working example application called the SRDemo which is a simple service request system. The aim of the SRDemo is to solve most of the design woes faced by any developer starting out on green fields J2EE web application. SRDemo is written in ADF Faces (JSP) using TopLink and use J2EE container security for authentication and authorisation.

Why TopLink? TopLink is a POJO (plain old java object) based approach to creating an object-to-relational persistence layer. TopLink uses and EJB (Enterprise Java Bean) session façade and provides a full declarative (XML) persistence layer defined in what’s called a TopLink map. One really nice feature of TopLink is named queries; Named queries encourage the reuse of TopLink entities by exposing different operations on the entity (such as setting or changing conditions) by exposing methods through the Session Façade bean. I was impressed with TopLink, because it has some original and well implemented ideas. The POJO approach unpacks all the complexity which is hidden in ADF BC, which can be a bit daunting when starting out with the TopLink framework.

There are some significant improvements with ADF BC including some out-of-the-box goodies which either didn’t work or were a headache to implement in 10.1.2. Read-only view objects are great as well as dynamic view criteria. For those coming from an Oracle Forms or non-OO background, ADF BC is an easier transition than TopLink and is a mature and robust framework to go with.

The actual ADF Faces user interface can be implemented in two ways, a JSP (Java Server Pages) or a JSPX (XML Document). The faces lifecycle and faces-config.xml implements the controller layer providing the interaction between the model and view layers. ADF Faces provides an abundant set of UI components which give a consistent looking and rich user interface. Strong support for expression language makes binding components to the model a breeze. The backing bean and managed bean concept has also greatly simplified managing events.