by Chris Muir
This is Part 5 of a five-part series on adapting Oracle ADF development and Subversion to your enterprise’s needs. It covers:
Oracle JDeveloper 11g application architecture
Oracle ADF libraries and the Resource Palette
Finalizing the Oracle ADF library CR
Some additional rules
Up to this point of the article, we’ve been considering a relatively simple “single” Oracle ADF application that comprises two projects. This follows a model of application architecture used in Oracle JDeveloper 10.1.3 applications. This approach had some problems:
The resulting application could be huge; care had to be given to dividing the application into logical chunks.
Oracle ADF applications, by their nature, have central configuration files that drive the applications’ operation. As different team members worked on different parts of an application, they often needed to change the central configuration files. The chances of two or more developers wanting to change the master configuration files at the same time were high.
It was very easy for beginner programmers not to know what they were doing with the entire code base and, therefore, to inadvertently make changes to code where they shouldn’t.
The architecture supported no clear division of labor.
Within Oracle JDeveloper 11g, it is possible to have a composite master Oracle ADF application workspace that loads and makes use of numerous other applications through the Oracle ADF libraries facility. These other applications are composed of one or more Bounded Task Flows (BTFs), Declarative Components, or Page Templates. The idea is that each is worked on separately, potentially by separate team members, and then they are brought together by the master Oracle ADF application.
This architecture has a number of benefits:
The primary benefit is that this architecture allows an organization to have one or more master composite Oracle ADF applications that reuse mini-applications as they see fit.
Team members can be tasked to work on one of the mini-applications, so there is a clear division of labor.
It becomes harder for junior programmers to accidentally change critical files that other parts of the system rely on.
While these benefits ring loudly, they present a greater challenge:
As one or more master Oracle ADF applications are created, what mini-applications they are dependent on becomes important to track.
Where are the mini-applications for the master Oracle ADF application available?
And importantly, from this article’s point of view, how do we handle the change control of these mini-applications? When a change request is raised, does it apply to the master Oracle ADF application, a mini-application that the master Oracle ADF application uses, or both?
The following sections outline a potential solution to the challenges above. Readers are directed to assess the solution outlined to ensure it is fit for their purpose. Readers should note that the issue of library dependency management is a complex area within Java development and other languages that provide a strong code reuse facility. Within the Java arena, tools such as Ant-Ivy and Maven are provided to assist with and control this burden, and readers are strongly encouraged to undertake research on these solutions. What’s provided here is potentially an overly simple solution to demonstrate the issues at hand and to get the reader thinking. This solution might not be suitable in itself for large-scale developments.
The ability to load and reuse one or more mini Oracle ADF applications in a master oracle ADF application is provisioned by Oracle JDeveloper’s Oracle ADF libraries and Resource Palette facilities. Each mini-application is jarred into an Oracle ADF library, and the Resource Palette exposes the mini-applications to load into the master-application.
In considering our original Beanz application, let’s consider it a master Oracle ADF application that needs to make use of a mini-application containing a Bounded Task Flow called MiniBean. The inclusion of MiniBean into our master Beanz application was raised as part of CR005.
We allocate CR006 to one of our developers to work on. As an entirely new mini-application, the developer creates an associated Oracle JDeveloper application workspace and a number of other design-time artifacts to meet the requirements:
An important question is where does this mini-application go in our SVN repository? Our repository stores only the original Beanz application:
The solution is to check the MiniBean application in under its own tree. Because we might have multiple (if not hundreds) of mini-applications in the future, we’ll also create a high-level subdirectory to logically separate these from the master application. The result is this:
Note the use of the tags and trunk structure under the ADFMiniApplications/MiniBean tree, but branches is missing. There’s more on this in a moment.
To load the MiniBean application into the Beanz master application, we need to create an Oracle ADF library. This is done by creating an Oracle ADF library deployment profile on the MiniBean application’s ViewController project. Open the ViewController Project Properties → Deployment node:
By default, a WAR file deployment profile already exists. This can stay if the mini-application will be run and/or tested standalone on the local developer’s integrated Oracle WebLogic Server.
Selecting the New button presents the Create Deployment Profile dialog where we select and enter the following:
Note the Oracle ADF library archive type and, importantly, the JAR file name to be produced. The JAR file name specifically identifies the CR number that the mini-application was created for.
From here, we accept all changes, close the windows, right-click ViewController, and deploy using the Oracle ADF library option just created, accepting the defaults in the resulting Deploy dialog:
As can be seen from the resulting log window, the Oracle ADF library JAR file is written to the file system:
The JAR file should not be checked into SVN (because it can always be regenerated), but it is essential that the changes to the ViewController project file be checked back into the repository.
After the developer is confident that the work has been completed and the code is ready to be used elsewhere, within the SVN repository, the MiniBean/trunk should be tagged with the appropriate CR number, resulting in the following repository configuration:
At this point, we want to load the Oracle ADF library into our master Oracle ADF application. From a change-control point of view, this is a change to the existing application and, as a result, the developer who is assigned to load the Oracle ADF library into the master Beanz application will load it in to the trunk of the Beanz application. This implies the developer should check out a working copy from the Beanz\trunk in the SVN repository.
Oracle JDeveloper 11g provides the Resource Palette, accessible through the View menu, as an easy way to load mini-applications into a master application:
The Resource Palette’s New Connection menu allows you to create a named file system connection to wherever the Oracle ADF libraries are stored:
In the Create File System Connection dialog, you enter a name for the connection and the location of the Oracle ADF libraries:
This task presents a problem. Because this is a separate developer loading the MiniBean Oracle ADF library JAR into the master Beanz application, where should the developer get it from? One solution is to check out the MiniBean application onto the developer’s local machine, deploy the Oracle ADF library JAR, and then connect to the directory where the JAR exists. However, this solution doesn’t scale as more mini-applications are created. Each time a change is required to the master Oracle ADF application, this solution would that the responsible developer check out the mini-applications from the SVN repository to the exact location on the local PC, as the previous developer did.
A much easier method is to create a central network location that all developers share. The shared Oracle ADF libraries are placed there, and the Resource Palette is configured to use that location. Under Microsoft Windows, this could be a named network drive, say, the J: drive (J for Java).
(Within Oracle JDeveloper 11g PS1 build 5536, support for network paths rather than hardcoded Microsoft Windows drives is currently limited, due to a bug. Ideally, a network path would be used because that doesn’t require Microsoft Windows developers to use a precious mapped network drive. Readers are encouraged to discover whether this limitation is removed in their version of Oracle JDeveloper.)
Using this method, when the MiniBean developer has completed the work and tagged it, the developer should also place a copy of the Oracle ADF library in the shared network drive.
Now, when creating the file system connection in the Resource Palette, we can specify the drive location:
The resulting JAR file is displayed in the Resource Palette:
This can then be added to the master Oracle ADF application by selecting the master Oracle ADF application’s ViewController project, then, in the Resource Palette, right-clicking the JAR you wish to add, and then selecting the Add to Project option. A confirmation dialog appears where you select the ADF Library button. Finally, you’ll see the following confirmation in the Log window:
In addition, displaying the ViewController’s Libraries and Classpaths properties from the Project Properties window reveals the attached Oracle ADF libraries:
And the Edit button reveals the loaded JARs:
Of particular note, the Oracle ADF libraries feature is reusing the shared network location. So, it’s essential that all developers keep to convention of having the J: drive configured on their local PC.
After the developer who is modifying the master Oracle ADF application has completed the work, which includes integrating the MiniBean application, according to the earlier sections of this document, the developer should create an associated tags entry as tags\CR005 from the trunk branch and, if the application is ready to test, migrate the application to Test and also put it in the branches\test\CR005 branch.
At this point, we’ll revisit why the MiniBean application doesn’t have a branches tree in the SVN repository. As the MiniBean application itself doesn’t get deployed to the application server, but rather it is composited into master applications that do, there’s no point in tracking which environment the MiniBean application has risen to because the master application keeps track of that. In addition, because the MiniBean application itself can be used in one or more master applications, it could have actually achieved different environments for different master applications; therefore, maintaining the branches environment becomes untenable.
At the conclusion of this section, it’s important to emphasize a number of rules.
The CR number in the Oracle ADF library file name tells you which CR initiated the work to create the new release of a common Oracle ADF library. However, later applications with different CRs can make reuse of an earlier CR’s Oracle ADF library. The rules are as follows:
For a new application:
If the new application requires no new functionality in a common Oracle ADF library, the application can be associated with a previous CR number of the common Oracle ADF library. This is done by explicitly attaching the specific CR number to the Oracle ADF library from the J: drive.
Alternatively, if the new application requires a new version of the common Oracle ADF library because its functionality is incomplete, then generate the new Oracle ADF library JAR with the current CR number, and place it on J: drive.
For older applications that are dependent on an earlier CR number version of an Oracle ADF library JAR, don’t arbitrarily upgrade to a newer Oracle ADF library JAR CR number unless you’ve undertaken regression testing.
Because of the previous point, don’t assume a higher CR number necessarily means a newer version of an Oracle ADF library JAR; CRs can be worked on out of order. You’ll need some other mechanism to work out what is the most up-to-date version, for example, an incrementing version number included in the Oracle ADF library JAR name or a more sophisticated build and dependency management tool, such as Maven.
It is okay for developers to overwrite on the J: drive an Oracle ADF library JAR with a specific CR number if that’s the one they’re working on. But developers should never overwrite a previous Oracle ADF library CR number on the J: drive unless they have a very good reason! Overwriting a previous Oracle ADF library CR number can break existing applications.
In this final chapter of five we investigated the broader issue of ADF architecture, specifically ADF Libraries and how they fit into the overall Subversion workflow.