| Oracle® Fusion Middleware Developer's Guide for Oracle WebCenter 11g Release 1 (11.1.1) Part Number E10148-09 |
|
|
View PDF |
| Oracle® Fusion Middleware Developer's Guide for Oracle WebCenter 11g Release 1 (11.1.1) Part Number E10148-09 |
|
|
View PDF |
This chapter contains information for a team development environment, where developers are sharing files in Oracle JDeveloper. It includes information about source (or version) control systems, namely Subversion.
Tip:
Typically, one member of the development team creates a new portal application and checks it in to the source code repository. You can create any required connections and check those in as well.This chapter includes the following sections:
Section 4.1, "Enabling Source Control on WebCenter Portal Applications"
Section 4.2, "Understanding WebCenter Portal Application Files Affected by Developers"
You can use source control in a WebCenter Portal application similar to the way you would use source control in any other development environment.
JDeveloper includes Subversion for source control. Oracle also provides free extensions to other source support systems, such as Concurrent Versions System (CVS), Dimensions, and ClearCase. You can install these extensions directly from inside JDeveloper through the Help - Check for Updates menu option, which is the recommended way install extensions. If you cannot connect to the internet from your JDeveloper instance, then download the extension from Oracle Technology Network (OTN) at http://www.oracle.com/technetwork/index.html. Point the Check for Updates wizard to the local file you download.
Note:
You may need to configure a proxy server to access the extensions. To set up a proxy server:In Oracle JDeveloper, choose the Tools menu option, then select Preferences.
In the Preferences dialog, scroll down the list and select Web Browser and Proxy.
In the right pane, under Web Browser and Proxy, select Use HTTP Proxy Server and enter the host name and port number of your proxy server, and note any exceptions. Click OK.
There are two ways to use Subversion, or any other installed source control system: In JDeveloper, either click the Versioning menu or use the Versioning Navigator (click View - Team - Versioning Navigator). The Versioning Navigator is shown in Figure 4-1.
For detailed information about 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.
To create a Subversion repository:
From the Versioning menu, choose Subversion, and then Create Local Repository. The Create Subversion Repository dialog displays (Figure 4-2).
In the Create Subversion Connection dialog, enter connection details, and then click OK. (Figure 4-3)
Note:
An alternative way to create a connection is to right-click Subversion in the Versioning Navigator and select New Repository Connection.Later you can edit these pages on the Edit Subversion Connection page (Figure 4-4).
Oracle Team Productivity Center is an Application Lifecycle Management tool that enables software development teams to collaborate and work productively when developing applications using JDeveloper. This also is a free extension to JDeveloper.
Oracle Team Productivity Center integrates task, bug, and defect repositories, such as JIRA, Bugzilla, and its own built-in task repository into the IDE. It provides a chat interface inside JDeveloper and other team working benefits, such as recording details of files checked into the source control system against tasks and developer productivity aids, such as saving the context of your IDE.
For more information, or to download Oracle Team Productivity Center, go to Oracle Technology Network (OTN) at http://www.oracle.com/technetwork/index.html.
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 WebCenter Portal application.
This section contains the following subsections:
The main objects with which you work in a WebCenter Portal application are as follows:
Pages
Portlets
Task flows
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 Portal Applications."
Table 4-1 lists developer actions and the files that are affected by these actions. Take this information into account while managing your files.
Table 4-1 Developer Actions Affecting Metadata Files
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.
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, 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 *.pxml files 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>.pxml file is correct and that it refers to the proper *.pxml files.
|
 Copyright © 2007, 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
