9 Building Java Projects

JDeveloper supports several ways to build and compile your projects and applications, including the Make and Rebuild operations, Apache Ant, and Apache Maven.

Make operations compile source files that have changed since they were last compiled, or have dependencies that have changed. Rebuild operations, in contrast, compile source files unconditionally. You can invoke make on individual source files, on working sets, or on containers such as packages, and projects.

Ant supplies a number of built-in tasks that allow you to allowing to compile, assemble, test and run Java applications. You use Ant buildfiles written in XML to build your project. Each buildfile contains one project and at least one (default) target.

Maven support is very similar to Ant support. You can configure WebLogic Maven plug-ins in your POM to deploy a Java project to a WebLogic server.

This chapter includes the following sections:

• About Building Java Projects

• Building with Make and Rebuild Commands

• Understanding Dependency Checking

• Compiling Applications and Projects

• Cleaning Applications and Projects

• Building with Apache Ant

• Building and Running with Apache Maven

• Understanding Continuous Delivery and Continuous Integration

9.1 About Building Java Projects

Use Rebuild to compile source files irrespective of changes, or use Make to compiles source files with changes or have dependencies with changes. Build Java projects using Ant or Maven that uses a project object model, a project lifecyle, a dependency management system, and a set of plugins.

JDeveloper supports Rebuild operations that compile source files unconditionally. To compile source files that have changed since they were last compiled, or have dependencies that have changed, use the Make command. For each project you compile, you can configure the Java compiler by setting options in the Project Properties dialog.

Ant provides another way to build applications. You can invoke Ant from JDeveloper's main menu to build targets defined in the current project's project buildfile. Ant is integrated into JDeveloper. You can add or create Ant buildfiles for 12c applications and projects and edit them using the XML Source Editor.

Maven is project management tool that provides a consistent, automated build, test and deployment process for your projects through a project object model (POM), a project lifecyle, a dependency management system, and a set of plugins that are shareable by multiple projects. You can obtain a wide array of project information through Maven including dependency lists and unit test reports.

9.2 Building with Make and Rebuild Commands

The tabulated Make and Rebuild commands execute standard operations to compile projects in JDeveloper.

The Make and Rebuild commands shown in Table 9-1 execute standard operations for compiling projects in JDeveloper.

Table 9-1 Make and Rebuild Commands

Command	Description
Make Project	Makes all the projects the project depends on (recursively), and then makes the project.
Make Project only	Makes the project but not any of the projects it depends on.
Make Project Working Set	Makes all the projects in the working set.
Rebuild Project	Rebuilds all the projects the project depends on (recursively), and then rebuilds the project.
Rebuild Project only	Rebuilds the project but not any of the projects it depends on.
Rebuild Project Working Set	Rebuilds all the projects in the working set.
Make All	Makes all the projects.
Clean All	Cleans all the projects.
Clean Project	Cleans the project the project depends on (recursively), and then makes the project.

9.2.1 How to Set Compiler Preferences

Set the options for the way the compiler builds code using the Compiler page of the Preferences dialog. Use the procedure to configure the deployment preferences.

You can set compiler options in the Compiler page of the Preferences dialog.

To configure the deployment preferences:

1. Choose Tools > Preferences from the main menu.
2. Select the Compiler node. Configure the compile options as required. For more information, click Help.
3. Click OK.

9.2.2 Compiling with Make

Invoke a Make operation on individual source files, on working sets, or on containers to compile source files that have changes or have dependencies with changes. Use a step from the options to initiate a Make operation.

Make operations compile source files that have changed since they were last compiled, or have dependencies that have changed. Rebuild operations, in contrast, compile source files unconditionally. You can invoke make on individual source files, on working sets, or on containers such as packages, projects, and workspaces.

If you want to compile more selectively, you can add an Ant buildfile to a project, define additional targets, and run Ant to make those targets.

You cancel a compilation currently in progress by clicking the Cancel Build icon in the main toolbar.

When you click this icon, an error message prints on the top row of the Compiler Log window.

To make a source file, do one of the following:

• Right-click in a file's source editor and choose Make.

• Select one or more projects in the Applications window, and click Make in the toolbar.

• Select one or more projects in the Applications window, and choose a Make item from the Build menu.

• Select one or more projects in the Applications window, right-click, and choose Make.

9.2.3 Compiling with Rebuild

Rebuild operations are not conditional, and compile all the source files in a project or workspace. Use a step from the options to initiate a Rebuild operation.

Rebuild operations compile all the source files in a project or workspace. Unlike make operations, which recompile only those source files that have changed or have dependencies that have changed, rebuild operations are not conditional.

If you want to compile more selectively, you can add an Ant buildfile to a project, define additional targets, and run Ant to make those targets. Ant supplies a number of built-in tasks allowing you to compile, assemble, test and run Java applications.

You cancel a compilation currently in progress by clicking the Cancel Build icon in the main toolbar. When you click this icon, an error message is printed to the top row of the Compiler Log window.

To rebuild source files, do one of the following:

• Select one or more source files in the Applications window, right-click, and click Rebuild (for one file), or Rebuild Selected (for multiple files).

• Select one or more projects or workspaces in the Applications window, and click Rebuild in the toolbar.

• Select one or more projects or workspaces in the Applications window, and choose a Rebuild item from the Build menu.

• Select one or more projects or workspaces in the Applications window, right-click, and choose Rebuild.

9.3 Understanding Dependency Checking

JDeveloper analyzes dependencies while building code. A Make operation for compilation includes dependency checking which accelerates the edit and compile cycle by circumventing needless compiles of interdependent source files.

JDeveloper provides fast yet complete compiling by analyzing dependencies while building. Dependency checking results in fewer unnecessary compiles of interdependent source files, and thus accelerates the edit and compile cycle.

When you compile using JDeveloper, dependency checking is performed whenever you compile with Make. Make uses a dependency file that is automatically created within JDeveloper.

If you compile from the command line, you create or use a dependency file by specifying the following parameter:

javac -make <makedepfile>

9.4 Compiling Applications and Projects

Set the compiler options for the Java Compiler, Javac that JDeveloper uses by selecting Options for Compiler from Project Properties. Javac transforms Java source code into Java bytecode for JVMs.

JDeveloper uses the Java Compiler (Javac) to compile Java source code (.java files) into Java bytecode (.class files). The resulting bytecode is the machine code for a Java Virtual Machine (JVM). Compiling a Java source file produces a separate class file for each class or interface declaration. When you run the resulting Java program on a particular platform, its JVM runs the bytecode contained in the class files.

Javac compiles the specified Java file and any imported files that do not have a corresponding class file. Unless dependency checking is specified (with the -make option), the compiler compiles all of the target Java files. See Understanding Dependency Checking.

