1 Introduction to Building Fusion Web Applications with Oracle ADF

1.2.1 ADF Business Components

When building service-oriented Java EE applications, you implement your core business logic as one or more business services. These backend services provide clients with a way to query, insert, update, and delete business data as required while enforcing appropriate business rules. ADF Business Components are prebuilt application objects that accelerate the job of delivering and maintaining high-performance, richly functional, database-centric services. They provide you with a ready-to-use implementation of Java EE design patterns and best practices.

As illustrated in Figure 1-3, Oracle ADF provides the following key components to simplify building database-centric business services:

• Entity object

  An entity object represents a row in a database table and simplifies modifying its data by handling all data manipulation language (DML) operations for you. It can encapsulate business logic to ensure that your business rules are consistently enforced. You associate an entity object with others to reflect relationships in the underlying database schema to create a layer of business domain objects to reuse in multiple applications.

• View object

  A view object represents a SQL query and simplifies working with its results. You use the SQL language to join, project, filter, sort, and aggregate data into the shape required by the end-user task being represented in the user interface. This includes the ability to link a view object with other entity objects to create master-detail hierarchies of any complexity. When end users modify data in the user interface, your view objects collaborate with entity objects to consistently validate and save the changes.

• Application module

  An application module is the transactional component that UI clients use to work with application data. It defines an updateable data model and top-level procedures and functions (called service methods) related to a logical unit of work related to an end-user task.

Figure 1-3 ADF Business Components Simplify Data Access and Validation

1.2.2 ADF Model Layer

In the model layer, Oracle ADF Model implements the JSR-227 service abstraction called the data control. Data controls abstract the implementation technology of a business service by using standard metadata interfaces to describe the service's operations and data collections, including information about the properties, methods, and types involved. Using JDeveloper, you can view that information as icons that you can then drag and drop onto a page. At that point, JDeveloper automatically creates the bindings from the page to the services. At runtime, the ADF Model layer reads the information describing your data controls and data bindings from appropriate XML files and implements the two-way connection between your user interface and your business service.

Oracle ADF provides out-of-the-box data control implementations for the most common business service technologies. Using JDeveloper and Oracle ADF together provides you a declarative, drag-and-drop data binding experience as you build your user interfaces. Along with support for ADF application modules, ADF Model also provides support for the following service technologies:

• Enterprise JavaBeans (EJB) session beans and JPA entities

• JavaBeans

• Web services

• XML

• CSV files

1.2.3 ADF Controller

In the controller layer, where handling page flow of your web applications is a key concern, ADF Controller provides an enhanced navigation and state management model on top of JSF. JDeveloper allows you to declaratively create task flows where you can pass application control between different types of activities, such as pages, methods on managed beans, declarative case statements, or calls to other task flows.

1.2.4 ADF Faces Rich Client

ADF Faces Rich Client (RC) is a set of standard JSF components that include built-in AJAX functionality. AJAX is a combination of asynchronous JavaScript, dynamic HTML (DHTML), XML, and XmlHttpRequest communication channel. This combination allows requests to be made to the server without fully re-rendering the page. While AJAX allows rich client-like applications to use standard internet technologies, JSF provides server-side control, which reduces the dependency on an abundance of JavaScript often found in typical AJAX applications.

ADF Faces RC provides over 100 rich components, including hierarchical data tables, tree menus, in-page dialogs, accordions, dividers, and sortable tables. ADF Faces RC also provides ADF Data Visualization components, which are Flash- and SVG-enabled components capable of rendering dynamic charts, graphs, gauges, and other graphics that can provide a real-time view of underlying data. Each component also supports skinning, along with internationalization and accessibility.

To achieve these front-end capabilities, ADF Faces RC components use a rendering kit that handles displaying the component and also provides the JavaScript objects needed for the rich functionality. This built-in support enables you to build rich applications without needing extensive knowledge of the individual technologies on the front or back end.

