Managing ADF Development Across Multiple Applications with Subversion

An Oracle JDeveloper How To Document
Written by Susan Duncan, Oracle Corporation
April, 2009

Introduction

ADF development can be approached in a number of different ways. Some organizations prefer to work with one ADF application consisting of many projects. Others prefer to divide development across multiple applications by functional area. How the development environment is managed can also be done in a number of ways. Among the many decisions to be made are how code is to be stored and versioned and how ADF Libraries libraries will be shared among teams. There are many approaches to this, among the most obvious are the use of a tool such as Maven, accessing shared resources through JDeveloper's Resource Catalog or making use of the facilities offered by your source code control system.

This document proposes a methodology for the latter approach and more specifically using Subversion to both version and control the sharing of common components such as ADF libraries between teams and multiple applications. The use of Maven or the Resource Catalog are outside the scope of this document as is a discussion on how to achieve optimal deployment of shared components. But they will be covered in separate documents at a later date.

 

Utilising Subversion

This document proposes a working methodology for Team Development where

  • ADF Business Components provide the business services layer
  • Functional development is distributed over a number of ADF Fusion applications
  • Development is done concurrently on multiple applications
  • Source files are versioned using Subversion (SVN)
  • ADF Libraries are used to share common ADF components developed in different applications
  • SVN is used to store and distribute ADF and any third party libraries to developers

This methodology is for distributed teams working on different functional areas with some common components. Typically one application is used to develop the reusable ADF business services. This application holds reusable entity objects. In addition it may hold reusable view objects. UI development is split across functional areas using multiple applications that access the common business services through ADF Libraries. Each UI application may also be exposed as an ADF Library to share common components (such as unbounded task flows)

 

Application Setup

Development is split into a number of applications. This document does not propose naming conventions for applications it uses generic names that should be customized as appropriate.

 

Common Components Application

This application typically holds the business components that are to be shared through libraries or infrastructure components that can be shared between applications. Components may be:

  • Project(s) containing Business Components deployed to an ADF Library
  • Third Party Libraries held in a project
  • Offline database model

Write access to this application is restricted to those working on shared components and libraries.

This example shows the Common Components application with one project CommonADFModel. It is a working copy of the application checked out from its SVN repository

The CommonADFModel project contains the ADF Entity Objects that are shared between the different development teams through the commonModelEO ADF Library.

The library has been deployed to the default project folder.

Note: To display the library in this illustration the deploy folder was added to the project resource path.

 

Team Development Application(s)

Each application represents one functional area of the development. The application must be setup to share any ADF libraries directly from the SVN repository. Developers check out their 'working copy' of the application for development and update/commit to the SVN repository as normal.

Deployed ADF libraries are shared directly from the SVN repository. This ensures that all developers working on applications are using the correct version of the library at any given time. It is an alternative to storing the library on a shared file system and accessing it from the Resource Palette. Using the Resource Palette is outside the scope of this document

In addition to consuming the commonModelEO library it may be that each team application provides and consumes ADF libraries from other team development applications. Typically this occurs when bounded task flows are shared between different functional areas. A discussion on bounded task flows is outside the scope of this document.

Working with Bounded Task Flows and ADF Libraries is covered in the Application Development Guides available from OTN

 

Master Deployment Application

This application pulls together all the common and team applications into the full development. It typically provides some functional development in its own right but also consumes all other shared components to provide the full application for testing and release purposes.

 

SVN Setup

Repository Structure

There are many ways to set up a development folder structure in SVN. This document proposes one approach when using multiple applications

Root directory MultiAppExample holds all the development applications

Each application has its own trunk, tags, branches structure to accommodate development process milestones and branching as applicable.

Main development is done in the trunk directory while tags are used to store milestones and releases

In this example the application structure proposed earlier in this document is reflected in the SVN repository structure

 

Using Tags for Library Sharing

In Subversion a tag directory is used to store milestones, versions of code. A tag is simply a copy* of development at a specific revision (point in time). It is up to the SVN repository administrator to control the creation and access to tag directories

*SVN uses the term 'copy' when creating branches or tags of directories. However, this is not an expensive operation as it is pointers that are used under the covers.

In this example the CommonComponents_Feb2009_v1 directory has been created under the tags directory of the CommonComponentsApp application

 

 

Creating a Tag Using the Versioning Navigator

To create a tag, select the directory (typically an application directory) that the tag version is to be created from. A copy of the contents of this and any sub-directories will be made

Use the context menu of the directory to access the Branch/Tag menu

In this example the contents of the head (latest) revision of the trunk/CommonComponents is copied to the tag directory tags/CommonComponents_Feb2009_v1

 

The result is the contents of the directory has been copied to the tag directory. This Includes its deployed ADF library. However, it is only the commonModelEO.jar file that is to be shared with other applications.

Making a full application copy ensures that the design time components that make up the library at any revision can be recreated if required

 

Accessing the file URL of a versioned directory

To perform such actions as setting SVN properties you may need to access the file URL of a versioned file or directory.

To do this use the context menu on the directory in the Versioning Navigator to invoke either the Copy URL or Properties menu