When you work inside JDeveloper, the compiler used is Javac. You can adjust compiler options by choosing Project Properties > Compiler > Options. Each option on the Compiler: Options page contains a description alongside it.

9.4.1 How to Configure Your Project for Compiling

Set the options in the Project Properties for how the Java compiler builds code. Use the procedure to configure project properties for compiling.

For each project, you can configure the Java compiler by setting options in the Project Properties. For example, you may not want the compiler to display compiler messages such as:

• Note: Some input files use unchecked or unsafe operations.

• Note: Recompile with -Xlint:unchecked for details.

To configure project properties for compiling:

1. Right-click a project in the Applications window and choose Project Properties from the context menu.

   You can also double-click a project node in the Applications window.

2. In the Project Properties dialog, expand the Compiler node.
3. Click Options.
4. Under Compiler Options, expand the Javac node.
5. Optionally expand the Warnings node.

   You can optionally check here first to see which options are turned on by default. For example, if -Xlint:all is turned on, all -Xlint warnings are turned on.

   If you do not want to display the -Xlint message, go to Compiler > Options and expand the Javac > Warnings node in the Project Properties dialog. This allows you to specify which Xlint messages are displayed.

6. Optionally expand the Turn Individual Warnings Off node.
7. Uncheck the -Xlint Unchecked checkbox.
8. Close all dialogs and recompile.

Note:

If you want to have all your project files automatically saved before compiling, specify this in the Compiler page of the Preferences dialog.

9.4.2 How to Specify a Native Encoding for Compiling

The compiler uses the default native-encoding converter for the platform if no encoding scheme to control how the compiler interprets multibyte characters is set. Use the procedure to set an encoding option.

You can specify an encoding scheme to control how the compiler interprets multibyte characters. If no setting is specified, the default native-encoding converter for the platform is used.

Text characters are represented using different encoding schemes. In the Windows environment, these are code pages, whereas Java refers to them as native encodings. When moving data from one encoding scheme to another, conversion needs to be done. Since each scheme can have a different set of extended characters, conversion may be required to prevent loss of data.

Most text editors, including the JDeveloper source editor, use the native encoding of the platform on which they run. For example, Japanese Windows uses the Shift-JIS format. If the source code has been encoded with Shift-JIS and you are compiling it in a US Windows environment, you must specify the Shift-JIS encoding for the compiler to read the source correctly.

JDeveloper supports the character encoding schemes included with your currently installed J2SE.

To set the encoding option, do one of the following:

1. In JDeveloper, select Project > Project Properties.
2. In the Project Properties dialog, select the Compiler node.
3. On the command line, use the javac command with the -encoding option followed by the encoding name.
4. Choose an encoding name in one of the two following ways:

   • Select a name from the Character Encoding dropdown list.

   • Select "default" from the Character Encoding dropdown list to use the default encoding of your environment.

The Java SDK supported encodings are listed at http://download.oracle.com/javase/6/docs/technotes/guides/intl/ encoding.doc.html

9.4.3 Compiling from the Command Line

Compile applications and projects from within JDeveloper using the Build and Compile options, or compile from the command line by using the ojmake and ojdeploy tools.

There are two ways to compile applications (workspaces) and projects:

• Inside JDeveloper by using the various Build and Compile options on the application and project nodes

• From the command line by using ojmake and ojdeploy.

You can find both ojmake and ojdeploy in the jdeveloper/jdev/bin directory.

• ojmake can be used for applications and projects that don't involve any deployment, for example, projects with no deployment profile defined.

• ojdeploy can handle the build of any application and project (including any that involve deployment). You can think of it as a super-set of ojmake.

You can view help for the tools simply by executing ojmake or ojdeploy on the command line. The help will display in the console.

Note:

When you work from the command line, it is possible to use Javac to compile Java files, but it's not possible to build applications and projects by executing Javac manually. You must use ojmake or ojdeploy.

For information about using ojmake, see Using ojdeploy and ojmake.

For information about using ojdeploy, see Using ojdeploy.

9.5 Cleaning Applications and Projects

Specify the output location of the project to be cleaned as a directory, and use the Clean command to remove class files, all copied resource files, and all deployed files from the output, and deploy directories in a project or application. The Clean All and Refresh Application command also cleans IDE artifacts such as index files and deploy files.

Cleaning enables you to remove previous build artifacts and start afresh. You can clean your application or project using the Clean command. Running this command cleans the output and deploy directories in your project or application.

Running the Clean command on an application or project removes all class files, all copied resource files, and all deployed files. You can do this to ensure that there are no outdated files in the output and deploy directories. For instance, classes get renamed, moved, or deleted, and obsolete class files belonging to those classes need to be removed. Similarly, resources and deployments also get renamed, moved or deleted, and their obsolete copies in the output directory or deployment directory need to be removed.

The content in the deploy directory of the application is deleted.

The following conditions must be satisfied for the Clean command to run successfully:

• The output directory of the project to be cleaned, or of each of the projects in the application to be cleaned, must be specified.

• The output location must be specified as a directory, and not a file.

The Clean All and Refresh Application command performs all the functions described above but it also cleans IDE artifacts such as index files, deploy files, etc. If these artifacts are not cleaned, you may encounter errors during compilation or at runtime because these IDE artifacts may be out of sync with the current state of the application.

9.5.1 How to Clean

The Clean command enables you to remove artifacts left over from previous builds in order to begin a fresh build process.

9.5.1.1 Cleaning a Project

Cleaning a project prevents errors during compilation or at runtime. Use the procedure to clean a project.

You can clean a single project within an application.

To clean a project:

1. In the Applications window, select the project to be cleaned.
2. In the Build menu, select Clean <project>.
3. In the Cleaning <project> dialog, click Yes.

9.5.1.2 Cleaning an Application

Cleaning an application cleans the application and all of its projects. Use the procedure to clean an application.

Cleaning an application cleans the application and all of its projects. When you clean an application:

• The content in the output and deploy directories of each of the constituent projects in the application are deleted.

• The content in the deploy directory of the application is deleted.

To clean an application:

1. In the Applications window, select the application you want to clean.
2. In the Build menu, select Clean All.
3. In the Cleaning application dialog, click Yes.

9.5.1.3 Cleaning and Refreshing an Application

Select the Clean All and Refresh Application option to sync the IDE artifacts with the current state of the application and clean IDE artifacts to prevent errors at compilation or runtime. Use the procedure to clean and refresh an application.

You can clean and refresh and application with a single command.

To clean and refresh an application:

