Showing posts with label maven. Show all posts
Showing posts with label maven. Show all posts

Wednesday, August 16, 2017

Github: unexpected news


It's a great day for me. It's turned out that someone uses my Github repositories.
While ago I've created an Oracle-free version of FOP servlet for Apex application reports. The reason why I've created the code was simple. Naturally, I've blogged all the details and it's one of the most visited publications of mine. At the same time, servlet repository has not been used at all or I used to think so. Now I know that at least one more person, who has found this project useful. Please meet Roger Pilkey, who is so kind that he has adopted my doodles and developed new servlet for the latest Apache FOP version.
After such unexpectable and invaluable input, I have to upgrade project itself.  The major changes are:
  • Project structure has been reconfigured to use with the Apache Maven 
  • JSP page uses the latest FOP code to generate PDF response
  • Lifted index.html (with a brief description and sample form to test application)
  • Updated README.md with some project information. 
I guess it's hard to find the Apex installation with no Oracle REST Database Services installed, but if you are the happy owner of such system - you may find it useful. 

Tuesday, July 04, 2017

Apache Maven and SOA 11g. Enable the composite.


Okay everyone, holidays are over and it's time to complete this super long read. If you haven't seen 3 previous posts you may go and check the first one here. Today we will discuss how to enable Maven for the SOA projects. Bad thing - it has a proprietary compiler and there is no Maven plugin at all, good thing the compiler uses Ant tasks to build and deploy Oracle SOA 11g composites. Now we have a plan and our project model should be able to:
  • Compile Java code and package it along with the SOA artifacts. The reason is your composite may use custom Java classes to perform some activities that hard or impossible to implement with the XPath/XQuery/XSLT tools you have. 
  • Test Java code, before build or install, especially if you use JUnit to cover your code. 
  • Build SCA archive with the proper Ant task 
  • Deploy composite archive to the SOA servers.
Rephrasing those steps in the project configuration terms we will talk about:
  • Additional properties for the SOA-specific tasks. 
  • Configure Java compiler and package plugin
  • Configure Ant plugin for Maven 

Thursday, June 29, 2017

Apache Maven and SOA 11g. Configure J2EE Applications

Hello there,
I have selected the shortest night in the year to continue the story of the Apache Maven and Oracle SOA 11g marriage. If you haven't read my previous posts, please check them here. Last time I stopped on the Maven-enabled project. Now I'm going to finish Java/J2EE part and build Enterprise Java Archive (EAR).

Sunday, June 04, 2017

Apache Maven and SOA 11g. Configure Web Applications


Hello everyone, have a great any time of the day or night. It's time to continue what I've started here. So far, I haven't described anything useful, but extra efforts to maintain all that Maven configuration. Now it's time to get some perks from the situation. I've decided to start from the J2EE for two reasons: highlight the Maven and JDeveloper compatibility issues and how to address them, and create diversified project model (next post will be all about SOA composites).

Project dependencies

Service does a little bit weirdo function - receive Apache FOP XML as the input string and reply with the generated PDF document as a Base64 string. The project itself isn't relevant and you may use any of yours; Although, you may find a real-life scenario: Your SOA composites receive and prepare some data and you want to deliver it as a PDF report, attached to the email (I'm not going to ask you why you don't consider any report management frameworks).  However, I use this example on purpose to stress unlikeness between Maven and JDeveloper in the library management.
Anyone who uses Oracle JDeveloper knows, to compile code project should be aware where to find dependencies. In the Oracle world answer is simple: Libraries. The library allows you to define a group of files and reuse it on your local workstation. If you want to share your project - the library should come along otherwise, your peers wouldn't be able to build your project. To work with our project you will need 2 libraries as on screenshot below: JAX-WS Web Services is the standard one. the second is the custom library and describes Apache FOP framework on my hard drive.


