Hacking Oracle SOA Suite (11.1.1) builds to work with Ivy and Artifactory

As discussed in a few previous posts, I’m on a mission to get my project’s SOA Suite builds to work without having to rely on a local installation of JDeveloper 11g with the added SOA Extension.

I’ve continued to make progress (with the help of Mayur – thanks) and we’ve now got compilation, packaging, deployment, and Unit Testing to work. We’ve still to tidy up our scripts so that they’re ready for publishing for public consumption, but in the meantime, I thought I’d put out some snippets which will help the enthusiastic to get to where we have.

Getting your Jar dependencies into Artifactory

My aim was to depend on Maven (and JFrog Artifactory) for our dependencies as much as possible. Where we could use publicly available Jars from the standard repositories we did. Sadly this turned out to be very infrequent. It did mean however that there was another reason to download and install Artifactory. This was very simple. We downloaded the Standalone version and ran it using the embedded Jetty. The only thing I needed to change from the default settings was to set a proxy (we’re behind a firewall.)

I then had to manually add all the Oracle dependencies which I had identified to ext-releases-local (Artifactory’s default Local repository for third party libraries). I had logged in as an Admin, and using the “Deploy” tab added them one at a time.

When I’d finished, it looked like this (apologies for the crappy screen grabs):

 

 

NOTE: It might be nice to bundle all these up as an artifacts bundle. I’ve not had the time to do this yet.

This meant we were now ready to link Ivy up to all of this.

Connecting Ivy and Artifactory

Next we had to tell Ivy to use either its local cache, or Artifactory, for all its dependency lookups. To do this, I created a new ivysettings.xml file with the following content:

<ivysettings>
    <settings defaultResolver="chain" />
    <resolvers>
        <chain name="chain" returnFirst="true">
            <filesystem name="local">
                <ivy pattern="C:/Documents and Settings/aharmel/.m2/repository/[organisation]/[module]/[revision]/[artifact]-[revision].[ext]" />
            </filesystem>
            <url name="shared">
                <artifact pattern="http://build-xp-10:8081/artifactory/repo/[organisation]/[module]/[revision]/[artifact]-[revision].[ext]" />
            </url>
            <url name="public">
                <artifact pattern="http://build-xp-10:8081/artifactory/repo/[organisation]/[module]/[revision]/[artifact]-[revision].[ext]" />
            </url>
        </chain>
    </resolvers>
</ivysettings>

This meant that when an ivy:resolve target was called, the local Ivy cache would be looked up first, and if that was not successful, then artifactory would be checked for both shared and public lookups. This meant that we would cache those dependencies which were available publicly in Maven, speeding up the second, and all subsequent lookups.

Using Ivy to get the dependencies in the Ant files

Penultimately (is that a word? I doubt it), we created an ivy.xml file containing all our dependencies and different configurations:

