| Oracle® Application Development Framework Developer's Guide 10g (10.1.3.1.0) Part Number B28967-01 |
|
|
View PDF |
| Oracle® Application Development Framework Developer's Guide 10g (10.1.3.1.0) Part Number B28967-01 |
|
|
View PDF |
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 |Extensions | 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 files within a multi-file component synchronized, for example, by automatically checking out all the files that are dependent on a file that you expressly check out. However, when working with Oracle ADF-base JSP pages, you should be conscious of the dependencies between the various, related artifacts.
For example, when you commit a JSP page like SomeName.jsp, if changes you made in JDeveloper have caused the associated SomeNamePageDef.xml file to be modified, it will also appear in the Outgoing page of the Pending Changes window. On the other hand, if SomeName.jsp is a new JSP page on which you've dropped some databound controls, its associated SomeNamePageDef.xml file will also appear in the Candidates page of the Pending Changes window, and the DataBindings.cpx file will appear as a modified file in the Outgoing page. By understanding these relationships, you can better decide which files need to be committed together as part of the same CVS transaction to ensure that other developers who update their project from the source control server receive a consistent set of related files.
Most JDeveloper and ADF objects will be created only once per project and will by definition have the same name regardless of who sees or uses them. However, some objects like database connections could theoretically be left to the creativity of each team member in their own JDeveloper environment, even though they map to the same connection details. Avoid such naming differences for otherwise common connection definitions when working with ADF under version control since the discrepancy will cause unnecessary differences in your data-sources.xml files. Team members should agree up front on a common, case-sensitive connection name and that should be used by every member of the team.
In general, you should commit your work after it has been tested and are satisfied that it is working. The longer you work on a set of components without testing the changes and checking them in, the greater the chances that other developers will have modified them too, resulting in merge conflicts and the need to resolve them.
Make sure to have an active CVS connection open in the CVS navigator when you are performing any kind of renaming or refactoring operations. If you do so, these will be automatically handled as appropriate file deletes and adds in the source control system. If you are not in the context of a CVS connection when you make these kinds of changes, then the next time you connect to source control, your renamed files may inadvertently show up as new files.
When renaming files (for example, through refactoring), you should commit the files as soon as practicable after you have renamed them. This is because 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. However, you should still test the changes before committing them. A typical scenario would be to refactor the files, then rerun the unit tests, then commit the files.
When developing new features, you may have to depart from the normal rule of unit testing files before committing them, if other members of the team need to work on the files in order to complete the unit of work that is to be tested. In this case, the files will need to be committed before testing so that other members of the team can obtain them from the CVS repository.
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.
You could use Apache Ant, which is integrated into JDeveloper, to create a script that will automatically check out the full source and build it. If the build completes successfully, this will be confirmation that everyone has committed all the changes required to make the system perform correctly. Otherwise, the build will break and problems will be signalled. To find out how to use Apache Ant to create build scripts, search for "About Ant Integration in JDeveloper" in the JDeveloper online help.
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 force it to reflect the rule change. It also ensures that the faces-config.oxd_faces file is marked for commit and that the two files will not get out of synchronization.
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.