For more information about ADF Faces RC, including the architecture and detailed information about each of the components, see the Oracle Fusion Middleware Web User Interface Developer's Guide for Oracle Application Development Framework.

Along with ADF Faces RC, Oracle ADF also supports the following view technologies:

• Apache MyFaces Trinidad: This is the open source code donation from Oracle to the Apache Software Foundation. ADF Faces RC components are based on these Trinidad components)

• Java Swing and ADF Swing: ADF Swing is the development environment for building Java Swing applications that use the ADF Model layer.

• ADF Mobile: This is a standards-based framework for building mobile applications built on the component model of JSF.

1.3.1 Creating an Application Workspace

The first step in building a new application is to assign it a name and to specify the directory where its source files will be saved. When you create an application using the application templates provided by JDeveloper, JDeveloper organizes your workspace into projects and creates and organizes many of the configuration files required by the type of application you are creating.

One of these templates is the Fusion Web Application (ADF) template, which provides the correctly configured set of projects you need to create a web application that uses ADF Faces Rich Client for the view, ADF Page Flow for the controller, and ADF Business Components for business services. When you create an application workspace using this template, JDeveloper creates a project named Model that will contain all the source files related to the business services in your application, and a project named ViewController that will contain all the source files for your ADF Faces view layer, including files for the controller. JDeveloper automatically creates the JSF and ADF configuration files needed for the application. JDeveloper displays all the files for your application in the application overview editor, as shown in Figure 1-4.

Figure 1-4 New Workspace for a Fusion Web Application

JDeveloper also adds the following libraries to the view project:

• JSF 1.2

• JSTL 1.2

• ADF Page Flow Runtime

• ADF Controller Runtime

• ADF Controller Schema

• ADF Faces Runtime 11

• ADF Common Runtime

• ADF Web Runtime

• MDS Runtime

• MDS Runtime Dependencies

• Commons Beautils 1.6.1

• Commons Logging 1.0.3

• Commons Collections 2.1

• Trinidad Runtime 11

Once you add a JSF page, JDeveloper adds the following libraries:

• JSP Runtime

• DVT Faces Runtime

• Oracle JEWT

Once the projects are created for you, you can rename them as you need. You can then use JDeveloper to create additional projects, and add the packages and files needed for your application.

Figure 1-5 shows the different projects, packages, directories, and files for the StoreFrontModule application, as displayed in the Application Navigator.

Figure 1-5 StoreFrontModule Application Projects, Packages, and Directories

For more information, see "Managing Applications and Projects" in the "JDeveloper Basics" section of the JDeveloper online help.

When you work in your files, you use mostly the editor window, the Structure window, and the Property Inspector, as shown in Figure 1-6. The editor window allows you to view many of your files in a WYSIWYG environment, or you can view a file in an overview editor where you can declaratively make changes, or you can view the source code for the file. The Structure window shows the structure of the currently selected file. You can select objects in this window and then edit the properties for the selection in the Property Inspector.

Figure 1-6 The JDeveloper Workspace

1.3.2 Creating Use Cases

After creating an application workspace, you may decide to begin the development process by doing use case modeling to capture and communicate end-user requirements for the application to be built. Figure 1-7 shows a simple diagram created using the UML modeler in JDeveloper. The diagram represents an end user viewing a list of his orders and then drilling down to view the details of an order. Using diagram annotations, you can capture particular requirements about what end users might need to see on the screens that will implement the use case. For example, in this use case, it is noted that the user will select order details for each order listed.

Figure 1-7 Use Case Diagram for Viewing Order History

For more information about creating use case diagrams, see "Modeling With Diagrams" in the "Designing and Developing Applications" section of the JDeveloper online help.

1.3.3 Designing Application Control and Navigation Using ADF Task Flows