<ivy-module version="2.0">
    <info organisation="example" module="example-dummy" />

    <configurations>
        <conf name="base" description="Jars required at both compile and runtime" />
        <conf name="taskdefs" description="Jars required for Ant Taskdefs" />
        <conf name="compile" description="Jars required at compile / package time" />
        <conf name="deploy" description="Jars required at deploy time" />
        <conf name="test" description="Jars required at test time" />
    </configurations>

    <dependencies>
        <dependency org="oracle/soa/bpel" name="orabpel" rev="11.1.1" conf="compile->default" />
        <dependency org="oracle/soa/bpel" name="orabpel-validator" rev="11.1.1" conf="compile->default" />
        <dependency org="oracle/soa/bpel" name="orabpel-common" rev="11.1.1" conf="compile->default" />
        <dependency org="oracle/soa/bpel" name="orabpel-thirdparty" rev="11.1.1" conf="compile->default" />
        <dependency org="oracle/soa/fabric" name="fabric-runtime" rev="11.1.1" conf="compile,taskdefs->default" />
        <dependency org="oracle/soa/mgmt" name="soa-infra-mgmt" rev="11.1.1" conf="compile,taskdefs->default" />
        <dependency org="oracle/soa/fabric" name="soa-infra-tools" rev="11.1.1" conf="compile,taskdefs->default" />
        <dependency org="oracle/soa/fabric" name="testfwk-xbeans" rev="11.1.1" conf="compile->default" />
        <dependency org="oracle/fabriccommon" name="fabric-common" rev="11.1.1" conf="compile->default" />
        <dependency org="oracle/xdk" name="xmlparserv2" rev="11.1.0" conf="compile->default" />
        <dependency org="commons-logging" name="commons-logging" rev="1.0.4" conf="compile->default" />
        <dependency org="commons-digester" name="commons-digester" rev="1.7" conf="compile->default" />
        <dependency org="commons-beanutils" name="commons-beanutils" rev="1.6" conf="compile->default" />
        <dependency org="commons-collections" name="commons-collections" rev="3.2.1" conf="compile->default" />
        <!--dependency org="commons-cli" name="commons-cli" rev="1.1" conf="compile,deploy->default" /-->
        <dependency org="oracle/commonj-sdo" name="commonj-sdo" rev="2.1.0" conf="compile->default" /> <!-- This is a hack as the Oracle JDeveloper one is different from the one in M2 repositories -->
        <dependency org="oracle/logging-utils" name="oracle.logging-utils" rev="11.1.1" conf="compile->default" />
        <dependency org="oracle/dms" name="dms" rev="11.1.1" conf="compile->default" />
        <dependency org="oracle/webservices" name="orawsdl" rev="11.1.1" conf="compile->default" />
        <dependency org="oracle/mds" name="mdsrt" rev="11.1.1" conf="compile->default" />
        <dependency org="oracle/jmx" name="jmxframework" rev="11.1.1" conf="compile->default" />
        <dependency org="oracle/adf/share" name="adf-share-base" rev="11.1.1" conf="compile->default" />
        <dependency org="oracle/adf/share" name="adf-logging-handler" rev="11.1.1" conf="compile->default" />
        <dependency org="oracle/odl" name="ojdl" rev="11.1.1" conf="compile->default" />
        <dependency org="oracle/http-client" name="oracle-httpclient" rev="11.1.1" conf="compile,deploy->default" />
        <dependency org="oracle/wsm/common" name="wsm-policy-core" rev="11.1.1" conf="compile->default" />
        <dependency org="oracle/classloader" name="oracle-classloader" rev="11.1.1" conf="compile->default" />
        <dependency org="com/bea/core" name="com-bea-core-apache-commons-lang" rev="2.1.0" conf="compile->default" />
        <dependency org="com/bea/core" name="com-bea-core-xml-xmlbeans" rev="2.2.0.0" conf="compile->default" />
    </dependencies>
</ivy-module>

NOTE: I haven’t managed to get Ivy to load configurations for the taskdefs yet (see below). I’ll update this post when I get it to work

NOTE: Only the configurations for compile/package and deploy are included in this. It’s pretty easy to add the declarations for the other paths you need to set. I’ll repost this once it’s complete.

The final step was to add Ivy support to the out-of-the-box ant files.  To do this we;

1. Added the ivy.jar to our ant/lib directory
2. Added the Ivy namespace to the ant file: 

<project xmlns:ivy="antlib:org.apache.ivy.ant"
         name="ant-scac"
         default="scac">

3. Removed the elements setting all classpaths (e.g. scac.tasks.class.path in ant-scac-compile.xml)
4. Added a new path declaration just for the taskdefs. E.g.: 

<!-- Set the Path we need for the Ant Taskdefs -->
    <property name="oracle.ant.taskdef.path" refid="oracle.ant.taskdef.path"/>
    <path id="oracle.ant.taskdef.path">
        <fileset dir="${applications.home}/lib">
            <include name="fabric-runtime.jar"/>
            <include name="soa-infra-mgmt.jar"/>
            <include name="soa-infra-tools.jar"/>
        </fileset>
    </path>

5. Updated the taskdef declaration elements to use this new path. E.g:  <taskdef name="scac" classname="oracle.soa.scac.scac" classpath="${oracle.ant.taskdef.path}" />
6. Added a new “init” task which sets the path we removed earlier (e.g. scac.tasks.class.path in ant-scac-compile.xml):

<target name="init" description="Sets up the compilation classpath">
        <ivy:resolve />
        <ivy:cachepath conf="compile" pathid="scac.tasks.class.path" />
        <property name="scac.tasks.class.path" refid="scac.tasks.class.path"/>
    </target>

7. Updated the targets to have a dependency on “init”. E.g.:

<target name="scac" description="Compile and validate a composite" depends="init">
        <scac input="${scac.input}"
              outXml="${scac.output}"
              error="${scac.error}"
              appHome="${compositeDir}"
              failonerror="true"
              displayLevel="${scac.displayLevel}">
        </scac>
    </target>