But if we switch to the Maven world, we also should instruct Maven which libraries are required. In the project model terms, we are talking about dependencies. Project file describes what we need to compile and build the project. Normally I think about dependencies as of horizontal links between projects, and of course, links have directions.   The good news, Maven knows where to get your dependencies and dependencies of the dependencies. You don't need to instruct Maven use the JAX-WS libraries, it will find and include appropriate classes automatically. But let's start from the start and create the project POM first.

Maven mode for the project.

You may find more suitable to create application level model first and instruct wizard to create all the project level files as well. But I prefer go in the opposite direction, moving from the project level to the application. I do it as follow:
  1. Open new item wizard by any convenient way (Ctrl+N for example). 
  2. Select General section from the tree on the left 
  3. Start typing maven in the search field.  
  4. There are several options, Select "Maven POM fro Project" one.
  5. Fill the fields with the values as below, or use your own, but write them down for the future reference.
    1. File name:  pom.xml
    2. Directory: your project directory
    3. Group ID: pdf-print-app
    4. Artifact ID: pdf-print-servlet
    5. Version: 0.0.1-SNAPSHOT
    6. Description: Print PDF Web Service
    7. Packaging:  war
  6. Click Ok button and save the new configuration.
  7. Open the pom.xml file for edit. 
Result file should look like the example below.

<?xml version="1.0" encoding="UTF-8" ?>
<project xmlns="http://maven.apache.org/POM/4.0.0">
  <modelVersion>4.0.0</modelVersion>
  <groupId>pdf-print-app</groupId>
  <artifactId>pdf-print-servlet</artifactId>
  <version>0.0.1-SNAPSHOT</version>
  <build>
    <sourceDirectory>src/</sourceDirectory>
    <outputDirectory>classes/</outputDirectory>
    <resources/>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>2.0.2</version>
        <configuration>
          <source>
            1.6
          </source>
          <target>
            1.6
          </target>
        </configuration>
      </plugin>
    </plugins>
  </build>
</project>

Configure Web application 

