39 Working Productively in Teams
This chapter contains information about managing files in Oracle JDeveloper. It includes information about source control systems, namely CVS and Subversion.
This chapter includes the following sections:
-
Section 39.1, "Enabling Source Control on WebCenter Applications"
-
Section 39.2, "Understanding WebCenter Application Files Affected by Developers"
39.1 Enabling Source Control on WebCenter Applications
You can use CVS or Subversion for source control in a WebCenter application, similar to the way you would use a source control system in any other development environment.
There are two ways to use CVS or Subversion: In Oracle JDeveloper, either click the Versioning menu or use the Versioning Navigator (click View - Versioning Navigator). The Versioning Navigator is shown in Figure 39-1.
This section contains the following subsections:
For detailed information about CVS and Subversion, see the Oracle JDeveloper online help system and the "Using a Source Control System" section in the Oracle Application Development Framework Developer's Guide.
39.1.1 Importing Application Files into CVS
If you do not have your application files source controlled in CVS, then you must import them into CVS before you can get started.
To import application files into CVS:
-
In Oracle JDeveloper, from the Versioning menu, select CVS and then Check Out Module.
If you have a CVS connection, then you are taken directly to step 2. If you do not have a CVS connection, then you are prompted to create a connection, as follows:
Note:
An alternative way to create a CVS connection is to right-click CVS in the Versioning Navigator and select New CVS Connection. Any existing CVS connection is shown in the Versioning Navigator.-
If the Confirm Create Connection dialog appears, then click OK (Figure 39-2).
Figure 39-2 Confirm Create Connection Dialog
Description of "Figure 39-2 Confirm Create Connection Dialog"
-
In the Create CVS Connection wizard, on the Connection page, enter your connection information for CVS, then click Next (Figure 39-3).
Figure 39-3 Create CVS Connection - Connection
Description of "Figure 39-3 Create CVS Connection - Connection"
-
On the Root page (Figure 39-4), in the Value of CVSROOT field, enter a value for the CVSROOT. Click Next.
-
On the Test page (Figure 39-5), click Test Connection. The Log In to CVS dialog displays, as shown in Figure 39-6.
Figure 39-5 Create CVS Connection - Test Connection
Description of "Figure 39-5 Create CVS Connection - Test Connection"
-
Enter your password, and then click OK.
-
If the test is successful, then you should see something similar to Figure 39-7. Click Next.
Figure 39-7 Create CVS Connection - Test Connection Success
Description of "Figure 39-7 Create CVS Connection - Test Connection Success"
-
On the Name page, enter a value for Connection Name, as shown in Figure 39-8. Click Next.
-
The Summary page displays with the connection information. Click Finish (Figure 39-9).
Figure 39-9 Create CVS Connection - Summary
Description of "Figure 39-9 Create CVS Connection - Summary"
-
-
On the Check Out from CVS page, enter the application path.
-
Click OK to execute the import operation. You can see the connection now in the Application Navigator, as shown in Figure 39-10.
Figure 39-10 Application Navigator with CVS Connection
Description of "Figure 39-10 Application Navigator with CVS Connection"
39.1.2 Creating a Subversion Repository
To create a Subversion repository:
-
From the Versioning menu, choose Subversion, and then Create Repository. The Create Subversion Repository dialog displays (Figure 39-11).
Figure 39-11 Create Subversion Repository
Description of "Figure 39-11 Create Subversion Repository"
-
In the Create Subversion Connection dialog, enter connection details, and then click OK. (Figure 39-12)
Note:
An alternative way to create a connection is to right-click Subversion in the Versioning Navigator and select New Repository Connection.Figure 39-12 Create Subversion Connection
Description of "Figure 39-12 Create Subversion Connection"
-
Later you can edit these pages on the Edit Subversion Connection page (Figure 39-13).
39.2 Understanding WebCenter Application Files Affected by Developers
An important aspect of working with any source control system is understanding which files are affected by any particular action. Without this knowledge, you may inadvertently corrupt the source by checking in or checking out either too few or too many files given the actions you are performing on the project. This section helps you understand what files are needed for the main actions you may perform while building a custom WebCenter application.
This section contains the following subsections:
39.2.1 Files Associated With Common Objects
The main objects with which you work in a WebCenter application are as follows:
-
Pages
-
Portlets
-
Services
-
Data controls
Each of these are fairly complex objects, made up of several different metadata files.
For information about page metadata files, see the "Introduction to the ADF Metadata Files" section in the Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework. For information about portlet and producer metadata files, see Appendix A, "Files for WebCenter Applications."
39.2.2 Developer Actions Affecting Metadata Files
Table 39-1 lists developer actions and the files that are affected by these actions. Take this information into account while managing your files in CVS or Subversion.
Table 39-1 Developer Actions Affecting Metadata Files
39.3 Implementing Common Requirements One Time
It is good practice for the project administrator to implement any common developer requirements one time and then check in that version for all to use. By planning ahead and having the administrator take care of these common requirements up front, you can reduce redundancy and error.
For example, suppose two developers need to add OmniPortlet on different pages of an application. If the project administrator has registered the OmniPortlet producer, then it is available for both of them to use. If not, then each developer likely registers the OmniPortlet producer separately, leading to unnecessary duplication and confusion.
Another example: suppose many developers need content from the same content repository. One person should set up and check in the needed connection first. Other developers then can simply reuse the same data control.
39.4 Portlet Producer Considerations
When working in a team environment, bear in mind the following considerations pertaining to portlet producers:
39.4.1 Portlet Producer Connections
When building an EAR file for your project, connections are loaded for the entire application rather than individual projects. For example, suppose you have an application with two projects: P1 and P2. P1 has 100 registered producers and P2 has no producers. When you build an EAR file for either project, all 100 of P1's producer connections are loaded into connections.xml. Note, though, that you can also edit connections.xml manually.
When you run the predeployment tool to create a targeted EAR file, all of the connections in connections.xml must be accessible. Hence, in our example, the generation of a targeted EAR file for either project would fail if any of the 100 portlet producer connections for P1 are unavailable for some reason. Given this behavior, you must carefully consider how you plan to subdivide your overall development effort into applications and projects.
39.4.2 Portlet Producer Name Clashes
While Oracle WebCenter Framework lets you register two portlet producers under the same name, it generally is better to avoid this situation. For example, if two developers working on the same application inadvertently register a portlet producer with the same name, then usually it is best to change one of the names to be unique. If you have two portlet producers registered under the same name, then it becomes very difficult to distinguish between them when debugging errors or performing administrative tasks on the portlet producers.
39.4.3 Combining Portlets from Different Portlet Producers
In some cases, you might have multiple developers building portlets and ultimately you want those portlets to be combined under a single portlet producer. The developers must be conscious of some potential issues.
-
Portlet names and JSP paths could clash. Portlet developers should use prearranged class package names and JSP paths to avoid naming clashes when portlets are combined within one portlet producer in one application.
-
When you create a JPS portlet in the Portlet wizard, the directory for the portlet modes defaults to
portletn\html\mode_name, wherenis a number that increments for each portlet you create. To avoid directory and file name clashes, portlet developers should change the directory name on the Content Type and Portlet Modes page of the Portlet wizard. Select the portlet mode and then change the directory name in the corresponding field to something unique. -
When you combine portlets into one portlet producer, you must manually merge the portlet descriptor files, avoiding identifier clashes as you do so as follows:
-
JPS portlet identifiers in the
portlet.xmlandoracle-portlet.xmlfiles are generated automatically starting fromportlet1. When you manually merge multiple portlet descriptor files into one, you must change any portlet identifiers that clash with one another. -
Similarly, the PDK-Java portlet identifiers in
provider.xmlare automatically generated starting from1. When you manually merge multipleprovider.xmlfiles, you must change any portlet identifiers that clash with one another.
-
-
You must manually merge any web descriptor (
web.xml) changes; for example, security role information. -
For PDK-Java portlets, you also might need to manually merge
.propertiesfiles. -
When using many different portlets, parts of files might not be checked in properly because they are overwritten by someone else or because JDeveloper does not pick up the changed files correctly. For example, you might deploy an application with many types of portlets and see the following error in two of the three OmniPortlets:
mdsId oracle/adf/portlet/OmniPortlet_1172537210873/ap/Portlet100_0b4156e9_0111_1000_ 8001_82235f273a39.pxml not found mdsId oracle/adf/portlet/OmniPortlet_1172537210873/ap/Portlet100_250498fc_0111_1000_ 8002_a9fe7286a54e.pxml not found
If you receive error messages like these, then ensure that all
*.pxmlfiles from the development environment are copied over to the deployed environment. -
Your portlet customizations might not appear in your deployed environment. Make sure that the content of the
oracle\adf\portlet\<portletInstanceName>.pxmlfile is correct and that it refers to the proper*.pxmlfiles.