And that’s it. Unfortunately there’s not a zip file you can download with a few bat/sh files to run, but maybe I’ll get there one day. In the meantime, this should help you to get where we have.

The Goods Delivered – SOA Suite “ant-sca-compile.xml” File Simplified (Plus Ivy Dependency Management)

As promised in my last post, I’ve been continuing to work on getting Oracle SOA Suite (11g) projects to build outside the JDeveloper IDE.  I’ve spent some time getting the ant-sca-compile.xml file to work first and thought I’d share the results.

I’ve rushed a little to publish this so there are still a few things you’ll have to do manually if you want this to work for you, but it does work. Trust me.  If I get a chance, I’ll keep blogging things as I progress and hopefully you’ll have to do less and less work if you want to do the same as us.

What I have now comes in three parts:

1. A simplified ant-sca-compile.xml file

<?xml version="1.0" encoding="iso-8859-1"?>
<project xmlns:ivy="antlib:org.apache.ivy.ant"
         name="ant-scac"
         default="scac">

    <!-- Set all the Properties we need -->
    <property file="build.properties"/>
    <!--propertycopy name="proj.revision" from="${project}.revision"/-->
    <property name="oracle.home" value="${applications.home}/lib"/> <!-- Monkey patch to remove need for full JDeveloper install -->
    <property name="config.dir" value="C:/oracle/Middleware/jdeveloper/integration/seed/soa/configuration/" />  
    <property name="compositeDir" value="${applications.home}/${compositeName}" />
    <property name="scac.input" value="${compositeDir}/composite.xml"/>
    <condition property="scac.displayLevel" value="3">
        <not>
            <isset property="scac.displayLevel"/>
        </not>
    </condition>
    <condition property="scac.overwrite" value="true">
        <not>
            <isset property="scac.overwrite"/>
        </not>
    </condition>
    <condition property="scac.error" value="${tmp.output.dir}/${compositeName}.error">
        <not>
            <isset property="scac.error"/>
        </not>
    </condition>
    <condition property="scac.output" value="${tmp.output.dir}/${compositeName}.xml" >
        <not>
            <isset property="scac.output"/>
        </not>
    </condition>
    <condition property="scac.sar" value="${tmp.output.dir}/${compositeName}.sar" > 
        <not>
            <isset property="scac.sar"/>
        </not>
    </condition>
    <condition property="scac.plan" value="${tmp.output.dir}/${compositeName}.plan" >
        <not>
            <isset property="scac.plan"/>
        </not>
    </condition>

    <!-- Set the Path we need for the Ant Taskdefs -->
    <property name="oracle.ant.taskdef.path" refid="oracle.ant.taskdef.path"/>
    <path id="oracle.ant.taskdef.path">
        <fileset dir="${applications.home}/lib">
            <include name="fabric-runtime.jar"/>
            <include name="soa-infra-mgmt.jar"/>
            <include name="soa-infra-tools.jar"/>
        </fileset>
    </path>

    <!-- Oracle SOA Suite Project Compilation Targets -->
    <target name="generateplanfromsar" description="Generate soa config plan from a soa archive">
        <ivy:resolve />
        <generateplan sar="${scac.sar}"
                      planfile="${scac.plan}"
                      verbose="true"
                      overwrite="${scac.overwrite}"/>
    </target>

    <target name="generateplan" description="Generate soa config plan from a composite">
        <ivy:resolve />
        <generateplan composite="${scac.input}"
                      planfile="${scac.plan}"
                      verbose="true"
                      overwrite="${scac.overwrite}"/>
    </target>
    <target name="attachplan" description="Attach a soa config plan to a soa archive">
        <ivy:resolve />
        <attachplan planfile="${scac.plan}"
                    sar="${scac.sar}"
                    verbose="true"
                    overwrite="${scac.overwrite}"/>
    </target>

    <target name="extractplan" description="Extract a soa config plan from a soa archive">
        <ivy:resolve />
        <extractplan planfile="${scac.plan}"
                     sar="${scac.sar}"
                     verbose="true"
                     overwrite="${scac.overwrite}"/>
    </target>

    <target name="validateplanfromsar" description="Validate a soa config plan for a soa archive">
        <ivy:resolve />
        <validateplan sar="${scac.sar}"
                      planfile="${scac.plan}"
                      reportfile="${scac.output}"
                      verbose="true"
                      overwrite="${scac.overwrite}"/>
    </target>

    <target name="validateplan" description="Validate a soa config plan for a composite">
        <ivy:resolve />
        <validateplan composite="${scac.input}"
                      planfile="${scac.plan}"
                      reportfile="${scac.output}"
                      verbose="true"
                      overwrite="${scac.overwrite}"/>
    </target>
    <target name="scac" description="Compile and validate a composite" depends="init">
        <property name="scac.tasks.class.path" refid="scac.tasks.class.path"/>
        <scac input="${scac.input}"
              outXml="${scac.output}"
              error="${scac.error}"
              appHome="${compositeDir}"
              failonerror="true"
              displayLevel="${scac.displayLevel}">
        </scac>
    </target>

    <target name="init" description="Sets up the compilation classpath">
        <property name="ivy.local.default.root" value="C:/Documents and Settings/aharmel/.m2/repository" />
        <property name="ivy.local.default.artifact.pattern" value="[organisation]/[module]/[revision]/[artifact]-[revision].[ext]" />
        <ivy:resolve />
        <ivy:cachepath conf="compile" pathid="scac.tasks.class.path" />
    </target>

    <!-- taskdefs mapping script Ant targets to Oracle Ant implementataion classes -->
    <taskdef name="scac" classname="oracle.soa.scac.scac" classpath="${oracle.ant.taskdef.path}" />
    <taskdef name="attachplan" classname="oracle.soa.deployplan.task.attachPlan" classpath="${oracle.ant.taskdef.path}" />
    <taskdef name="extractplan" classname="oracle.soa.deployplan.task.extractPlan" classpath="${oracle.ant.taskdef.path}" />
    <taskdef name="generateplan" classname="oracle.soa.deployplan.task.generatePlan" classpath="${oracle.ant.taskdef.path}" />
    <taskdef name="validateplan" classname="oracle.soa.deployplan.task.reportPlan" classpath="${oracle.ant.taskdef.path}" />