1. In the Applications window, select the application to be cleaned and refreshed.
2. In the Build menu, select Clean All and Refresh Application.
3. In the Cleaning All and Refresh Application dialog, click Yes.

9.6 Building with Apache Ant

Ant, a Java library and command-line tool written in Java, is integrated with and installed with JDeveloper. Ant is extensible, supports cross-platform compilation, and uses XML formatted buildfiles to describe and control build processes for applications and application components.

Apache Ant is a build tool similar in functionality to the Unix make utility. Ant uses XML formatted buildfiles to both describe and control the process used to build an application and its components. Ant supports cross-platform compilation and is easily extensible. Apache Ant is a product of the Apache Software Foundation. See http://ant.apache.org/index.html.

An Ant buildfile defines targets and dependencies between targets. Each buildfile contains one project and at least one target. A target is a sequence of programmatic tasks. When you run Ant to make a target, it first makes other targets on which it depends, and then executes the target's own tasks.

Ant is integrated and installed as part of JDeveloper, which means you do not need to add it as an extension. You can add or create Ant buildfiles for applications or for projects, or you can create and empty buildfile. You can use the XML Source Editor in JDeveloper to edit Ant buildfiles.

9.6.1 Create an Ant Build File at Application Level

An Ant buildfile defines targets and dependencies between targets. Use the procedure to create an Ant build file at the application level.

To create an Ant build file at application level:

1. Open the New Gallery by choosing File > New.
2. In the New Gallery, in the Categories tree, under General, select Ant.
3. In the Items list, double-click Buildfile from Application. The Create Buildfile dialog opens where you can change the default filename and directory. For help with the dialog, press F1.
4. Click OK. A new build.xml file is created and opened in the XML Source Editor. The generated build.properties file is also created. Both files are listed in Application Resources in the Applications window.

9.6.2 Create an Ant Build File at Project Level

Use the procedure to create an Ant build file at the project level.

To create an Ant build file at project level:

1. Open the New Gallery by choosing File > New.
2. In the New Gallery, in the Categories tree, under General, select Ant.
3. In the Items list, double-click Buildfile from Project. The Create Buildfile dialog opens where you can change the default filename and directory. For help with the dialog, press F1.
4. Click OK. A new build.xml file is created and opened in the XML Source Editor. The generated build.properties file is also created. Both files are listed in Application Resources in the Applications window.

9.6.3 Create an Empty Ant Build File

Use the procedure to create an empty Ant build file.

To create an empty Ant build file:

1. Open the New Gallery by choosing File > New.
2. In the New Gallery, in the Categories tree, under General, select Ant.
3. In the Items list, double-click Empty Buildfile. The Create Buildfile dialog opens where you can change the default filename and directory. For help with the dialog, press F1.
4. Click OK. A new build.xml file is created and opened in the XML Source Editor, and it is listed in the Applications window under the Resources node.

Example 9-1 Running Ant on buildfile targets:

• On targets in the project buildfile. A project can contain several Ant buildfiles, but only one can be designated as the project buildfile. You can configure the Run Ant on <project> toolbar icon and dropdown menu to give easy access to the project buildfile's targets.

• From the Structure window when editing an Ant buildfile. When an Ant buildfile is open in an XML source editor, its targets are listed in the Structure window. You can select these and run them.

• From external tools you define. Use the Create External Tool wizard to define menu items and toolbar buttons that make Ant targets.

9.6.4 Running Ant on Project Buildfile Targets

A project contains one designated project buildfile to build tasks that work towards a required state during the build process. Invoke Ant in JDeveloper to build targets defined in the project buildfile.

You can invoke Ant from JDeveloper's main menu and toolbar to build targets defined in the current project's project buildfile.

A project can contain several Ant buildfiles, one of which can be designated as the project buildfile. You can configure the Run Ant on <project> toolbar button and dropdown menu to give easy access to the project buildfile's targets.

To select and configure a project's buildfile, go to the Ant project properties page (choose Project > Project Properties > Ant).

You can run Ant on targets in the project buildfile:

• From the toolbar, click Run Ant on <project>.

  Ant will make the project's designated default target.

• From the main menu, choose Build > Run Ant on <project>.

  Ant will make the project's designated default target.

• From the Structure Pane, choose a target.

9.6.5 Using the Ant Tool in the IDE

The Ant Log window displays messages pertinent to an Ant build, such as building targets, compilation errors, and warnings pointing to the source code, and the output level of the messages.

The Ant Log window displays messages specific to the Ant build. Some features of the Ant Log window are:

• It displays messages generated by an Ant invocation to build one or more targets.

• Messages generated by Ant tasks are linked to the definitions of those tasks in the Ant buildfile, while compilation errors and warnings are linked to the source code that produced them.

• The color coding indicates the output level of messages.

9.7 Building and Running with Apache Maven

Apache Maven is a build process automation tool that manages a project build, reporting, and documentation from the project object model. Use Maven to build projects, manage dependencies on Oracle and third party artifacts, and to download artifacts.

Apache Maven is a widely used tool for managing and automating the build process. It is also used for project management, in particular dependency and release management.

It provides consistent and automated build, test and deployment of applications built using JDeveloper. One advantage of using it is that a developer who has worked on a project that uses Maven is usually able to transfer to another project that uses Maven with very little effort. Most developers who have used Maven before are able to get an unfamiliar project that uses Maven downloaded, built and deployed quickly.

Maven can manage a project's build, reporting and documentation from a central piece of information, the project object model (POM). You can build the project using its POM and a set of plugins that are shared by all projects using Maven, providing a uniform build system. A Maven lifecycle consists of the processes for building and processing an artifact, that is a project. The following are different types of Maven build lifecycles:

• Default - project deployment

• Clean - project cleaning

• Site - project site documentation

Each build lifecycle is defined by a set of build phases where each phase a stage of the lifecycle. For example, a default build lifecycle can consist of the following phases:

• validate - verify the project is correct and all necessary information is available

• compile - compile the source code of the project

• test - test the compiled source code using a suitable unit testing framework

• package - take the compiled code and package it in its distributable format, such as a JAR.

• install - install the package into the local repository, for use as a dependency in other projects locally

• deploy - copy the final package to the remote repository for sharing with other developers and projects

In turn, each phase is defined by a set of plugin goals (tasks) that determine specifically how the phase is accomplished. Goals and phases are run sequentially and in the order they are invoked. JDeveloper enables you to define the phases and their goals and invoke them from the POM file context menu. For more information, see SeeUsing the Context Menu in the POM file .

If you are developing an application using Oracle Fusion Middleware, you can use Maven to:

• Build projects.

• Manage dependencies on Oracle and third party artifacts.

