| Oracle® Fusion Middleware Developer's Guide for Oracle WebCenter 11g Release 1 (11.1.1) Part Number E10148-02 |
|
|
View PDF |
| Oracle® Fusion Middleware Developer's Guide for Oracle WebCenter 11g Release 1 (11.1.1) Part Number E10148-02 |
|
|
View PDF |
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 26.1, "Enabling Source Control on WebCenter Applications"
Section 26.2, "Understanding WebCenter Application Files Affected by Developers"
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 26-1.
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.
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 26-2).
Figure 26-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 26-3).
Figure 26-3 Create CVS Connection - Connection
On the Root page (Figure 26-4), in the Value of CVSROOT field, enter a value for the CVSROOT. Click Next.
On the Test page (Figure 26-5), click Test Connection. The Log In to CVS dialog displays, as shown in Figure 26-6.
Figure 26-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 26-7. Click Next.
Figure 26-7 Create CVS Connection - Test Connection Success
On the Name page, enter a value for Connection Name, as shown in Figure 26-8. Click Next.
The Summary page displays with the connection information. Click Finish (Figure 26-9).
Figure 26-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 26-10.
Figure 26-10 Application Navigator with CVS Connection
To create a Subversion repository:
From the Versioning menu, choose Subversion, and then Create Repository. The Create Subversion Repository dialog displays (Figure 26-11).
Figure 26-11 Create Subversion Repository
In the Create Subversion Connection dialog, enter connection details, and then click OK. (Figure 26-12)
Note:
An alternative way to create a connection is to right-click Subversion in the Versioning Navigator and select New Repository Connection.Figure 26-12 Create Subversion Connection
Later you can edit these pages on the Edit Subversion Connection page (Figure 26-13).
One of the most important aspects 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.
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."
Table 26-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 26-1 Developer Actions Affecting Metadata Files
It is good practice for the project administrator to implement any common developer requirements once 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 will register 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.
When working in a team environment, bear in mind the following considerations pertaining to portlet producers:
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.
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.
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, where n is 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.xml and oracle-portlet.xml files are generated automatically starting from portlet1. 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.xml are automatically generated starting from 1. When you manually merge multiple provider.xml files, 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 .properties files.
When using many different portlets, it is possible that parts of files are not 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 make sure that all *.pxml files from the development environment are copied over to the deployed environment.
Your portlet customizations might not show up in your deployed environment. Make sure that the content of the oracle\adf\portlet\<portletInstanceName>.pxml file is correct and that it refers to the proper *.pxml files.
|
 Copyright © 2007, 2009, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