</project>

NOTE: I haven’t yet figured out how to get Ivy to manage the three dependencies for the  Oracle Ant Tasks themselves. I’ll update later once I have time to fix this.  Until then you also need to copy the three required jars into a new “lib” directory in your Composite Project

NOTE: The Monkey patch requires that you create a new “lib” directory in your Composite Project and add “./soa/modules/oracle.soa.bpel_11.1.1/orabpel.jar” to it. You’ll find this in your JDeveloper install

2. Dependencies managed in a new ivy.xml file

<ivy-module version="2.0">
    <info organisation="copfs" module="cmrs-dummy" />

    <configurations>
        <conf name="base" description="JARs required at both compile and runtime" />
        <conf name="taskdefs" description="JARs required for Ant Taskdefs" />
        <conf name="compile" description="JARs required at compile time" />
        <conf name="runtime" description="JARs required at runtime" />
    </configurations>

    <dependencies>
        <dependency org="oracle.soa.bpel" name="orabpel" rev="11.1.1" conf="compile->default" />
        <dependency org="oracle.soa.bpel" name="orabpel-validator" rev="11.1.1" conf="compile->default" />
        <dependency org="oracle.soa.bpel" name="orabpel-common" rev="11.1.1" conf="compile->default" />
        <dependency org="oracle.soa.bpel" name="orabpel-thirdparty" rev="11.1.1" conf="compile->default" />
        <dependency org="oracle.soa.fabric" name="fabric-runtime" rev="11.1.1" conf="compile,taskdefs->default" />
        <dependency org="oracle.soa.mgmt" name="soa-infra-mgmt" rev="11.1.1" conf="compile,taskdefs->default" />
        <dependency org="oracle.soa.fabric" name="soa-infra-tools" rev="11.1.1" conf="compile,taskdefs->default" />
        <dependency org="oracle.soa.fabric" name="testfwk-xbeans" rev="11.1.1" conf="compile->default" />
        <dependency org="oracle.fabriccommon" name="fabric-common" rev="11.1.1" conf="compile->default" />
        <dependency org="oracle.fabriccommon" name="fabric-common" rev="11.1.1" conf="compile->default" />
        <dependency org="oracle.xdk" name="xmlparserv2" rev="11.1.0" conf="compile->default" />
        <dependency org="commons-logging" name="commons-logging" rev="1.0.4" conf="compile->default" />
        <dependency org="commons-digester" name="commons-digester" rev="1.7" conf="compile->default" />
        <dependency org="oracle.commonj-sdo" name="commonj-sdo" rev="2.1.0" conf="compile->default" /> <!-- This is a hack as the Oracle JDeveloper one is different from the one in M2 repositories -->
        <dependency org="oracle.logging-utils" name="oracle.logging-utils" rev="11.1.1" conf="compile->default" />
        <dependency org="oracle.dms" name="dms" rev="11.1.1" conf="compile->default" />
        <dependency org="oracle.webservices" name="orawsdl" rev="11.1.1" conf="compile->default" />
        <dependency org="oracle.mds" name="mdsrt" rev="11.1.1" conf="compile->default" />
        <dependency org="oracle.jmx" name="jmxframework" rev="11.1.1" conf="compile->default" />
        <dependency org="oracle.adf.share" name="adf-share-base" rev="11.1.1" conf="compile->default" />
        <dependency org="oracle.adf.share" name="adf-logging-handler" rev="11.1.1" conf="compile->default" />
        <dependency org="oracle.odl" name="ojdl" rev="11.1.1" conf="compile->default" />
        <dependency org="oracle.http-client" name="oracle-httpclient" rev="11.1.1" conf="compile->default" />
        <dependency org="oracle.wsm.common" name="wsm-policy-core" rev="11.1.1" conf="compile->default" />
        <dependency org="oracle.classloader" name="oracle-classloader" rev="11.1.1" conf="compile->default" />
        <dependency org="com.bea.core" name="com-bea-core-apache-commons-lang" rev="2.1.0" conf="compile->default" />
        <dependency org="com.bea.core" name="com-bea-core-xml-xmlbeans" rev="2.2.0.0" conf="compile->default" />
    </dependencies>