By modeling the use cases, you begin to understand the kinds of user interface pages that will be required to implement end-user requirements. At this point, you can begin to design the flow of your application. In a Fusion web application, you use ADF task flows instead of standard JSF navigation flows. Task flows provide a more modular and transaction-aware approach to navigation and application control. Like standard JSF navigation flows, task flows contain mostly viewable pages. However, instead of describing navigation between pages, task flows facilitate transitions between activities. Aside from navigation, task flows can also have nonvisual activities that can be chained together to declaratively affect the page flow and application behavior. For example, these nonvisual activities can call methods on managed beans, evaluate an EL expression, or call another task flow. This facilitates reuse, as business logic can be invoked independently of the page being displayed.

Figure 1-8 shows the checkout-task-flow task flow from the StoreFront module of the Fusion Order Demo application. In this task flow, order and orderSummary are view activities that represent pages, while syncShoppingCartForAuthenticatedUser is a method call activity. When the user enters this flow, the syncShoppingCartForAuthenticatedUser activity is invoked (because it is the entry point for the flow, as denoted by the green circle) and the corresponding method is called. From there, the flow continues to the order page. From the order page, control can be passed to the orderSummary page, or to the continueShopping return activity that is the exit point of the flow and passes control back to the home page.

Figure 1-8 Task Flow in the StoreFrontModule Application

The ADF Controller provides a mechanism to declaratively define navigation using control flow rules. The control flow rule information, along with other information regarding the flow, is saved in a configuration file. Figure 1-9 shows the Structure window for the checkout-task-flow task flow. This window shows each of the items configured in the flow, such as the control flow rules. The Property Inspector (by default, located at the bottom right) allows you to set values for the different elements in the flow.

Figure 1-9 Task Flow Elements in the Structure Window and Property Inspector

Aside from pages, task flows can also coordinate page fragments. Page fragments are JSF JSP documents that are rendered as content in other JSF pages. You can create page fragments and the control between them in a bounded task flow as you would create pages, and then insert the entire task flow into another page as a region. Because it is simply another task flow, the region can independently execute methods, evaluate expressions, and display content, while the remaining content on the containing page remains the same. For example, before registering a new user, the application needs to determine what kind of user needs to be created. All the logic to do this is handled in the user-registration-task-flow task flow, which is used as a region in the registerUser page.

Regions also facilitate reuse. You can create a task flow as a region, determine the pieces of information required by a task and the pieces of information it might return, define those declaratively as parameters and return values of the region, then drop the region on any page in an application. Depending on the value of the parameter, a different view can display. For information about task flows and creating them, see Chapter 13, "Getting Started with ADF Task Flows".

1.3.4 Identifying Shared Resources

You may find that some aspects of your application can be reused throughout the application. For example, you may need the functionality of creating an address to appear both when a user registers and when a user creates an order. Or you may find throughout the development process that certain components of your application should be shared throughout the application. You can declaratively create ADF libraries that allow you to package artifacts and reuse them throughout the application. For example, you might create a task flow for the process of creating an address. You can then save this task flow and package it as a library. The library can be sent to other developers who can add it to their a resource catalog, from which they can drag and drop it onto any page where it's needed. Figure 1-10 shows the Resource Palette in JDeveloper.

Figure 1-10 Resource Palette in JDeveloper

When designing the application, be sure to note all the tasks that can possibly become candidates for reuse. For more information about component reuse see Chapter 31, "Reusing Application Components".

1.3.5 Creating ADF Business Components to Access Data

Typically, when you implement business logic as ADF Business Components, you do the following:

• Create entity objects to represent tables that you expect your application to perform a transaction against (if no transaction is to be performed, an entity object is not needed). Add validation and business rules as needed.

• Create view objects that work with the entity objects to query and update the database. These view objects will be used to make the data available for display at your view layer.

• Create the application module that the UI layer of your application will use. This application module contains view object instances in its data model along with any custom methods that users will interact with through the application's web pages.

1.3.5.1 Creating a Layer of Business Domain Objects for Tables

