Wind Up Reloaded

(Note: 08/24/2009 This was posted in my old blog here, since the part 2 of the article is available on this blog. I’m moving the content here, with the original published date.)
(Update: The content has been slightly updated)

So another one for my notes. After searching in-vain for proper way to integrate the Weblogic 10.3 with maven, I think the solution below is working very well for me. We are going to use the weblogic-maven-plugin from codehaus. All the current solution including the plugin documentation requires either installing a bunch of jars from the weblogic installation. Please make sure you satisfy the requirements below.
Requirements:

• You have a WL 10.3 installation
• You are running JDK5 and above.
• Maven 2.0.9 or above

Step By Step Guide

We will break it down into three main steps. One of the steps could be avoided if the weblogic-maven-plugin authors did not hard-code weblogic dependencies which are not available in the Maven repositories anyway (or if maven could support excluding plugin dependencies).

1. Building the uber weblogic jar and publishing it to your local or organization repository.
2. Downloading the weblogic-maven-plugin pom and jar.
3. Configuring WL 10.3 a non-ssl admin channel.

1. Building the uber weblogic jar

(Updated content):

• Install omitted jars: The wllfullclient jar process that is detailed next, is missing one required jar, so we will install that first and its location is:

• Install into Maven Repository (Local, shown here): So now, let’s install it to the maven repo, also the coordinates are important for the next step when we install the full weblogic client jar.

• Build the wlfullclient.jar: There is a way to build a full weblogic client jar, so we don’t have to figure out what jars we need. For this of course you need a WL 10.3 installation. The instruction are actually given here (weblogic jarbuilder tool). If you follow the steps then you should have a wlfullclient.jar, in the WL_HOME/sever/lib folder. Here is a log for my installation of Weblogic 10.3 after following the instructions.

• Create a POM file for wlfullclient.jar: We will actually create a POM file, instead of generating the POM, open up a text editor paste the contents below and name the file wlfullclient-103.pom. The reason we do this, so we don’t have to put multiple dependencies in the plugin configuration. This was a result of wlfullclient not including the missing module. So here is the POM for wlfullclient.jar (NOTE: in the dependencies section)

• Install wlfullclient.jar to Maven Repository: Now, we will use maven to install this for this example in our local repository (you can use deploy to publish it to your org. repo, such as Nexus).

Note the use of the character “\” is just a *nix newline escape, basically the whole thing above should be on one line.
Also notice the pomFile value.

2. Download and modify the weblogic-maven-plugin POM and jar

As mentioned before, we need to modify the pom because of hard coded dependency to weblogic. So what we do here is:

1. Download the POM
2. Change the version in the pom and delete the 2 weblogic dependencies.
3. Then install the Pom and the associated jar into our repository (local).

2.1 Download the weblogic-maven-plugin POM.

Download the weblogic-maven-plugin POM (2.9.1) and then also download the plugin jar.

2.2 Edit the downloaded POM

Open the downloaded POM from any editor. Comment out the any weblogic dependencies as shown below. And change the version, as shown below I am changing it to 2.9.1-001.

2.3 Install the edited POM and the plugin jar to your local repository.

Now we install it to our local repository (or a corp repo if you have one.). Please notice the -DpomFile argument this should be the edited POM from above.

Important things to note above:

• -DpomFile the pom file is the edited one as we did before, I called the edited pom weblogic-maven-plugin-2.9.1-001.pom
• The version -Dversion=2.9.1-001
• And the packaging (very important) -Dpackaging=maven-plugin

Now, of course in your project you would use this version of the installed plugin.

3. Create an admin channel in Weblogic 10.3

Ok, we need to do this step because for some reason WL 10.3, you can no longer do the deploys using the t3. Only SSL is allowed, and for some reason the uber jar does not include a particular implementation and I did not have the time to investigate it. Another post describing the process (Update: The steps is described here.)

Putting it all together

Ok, after you have done all the 3 steps, here is how the configuration looks like in your POM file. Enjoy and leave a comment if this was useful or need more clarification.

Few things to note here:

• The adminServerPort corresponds to 10058, this is the port I configured in the Step 3 (admin channel)
• Also note, the wlfullclient dependency I chose to add it here, instead of the edited pom in Step 2. Of course this requires Maven 2.0.9 and above.
• Also the plugin version is 2.9.1-001 the one we installed in Step 2.

So that’s it, folks.

This is a continuation of the Part 1, where in Step 3) creation of t3 admin channel was not given.This is step by step guide to creating an t3 admin channel. For some reason this is not available when configuring a domain (due to security requirements?), anyways this is a problem for local weblogic installation especially if using the weblogic-maven-plugin.

1. Assumptions

The following are assumed:

• You have a working Weblogic 10.3 installation.
• You have full control of the Weblogic Installation (aka you have admin privileges)
• The screenshots below show my local installation which I am running on port 10050

