Step 8 - The fat jar
The next and final step is to bundle everything into one fat jar (200MB the resulting size) with:

$ mvn -X -e clean install -DskipTests=true

running the command gives :

[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 01:10 min
[INFO] Finished at: 2017-08-30T07:31:19+03:00
[INFO] Final Memory: 44M/305M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-install-plugin:2.4:install (default-install) on project wlogicclient: Execution default-install of goal org.apache.maven.plugins:maven-install-plugin:2.4:install failed: Plugin org.apache.maven.plugins:maven-install-plugin:2.4 or one of its dependencies could not be resolved: The following artifacts could not be resolved: org.codehaus.plexus:plexus-utils:jar:3.0.5

Apparently the 'org.codehaus.plexus:plexus-utils:jar:3.0.5' artifact could not be resolved.Let's help Maven by manually feeding it a newer version from the central repository:

<dependency>
    <groupId>org.codehaus.plexus</groupId>
    <artifactId>plexus-utils</artifactId>
    <version>3.1.0</version>
</dependency>

and try again:

$ mvn -X -e clean install -DskipTests=true

this time giving:

[DEBUG] Failure to find com.oracle.weblogic:com.oracle.webservices.mdds-jersey-api_12.1.3/maven-metadata.xml in https://repo.maven.apache.org/maven2 was cached in the local repository, resolution will not be reattempted until the update interval of central has elapsed or updates are forced

[DEBUG] Could not find metadata com.oracle.weblogic:com.oracle.webservices.orasaaj-rt-api_12.1.3/maven-metadata.xml in local (/home/test/.m2/repository)

[DEBUG] Skipped remote request for com.oracle.weblogic:com.oracle.webservices.orasaaj-rt-api_12.1.3/maven-metadata.xml, locally cached metadata up-to-date.

[DEBUG] Failure to find com.oracle.weblogic:com.oracle.webservices.orasaaj-rt-api_12.1.3/maven-metadata.xml in https://repo.maven.apache.org/maven2 was cached in the local repository, resolution will not be reattempted until the update interval of central has elapsed or updates are forced

[DEBUG] Could not find metadata com.oracle.weblogic:com.oracle.webservices.session-manager-impl_12.1.3/maven-metadata.xml in local (/home/test/.m2/repository)

[DEBUG] Skipped remote request for com.oracle.weblogic:com.oracle.webservices.session-manager-impl_12.1.3/maven-metadata.xml, locally cached metadata up-to-date.

[DEBUG] Failure to find com.oracle.weblogic:com.bea.core.descriptor_2.2.0.0/maven-metadata.xml in https://repo.maven.apache.org/maven2 was cached in the local repository, resolution will not be reattempted until the update interval of central has elapsed or updates are forced

[DEBUG] Could not find metadata com.oracle.weblogic:com.bea.core.compat.wl.90_1.6.0.0/maven-metadata.xml in local (/home/test/.m2/repository)

[DEBUG] Skipped remote request for com.oracle.weblogic:com.bea.core.compat.wl.90_1.6.0.0/maven-metadata.xml, locally cached metadata up-to-date.

It looks like that Maven tries to resolve dependencies such as
  
'Failure to find com.oracle.weblogic:com.bea.core.descriptor_2.2.0.0/maven-metadata.xml in https://repo.maven.apache.org/maven2'

from the central Maven repository, but since they are Weblogic ones they can only be found on the maven.oracle one.But, we've already downloaded and cached them in our local repo anyway, so let's force Maven to go offline with the -o switch and use the localy stored version:

 $ mvn -X -e -o clean install -DskipTests=true

 This overcomes the previous build errors and goes into the bundling phase:

[DEBUG] adding entry com/oracle/state/provider/aggregate/AggregateObject$Description.class
[DEBUG] adding entry com/oracle/state/provider/aggregate/TimerStateManager$Description.class
[DEBUG] adding entry com/oracle/state/provider/aggregate/Timer.class
[DEBUG] adding entry com/oracle/state/provider/aggregate/AggregateObjectFactory.class
[DEBUG] adding entry com/oracle/state/provider/aggregate/AggregateObjectStateManager$1.class
[DEBUG] adding entry com/oracle/state/provider/aggregate/TimerStateManager.class
[DEBUG] adding entry com/oracle/state/provider/aggregate/BasicAggregateObject.class
[DEBUG] adding entry com/oracle/state/provider/aggregate/AggregateObjectStateManager.class
[DEBUG] adding entry com/oracle/state/provider/aggregate/BasicAggregateObjectFactory.class
[DEBUG] adding entry com/oracle/state/provider/aggregate/AggregateObject$TypeInfo.class
[DEBUG] adding entry com/oracle/state/provider/aggregate/AggregateObject.class
[DEBUG] adding entry com/oracle/state/provider/aggregate/StateListenerProxy$StateEventInfo.class
[DEBUG] adding entry com/oracle/state/provider/aggregate/StateListenerProxy$1.class
.
.
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 01:05 min
[INFO] Finished at: 2017-08-30T08:15:18+03:00
[INFO] Final Memory: 16M/313M
[INFO]

Step 9 - Validation
The 'install' phase has now generated a 'wlogicclient-jar-with-dependencies.jar' fat jar.Let's verify that it has in fact captured all that's necessary.

Running:

$ jar tf target/wlogicclient-jar-with-dependencies.jar

generates a list of what's included inside the final jar :

org/
org/codehaus/
org/codehaus/plexus/
org/codehaus/plexus/util/
.
.
/weblogic-server-pom-12.1.3-0-0.pom
schemaorg_apache_xmlbeans/
schemaorg_apache_xmlbeans/type/
schemaorg_apache_xmlbeans/type/http_3A_2F_2Fwww_2Ew3_2Eorg_2F2001_2FXMLSchema/
schemaorg_apache_xmlbeans/type/http_3A_2F_2Fwww_2Ew3_2Eorg_2F2001_2FXMLSchema/facet.xsb
.
.
weblogic/xml/saaj/
weblogic/xml/saaj/mime4j/
weblogic/xml/saaj/mime4j/message/
weblogic/xml/saaj/mime4j/message/AbstractBody.class
weblogic/cluster/migration/MigratableMDB.class

and so on.

Now at last, let's run the jar with:

$ java -jar target/wlogicclient-jar-with-dependencies.jar

which gives :

Hello World with WebLogic dependencies!

Transferring the very same jar file to one of the other 10 machines as well as running it, worked as advertised, no questions asked.

Of course this manual building process has its downsides too, merely that during the 'install' phase you might potentially encounter all sorts of exotic errors that vary from machine to machine.For example in replicating the same setup in another development CentOS machine, the install phase was halting with a very peculiar error:

[ERROR]
Failed to execute goal on project: Could not resolve dependencies for project
Failed to collect dependencies at com.oracle.weblogic:weblogic-server-pom:pom:12.1.3-0-0 -> com.oracle.weblogic:weblogic:jar:[12.1.3,12.1.4): No versions available for com.oracle.weblogic:weblogic:jar:[12.1.3,12.1.4) within specified range -> [Help 1]

The exotic part is '12.1.3,12.1.4', versions that do not exist in Oracle's repository nor in the local cache and it really beats me how they got there in the first place!

The solution I was forced to give was drastic;operate on the pom file stored in the local cache and change all occurrences of [12.1.3,12.1.4) to 12.1.3-0-0, the actual version residing in the Oracle repository.

 
$ cd /home/test/.m2/repository/com/oracle/weblogic/weblogic-server-pom/12.1.3-0-0

$ vi *

<dependency>
      <groupId>com.oracle.weblogic</groupId>
      <artifactId>weblogic</artifactId>
      <version>[12.1.3,12.1.4)</version>
    </dependency>
<dependency>

    $ s/\[12.1.3,12.1.4)/12.1.3-0-0/g

This relieved the error condition of the 'weblogic-server-pom' instance, but on subsequent runs all other poms were complaining too so this was a generalized situation that had to be taken care of by intrusively operating on all Weblogic related pom files inside the local repo.

$ cd /home/test/.m2/repository/com/oracle

$ find . -name "*.pom" -type f -exec sed -i -e "s/\[12.1.3,12.1.4)/12.1.3-0-0/g" {} \;

Talking about total control and the CLI...

Point is that you just might get unlucky, mileage varying, therefore you have to be ready to improvise, think out of the box and put your devops skills to use if and when the need arises.

The good part is that these are edge case scenarios which are going to be encountered just once on the development machine.The rest will get the goods for free...

More Information

GitHub repo of this article's project

Fusion Middleware Programming Stand-alone Clients for Oracle WebLogic Server

Fusion Middleware Getting Started With JAX-RPC Web Services for Oracle WebLogic Server

Apache Maven

Apache Maven Central Repository

Related Articles

Data Entry with Xataface

AWS Lambda For The Impatient Part 1

AWS Lambda For The Impatient Part 2

AWS Lambda For The Impatient Part 3

To be informed about new articles on I Programmer, sign up for our weekly newsletter, subscribe to the RSS feed and follow us on Twitter, Facebook or Linkedin.

Comments

Make a Comment or View Existing Comments Using Disqus

or email your comment to: comments@i-programmer.info