Once you have an understanding of the data that will be presented and manipulated in your application, if you haven't already done so, you can build your database (for more information, see the "Designing Databases" in the "Designing and Developing Applications" section of the JDeveloper online help). Once the database tables are in place, you can create a set of entity objects that represents them and simplifies modifying the data they contain. When you use entity objects to encapsulate data access and validation related to the tables, any pages you build today or in the future that work with these tables are consistently validated. As you work, JDeveloper automatically configures your project to reference any necessary Oracle ADF runtime libraries your application will need at runtime.

For example, the StoreFrontService project of the StoreFrontModule application contains the business services needed by the application. Figure 1-11 shows two of the entity objects that represent the database tables in that application.

Figure 1-11 Business Components Diagram Showing Entity Objects and Related Tables

To create the business layer, you first create the entity objects based on your database tables. Any relationships between the tables will be reflected as associations between the corresponding entity objects. Alternatively, you can first create the entity objects, and the associations, and then create database tables from those objects.

Once the entity objects are created, you can define control and attribute hints that simplify the display of the entities in the UI, and you can also add behaviors to the objects. For more information, see Chapter 4, "Creating a Business Domain Layer Using Entity Objects".

1.3.5.2 Building the Business Services

Once the reusable layer of business objects is created, you can implement the application module. An application module is the transactional component that UI clients use to work with application data. It defines an updateable data model and top-level procedures and functions (called service methods) for a logical unit of work related to an end-user task.

The application module's data model is composed of instances of the view object components you create that encapsulate the necessary queries. View objects can join, project, filter, sort, and aggregate data into the shape required by the end-user task being represented in the user interface. When the end user needs to update the data, your view objects reference entity objects in your reusable business domain layer. View objects are reusable and can be used in multiple application modules.

When you want the data to display in a consistent manner across all view pages that access that data, you can configure metadata on the view object to determine display properties. The metadata allows you to set display properties in one place and then change them as needed, so that you make the change only in one place instead of on all pages that display the data. Conversely, you can also have the query controlled by the data the page requires. All display functionality is handled by the page. For more information, see Chapter 5, "Defining SQL Queries Using View Objects".

For example, the StoreFrontService project contains the oracle.fodemo.storefront.store.queries package, which contains many of the queries needed by the StoreFrontModule application, as shown in Figure 1-12.

Figure 1-12 View Objects in the StoreFrontModule Application

1.3.6 Implementing the User Interface with JSF

From the task flows you created during the planning stages, you can double-click on the view activity icons to create the actual JSP files.When creating a Fusion web application, you create an XML-based JSP document (which uses the extension *.jspx) rather than a *.jsp file. Using an XML-based document:

• Simplifies treating your page as a well-formed tree of UI component tags

• Discourages you from mixing Java code and component tags

• Allows you to easily parse the page to create documentation or audit reports

• Allows you to create a view layer that can be personalized

Oracle ADF allows you to create and use page templates. When creating templates, a developer can determine the layout of the page, provide static content that must appear on all pages, and create placeholder attributes that can be replaced with valid values for each page. Each time the template is changed, for example if the layout changes, any page that uses the template will reflect the update.

Most pages in the StoreFrontModule application use the StoreFrontTemplate template, which provides an area for branding and navigation, a main content area divided into three panes, and a footer area. If the template designer decides to switch the location of the branding and the navigation, all pages that use the template will automatically reflect that change at runtime.

For more information about creating pages for your Fusion web application, see Chapter 18, "Getting Started with Your Web Interface". Once your page files are created, you can add databound UI components. Part IV, "Creating a Databound Web User Interface" is dedicated to creating the view layer of a Fusion web application.

1.3.7 Data Binding with Oracle ADF Model Layer