2. Step By Step Guide

Here we go:

1. Log into the admin console.
2. In the “Domain Structure” pane on the left side, open up “Environment” and Select “Servers“.
3. At this point the right hand pane should show you a list of Admin Server (I have only one, called Domain01AdminServer). Click on the Admin Server of interest (in the example below it is Domain01AdminServer)
   
4. Click on the Protocols tab.
5. The Second Level Menu changes, at the point click on “Channels“
6. It should look like something like below
   
7. Now, we are ready. Click “New” button, this will take you to a wizard process. I am going to give the screenshots, please adapt the Name and Listen Port for your installation, they do not need to be the same as shown.
8. New Channel Step 1, looks like below
   
9. New Channel Step 2 (Click Next) (Change the Listen Port as you see fit)
10. New Channel Step 3 (Click Next) (Make sure everything is checked here)
11. New Channel Step 4 (after clicking Next) (Nothing to do, this is a local install, I left everything unchecked)
12. That’s it Click on Finish button. You are done, you should see something like this:
    

3. Summary

At this point the weblogic-maven-plugin can be configured with the t3 protocol. Sorry, for posting this so late.

Maven 2 internally has a concept of two repositories:

• Plugin Repositories (POM element <pluginRepository>)
• “Standard” Repositories (POM element <repository>)

WARNING: These are just my notes, for my recollection you really don’t need to understand this nowadays, use a repository manager (like Nexus, Archiva or Artifactory) and have it proxy any remote repositories and distribute a settings.xml to your users. Also this applies to 2.0.x and may not be correct.

Summary

Here is a brief summay for the notes:

• The magic version strings LATEST and RELEASE are applicable to plugin’s only and not dependencies.
• When a plugin version is not given (bad idea, don’t do this) in the POM, maven will automatically look for the youngest version. This includes both SNAPSHOTS and releases. Which means if 1.2.5-SNAPSHOT and 1.2.4 (the last released version of the plugin) are available, then you get 1.2.5-SNAPSHOT.
• Keep in mind all the above can be skewed if running your own repository manager and redirecting all repositories (via mirror settings, in settings.xml) to your own repository manager.

Plugin Repositories

This is usually encoded in POM (don’t do this, please use a repository manager) as the <pluginRepository> element. I still don’t understand the reason to partition as two repositories. I believe any plugin dependencies would be fetched from the plugin repository.
But here is the kicker:
If you have a plugin that provides a new packaging that is not part of the Maven core, which means the plugin has to be configured as <extension>true</extension>, the dependencies will be fetched from your standard repositories. Yes, very strange indeed.

Standard Repositories

This is represented in the POM (Project Object Model) with the <repository> element. Any dependency for your project (in the <dependencies> section) is resolved by consulting all the repositories configured in the <repositories> elements. Again, cannot be stressed enough, please if you are building a Maven 2 artifact and want to share it do NOT encode the <repository> or <pluginRepository> in your POM, please use a repository manager.

maven-metadata.xml

What is the connection to repositories and maven-metadata.xml? Well, I don’t know . But I do know that this additional information is maintained at least for plugins, this usually contains information on what is oldest released version and youngest released version and the SNAPSHOT versions available.

Why is this all here?

So, in case you did the unthinkable of not locking down or pegging the plugin version. Maven will always download the LATEST (this is a magic version value) version of the plugin, aka, the latest SNAPSHOT version of the plugin NOT the latest RELEASE (another magic version value). Result: broken builds. Please, please lock down your versions. (NOTE: As of Maven 2.0.9 and above the core Maven plugin versions are pegged, regardless of this take control of your Maven projects and lock it down).

Example: You are using maven-zzz-plugin, all versions that are available from all the visible plugin repositories are 1.0,1.1,2.0,2.1,2.2,1.0-SNAPSHOT,2.0-SNAPSHOT,2.3-SNAPSHOT. Maven will automatically fetch 2.3-SNAPSHOT.

But there is a catch: If your Maven execution environment if after merging all the information about a particular plugin (from all the plugin repositories configured), if the RELEASE version of the plugin is younger than the SNAPSHOT version, then the RELEASE version is fetched.

Example: Say you are using the plugin maven-xxx-plugin, it has version 1.0, 1.2,1.3, 1.0-SNAPSHOT and 1.2-SNAPSHOT available after *merging* from all the repositories. If you “*don’t* provide a version, Maven will automatically fetch 1.3 version.

Another one of those annoying differences between Eclipse JDT and Java (SUN) JDK, especially using generics. Sometime, you have to live outside the IDE to compile the code (e.g. CI), have you ever got bitten by this:

Solution

I don’t know whether it is fixed in the latest JDK (JDK5 u16, still has this bug), but essentially the Sun JDK compiler is not able to infer the type correctly. The solution involves helping the compiler by providing the type parameter explicitly. An example: