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.
This chapter includes the following topics:
You can use source control in WebCenter Portal 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 to 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. For details, see the "Proxy Settings and JDeveloper" topic in the Oracle JDeveloper online help.For more complete and extensive information about setting up and using SubVersion and other source control systems with JDeveloper, see the "Developing in Teams" topic in the Oracle JDeveloper online help.
Oracle Team Productivity Center is an Application Lifecycle Management tool that enables software development teams to collaborate and work productively when developing portals 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 to check in and which actions might affect those files. In general, as you your team members begin creating new projects, you will see which files are created, and then can determine what you wish to check into source control. It's difficult to summarize all the possible interactions with files you may encounter; however, this section offers a few general tips.
Table 3-1 lists a few of the components with which developers typically interact, and provides links to more information about those components and their related files.
Table 3-1 Commonly Encountered Components
| Component | For More Information... |
|---|---|
|
Pages |
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. |
|
Portlets |
For information about portlet and producer metadata files, see Appendix A, "WebCenter Portal Files." See also, Section 59, " Building Standards-Based Java Portlets Using JSR 286." |
|
Task Flows |
For detailed information about ADF task flows, see the "Getting Started with ADF Task Flows" section in Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework. |
|
Data Controls |
For information on other features and related files you may wish to review when planning your source control strategy, see Appendix A, "WebCenter Portal Files." The appendix lists and describes Portal Framework files, system files, JDeveloper files, and others.
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 must add OmniPortlet on different pages of a portal. 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 portal rather than individual projects. For example, suppose you have a portal 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 portals and projects.
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 portal.
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 a portal 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.