In this example the URL of the deploy directory in the tag CommonComponents_Feb2009_v1 is being copied

To add the library to a project from the SVN repository the svn:externals property is used. Once the property is set and committed to the SVN repository all users of the application will obtain the library when they next either check-out or update their working copy from the SVN repository.

It is advisable to set up sharing as early as possible in an Application's development. Once the application has been initially versioned the svn:externals property can be used to obtain the library that is to be consumed

 

Share ADF Library with Team Applications

To add an ADF Library or other shared component between applications during development. It is advisable to access the library directly from SVN. This allows control of the release mechanism of versions during the development phase. This can be especially important if development is being done concurrently on both shared and non-shared components.

To add code to a project from the SVN repository the svn:externals property is used. Once the property is set on an application all users of the application will obtain the library when they next check-out or update their working copy from the SVN repository.

It is advisable to set up sharing as early as possible in an Application's development. Once the application has been initially versioned the svn:externals property can be used to obtain the library that is to be consumed

 

Setting svn:externals

The first step is to copy the File URL of the directory containing the library in the SVN repository. Use the technique described above.

In the Application Navigator, select the project node to hold the shared library (in this example TeamApp1Model

From the Versioning menu, open View Subversion Properties

In the Subversion Properties window click Add Subversion Property

In the Resource File field, remove the project .jpr file from the path to leave the project root folder (in this example TeamApp1Model)

Select the svn:externals property from the dropdown list.
Note: the dropdown list filters the svn properties that are applicable to the selected node in the Application Navigator. If you do not see svn:externals it might be that you do not have a folder (the project root folder in this case) selected.

In the value string add a new directory that will contain the library (note this directory must not yet exist in the file system). In this example shared_commonComponents is used.

Leave blank space and paste in the URL for the tag folder holding the library (as described in tag section of this document).

In this case the SVN repository's protocol is svn://

Click OK

Note that the property now appears in the Subversion Properties window against the project .

Use the SVN Console - Log to see that the property has been set in the repository: Note that the project's Resources file source path (.../Team1App/TeamApp1Model) is where the new shared_commonComponents directory will be created to hold the shared library

Finally, Update Working Copy to get the shared library copied into the local working copy.

 

Import Shared Library into Project

Having shared a copy of a library from the SVN repository the next step is to set up your project to use the library. If you are using an ADF Library, the following steps are required. If it is another third party library then adding the library to the projects Libraries and Classpath may suffice (Use Project Properties to do this, it is not covered in detail in this document).

 

Setup Project for Business Components

If your project is not yet setup for Business Components you need to do one of the following:

  • Create a new project with technology scope Business Components
  • Go to Project Properties of an existing project and initialize the project for Business Components

 

Import Shared ADF Library of Business Components

Open Project Properties for the project to contain the library components. Under Business Components select Imports and add the commonModelEO.jar from the file system location specified in svn:externals. This gives you the option to automatically adds the jar file to Libraries. (you can check this by looking under the Libraries and Classpath project properties)

In addition go to Project Source Paths - Resources to add the directory to the resources path and see read-only versions of the objects in the navigator.

 

Moving To Latest Revision ADF Library

Periodically a new version of any shared ADF Library will be deployed. If this new version is to be picked up by other users, or is a milestone release of some sort, the Application should be tagged to ensure it is permanently and easily accessible.

There are three stages to this operation:

  1. Create new tagged revision of ADF Library
  2. Update each application's svn:externals property to point to the new tag revision
  3. Update all checked-out working copies to refresh and reload the imported ADF Library

Note: Similar instructions will apply to third party libraries being stored in projects/SVN

 

Create New Tag for Latest Revision of ADF Library

Use the Versioning Navigator to access the Branch/Tag menu of the CommonComponentsApp.

 

Generally the HEAD (latest) revision is used to create the tag.

The From field shows the application repository path - in this example .../trunk/CommonComponents

In the To field browse to the tags directory for the application and write-in a new tag directory

In this illustration .../tags/CommonComponents_Mar_09_v2

Click ok and the tag is created

 

 

Point Team Applications to Latest Tagged ADF Library Version

This involves changing the svn:externals property set earlier. It is good practice to do this at specific milestones when user working copies have been merged and any conflicts resolved, to reduce any possible conflicts between old and new library code. Then, check out a working copy of the TeamApp to be updated.

In the Application Navigator, select the project node that is sharing the ADF Library

Use the Versioning menu to open the Subversion Property Viewer.

Select the svn:externals property and click Edit to open the Edit Subversion Property dialog

Change value string to point to the new tagged library directory for the library. (Use the Copy URL command on the repository as described earlier).

In this example ../ CommonComponents_Mar_09_v2/.......

Click OK to save the edited property

Note: as this is an edit of the existing svn:externals property the same file system directory can be used. (In an earlier section it was stated that the file system directory must not exist when svn:externals is first setup).

Update the working copy to access the latest library - see note below for refreshing project content.

 

Update Check Out Working Copy

Each user must Update their working copy from the SVN repository to get the latest ADF Library downloaded from the repository.

In addition, to ensure that the updated ADF Library is reloaded into the project either close and re-open the project from the Application Navigator or close and reopen JDeveloper.