In JSF, you use a simple expression language (called EL) to bind to the information you want to present and/or modify. Example expressions look like #{UserList.selectedUsers} to reference a set of selected users, #{user.name} to reference a particular user's name, or #{user.role == 'manager'} to evaluate whether a user is a manager or not. At runtime, a generic expression evaluator returns the List, String, and boolean value of these respective expressions, automating access to the individual objects and their properties without requiring code.

At runtime, the value of a JSF UI component is determined by its value attribute. While a component can have static text as its value, typically the value attribute will contain a binding that is an EL expression that the runtime infrastructure evaluates to determine what data to display. For example, an outputText component that displays the name of the currently logged-in user might have its value attribute set to the expression #{UserInfo.name}. Since any attribute of a component can be assigned a value using an EL expression, it's easy to build dynamic, data-driven user interfaces. For example, you could hide a component when a set of objects you need to display is empty by using a boolean-valued expression like #{not empty UserList.selectedUsers} in the UI component's rendered attribute. If the list of selected users in the object named UserList is empty, the rendered attribute evaluates to false and the component disappears from the page.

In a typical JSF application, you would create objects like the UserList object as a managed bean. The JSF runtime manages instantiating these beans on demand when any EL expression references them for the first time. However, in an application that uses the ADF Model layer, instead of binding the UI component attributes to properties or methods on managed beans, JDeveloper automatically binds the UI component attributes to the ADF Model layer, which uses XML configuration files that drive generic data binding features. It implements the two concepts in JSR-227 that enable decoupling the user interface technology from the business service implementation: data controls and declarative bindings.

Data controls use XML configuration files to describe a service. At design time, visual tools like JDeveloper can leverage that metadata to allow you to declaratively bind UI components to any data control operation or data collection. For example, Figure 1-13 shows the StoreServiceAMDataControl data control as it appears in the Data Controls panel of JDeveloper.

Figure 1-13 StoreFrontServiceAMDataControl

Note that the collections that display in the panel represent the set of rows returned by the query in each view object instance contained in the StoreServiceAM application module. For example, the OrderPaymentOptions data collection in the Data Controls panel represents the OrderPaymentOptions view object instance in the StoreServiceAM's data model. The OrderBillingAddress data collection appears as a child, reflecting the master-detail relationship set up while building the business service. The attributes available in each row of the respective data collections appear as child nodes. The data collection level Operations node contains the built-in operations that the ADF Model layer supports on data collections, such as previous, next, first, last, and so on.

Using the Data Controls panel, you can drag and drop a data collection onto a page in the visual editor, and JDeveloper creates the necessary bindings for you. Figure 1-14 shows the CustomerRegistration collection from the StoreServiceAMDataControl data control being dragged from the Data Controls panel, and dropped as a form onto a JSF page.

Figure 1-14 Declaratively Creating a Form Using the Data Controls Panel

The first time you drop a databound component from the Data Controls panel on a page, JDeveloper creates an associated page definition file. This XML file describes the group of bindings supporting the UI components on a page. The ADF Model uses this file at runtime to instantiate the page's bindings. These bindings are held in a request-scoped map called the binding container. Each time you add components to the page using the Data Controls panel, JDeveloper adds appropriate declarative binding entries into this page definition file. Additionally, as you perform drag-and-drop data binding operations, JDeveloper creates the required tags representing the JSF UI components on the JSF page. For more information about using the Data Controls panel, see Chapter 11, "Using Oracle ADF Model in a Fusion Web Application".

Figure 1-15 illustrates the architecture of a JSF application when you leverage ADF Model for declarative data binding. By combining ADF Model with JSF, you avoid having to write a lot of the typical managed bean code that would be required for real-world applications.

Figure 1-15 Architecture of a JSF Application Using ADF Model Data Binding

Aside from forms and tables that display or update data, you can also create search forms, and databound charts and graphs. For more information about using data controls to create different types of pages, see the chapters contained in Part IV, "Creating a Databound Web User Interface". For more information about the Data Controls panel and how to use it to create any UI data bound component, see Chapter 11, "Using Oracle ADF Model in a Fusion Web Application".