</ivy-module>

NOTE: These are only the dependencies for the “scac” target. More may be required for the other targets.

NOTE: I used a local maven 2 repository as my Ivy repository. I had to import the JARs which came with JDeveloper into this in the structure indicated by the “dependency” entries.  The aim was to keep things structured nicely, add version info to JARs which lacked this.

NOTE: I tried to reuse standard external JARs from the various M2 repositories where possible. In the case of the com-bea-core libraries and oracle.commonj-sdo library this was not possible.  It seems for example that the latter has an additional package added to it (“helper”) even though the version number and name of this JAR is the same as you find on the web.

3. A Pared-down build-properties file

# temp
tmp.output.dir=c:/

# Project
applications.home=C:/Jazz/MyWorkspace-16-09-2009/WpfAutoDeployTestApp/TestApplication/
compositeName=GetEmployeeName
revision=1.0

deployment.plan.environment=dev

# dev deployment server weblogic
bea.home=C:/oracle/Middleware
dev.serverURL=http://10.23.7.66:8001
dev.overwrite=true
dev.user=weblogic
dev.password=welcome1
dev.forceDefault=true

# acceptance deployment server weblogic
# acc.serverURL=http://10.23.7.66:8001
# acc.overwrite=true
# acc.user=weblogic
# acc.password=welcome1
# acc.forceDefault=true

NOTE: See, the #global properties are gone. Nice eh?

NOTE: You’ll need to set the applications.home yourself as applicable. Not the nicest I know, but I’m moving fast here…

NOTE: I’ve hacked things so I need to provide the compositeName. This is not how it worked out of the box, and you could fix it to get this from your [App Name].properties file

Monkey-Patching Oracle SOA Suite 11g Ant Files to Build Without JDeveloper

I hate having to have more than the bare minimum installed on my build boxes. We’re using SOA Suite 11g and JDeveloper on our current project and much to my annoyance it seemed as if I’d have to install the Oracle IDE on all my build boxes in order to run the Ant scripts which it can generate. I didn’t like the idea of that, so I did some hacking and monkey patched them.

The Problem

I started at the beginning - with ant-sca-compile.xml and build.xml from JDeveloper.  Using these I could run Ant targets such as “scac” which meant my composite was compiled and verified.  The problem was, I needed to tell Ant where JDeveloper was installed. This in turn hid a mass of dependencies. 

I don’t like unmanaged dependencies. I like to know what goes into the various steps of my build.

The Solution

The first task was to move all the dependencies out of the JDeveloper install and into a project-local location. I created a “lib” directory in my Composite project for this purpose.  I then worked my way down through all the dependencies listed in “FileSet” elements in path “scac.tasks.class.path” in ant-sca-compile.xml  and copied them to ./lib.