• Download artifacts automatically from an internal or external (public) Maven repository.

For information about Maven, see http://maven.apache.org/index.html.

9.7.1 Understanding Repositories

A Maven repository is sharable location that hosts a collection of artifacts. Artifacts can be pulled in from central public repository or private repositories. Maven updates artifacts from specified public or private repositories. Each artifact is pulled into your local Maven repository as a build executes. The artifacts are organized in a particular directory structure. These include compiled code (JAR files, WAR files) and metadata about that code.

There are two types of repositories:

• Local Repository - A cache of a remote repository that is stored on the local machine. Maven projects are built against the local repository. The local repository usually only stores a subset of the files available in the remote repository and any temporary build artifacts. Maven accesses this location for resolving any artifact. You should not edit the contents in this location.

  When you execute a Maven goal to build a project, Maven downloads any necessary dependencies from the upstream repositories and saves them in your local repository. Maven accesses this location for resolving any artifact.

• Remote Repository - A repository that contains all the Maven artifacts and plugins. The remote repository may be a third-party repository (for example, http://repo.maven.apache.org/), or it may be a private internal repository.

JDeveloper manages Maven repositories and makes them available to you, typically through HTTP. It may also proxy (cache artifacts from) other, usually external, Maven repositories to shorten build times and reduce network usage. This means that a Maven POM is provided for each developer-focused product artifact. You are then able to configure Maven to point to this Maven repository.

Use the Maven Synchronization tool to facilitate setting up and populating the repositories. The synchronization tool is a plugin available in the Oracle JDeveloper and the Oracle WebLogic Server installations. To add this plugin, see Populating the Repository.

9.7.2 Understanding Maven Plugins

Extend Maven with plugins because Maven is a plugin execution framework whose work is done by plugins. Configure core plugins such as build plugins that run during the build, and reporting plugins using the <build/> and <reporting/> elements from the POM.

You can extend Maven with plugins. These provide a number of other development tools for reporting or the build process. Plugins allow running Maven goals. All work is done by plugins. There are a number of core plugins:

• Build plugins execute during the build and should be configured in the <build/> element from the POM.

• Reporting plugins execute during the site generation and should be configured in the <reporting/> element from the POM.

For a list of available Maven plug-ins, see http://maven.apache.org/plugins/index.html.

9.7.3 Understanding Dependencies

Maven dependencies specify the libraries containing the jar files required for project builds. Compilation causes Maven to download and link dependencies, and all dependencies in the POM file are always kept in sync with the .jpr project or the .jws application.

You use a Maven dependency to specify a library containing the jar files required for building your project. If you build a project with a dependency that does not exist in a local repository, Maven will search for it and add it to your local repository. If the project is a Maven project (that is, has an associated POM file) and dependencies are added to the project, the changes are committed to the POM as well.

Maven downloads and links the dependencies for you on compilation and other goals that require them. It also brings in the dependencies of those dependencies (transitive dependencies), allowing your list to focus solely on the dependencies your project requires.

Dependencies are synchronized between the selections on the Dependencies tab and the POM file. For example, if a project has a dependency that is not in the POM and you add another dependency from the project, both dependencies are added to the POM when you click OK on the Maven: Dependencies dialog.

The dependencies in the POM file are always kept in sync with the .jpr project or the .jws application associated with the POM file. The dependencies (except from the repository) can also be added from project properties and application properties dialogs, they are automatically synced to the associated POM file.

9.7.4 Understanding the Project Object Model

Project Object Model represents a Maven project held in a file named pom.xml that contains project information and the plugins configurations required for the build process. The required fields, groupId:artifactId:version and packaging point to a specific project version and behave like an address and timestamp.

A Maven project object model (POM) file is similar to a JDeveloper .jpr file. The POM is an XML file that contains information about the project and configuration details used by Maven to build the project. The XML file contains most of the information required to build a project. Configuration information that can be specified in the POM includes the project dependencies, the plugins or goals that can be executed, and the build profiles.

Maven uses the concept of "convention over configuration" by assuming a standard default behavior for projects. For instance, for a Java application, Maven assumes the location of source code is ${basedir}/src/main/java, resource files are assumed to be in .../main/resources, and so on. Following convention then, Maven assumes that ultimately a JAR is to be created in a directory ${basedir}/target. All of this information is already contained in the POM, relieving you of having to configure each and every path. The Maven core plugins also employ conventions for compiling source code, packaging, and other processes. By following convention, Maven can perform most of the work of building and managing a project for you.

The following are the minimal Maven coordinates that a POM can contain:

• Group ID - a unique identifier for the project that is similar to a package name, for example, com.acme.corp.

• Artifact ID - the name of the JAR without the extension, for example, MyProject.

• Version - the current version of the artifact produced by this project, for example 1.1.0.

Packaging is another coordinate that you can specify when creating a POM. You use packaging to specify the project's artifact type (for example, you specify that the project is packaged as a JAR or a WAR file). If you do not specify a value for packaging, Maven assumes the default type is a JAR.

For information about the Maven Project Object Model, see: http://maven.apache.org/index.html

9.7.5 Understanding the Settings File

Use the main Maven control file, the settings.xml file, that is common to all projects, to configure Maven execution, such as setting the local repository path, setting an alternate remote repository servers, and setting proxies. Use the procedure to configure the settings.xml file.

The settings.xml file is the main Maven control file. You use this file to configure Maven execution such as setting the local repository path, setting an alternate remote repository servers, setting proxies, and more. However, unlike the POM file, the settings.xml file should remain common to all projects (recommended) until you explicitly change it.

To configure the settings.xml file:

1. In the main menu, choose Tools > Preferences.
2. Select Maven > Settings in the category tree.
3. Check the command line options you want.

For information about the settings file, see http://maven.apache.org/settings.html.

9.7.6 Selecting the POM File

Select a POM for an application and each project so as to sync the paths and the dependencies of the.jpr file. Use the procedure to set the application POM file.

When you use Maven to create and manage your application, a POM is created at the application level and for each project within the application. You can specify the POM files to use for the application and each project. When you select the POM file for a project, the paths and the dependencies of the .jpr will automatically be in sync.

Note:

Typically you do not need to explicitly set the POM files as they are set when you create the application or project when you select Maven as the build tool in the application or project creation wizard. The POM files are also set if you choose to create a POM for your application or project from the gallery.

To set the application POM file:

1. Right-click the application in the Applications Window and choose Application Properties.

2. Select Maven in the category tree.

   If this is the first time you have selected Maven for this application, click Load Extension.

3. Click the Browse button and select the POM file you want to use.

To set the project POM file:

1. Right-click the project in the Projects window and choose Project Properties.
2. Choose Maven in the category tree.
3. Click the Browse button and select the POM file you want to use.

9.7.7 Installing Maven

Maven is provided by JDeveloper and can be found in the ORACLE_HOME/oracle_common/modules directory. If you want to install Maven on a server, see Installing and Configuring the Archiva Maven Repository Manager.

9.7.8 Before You Begin

Use the procedure to create a Maven application and project for use. Create an application and generate POM files for an application and all of its projects using the New Gallery.

To use Maven, you first create an application and then select options for at least one of the projects within it.

You can generate POM files for an application and all of its projects using the New Gallery. This generates an application, a top level Project Object Model file (pom.xml) for the application, and a default pom.xml file for each project.

To create a Maven application and project for use:

1. From the Main menu, select File > New > From Gallery > Maven > Application POM.
2. Follow the instructions in the dialog to specify options that create an application that will be configured for use with Maven technologies.
3. Ensure that you enter the options marked (required) in the wizard:

   • Group ID

   • Artifact ID

   • Version

4. When you complete the wizard, the application displays in the Applications window with a single Maven project under it.

   Note:

   You can also create another type of application, for example, a Custom application, and import an existing Maven project to it using the New Gallery.

5. In the Applications window, expand a project node and it's Resources node.
6. Double-click the POM file to open it.

   By default, the name of the POM file is pom.xml. It is usually located in the Applications window under Projects > Resources.

7. In the Overview tab, click Repositories.
8. In the Local Repositories field, check for a red underline.

   A red underline indicates that the directory being pointed to is an invalid one. It does not show up for a valid directory.

   This field displays the location of your local Maven repository. The repository holds a local copy of all artifacts and dependencies that your project may need.

   By default, the location of the local repository is USER_HOME/.m2/repository. If the location of the local repository is underlined in red, the location is invalid. Create a directory using file explorer or using the browse icon next to the Local Repositories field. Once you select a valid directory, the red underline disappears.

   The local repository remains common to all projects (recommended) until you explicitly change it.

9. Choose File > Save to save any changes.
10. From the Main Menu, choose Tools > Preferences > Maven > Settings.
11. Optionally change the path in the User Settings field.

    When you create the Maven application, a file called settings.xml is also created in USER_HOME/.m2/ by default.

12. Click OK.
13. From the Main menu, select Tools > Preferences > Web Browser and Proxy.

    By default, settings.xml does not contain active proxy information, but JDeveloper has proxy settings enabled.

14. Click the Proxy Settings tab and select either Use System Default Proxy Settings or Manual Proxy Settings.

    Maven uses the proxy to download artifacts from remote repositories.

15. Click OK when you are finished.

9.7.9 How to Create Maven POM Files

You can add a POM file to a project that is created in a Maven-enabled application. Use the procedure to create a POM.

If you create a project in a Maven-enabled application, you can add a POM file to the project.

To create a POM:

1. In the Applications Window, select the project or file where you want to locate the POM.
2. Choose File > New > From Gallery to open the New Gallery.
3. In the Categories list, expand General and select Maven.
4. In the Items list, select Maven POM for Project.
5. Click OK.
6. Change any required and optional options in the dialog as needed.
7. Click OK.

   The POM file is created under the Resource node of the project and the file is opened in the Overview editor by default.

9.7.10 Using the Context Menu in the POM file

Specify the phases or goals to include in a lifecycle phase to create and manage a goal profile. Use the procedures to create or manage a goal profile, and to add a goal.

You can access a menu of commands such as Run Maven Goal Profile profile and Run Maven Phase phase by right-clicking the pom.xml file in the Applications window or the pom.xml Overview or Source tab if you have the POM file open.

You can create and manage a goal profile by specifying the phases or goals to include in a lifecycle phase:

To create or manage a goal profile:

1. Right-click a POM file.

2. Select Manage Goal Profiles.

3. In the Maven: Phases/Goals preference page, select the goal profile you want (or click the plus icon to create a new profile).

4. Select the lifecycle phases you want and click the right arrow to move them into the Selected Phases/Goals column.

   Hold down the Shift key to select and move multiple phases at once.

5. Click OK.

You can customize the list of phases and goals by adding or deleting goals from the Selected Phases/Goals list. For instance, if you want to be able to undeploy a Maven application, you can add the undeploy goal from the weblogic-maven-plugin available from the local repository.

To add a goal:

1. Click the plus (+) sign in the Selected Phases/Goals panel.
2. Locate and expand the plugin node containing the specific goals you want to add.
3. Select the goals (press Shift down to select multiple goals in sequence or press Ctrl to select non-adjacent goals) you want.
4. Click OK.

If the goal you want is not available in the local repository, click Download from Remote Plugin Repository and specify the name of the goal, the plugin version, and select the remote repository containing the plugin. To ensure you have access to the remote repository, click Verify Plugin.

For information on running Maven goals from the command line, see "Running the Oracle Maven Synchronization Plug-In".

For information on Maven phases and goals, see http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html.

9.7.11 How to Specify and Manage Remote Repositories

If a project needs artifacts in remote repositories, use the Tools menu or the POM file of the project to manage the remote repositories. Use the procedures to add and manage remote repositories by means of Preferences in Tools, and by means of the POM file.

You need access to remote repositories for a number of reasons. For example, your project might use dependencies from different external vendors. These dependencies may be available in different remote repositories. JDeveloper allows you to configure and search for artifacts in remote repositories.

You can manage remote repositories through Tools > Preferences from the main menu or through a project's POM file. If you add a remote repository through the Preferences dialog, you can add the repository to the settings.xml file making it available to all projects in the application. If you add the remote repository to the project's POM file, it is available only to that project.

To add and manage remote repositories through Tools > Preferences:

1. From the Main menu, click Tools > Preferences > Maven > Repositories.

2. In the Remote Repositories table, click the Add (+) icon.

   A new row is added to the table.

3. Select the new row.

4. In the Repository Details section of the Maven - Repositories page, enter a URL to the remote repository, for example, http://repo1.maven.org./maven2.

5. In the Index Update URL field, enter the base location from where nexus-maven-repository-index.zip and nexus-maven-repository-index.properties will be downloaded from.

   You must provide the index location to search for artifacts in the repository without having to actually download them.

   Note:

   You can check the accessibility to the repository and its index data by clicking the Test button.

6. Select Include in Settings.XML to add the repository to the settings.xml file.

7. Select the checkbox for the new repository in the Remote Repositories table.

8. Click the Index Selected Repositories icon (located to the right of the Delete Repository icon).

   This downloads the indexing data for the selected remote repository.

To add and manage remote repositories through the POM file:

1. Double click the pom.xml file for your Maven project in the Applications window. Details of the POM file are displayed in the IDE. By default, the General tab is opened.
2. Click the Repositories tab.
3. In the Remote Repositories table, click the Add (+) icon.

   A new row is added to the table. Alternatively, you can open the drop-down list next the Add icon and select Add Repository to add a new row.

   Alternatively, you can choose Add From Preferences to add a remote repository from a list of remote repositories. Select the desired repository and click OK to add it to the list of remote repositories.

4. Enter the name, ID, and URL of the new repository.
5. Check Repositories to include this repository in the Repositories section of the POM file.
6. Check Plugin Repositories to include this repository in the Plugin Repositories section of the POM file.

   If you are entering a new remote repository, you can click Add to Preferences to add the selected repository to the Preferences list.

Once added, you can specify the following details for the selected repository:

• Layout - Whether the directory structure of the repository is legacy (Maven 1) or the default (Maven 2). The layouts differ in directory structure, timestamp of snapshots in default, and existence of metadata files in default.

• Do Not Search for Releases - Whether Maven should look for release versions.

• Do Not Search for Snapshots - Whether to depend on snapshot releases. Note that is not advisable to release or deploy an artifact that has a dependency on a snapshot version of an artifact.

• Update Policy - How Maven should look for updates in the repository (always, daily, interval, or never) when searching for release version and for searching for snapshots.

• Checksum Policy - Which checksum policy to use (warn, fail, or ignore) when searching for release version and for searching for snapshots.

9.7.12 Populating the Repository

Upon a Maven project creation, JDeveloper downloads the latest versions of the artifacts into the local repository, and the Maven Synchronization plugin available with JDeveloper populates the local or shared repository with Maven artifacts. Use the procedure to run the Maven Synchronization plug-in in a shared repository.

When you create a Maven project, the IDE downloads the most recent artifacts into your local repository. In a typical development scenario, these dependencies are downloaded from a shared repository, although JDeveloper can also populate your local repository from IDE library definitions.

Oracle recommends development teams maintain a shared repository containing the artifacts the application depends on for compilation. To populate a shared repository containing JDeveloper and ADF libraries for teams to develop against, you can use the Maven Synchronization plugin (also referred to as the sync tool).

The Maven Synchronization plugin populates your local or shared repository from your ORACLE_HOME directory. The plugin is available with JDeveloper. The Synchronization plug-in consists of two components:

• oracle-maven-sync-version.pom - Describes the plug-in. The value of version is the version of the Maven sync POM file, for example, oracle-maven-sync.12.1.3.0.0.pom.

• oracle-maven-sync-version.jar - Contains the plug-in. The value of version is the version of the Maven sync JAR file, for example, oracle-maven-sync.12.1.3.0.0.jar.

Both components are located at ORACLE_HOME/oracle_common/plugins/maven/com/oracle/maven/oracle-maven-sync/version.

The synchronization plug-in checks for all Maven artifacts in ORACLE_HOME, ensures that all artifacts are installed in the specified repository, and that the versions are an exact match. This means that the version numbers and the files are exactly the same at the binary level, ensuring that all patched files reflect accurately in the Maven repository, which is essential for a successful deployment.

Maven artifacts like plugins are installed in ORACLE_HOME/maven/artifact.

To run the Maven Synchronization plug-in in a shared repository:

1. Install the Maven Synchronization plug-in:

   mvn install:install-file -DpomFile=/oracle-maven-sync.version.pom -Dfile=oracle-maven-sync.version.jar

2. Run the sync tool to populate the shared repository:

   mvn com.oracle.maven:oracle-maven-sync:push -Doracle-maven-sync.oracleHome=ORACLE_HOME -Dmaven.repo.local=/alt_path

Note:

For initial testing and prototyping of your Maven project, JDeveloper will populate a local repository for you, however, this is not recommended.

For information on installing and running the Maven Synchronization plug-in, see "Populating the Maven Repository Manager".

Once you have populated the repository, you have access to many archetypes, including the ADF oracle-adffaces-ejb archetype, which provides the basic template for Fusion Web applications using the Model and ViewController projects. When you use this archetype to create an application, three POM files are generated:

• A POM for the EJB project

• A POM for the WAR (JSF) project

• A POM that defines the EAR that packages the EJB and WAR projects

The project POM files contain the ojmake plugin and ojdeploy plugin. Both project POMs point to the parent POM that refers to a parent project from which the other projects inherit dependencies, plugins, plugin configurations, repositories, and more.

For information on creating an application using a Maven archetype, see How to Create Maven Projects Using Maven Archetypes.

9.7.12.1 Synchronizing POM and Project Files

When the project source path or the classpath for Maven-enabled projects is updated, the change to the POM file is synchronized in JDeveloper. If a dependency is added in the POM source file for a project, JDeveloper adds that artifact to the project .jpr file.

For Maven-enabled projects, when you update a project source path or classpath, JDeveloper synchronizes the change to the POM file. For example, if you go to the Libraries and Classpath panel of the Project Properties dialog and add a JAR file, JDeveloper creates a POM for that JAR file, loads it into your local repository, and adds a <dependency> element in the project's POM file. Similarly, if you add a dependency in the POM source file for your project, JDeveloper adds that artifact to the project file (.jpr).

9.7.12.2 Customizing Maven Synchronization

Upon a POM file modification, Maven automatically updates the project files to keep the project and POM in sync, and conversely, whenever a project is modified, the POM is automatically synced. Use the procedure to switch to manual synchronization.

Each time a POM file is modified, Maven automatically updates the project files to keep the project and POM in sync. The reverse is also true, that is whenever a project is modified, the POM is automatically synced.

Automatic synchronization between the project and POM is a setting in the application properties Maven page and is set to ON by default. In some cases, however, you might prefer to control when synchronization occurs, for instance:

• You are making several changes to a project or POM and you want to sync the repository once after all changes have been made instead of having syncing occurring at each change

• You have updated the project but do not want the POM to be updated immediately

• Your project is under source control and after making changes, you discover that the POM file or some project files were not checked causing synchronization to fail and you want to be able to manually trigger synchronization after checking out all files

• Libraries or classpath dependencies added to the project are not present in any of the project's repositories, and you want to manually trigger the deployment of libraries and classpath dependencies to the local repository

You can switch the synchronization setting to manual mode and trigger syncing to occur (from POM to project or project to POM) when you want it. You can also set an audit rule to alert you if the project and POM become out of sync when in manual mode. You can then elect to run a sync operation from the audit window. For information on setting an audit rule, see 11.2.7 How to Audit Java Code in JDeveloper.

To switch to manual synchronization:

1. Right-click an application and choose Properties from the context menu.
2. Select Maven in the Properties window.
3. Select Manually manage POM-Project synchronization.
4. Deselect Automatic synchronization.
5. Click OK.

When you are ready to sync the POM and project, go back to the Maven page in the Properties window and click Sync Now. Depending on what was modified, you can sync the POM to the project or the project to the POM.

Some project dependencies have dependencies of their own, referred to as transitive dependencies. When syncing dependencies from the POM to the project, any transitive dependencies are also synced at the same time.

9.7.13 How to Match the Default Maven Structure When You Create an Application

When a new Maven application is created, the normal project structure can be modified to match the default Maven structure. Use the procedure to modify the default Maven structure.

You can match the default Maven structure when you create a new Maven application.

To modify the default Maven structure:

1. Choose File > New > From Gallery to open the New Gallery.
2. In the Categories list, expand General and select Applications.
3. Choose Custom Application, then OK.
4. Choose default options and click Next.
5. On the Project Features tab, scroll down to Maven.
6. Click the shuffle icon to move Maven to the Selected column of the Project Features tab.
7. Click Next.
8. Select the Modify Normal Project Structure To Match The Default Maven Structure checkbox.

   This is selected by default.

9. Click Finish to create the custom application.

9.7.14 How to Create Maven Projects Using Maven Archetypes

Maven Archetype is a project template toolkit from which the src-main and src-test types of source code are generated for a project. Use the procedure to create a Maven-enabled J2EE application using an archetype.

Archetypes are similar to templates that you can use to create applications quickly using Maven. The archetype provides a consistent means of generating Maven projects. For more information, go to http://maven.apache.org/guides/ and see the links for "What is an Archetype" and "Creating Archetypes."

To create a Maven-enabled J2EE application using an archetype:

1. Choose File > New > From Gallery.
2. In the Categories list, expand General and select Maven > Generate from Archetype.
3. In the Create Project from Archetype dialog's Select an Archetype page, enter options for the new project. Ensure that you enter the options marked (required) in the dialog.
4. Click the browse icon next to the Maven Archetype field.
5. In the search field in the Search for Archetype dialog, enter search text and any filters to find the archetype you want to use.

   For example, you could enter j2ee as your search text to find an archetype called maven-archetype-j2ee-simple. You can also choose to narrow the search to a particular repository or repositories.

   Note:

   The list of available repositories is set in the Maven - Repositories page.

   To access a remote repository, make sure you have specified proxy information on the Web Browser and Proxy dialog.

6. Select the repositories to search in the Repositories panel.
7. Press the Return key.

   The Matching Archetypes list populates with all of the archetypes that meet your search criteria.

8. Drill down to an archetype in the list and select it, for example, maven-archetype-j2ee-simple.
9. Click OK.

   The archetype source is displayed in the Maven Archetype field on the Select an Archetype page.

10. Click Next.
11. Change the value of a parameter if needed by double-clicking in the Parameter Value column for the selected parameter, and enter a new value.
12. Click Finish.

    A new Maven application is created from the archetype. It displays in the Applications window, as shown in Figure 9-1.

    Figure 9-1 Maven Application in Applications window

    
    Description of "Figure 9-1 Maven Application in Applications window"

When you create a maven project using an archetype, two types of source code are generated. A src/main and src/test are generated. Project source code and resources are placed under src/main while test cases for the project are placed under src/test. You can find Java classes such as JUnit or TestNG tests in this directory along with classpath resources for tests.

Note:

You can also import existing Maven projects into JDeveloper by selection using New Gallery > General > Maven > Import Maven Projects. This creates a Maven application and associated projects based on the contents of the imported Maven source.

9.7.15 What Happens When You Create a New Maven Application

Use the procedure to view dependencies for a Maven application in Dependencies for ejbs Resources.

The application in Figure 9-1 contains a number of Maven projects.

1. In the Applications window, scroll to the ejbs project under the Maven application you just created.
2. Expand ejbs, then Resources.
3. Double-click the project file. By default this should be pom.xml. The Editor opens.
4. Click the Dependencies tab.
5. Notice the dependencies on the Dependencies tab, for example, those shown in Figure 9-2:

   Figure 9-2 Maven Dependencies

   
   Description of "Figure 9-2 Maven Dependencies"
6. From the Main toolbar, choose Project > Project Properties > Libraries and Classpath.
7. Notice that the same two dependencies in Figure 9-2 are listed here.

   The dependencies are kept in sync between the application/project and its associated project POM files. Try adding new dependencies in the application/project or POM file to observe the sync process. The sync is required to manage the application/project using both JDeveloper build tools and Maven.

8. In the Project Properties dialog, click on Maven.

   This POM file is set as default POM for the project.

9.7.16 How to Run Maven Goals on POM Files

Maven plugin goals, such as clean, compile, build, and package, represent stages that comprise build phases in build lifecycles. Use the procedure to run Maven goals.

Maven is based around the concept of a build lifecycle. A build lifecycle is made up of build phases, wherein a phase is comprised of plugin goals that represent a stage in the lifecycle. Maven provides some default goals such as clean, compile, build, and package to manage your project. Every project runs the same core phases which includes the goals in the phase.

To run Maven goals:

1. From the Main menu, select Tools > Preferences > Maven > Phases/Goals.

   You can also right click on a POM file in the Overview or Source tab and choose Manage Goal Profiles.

2. To optionally set up a profile, a collection of goals that you can save for future use, click the plus (+) icon next to the Goal Profile field.

   • In the Goal Profile field, enter a name for your profile and click OK.

3. In the Available Lifecycle Phases list, select one or more goals.

   Note:

   The first time you try this, make sure the default set of goals are included in this list.

4. Click the shuttle button to add the selection to the Selected Phases / Goals list.
5. Click OK.
6. In the Applications window, scroll down to the POM file for the project you want to run.
7. Right click and Run Maven Phase "compile".

   This downloads some artifacts into the local repository from a remote central repository automatically that are required to execute the compile goal. This is one-time process. Once you have a copy of those artifacts in your local repository, Maven no longer needs to download them again.

   After downloading, the compile goal executes. The project and the Java class contained in it are compiled using Maven.

   Note:

   If Maven reports an error in resolving a dependency or artifact, add the repository into the POM file using the Repositories page and try again. Make sure that the repository that the URL points to is up and accessible.

9.7.17 How to Create a Maven POM for a Project

The pom.xml is the configuration file that contains the information to build a project. Use the procedure to create a Maven POM for a project from an existing project by adding elements and settings for the compiler.

You can create a Maven POM based on an existing project that you select in the Applications window. Build elements will be added for multiple source directories. Settings will be added for the Java compiler you have specified for the project.

To create a Maven POM for a project:

1. In the Applications window, select the project that you want to create the POM from.
2. Choose File > New to open the New Gallery.
3. In the Categories list, expand General and select Maven.
4. Select Maven POM for Project.
5. Complete the dialog and click OK.

9.7.18 Auditing Maven Applications

Empty tags or invalid values cause errors during a build run. An Audit handles the errors encountered when creating a Maven project for the pom.xml.

While editing pom.xml, empty tags or invalid values can cause errors when running the build. These errors need to be caught and reported as part of audit. Audit should handle any errors that are reported when creating a Maven project for the pom.xml.

Some examples for validations:

• Invalid/ empty values for artifact id, group id, version in dependency, plugins etc. after inheritance is applied.

• Duplicate entries in profile activation rules.

9.7.19 Configuring Test Settings

Specify how Maven finds test resources in an application by double-clicking the POM file and selecting Test Settings in Overview. Configure the application test source and resource paths using the JUnit Test project in JDeveloper, or configure the test paths from the project properties dialog for the test project.

You can specify how Maven finds test resources in your application. Double-click the POM file and select Test Settings in the Overview tab. You can manually configure application's test source and resource paths. In the Test Settings tab, you can specify a project for testing purposes or point JDeveloper to testing resources.

If there is a separate project for testing, JDeveloper can detect the paths to the various testing artifacts. If the testing resources are in a project with other source and artifacts, you must select those explicitly. More

There are two ways to configure test settings:

• If you already have a dedicated JDeveloper project (JUnit Test project) that contains the test sources and resources, then use that on the Test Settings tab.

• You can also configure the test paths from the project properties dialog for the test project. The test project sources and resources are automatically synced into the associated POM file.

9.7.20 Understanding Code Insight

Code insight speeds up the code writing in a pom.xml source file fetching required values from the local repository. Use the procedure to see code insight.

You can use code insight to speed up the process of writing code in your pom.xml source file.

To see code insight:

1. Open a pom.xml file in the Code Editor.
2. On the Plugins tab, add a plugin element.
3. Add the plugin's <executions> section.

Support for code insight is based on values in the Overview tab, which are fetched from the local repository. For example, for packaging type, code insight displays the list of values that is shown in the Overview editor for Packaging Type.

The following code insight lists of values are also supported:

• phases, inside plugin

• update policy, checksum policy and layout

• type and scope, inside dependency

9.7.21 Using the WebLogic Maven Plugin in JDeveloper

Use the WebLogic Maven Plugin to deploy, redeploy, undeploy, and update applications built using Maven to a WebLogic Server from within the Maven environment.

You can use the plug-in to deploy, redeploy, and update applications built using Maven to WebLogic Server from within the Maven environment. You can even undeploy an application. See Deploying Applications to Oracle WebLogic Server.

9.7.22 Using ojdeploy and ojmake

JDeveloper supports deployment in Ant scripts by adding a deploy target to the build.xml file. Modify the POM file to add the ojdeploy and ojmake deployment plugins to use commands with the Maven build tool, configure the plug-ins during POM creation, and add deployment profiles to the project.

JDeveloper supports deployment in Ant scripts. It does this by adding a deploy target to the build.xml file. See How to Deploy from the Command Line Using Ant .

You can use ojmake, as well as ojdeploy, in Maven POM files. JDeveloper modifies the POM file and adds ojdeploy and ojmake deployment plugins when necessary, as shown below:

<build>
  <plugins>
    <plugin>
        <groupId>com.oracle.adf.plugin</groupId>
        <artifactId>ojmake</artifactId>
        <version>12.1.3-0-0</version>
        <configuration>
          <ojmake>
            ${oracleHome}/jdeveloper/jdev/bin/ojmake
          </ojmake>
          <files>
            ${basedir}/Application2.jws
          </files>
          <usemaven>
            true
          </usemaven>
        </configuration>
        <executions>
          <execution>
            <phase>compile</phase>
            <goals>
              <goal>compile</goal>
            </goals>
          </execution>
        </executions>
      </plugin> 
    <plugin>
      <groupId>oracle.jdeveloper.deploy.maven</groupId>
      <artifactId>maven-ojdeploy-plugin</artifactId>
      <version>1.0.0</version>
      <configuration>
        <ojdeploy>/scratch/jdoe/view_storage/pmed_jdev_l/oracle/jdeveloper/            jdev/bin/ojdeploy</ojdeploy>
        <workspace>/home/jdoe/jdeveloper/mywork/Application1/Application1.jws                </workspace>
        <project>ViewController</project>
        <profile>Application1_ViewController_webapp</profile>
        <usemaven/>
      </configuration>
      <executions>
        <execution>
          <phase>install</phase>
          <goals>
            <goal>deploy</goal>
          </goals>
        </execution>
      </executions>
    </plugin>
  </plugins>
</build>

JDeveloper provides the ojmake and ojdeploy plug-ins. When you add these plug-ins, JDeveloper can do the following:

• Use the ojmake and ojdeploy commands with the Maven build tool

• Configure the plug-ins during POM creation

• Configure the plug-ins in the POM (if not already present) when you add deployment profile to the project

To add the plugins, double-click the project's POM file and click on the Plugins tab. Select the ojmake and ojdeploy plug-ins in the Build column and configure the parameters as needed in the Configuration section.

To see the usage, parameters, options, and examples for ojmake, at the command line for jdeveloper_install/jdeveloper/jdev/bin type ojmake.

9.8 Understanding Continuous Delivery and Continuous Integration

A Maven repository hosts artifacts such as compiled code and metadata about that code. Maven projects are built against the local repository, a cache of a remote repository that is stored on the local machine, and remote repository, a repository that contains all the Maven artifacts and plugins.

Continuous delivery is an extension of practices, from the build process through to the actual delivery of the software. Continuous delivery takes the next step to automate release management and deployment of software to end users, starting from where continuous integration finishes, automation of the building and testing of software. The purpose is to minimize the time between users expressing a requirement and a product being delivered to address that requirement. This avoids issues commonly seen in large software development projects.

Continuous integration is a software engineering practice which attempts to improve quality and reduce time to deliver software by applying small, frequent quality control efforts. It is characterized by these practices:

• Use of a version control system

• Developers commit to the main code line every day

• The product is built on every commit

• The build must be automated and fast

• Automated deployment to a production-like environment

• Automated testing is employed

• Results of all builds are published so everyone can see who broke the build

• Deliverables are easily available to developers, testers, and other stakeholders

For information on continuous delivery and integration, see Developing Applications Using Continuous Integration.