12 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. Rebuild operations compile all the source files in a project or workspace.

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 use the WebLogic Maven plug-in to create Maven scripts that deploy a Java project to a WebLogic server.

This chapter includes the following sections:

12.1 About Building Java Projects

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 and toolbar 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 12c Integration project provides a consistent, automated build, test and deploy process for your projects. You can use Maven to build a project, manage dependencies on Oracle and third party artifacts, and automatically download artifacts from an internal or external (public) Maven repository.

12.2 Building with Make and Rebuild Commands

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

Table 12-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.

12.2.1 How to Set Compiler 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.

12.2.2 Compiling with Make

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.

12.2.3 Compiling with Rebuild

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.

12.3 Understanding Dependency Checking

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>

12.3.1 How to Configure Your Project 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 may to display compiler messages such as:

Example 12-1 Compiler Messages

  • 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 shown in Example 12-1, go to the Turn Individual Warnings Off section of the Project Properties dialog. This allows you to turn off the display of specific Xlint messages, while continuing to display others by default.

  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.

12.3.2 How to Specify a Native Encoding for Compiling

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

12.4 Compiling Applications and Projects

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. For more information, see Section 12.3, "Understanding Dependency Checking."

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

12.4.1 Compiling from the Command Line

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 more information about using ojmake, see Section 12.7.20, "Using ojdeploy and ojmake."

For more information about using ojdeploy, see Section 9.8.2, "Using ojdeploy."

12.5 Cleaning Applications and Projects

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.

12.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.

12.5.1.1 Cleaning 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.

12.5.1.2 Cleaning 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.

12.6 Building with Apache Ant

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. For more information, see the website 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 editor in JDeveloper to edit Ant buildfiles.

Creating 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.

Creating 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.

Creating 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.

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.

12.6.1 Running Ant on Project Buildfile Targets

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.

12.6.2 Using the Ant Tool in the IDE

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.

12.7 Building and Running with Apache Maven

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.

If you can develop an application using Oracle Fusion Middleware 12c, you should be able to 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 more information about Maven, see http://maven.apache.org/index.html.

12.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. These are located outside your home directory. There is also a local repository under your home directory. It acts as a cache for the artifacts.

A Maven Local Repository is exclusive to a system where all artifacts/dependencies required for your project are downloaded. 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.

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.

12.7.2 Understanding Maven Plugins

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.

12.7.3 Understanding Dependencies

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.

12.7.4 Understanding the Project Object Model

The Project Object Model (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.

POMs are organized hierarchically.

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

POM files exist under Application/Project resources directory.

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

12.7.5 Selecting the POM File

When you select the POM file for the project, the paths and the dependencies of the jpr will automatically be in sync.

To set the POM file:

  1. In the Applications window, select the project whose POM file you want to set.

  2. From the Main toolbar, choose Project > Project Properties.

  3. Choose Maven.

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

12.7.6 Understanding Continuous Delivery

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.

12.7.7 Understanding Continuous Integration

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

12.7.8 Before You Begin

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 - a unique identifier for the project, for example, Project.

    • Artifact ID - an identifier for the artifact that is unique within the group specified by the group ID, for example, Project1.jpr. Examples of artifacts produced by Maven for a project include JARs, source and binary distributions, and WARs.

    • Version - the current version of the artifact produced by this project.

    A POM's Group ID, Artifact ID, and Version form the project's fully qualified artifact name, in the form of <groupId>:<artifactId>:<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, double-click the project's 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 - Application Sources - <project_name>.

  6. In the Overview tab, click Repositories.

  7. 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.

  8. Choose File > Save to save any changes.

  9. From the Main Menu, choose Tools > Preferences > Maven > Settings.

  10. 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. This is the main Maven control file that is used to access information such as the local repository path, proxy settings, etc. The settings.xml file remains common to all projects (recommended) until you explicitly change it.

  11. Click OK.

  12. 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.

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

    Maven uses the proxy to download artifacts from remote repositories.

  14. Click OK when you are finished.

12.7.9 How to Create Maven POM Files

A Maven POM file is similar to a JDeveloper .jpr file. Maven understands everything about a project using the POM file. It contains all things concerning 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 POM for Project.

  4. Select required and optional options in the dialog.

  5. Click OK.

    The POM opens in the Overview editor by default.

12.7.10 Using the Context Menu in the POM file

You can access a menu of commands such as Run Maven Goals and Run Maven Phases by right-clicking on text inside the pom.xml source tab.

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

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

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.

12.7.12 How to Create Maven Projects Using Maven Archetypes

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, see
http://maven.apache.org/guides/introduction/introduction-to-archetypes.html.

To create a Maven 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, 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 field at the top of the dialog that displays, 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.

    Notes:

    The list of available repositories is set in the Maven - Repositories page. For more information, see Section 12.7.14, "How to Specify Remote Repositories."

    To access a remote repository, make sure you have specified proxy information on the Web Browser and Proxy dialog. For more information, see Section 23.2.1, "How to Use Proxy Settings and JDeveloper."

  6. Press the Return key.

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

  7. Drill down to an archetype in the list and select it, for example, maven-archetype-j2ee-simple.

  8. Click OK.

    The archetype source starts downloading.

  9. In the New Maven Application dialog, enter a name and location for the Maven application.

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

    Figure 12-1 Maven Application in Applications window

    Maven Application in Application Navigator

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.

12.7.13 What Happens When You Create a New Maven Application

The application in Figure 12-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 12-2.

    Figure 12-2 Maven Dependencies

    Maven Dependencies

  6. From the Main toolbar, choose Project > Project Properties > Libraries and Classpath.

  7. Notice that the same two dependencies in Figure 12-2 are listed here.

    The dependencies are kept in sync between the application and its associated project POM files. Try adding new dependencies in the application or POM file to observe the sync process. The sync is required to manage the 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.

12.7.14 How to Specify Remote Repositories

You need to access to remote repositories for a number of reasons. For example, your project may 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.

To manage remote repositories:

  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 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 the checkbox next to the row in the Remote Repositories table.

  7. Click the Index Repositories button.

    This downloads the indexing data for the selected remote repository.

12.7.15 How to Run Maven Goals on POM Files

Maven is based around the concept of a build lifecycle. A build lifecycle is made up of phases, also known as goals. 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 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.

12.7.16 How to Create a Maven POM for a Project

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.

12.7.17 Auditing Maven Applications

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.

Two 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.

12.7.18 Understanding 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

12.7.19 Using the WebLogic Maven Plugin in JDeveloper

You can use the plug-in to deploy, redeploy, and update applications built using Maven to WebLogic Server from within the Maven environment. For more information, see "Using the WebLogic Maven Plug-In for Deployment" in the Deploying Applications to Oracle WebLogic Server.

12.7.20 Using ojdeploy and ojmake

JDeveloper currently supports deployment in Ant scripts. It does this by adding a deploy target to the build.xml file. For more information, see Section 9.8.3, "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 in Example 12-2.

Example 12-2 ojdeploy and ojmake Deployment Plug-ins

<build>
  <plugins>
    <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>

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