|
Oracle® Application Development Framework Developer's Guide
10g Release 3 (10.1.3) B25386-01 |
|
 Previous |
 Next |
|
Oracle® Application Development Framework Developer's Guide
10g Release 3 (10.1.3) B25386-01 |
|
|
Previous |
Next |
This section contains advice specifically for using CVS with an ADF project, for example the SRDemo application.
A CVS client lets you import your work into CVS or check it out from CVS control. The CVS client can be a standalone program, or it can be integrated into an IDE, as it is with JDeveloper. The SRDemo application was created using the JDeveloper internal CVS client.
You set up JDeveloper to use CVS by ensuring that Support for CVS n.n is checked on the Extensions preferences page (Tools > Preferences |Extensions | Versioning Support n.n | Configure) and that CVS is selected from the dropdown list on the Versioning preferences page (Tools > Preferences | Versioning).
Preferences for using CVS are set by selecting Tools > Preferences | Versioning | CVS and its subpages.
The SRDemo application was created using the default preferences for CVS, although you may want to consider setting the timeout to ten minutes (Operation Timeout on the General subpage), especially if you have a slow connection to a remote server.
JDeveloper will work with the CVS version control system to keep dependent files in step. However, when working with ADF pages, you should be aware of the dependencies between the various ADF objects that you use. For example, when you commit a JSP page, you may also need to commit the associated pageDef and DataBindings.cpx files.
JDeveloper does not normally change the application control (.jws) and project control (.jpr) files unless necessary. However, some changes that are made to these files by JDeveloper may not be required for ADF development. To avoid possible versioning conflicts, only commit the application and project control files (using Versioning > Commit) when a change caused by ADF work has been made to them.
Most JDeveloper and ADF objects will be created uniquely and will by definition have the same name, whoever sees or uses them. However, some names can be assigned differently by different team members, even though they apply to the same item. Such naming differences should be avoided when working with ADF under version control. For example, database connections should all be given the same name (in the same case) by every member of the team.
In general, you should commit little and often (Versioning > Commit), although this should be when the work you have done is functionally complete or ready to be shared by other developers. You should not, for example, commit work that does not compile, because another developer updating their code from the CVS module containing your committed work will not be able to continue to develop the module.
You won't have to commit every file that JDeveloper lists on the Outgoing and Candidates tabs of the Pending Changes window. Carefully consider whether a file is essential to the project before committing it. Be especially wary of using the Commit All button on the toolbar of the Pending Changes window.
Do not commit the WEB-INF\temp directory.
Commit a file as soon you have renamed it (for example, through refactoring). Renaming a file through JDeveloper involves a CVS delete operation and a CVS add operation, and an added file needs to be committed to make it available to other developers.
When committing work to CVS, always add comments describing the changes you have made. You add comments in the Comments box of the Commit to CVS dialog (Versioning > Commit).
It is preferable to perform, at regular intervals, a clean checkout from the CVS repository to a fresh directory (using Versioning > Check Out Module). Simply updating your working copy from the repository (using Versioning > Update) can hide problems such as incomplete commits.
If you manually add navigation rules to the faces-config.xml file (using the XML view or the Overview screen) you must switch to the visual diagram view of faces-config, before checking in the faces-config.xml file. Doing so will cause the diagram file (faces-config.oxd_faces) to register the metadata change and realise that it needs to reflect the rule change. It will also ensure that the faces-config.oxd_faces file is marked for commit as well, and that the two files do not get out of step.
If you don't do this, the diagram file will no longer be in step with the XML metadata and will give errors. If this happens, the solution is to manually delete the diagram file and let JDeveloper re-create it when it next attempts to open the file. That file is \model\public_html\WEB-INF\faces-config.oxd_faces under the userinterface/viewcontroller project.