You may or may not noticed, but there are not enough information to properly build our project. For the first of all, there are no dependencies, the wizard has forgotten to add packaging information to the project. Also, it would be nice to keep our WEB-INF/** files, it's the place where JDeveloper keeps  web.xml and weblogic.xml. Let's take a look at the final pom.xml file and I'll explain all the changes.

<?xml version="1.0" encoding="windows-1252" ?>
<project xmlns="http://maven.apache.org/POM/4.0.0">
  <modelVersion>4.0.0</modelVersion>
  <groupId>pdf-print-app</groupId>
  <artifactId>pdf-print-servlet</artifactId>
  <packaging>war</packaging>
  <version>0.0.1-SNAPSHOT</version>
  <!-- https://mvnrepository.com/artifact/org.apache.xmlgraphics/fop -->
  <dependencies>
    <dependency>
        <groupId>org.apache.xmlgraphics</groupId>
        <artifactId>fop</artifactId>
        <version>2.2</version>
        <scope>provided</scope>
    </dependency>
  </dependencies>
  <build>
    <resources>
      <resource>
        <directory>${basedir}/public_html/</directory>
        <excludes>
            <exclude>WEB-INF/**</exclude>
        </excludes>
      </resource>
    </resources>
    <sourceDirectory>${basedir}/src/</sourceDirectory>
    <outputDirectory>classes/</outputDirectory>
    <testSourceDirectory>${basedir}/test</testSourceDirectory>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>2.0.2</version>
        <configuration>
          <source>
            1.6
          </source>
          <target>
            1.6
          </target>
        </configuration>
      </plugin>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-war-plugin</artifactId>
        <version>2.1.1</version>
        <configuration>
          <warSourceDirectory>${basedir}/public_html</warSourceDirectory>
        </configuration>
      </plugin>
    </plugins>
  </build>
</project>

The first change is <dependencies/> section. I don't use any non-J2EE classes but Apache FOP libraries, so I instruct Maven what should be available to successfully compile classes. The new element here is <scope>. With the scope "provided" I tell "don't bother to include dependencies to the package, it will be provided by the environment".
In the build section, I have specified where to find resources. All the static Web content JDeveloper keeps under public_html folder. But I don't want to include anything under WEB-INF folder, it's a place to keep web application metadata.
The next group of the parameters is:

  • sourceDirectory - Place where to find a source code. If you have more than one source location, you may add them under resources section.
  • outputDirectory - Directory to store your compiled Java code. 
  • testDirectory  -  By default, Maven looking for JUnit test source under src/test/** folder. I prefer to keep it next to the src/ folder and maintain the same package structure. 
The source and output folders are quite similar to the default values, and points to the same location, but the ${basedir}/ suffix changes default behavior. if we keep default value src/  Maven looks for the source code in src/java/**  folders, with the base dir we point to the exact location, so it will find our src/** classes.
And the last but not least,  Maven war plugin configuration. Option warSourceDirectory points to the place where plugin should find and reuse WEB-INF folder (yep, web.xml and weblogic.xml).

Build a Package 

Well, it's time to check if we have configured web application properly. Let's build our web application archive. We are not ready to run our fancy external tools, so we just run it from the context menu:
  1. Select project pom.xml in the Application Navigator.
  2. Right click on the pom.xml and select Run Goal(s)->package


After a while, you should see build result in the Apache Maven log window.














Lucky me, there are no errors.  Time to check if the result meets our expectations.  By default, Maven uses target/ folder to package artifacts. The result on the screenshot looks fine for me. 

It has:
  • Proper directory structure 
  • It doesn't contain any libraries. 
  • Web application descriptors are included. 
You can't deploy this application to the WebLogic, unless you deploy Apache FOP libraries first. Other optios:
  1. Comment Apache FOP dependency scope and rebuild package. All the dependencies will be added.
  2. Follow me and build EAR application with the all libraries placed there.
Enjoy, and have a great weekend. 


Sunday, May 28, 2017

Apache Maven and SOA 11g. Preparing Environment.

Good time of the day, It's time to resume the story of the happy marriage between SOA Studio 11g and Apache Maven.  This post will guide you trough environment configuration. During the process we will go through:

  • JDeveloper 11g extension configuration 
  • WebLogic Maven plugin configuration
  • Plugin and libraries installation. 
  • Configure External tools.
The actual configuration will take much less time than you would read this document because I have prepared scripts for you.  And good news it's lifetime configuration (for your workstation of course). Although, I presume that you have:
  • Oracle SOA Studio 11g (11.1.1.7.0)  installed and configured;
  • Your workstation has Internet access, or at least you have access to extensions and maven repository replicas. 
  • You know you Oracle Fusion Middleware directory name. If you don't it's location where you see folders similar to the screenshot below: 

Configure JDeveloper Extensions

You may have Apache Maven installed on your workstation, especially if you work under Linux and of course, it's the latest greatest one. However we should always keep in mind compatibility, so Let's use Maven, which will work for sure with our JDK and JDeveloper. If you'd make such thing and it will work with the latest maven releases, please let me know. 
Okay, Maven plugin installation is dull:
  1.  Start Oracle JDeveloper
  2. From the main menu select Help -> “Check For Updates …”
  3. In the Source list check  "Open Source and Partners Extensions" 
  4.  Locate and select 2 extensions with the name like  “Developer Preview: Maven*”
  5. Complete installation and restart IDE. 
To validate the installation 
  1.   Open command line window or shell terminal on the Linux box.
  2.  Go to your JDeveloper installation home  (in my case it’s C:\Oracle\Middleware\JDeveloper)
    C> cd \Oracle\Middleware\JDeveloper
  3. Check if you have your maven 2.1 installed and configured:
C:\Oracle\Middleware\jdeveloper>apache-maven-2.1.0\bin\mvn –version
Apache Maven 2.1.0 (r755702; 2009-03-18 15:10:27-0400)
Java version: 1.7.0_55
Java home: C:\Oracle\sqldeveloper.40\jdk\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 7" version: "6.1" arch: "amd64" Family: "windows"

Before you continue with the further configuration, let's check what JRE/JDK is available in your system by default. For me, it's Java 7 and it will not work for SOA projects because default JDK for 11.1.1.7 is JDK 1.6.  You can fix it with the environment variable JAVA_HOME which will point to the JDK from the Oracle Middleware. I prefer change JDK only for the maven script.  Steps are easy:

  1. Go to Maven extension bin folder 
  2.  Copy mvn or mvn.bat file to mvn6 or mvn6.bat (OS-depended)
  3.  Open mvn6 for edit and  add the new line in position 35 or 34:
    JAVA_HOME=C:\Oracle\Middleware\jdk160_24
  4. Save file and retest
    C:>cd \Oracle\Middleware\jdeveloper\apache-maven-2.1.0\bin\
    C>mvn6 --version
    Apache Maven 2.1.0 (r755702; 2009-03-18 15:10:27-0400)
    Java version: 1.6.0_24
    Java home: C:\Oracle\Middleware\jdk160_24\jre
    Default locale: en_US, platform encoding: Cp1252
    OS name: "windows 7" version: "6.1" arch: "amd64" Family: "windows"
    C:\Oracle\Middleware\jdeveloper>
Worth to notice, that you may create $HOME/.mavenrc for Mac/Linux or %USERPROFILE%\mavenrc_pre.bat for Window and keep all Maven related environment configuration settings there.

Configure WebLogic plugin

For the start, we prepare plugin archive and classes required for the plugin installation. 
Let's start from the session environment configuration:
  1. Set environment variables:

    C:>SET FMW_HOME=C:\Oracle\Middleware
    C:>SET ORACLE_HOME=%FMW_HOME%\JDeveloper
    C:>SET MVN_HOME=%ORACLE_HOME%\apache-maven-2.1.0
    C:>SET WLS_HOME=%FMW_HOME%\wlserver_10.3
    C:>SET JAVA_HOME=%FMW_HOME%\jdk160_24
  2. Generate full client library:
    C:>cd %WLS_HOME%\server\lib\
    C:>%JAVA_HOME%\bin\java -jar %WLS_HOME%\server\lib\wljarbuilder.jar -profile wlfullclient
  3. Generate Maven plugin library:
                C:>%JAVA_HOME%\bin\java -jar %WLS_HOME%\server\lib\wljarbuilder.jar –profile weblogic-maven-plugin
  4. Extract plugin model user jar tool or archiver program like 7-zip. Additional details could be found in Oracle Documentation.  Or just use wls-pom.xml from the script repository. 
  5. Install libraries required by the plugin at runtime:

    C:>%MVN_HOME%\bin\mvn install:install-file -DgroupId=com.oracle.cryptoj -DartifactId=cryptoj -Dversion=1.0 -Dpackaging=jar -Dfile=%FMW_HOME%\modules\cryptoj.jar -DgeneratePom=true
    C:>%MVN_HOME%\bin\mvn install:install-file -DgroupId=weblogic -DartifactId=weblogic -Dversion=10.3.6 -Dpackaging=jar -Dfile=%WLS_HOME%\server\lib\weblogic.jar
    C:>%MVN_HOME%\bin\mvn install:install-file -DgroupId=weblogic -DartifactId=weblogic -Dversion=10.3.6  -Dpackaging=jar -Dfile=%WLS_HOME%\server\lib\wlfullclient.jar 
    C:>%MVN_HOME%\bin\mvn install:install-file -DgroupId=weblogic -DartifactId=webservices -Dversion=10.3.6  -Dpackaging=jar -Dfile=%WLS_HOME%\server\lib\webservices.jar

  6. Install WebLogic Maven plugin:

    C:>%MVN_HOME%\bin\mvn install:install-file -Dfile=weblogic-maven-plugin.jar -DpomFile=pom.xml
  7. Test plugin configuration:
    C:>%MVN_HOME%\bin\mvn  weblogic:help
Successful output should looks like this one:

Configure External Tools. 

JDeveloper Maven extension adds project and application support however, it's bound rather to the project that application. So, I normally create 3 additional external tools, all of them call maven with 3 major goals: clean, build and install. I'll guide you through the first one, Create the rest on your own. 

  1. From the JDeveloper main menu select Tools/External Tools… 
  2. Click on the “New …” button
  3. Select External Program as a tool type
  4. Specify program parameters as below. Don't forget to use substitutions, it will make your tools project unaware.
  5. Click Next button.
  6. Give the caption for the command, ToolTip text and select icon for the command to show.  Maven icons could be found in  ${ide.oracle.dir}\jdev\extensions\oracle.jdeveloper.maven.jar, as on the screenshot below.
  7. Click Next. 
  8. I prefer to have all Maven tools in one click distance and add buttons to the Main Toolbar. Also, don't forget to mark "Save All" as before starts action. 
  9. Save External tool and repeat steps 1-9 for the other Maven goals. 
At this point, you have configured and integrated:

  • SOA Studio 11g with the Maven extension;
  • Apache Maven 2.1 installed with JDeveloper. 
  • Configured local repository with the Weblogic plugin
  • Universal external tools to clean, package and install applications.
Next time I'll show you how to build Web applications with Apache Maven. 

So long and thanks for all the fish! 

Wednesday, May 17, 2017

Apache Maven and SOA 11g.

I know it's time to go into the Clouds with the SOA Suite Service or at least upgrade your system to the SOA suite 12c and get all the CI perks out f the box.
Yeah, it sounds great as a sales pitch but in reality, you have good old 11g production system and upgrade project (not upgrade) in the "barely foreseeable future". It doesn't matter you can't use some of the automated techniques today (men, it would be a great improvement for your resume), it does mean you will spend some extra time for the initial application configuration.
Of course, you may google right away "soa 11g maven" and get some results with a bunch of copy-pastes "how to install Maven plugin and compile ADF application".  but I'm going to tell you the whole story in several parts:

Part I:   Preparing environment.
Part II:  Configure web applications
Part III: Configure J2EE applications
Part IV: Configure SOA Composites  

I will update this page with the URLs as soon as parts will be ready. I probably will not describe how to build and deploy ADF applications with Maven. There are documentation and some really great posts around.

Some MAVEN terms

I'm not going to complete with the Community and rephrase what it is and how it works. If you have no exposure with Maven or at least ANT. I would recommend you to stop right there and check Apache Maven Introductions 30 minutes long or the brief one because my descriptions and interpretations will be not exactly canonical. So let's go through some Maven terms:
Remote Repository - Some Service (local replica or global repository) which has descriptions for all available plugins and artifacts. From the SOA world - some service which helps you to find and download missed libraries or MAVEN plugins. In the reality, it's a way more complex set of services and processes, but we will use it as a yet another package manager.
  •  Local repository  - This one is more important, because all environment changes, downloaded libraries, and MAVEN plugins will be stashed here. Th local repository allows us to install our private artifacts and libraries without commits to the global services. Normally local repository resides under $HOME/.m2/repository folder (%USERPROFILE%\,m2\repository for the Windows platforms)
  •  Plugin - The building blocks of the Maven. Any Maven activity is a chin of the plugin(-s) executions. There are 2 types build and reporting plugins, and I will use and describe only building ones. 
  • POM (pom.xml) - Project Object Model is the most important item in the list. It describes the project, project dependencies, plugins and their execution steps.It allows you to tweak default Maven behavior (and we will do it a lot). In few words - POM describes plugins and their actions, which are required to build and install projects (archetypes in the Maven terms). 
  • Lifecycle - Formal name for the goals, targets or actions (pick your one you like). Instruction for Maven to perform some set of actions. For example, when you request clean - maven cleans all the target folders and prepares the project for the further actions. Next activity - compile will clean and compile your project. Next one build cleans, compiles and assembles your project into the package. Like I  said before, in reality, it's the heck of the simplification, but it's all we need to know to use maven with JDeveloper 11g.