Now I had to surgically extract all the references from ant-sca-compile.xml to the JDeveloper install.  I tackled all references to “oracle.home” first as I found this particularly galling. I created a new property called “applications.home” and set it to be the directory where ant-sca-compile.xml lived. I then worked down the definition of “scac.tasks.class.path” and changed all references from “${oracle.home}/…” to “${applications.home}/lib”, removing the additional directories as I went. (i.e. I ended up with “include name=”orabpel.jar””, etc.)

Every time I moved a large chunk of references I ran my built with Ant to check I’d not broken anything.  (Slowly, slowly, catchee monkee…)

Once I’d done this, I did the same for all the other elements in this path declaration. With this done, I then simplified things by removing all the checking of properties from the top of the file.

Now I was able to focus on the actual taskdef I was interested in: “scac”.  Firstly, I again simplified by removing the property checking. this left me with a single line; a call to the Oracle Ant task “scac”.

One by one, I took each of the parameters, and set them manually to extricate them from the mass of JDeveloper Ant complexity.  This involved:

• creating my own version of scac.input – myscac.input which I set to point at the location of my composite.xml file
• setting compositeName to the name of my SOA Suite Composite project (“GetEmployeeName” in my case)
• setting compositeDir to the path to my SOA Suite Composite project
• replacing scac.output with tmp.output.dir (pointing at “./”) combined with ${compositeName}.xml
• replacing scac.error with tmp.output.dir combined with ${compositeName}.error
• replacing scac.application.home with ${compositeDir}
• setting displayLevel manually to be “3” (the maximum)

I was almost there. It all worked. All I needed to do was remove the now redundant properties.

The Real Problem

This is where the monkey patching came in. I realised as I removed the now redundant properties that something, somewhere still needed to be told what oracle.home was.  I guess this is buried deep in the Oracle Ant tasks themselves. I tried to take a look but a decompiler was no help. (I guess they’re obfuscated.)

The Real Solution