1.3.8 Validation and Error Handling

You can add validation to your business objects declaratively using the overview editors for entity and view objects. Figure 1-16 shows the Validators tab of the overview editor for the AddressEO entity object.

Figure 1-16 Setting Validation in the Overview Editor

Along with providing the validation rules, you also set the error messages to display when validation fails. To supplement this declarative validation, you can also use Groovy-scripted expressions. For more information about creating validation at the service level, see Chapter 7, "Defining Validation and Business Rules Declaratively".

Additionally, ADF Faces input components have built-in validation capabilities. You set one or more validators on a component either by setting the required attribute or by using the prebuilt ADF Faces validators. You can also create your own custom validators to suit your business needs. For more information, see the "Validating and Converting Input" chapter of the Oracle Fusion Middleware Web User Interface Developer's Guide for Oracle Application Development Framework.

You can create a custom error handler to report errors that occur during execution of an ADF application. Once you create the error handler, you only need to register the handler in one of the application's configuration files. For more information, see Section 26.8, "Customizing Error Handling".

1.3.9 Adding Security

Oracle ADF provides a security implementation that is based on Java Authentication and Authorization Service (JAAS). JAAS is a standard security Application Programming Interface (API) that is added to the Java language through the Java Community Process. It enables applications to authenticate users and enforce authorization. The Oracle ADF implementation of JAAS is role-based. You define these roles and then apply constraints based on these roles throughout the application.

You can also create login pages that allow the application to authenticate users. To do this, you create a managed bean that handles authenticating the user and placing that user information into the session. For more information about securing your application, see Chapter 28, "Adding Security to a Fusion Web Application".

1.3.10 Testing and Debugging the Web Client Application

Testing an Oracle ADF web application is similar to testing and debugging any other Java EE application. Most errors result from simple and easy-to-fix problems in the declarative information that the application defines or in the EL expressions that access the runtime objects of the page's Oracle ADF binding container. In many cases, examination of the declarative files and EL expressions resolve most problems.

For errors not caused by the declarative files or EL expressions, JDeveloper includes the ADF Logger, which captures runtime trace messages from the ADF Model layer API. The trace includes runtime messages that may help you to quickly identify the origin of an application error. You can also search the log output for specific errors. JDeveloper also includes the ADF Declarative Debugger, a tool that allows you to set breakpoints. When a breakpoint is reached, the execution of the application is paused and you can examine the data that the Oracle ADF binding container has to work with, and compare it to what you expect the data to be. Chapter 29, "Testing and Debugging ADF Components" contains useful information and tips on how to successfully debug a Fusion web application.

For testing purposes, JDeveloper provides integration with JUnit. You use a wizard to generate regression test cases. For more information, see Section 29.8, "Regression Testing with JUnit".

1.3.11 Refactoring Application Artifacts

Using JDeveloper, you can easily rename or move the different components in your application. For example, you may find that you need to change the name of your view objects after you have already created them. JDeveloper allows you to easily do this and then propagates the change to all affected metadata XML files. For more information, see Chapter 30, "Refactoring a Fusion Web Application".

1.3.12 Deploying a Fusion Web Application

You can deploy a Fusion web application to either the integrated WebLogic server within JDeveloper or to a standalone instance. For more information about deployment, see Chapter 32, "Deploying Fusion Web Applications".

1.4.1 Enforcing Standards

Because numerous individuals divided into separate teams will be developing the application, you should enforce a number of standards before development begins to ensure that all components of the application will work together efficiently. The following are areas within an application where it is important to have standardization in place when working in a team environment:

• Code layout style

  So that more than one person can work efficiently in the code, it helps to follow specific code styles. JDeveloper allows you to choose how the built-in code editor behaves. While many of the settings affect how the user interacts with the code editor (such as display settings), others affect how the code is formatted. For example, you can select a code style that determines things like the placement of opening brackets and the size of indents. You can also import any existing code styles you may have, or you can create your own and export them for use by the team. For more information, see "Customizing the Source Editor Environment" in the "JDeveloper Basics" section of the JDeveloper online help.

