Sharing ADF artifacts (part 1)

ADF promotes reusability at every aspect of enterprise software development. For example, along with sharing Java code, you can build and share Business Services (entity, view and application module objects), UI Task flows (reusable user interface), Declarative Components (extensions to ADF UI Components) etc. In this article, i will talk about how to approach this process of sharing ADF artifacts.

ADF Library JAR

JDeveloper has concept of ADF Library JAR files to share artifacts, which is just a regular jar file along with certain metadata that describes reusable artifacts inside it. And, it is definitely good idea to share compiled code, so that developers are not spending time and resources to compile source code. Using “Resources” view in JDeveloper, you can easily examine ( and later add ) ADF Library JAR files.

Consume ADF Library JAR

• In later sections, i will talk about using these Jar files from SubVersion and they will be checked out in dependencies sub-folder of your application. You must add these jar file from dependencies sub-folder under your application. This is very important as JDeveloper will record relative path to jar files and you would want this all to work for your team members when they checkout this application in their JDeveloper.
• Create File System connection in JDeveloper – Resources to folder where you have stored ADF Library JAR files.
• Navigate to necessary JAR file.
• Select your project and then use “Add to Project…”.

 

What happens when you add ADF Library JAR

When you add ADF Library JAR, project’s classpath is updated. JDeveloper does this by creating or updating “ADF Library”. You may also see additional library named “ADF Library Dependencies”, which includes other library jar files that are necessary for library that you have added. JDeveloper is able to do this as ADF Library JAR has information about it’s dependencies. You must commit “ADF Library Dependencies” file as well along with update .jpr file to source control system.

Project configuration is also updated to reflect addition of ADF reusable components, so that various wizard and editor can use added components. For example, as shown below Business Components are imported and recorded in Project configurations. So, this process of adding ADF Library JAR is much more than just adding a Jar file on classpath, so you must use Resources view to perform this task.

Where to store ADF Library JAR files

Now that we understand that we use ADF Library JAR files to share artifacts, where should we store these files, so that other all developers can consume them. There are few obvious options.

• Share using network folder (not recommended)
  • This option works, but it limits all developers to use same version of libraries.
  • Also, all developers must have same name for mapped network drive.
  • There can also be issues with permissions to file system and possible performance problems while reading these jar files.
• Share using shared folder and version number in file names (not recommended)
  • This option can allow developers to use different version of the libraries(For example adflibABC_v1.0.jar, adflibABC_v1.1.jar etc), but it is not a good option.
  • Library dependency setup is recorded in .jpr file and it is eventually recorded as metadata in ADF Library JAR file. So if file name changes it disrupts all configuration files, you have to remove previous version and add new version of library. Now if you generate ADF Library JAR file, projects consuming that jar will also have to manually keep up with versions of libraries that your project is dependent on. 
• Share using tag folder in SubVersion (Recommended)
  • Every application define dependencies using svn:externals property. This allows every application to locally checkout library files independently from other developers. See example below, where all libraries are checked out in dependencies sub-folder.
  • As jar files are versioned using tag mechanism in SubVersion, file name does not change.
  • And folder paths reflect same folder structure as Application source, so it is easy to understand. This is done by generating ADF Library JAR in specific folder, explained in next section.
  • If you want to utilize new version of libraries, just update svn:externals property on your application and it does not affect other applications even on your local environment.
  • This still poses challenges as to what versions should be used on svn:externals and that should be communicated or published in your organization, so that developers or project leads can make informed choice on what versions to configure.

How to build ADF Library JAR files

As explained in previous section, in my opinion it is good option to share ADF Library JAR files using SubVersion repository tags. And obviously, we would want to automate creation of such libraries, so that developers do not have to waste time doing so. Here is an option that provides clear mapping between Application Source and Library folder structure and makes it easy to automate generation of these libraries.

By default, JDeveloper will generate ADF Library JAR in deploy sub-folder of every project, change this behavior by changing location of JAR file in application checkout folder/dependencies/application name/project name folder. See example below.

In next article, i will talk about using FlexDeploy to automate process of building and tagging these libraries.