But I didn’t want to give up (and here comes the monkey patch.)  To find out what actually was in oracle.home (effectively the JDeveloper install which was needed for a successful build and validation I took a copy of all the files, pointed oracle.home at this copy, and then piece by piece removed bits until I had the barest minimum needed for the target to run. The end result?  All you needed was orabpel.jar. The thing was, it needed to be in a directory like this: ${oracle.home}/soa/modules/oracle.soa.bpel_11.1.1

Problem solved! All then had to do was create this directory structure in my project’s ./lib directory, copy orabpel.jar into it, and then set ${oracle.home} to point to ${applications.home}/lib and we were up and running.

Where Now?

Next step is to get all the other SOA Suite Ant scripts (ant-scac-package.xml, ant-scac-upgrade.xml, ant-scac-dploy.xml and ant-scac-test.xml) to work without being umbillically attached to a JDeveloper install.

After that I’m going to use some Ivy and put all these dependencies (with some meaningful jar names including version numbers) into a Maven repository.

Finally I hope to wrap up the Ant targets themselves as Maven 2.x plugins.  It’d be really nice if Oracle put all these dependencies in the Maven repositories already, but knowing how long it’s taken/taking Sun, and how non-open to the idea IBM are I’m not holding my breath.  I guess this means there will need to be a little setup script which you’ll need to run against JDeveloper to get all the bits you need in a Local Maven repo.

Expect more blog posts as I progress.  There will also (hopefully) be some Ant source once I tidy things up.

RSA 7.5.4 and RTC 2.0.0.1 – Getting them to play nice too

Following on from my last post, we’re unfortunately unable to have everyone on a single tools. Our architects and BA’s, who are going to use Rational Software Architect for UML modelling also need access to Rational Team Concert. I had a genius plan that I could install RSA on top of SpringSource Tool Suite or vice versa. No joy I’m afraid. I did however manage to install RTC 2.0.0.1 on top of RSA 7.5.4.  I managed it as follows:

Firstly I obtained RSA 7.5.4 (all 100 gigs of it…).  Then I copied all the zips to my desktop and unzipped them all. NOTE: if you have them unzipped but running from a CD they won’t work. (That’s a free tip for you).

Then I started the IBM Installer. The first thing it did was want to update itself from 1.3.1 to 1.3.2 (i.e. the IBM Installer, not RSA.) I let it go off and do its thing. (You might need to go to the “Help” menu item and set your proxy info if you’re behind a firewall at this point).

Once the Installer had updated it let me install RSA 7.5.4 itself. I made sure the RTC 1.0 client was installed. (I don’t know if this made a difference to the later upgrade to 2.0.0.1, but it’s worth having if you want to follow these steps exactly.)

After the RSA install was finished I was ready to lay my RTC 2.0.0.1 install over it. For this I needed to download the RTC Client Installer (NOT the zip). E.g.:

https://jazz.net/downloads/rational-team-concert/releases/2.0.0.1/RTC-Eclipse-Client-2.0.0.1-Win32-Local.zip

Once this was downloaded, I unzipped it and started the Installation Manager it contained. I ran through the installation steps, accepting all the defaults until it gave me the chance to either install a new Eclipse Platform (default but wrong) or on top of an existing one (non-default but right). We selected this option and added the path to the RSA eclipse.exe as requested (C:\Program Files\IBM\SDP\eclipse.exe is the default).

I then let the rest of the install proceed as normal.

Once it was completed I started up RSA and switched to the newly added “Work Items” perspective and connected to our RTC 2.0.0.1 server.

It worked!

STS and RTC – Getting them to Play Nice

We’re developing our new app using Spring 3.0 RC1 and we want the best tools available. We’ve picked the following:

• SpringSource Tools Suite 2.2.1 (includes Maven 2.x)
• IBM Rational Team Concert Client 2.0.0.1
• Oracle Enterprise Pack for Eclipse 1.3.0
• Emma Plugin 1.4.3
• Findbugs Plugin 1.3.9
• PMD Plugin 3.2.6
• Checkstyle Plugin 5.0.3
• JDepend Plugin 1.2.1

We want everything to work as seamlessly as possible. This involved getting everything to run on STS.

First we downloaded STS from SpringSource.  Once this was installed (all the defaults selected) we ran the updater to get it up to version 2.2.1 (Help > Check for Updates). We installed all the bits on offer.

Next we installed our code quality tools. In each case we added the Eclipse Update Site for the plugins in question:

Help > Install New Software > Add…

• Emma – http://update.eclemma.org
• Findbugs – http://findbugs.cs.umd.edu/eclipse
• PMD – http://pmd.sourceforge.net/eclipse
• Checkstyle – http://eclipse-cs.sf.net/update
• JDepend – http://andrei.gmxhome.de/eclipse

And in each case, we added the plugins (versions at the top of this post.)  I restarted after each plugin install, just to be on the safe side.

Next we added the Oracle Enterprise Pack so we’d have support for Weblogic which is our deployment platform.  Just as before we added the Eclipse Update Site:

Help > Install New Software > Add…

• Oracle Enterprise Pack – http://download.oracle.com/otn_software/oepe/galileo

Now for the fiddly bit.  We needed to frig things a little to get the RTC 2.0.0.1 elements working on an Eclipse 3.5 (galileo) platform.  Please note, this is utterly and shamefully based on the fine set of info on Jazz.net:

https://jazz.net/wiki/bin/view/Main/InstallRTC20IntoEclipse35

Firstly we needed to download the RTC 2.0.0.1 Client zip (NOT the Installer) from Jazz.net:

https://jazz.net/downloads/rational-team-concert/releases/2.0.0.1/RTC-Client-2.0.0.1-Win.zip

Once this was downloaded, we unzipped it to a location of our choice. (Desktop is good.)

Next we installed the necessary pre-reqs into STS so the RTC plugins would work.  We again went to Help > Install New Software …

First we installed EMF and DTP. We selected the Galileo site in the  “work with:” drop down

• To install EMF, we expanded the Modeling category and selected EMF - Eclipse Modeling Framework SDK and the _ XSD - XML Schema Definition SDK_ entries
• To install DTP, we selected the Database Development category
• We then followed the wizard through to install these features and then restart

Next up was GEF. We selected the Galileo site again:

• This time we unchecked the “Group items by category” option at the bottom of the wizard
• And then typed “GEF” in the filter text area.
• Then we selected the Graphical Editing Framework GEF SDK entry
• And finally followed the wizard through to install GEF and then restart

Now we were finally ready to install RTC.

• Firstly we closed STS
• Then we simply copied the folders contained in our  downloaded and unzipped jazz/client/eclipse/jazz folder (e.g. build, scm, reports, etc.) to the our eclipse/dropins folder of our STS installation
• Then we restarted STS. The “Wotrk Items” perspective was now available, and we could connect to our Jazz Project areas.

Easy.