• Package naming conventions

  You should determine not only how packages should be named, but also the granularity of how many and what kinds of objects will go into each package. For example, all managed beans in the StoreFront module are in the view.managed package. All beans that contain helper-type methods accessed by other beans are in util packages (one for Oracle ADF and one for JSF). All property files are in the common package.

• Pages

  You can create templates to be used by all developers working on the UI, as described in Section 1.3.6, "Implementing the User Interface with JSF". This not only ensures that all pages will have the same look and feel, but also allows you to make a change in the template and have the change appear on all pages that use it. For more information, see Section 18.2, "Using Page Templates".

  Aside from using templates, you should also devise a naming standard for pages. For example, you may want to have names reflect where the page is used in the application. To achieve this goal, you can create subdirectories to provide a further layer of organization.

• Connection names: Unlike most JDeveloper and Oracle ADF objects that are created only once per project and by definition have the same name regardless of who sees or uses them, database connection names might be created by individual team members, even though they map to the same connection details. Naming discrepancies may cause unnecessary conflicts. Team members should agree in advance on common, case-sensitive connection names that should be used by every member of the team.

1.4.2 Using a Source Control System

When working in a team environment, you will need to use a source control system. By default, Oracle JDeveloper provides integrated support for both the CVS and Subversion source control systems, though others may be available through extensions. You can also create an extension that allows you to work with another system in JDeveloper. For information about using these systems within JDeveloper, see the "Using Versioning" topic in the "Designing and Developing Applications" section of the JDeveloper online help.

Following are suggestions for using source control with a Fusion web application:

• Checking out files

  Using JDeveloper, you can create a connection to the source control server and use the source control window to check out the source. When you work locally in the files, the pending changes window notifies you of any changed files. You can create a script using Apache Ant (which is integrated into JDeveloper). You can then use the script to build all application workspaces locally. This can ensure that the source files compile before you check the changed files into the source control repository. To find out how to use Apache Ant to create scripts, see "Building With Apache Ant" in the "Designing and Developing Applications" section of the JDeveloper online help.

• Automating builds

  Consider running a continuous integration tool. Once files are checked into the source server, the tool can be used to recognize either that files have changed or to check for changed files at determined intervals. At that point, the tool can run an Ant script on the server that copies the full source (note that this should be a copy, and not a checkout), compiles those files, and if the compilation is successful, creates a zip file for consumers (not developers) of the application to use. The script should then clean up the source directory. Running a continuous integration tool will improve confidence in the quality of the code in the repository, encourage developers to update more often, and lead to smaller updates and fewer conflicts. Examples of continuous integration tools include Apache Gump and Cruise Control.

• Updating and committing files

  When working with Subversion, updates and commits should be done at the Working Copy level, not on individual files. If you attempt to commit and update an individual file, there is a chance you will miss a supporting metadata file and thereby corrupt the committed copy of the application.

• Resolving merge conflicts

  When you add or remove business components in a JDeveloper ADF Business Components project, JDeveloper reflects it in the project file (.jpr). When you create (or refactor) a component into a new package, JDeveloper reflects that in the project file and in the business components project file (.jpx). Although the XML format of these project control files has been optimized to reduce occurrences of merge conflicts, merge conflicts may still arise and you will need to resolve them using JDeveloper's Resolve Conflicts option on the context menu of each affected file.

  After resolving merge conflicts in any ADF Business Components XML component descriptor files, the project file (.jpr) for an ADF Business Components project, or the corresponding business components project file (.jpx), close and reopen the project to ensure that you're working with latest version of the component definitions. To do this, select the project in the Application Navigator, choose File > Close from the JDeveloper main menu, and then expand the project again in the Application Navigator.