May 29, 2013

It’s a sad world

Filed under: meatspace — SiKing @ 8:52 am

When I was a kid I was obsessed with Start Trek. There was one episode where two planets fought a war all through a computer simulation. One computer launched a simulated attack, the other side simulated a response, and then the computers calculated casualties. Actual people had to report to “extermination booths” where they were swiftly and painlessly exterminated.
We are getting pretty close to accomplishing this.
It’s all great that in the course of fighting terrorism no American lives will be lost. However, the thing that we seem to have missed from the 1967 TV show, is that by making war clean and pretty, and removing all the pain and suffering, we have removed the very reason to STOP!

February 28, 2013

What is wrong with GroovyTestCase and Selenium?

Filed under: automation — SiKing @ 2:58 pm
Tags: ,

Sometime ago I had a problem with running Selenium with GroovyTestCase framework. Recently I started a new project and have spent some time looking at this again.

Short answer: user error! 😮

Long answer:

The problem

I instantiated all my stuff like this:

class MyTestSuite extends GroovyTestCase {
      WebDriver driver = new FirefoxDriver()
      // ... some other global variables go here

      protected void setUp() throws Exception {
            // ... some other code to run at the start of each test

      protected void tearDown() throws Exception {

      void test_one() {
            // ... more test code goes here

      void test_two() {
            // ... more test code goes here

Each time I ran any of the tests, it launched like four browser windows and ran the test in one of them. 😕

new FirefoxDriver() launches the new browser, as it is suppose to. The framework, I guess, launched the class four times, once for each of my methods, and Groovy automatically places that code in the constructor. It then started parsing for all the work (all the test* methods).

The solution

You need to launch the browser (only once per test) from the setUp(), like so:

class MyTestSuite extends GroovyTestCase {
      WebDriver driver
      // ... some other global variables go here

      protected void setUp() throws Exception {
            driver = new FirefoxDriver()
            // ... some other code to run at the start of each test

      protected void tearDown() throws Exception {

      void test_one() {
            // ... more test code goes here

      void test_two() {
            // ... more test code goes here

HTH, 😉

February 1, 2013

Noki Déjà vu

Filed under: noki — SiKing @ 8:56 am

After 6 years my phone finally died. People (some people) are freaked out that I have had a phone for 6 years. However, when I purchased it, I had all intentions of keeping it for at least 10! It powers on, however the keyboard is completely unresponsive. Actually for a few years I had been unable to reflash the OS. Unfortunately the phone took down my entire phonebook with it.

Getting a new phone was like déjà vu, or is that reja vu?

For like a year now I have been talking about getting a new (the?) phone, and actually trying to bid cheap on it on eBay. When my old phone died, due to some personal circumstances, I needed a phone like right now! I just went to Target and got whatever was the cheapest thing in stock. After a few days I decided that all I really need is a phone … that’s it! Just a phone that can make calls, and send the odd SMS text. So one last time I decided to have a browse through eBay, just to see what the current price point is on the N9. When I logged into my account I had a message … from a seller: “where the heck is my money for the phone you bought a week ago?!?!” That’s paraphrased, of course. This was a total surprise. I discovered that eBay completely redesigned their site! Auctions that you are either bidding on and have lost are easily accessible from the left navigation menu (even though the counts are updated correctly only after you click on one of the links). But auctions that you have actually won, are buried at the bottom of the “Summary” page. 😡

I apologized to the seller and paid for the phone right away. Since I am getting a new shiny phone, I even paid for the extra $20 faster shipping. Afterwards, on a whim, I decided to check the seller’s eBay store. The seller is from Hong Kong, and at the top of the storefront was a message: “tomorrow is the start of the Chinese New year celebrations, and so we will be shutting down for a month!” 😯

Update Feb.19: And it does not end there. The seller shipped it to the wrong address (someplace in California). USPS says they will wait 30 days and ship it back if it is unclaimed. 😦

Probably faith telling me that the cheapo is good enough for me?

July 25, 2012

SoapUI external XML DataSource

Filed under: automation — SiKing @ 2:57 pm
Tags: ,

I am normally not a fan of DDT, I tend to lean more towards BDT, so it was only very recently that I started looking at the DataSource test step in SoapUI. The available documentation has a lot of room for improvement. Here is how I was able to use an external XML file(s) as a data source for my test.

I was given three files that have filenames like Visa_AVS.xml and they contain data in the form:

<test accountNumber="4112344112344113" amount="1.00" street="1 Main Street" city="Boston" zip="031010001" expectedAvsResp="B" />

Step 1: read in the raw files

This is done with the DataSource step.

The only thing that I could find to read in a file (other than Excel) is the DataSource = Directory.

I am using SoapUI-Pro and my entire project is a Composite Project, so every TestSuite is a separate directory. I am going to keep all my data sources in the same directory as the TestSuite, so as to make it easier for uploading to SVN. Directory = ${projectDir}/AA-PPS-soapui-project/experimental-Test-Responses-TestSuite

The Filename Filter = *_AVS.xml should be pretty explanatory. The only thing worth mentioning is that the filter must start with an asterix – probably a bug in SoapUI.

At this point there is no way to format the data, so the entire contents will be read into only one Property. It does not matter what you call it; I used “allData“.

I know I have three files, so when I hit the play button, I should get three entries in the Data Log.

DataSource - file

Step 2: format the data

This is also done with a DataSource step.

This time we are dealing with DataSource = XML.

Note that the documentation for Source Step says: “could be another DataSource”. Source Step = DataSource – file (from Step 1).

Source Property = allData – the only one you created in Step 1.

You need the XPath that would select each of the data blocks in your source file. Row XPath = //test

Next start creating the Properties. If you prefer to visualize your data as a spreadsheet grid, then the Row XPath would be each of your rows, and the Properties will be each of the columns. I decided to name each Property after the data attributes, but you can name them anything you like. As soon as you create a Property, the form will automatically start inserting new Column XPaths. The form assumes that your source data is formatted something like:


and so it inserts XPath like accountNumber/text(). In my case this is not correct, so I needed to Edit this to say @accountNumber. One of my source files, instead of the attribute zip, has an attribute zip5. So I had to edit the XPath to “@zip | @zip5“.

Once you hit the play button, you should see correct data in the Data Log. If you did anything wrong there will probably not be an error, you will just not see correct (any?) data in the Data Log.

DataSource - XML

Step 3: your test steps

At this point you can use any number of any test steps you like. Any of the data above can be accessed with Property expansion, for example ${DataSource - XML#accountNumber}, and can be manipulated just as any other data either in Input or in Assertions.

Step 4: iterate over all data

You need to add two DataSourceLoop steps.

The first will iterate over all the data within one file. So the DataSource Step should be whatever you named your Step 2 above. The Target Step should probably be whatever is the first thing in Step 3 above.

The second iterates over all the files. So the DataSource Step should be whatever you named your Step 1 above. The Target Step should be Step 2 above.

Test Case


HTH. 😉

March 20, 2012

debugging SoapUI Groovy scripts in Eclipse

Filed under: automation — SiKing @ 4:27 pm
Tags: ,

The very first thing that I must say: I did not quite get it to work, yet! I am hoping that somebody out there will read this and prod me in the right direction to get the last bit to work – please be gentle.

Step 1: ready SoapUI

You need the Pro version to get this to work, because using this technique you can only debug stuff in the Groovy Script Library.
I have two installations of SoapUI: version 4.0.1 that I use just for debugging, and version 4.0.2 SNAPSHOT that I use for all other work. But that might be a little overkill. 😛

  1. Download/install/configure SoapUI Pro. The most important thing is that you need to refactor any script you want to debug into the script library.
  2. Download and unpack the SoapUI source into the same directory as the installation.
  3. Modify the SoapUI Bootstrap Script; depending on which platform you are running this is going to be in $SOAPUI_HOME/bin/ or %SOAPUI_HOME%\bin\soapui-pro.bat if you’re a Window$ weenie. The last line of the script reads something like: java $JAVA_OPTS -cp $SOAPUI_CLASSPATH com.eviware.soapui.SoapUIPro "$@". Modify it to say java $JAVA_OPTS -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=8666 -cp $SOAPUI_CLASSPATH com.eviware.soapui.SoapUIPro "$@". The details of what this does can be found in this DW article, by Charles Lu.

Step 2: ready Eclipse

Don’t bother with the Eclipse-SoapUI plugin; not only does it not support any of the Pro features, but it is completely useless.

  1. Download/install/configure Eclipse. I personally prefer Eclipse for Testers, with the Java tools and Groovy tools installed.
  2. Create a new Groovy project and import into it your SoapUI project. Make sure you specify that your scripts folder is where your source files are stored.

    specify scripts as your source folder name

  3. You will need to link in the soapui-pro-4.0.1.jar library with the attached sources, as well as everything in the lib directory as a user library.

    create a user library from everything in $SOAPUI_HOME/lib

    add the soapui-pro-4.0.1.jar and the SoapUI user library to the build path

  4. Create a New Debug Configuration. It is going to be a Remote Java Application running on localhost:8666 to match the port specified when launching SoapUI above.

    create a debug configuration

Step 3: debug

  1. Start SoapUI from the modified script. You should see a message something like: Listening for transport dt_socket at address: 8666.
  2. Fire up Eclipse and start the debug configuration. It should connect to the already running SoapUI.
  3. In Eclipse, in one of your scripts set a breakpoint. In SoapUI run the test that contains this script.
  4. My Eclipse Debug session stops in the correct spot, however:

    now what?

Would appreciate any hints how to resolve this. 😥

March 4, 2012

Zeroth law of Life

Filed under: meatspace — SiKing @ 10:06 am

Scientists discover laws of Universe – how the universe works. Engineers are paid to break them. There is however the Zeroth law of Engineering – law that no other can supersede and nobody can break. The concept is named after Asimov’s Zeroth law of Robotics. The Zeroth law of Engineering states that any project can be good (quality), fast (on time), or cheap (on budget), pick two!

My Zeroth law of Life states that you can be good (morally, ethically, legally, spiritually, whatever…), rich (at least comfortably), or happy, pick two! Personally I have struggled my whole life to get a firm grip on at least one of these.

February 26, 2012

Loop around Area51

Filed under: rides — SiKing @ 10:00 pm

CeeJ and I have been mulling around riding the Extraterrestrial Highway for a while. This weekend we made it happen.

Day 1

The plan was to start early afternoon (after CutiePie’s swim practice). Unfortunately, CJ’s Shadow made it as far as the end of his street before it took a dump and would not start again. He had to push it back up to his house and change bikes, obviously moving everything he packed the nigh before from one bike to a backpack. We left Vegas probably around 3 in the afternoon.

The ride up the 95 went by pretty uneventful. CutiePie took some pictures from the back – of her gloves, her pants, the asphalt – and filled up the camera memory. Mental note: the camera memory is not a good backup storage. 😕 CJ reported that CutiePie was occasionally practising her synchro moves on the back of the bike – too bad we don’t have any video of that. Beatty was the first gas stop, next to The candy store of course. 🙂

Onwards through Goldfield up to Tonopah. Both of these are quickly becoming ghost towns, leftovers from the gold-rush days. I was actually very pleasantly surprised how well maintained the town centre of both towns was.

Day 2

I woke up the next day around 8 (we did say no rush, right!), with both CJ and CutiePie both staring at me like: can we go yet? After the continental breakfast (mmmmm bacon! :razz:) we took a short walk around Tonopah. One, we wanted to gauge the morning temperature, and two, we wanted to see the town in daylight. If you are going to stay, I recommend the Mizpah hotel – it still has the old charm to it. We did not get a room there (no vacancy), but did have our dinner there. Eventually opted for for the winter riding pants, since I brought them along, but not the extra sweat shirt.

We got on the road probably just before 11. By this time I was sweating like a pig! About 40 miles out of town, I decided to pull over on the side of the road to zip up all the vents on my jacket and pants. The temps were getting below freezing, before the wind chill factor! A state trooper just happen to drive by, and pulled over to ask us if we were OK. On a whim I asked him if we are heading the right way towards the 375. He told us that we are headed exactly the opposite direction! We need to go back through Tonopah, and take the 6 towards Ely. The freaky thing is that about 5 miles back we passed a rest stop, where I was originally thinking of stopping to zip up, and where the trooper would have never seen us. By the time we were back in Tonopah, I had to gas up again, especially considering the next gas after that was going to be in Alamo – about 160 miles away; my bike has a range of 150 miles, riding 1up, down hill, with a good strong back wind. And off we were again, this time in the right direction.

The first stop we made was at the turnoff to the Tonopah Test Range airport – apparently this is where all the testing for the Stealth fighter was done. Half-way to Ely is the turnoff to the 375 – the Extraterrestrial Highway. As soon as we turned onto the highway, I remember seeing very tall mountains on the horizon, completely covered in white, and thinking that sure I sure hope that is not where we are going. 😮 The mountains stayed to the horizon all the way. 🙂 CutiePie kept up with her synchro workout on the back of the bike, and was freaking out the local Air Force as well as the UFOs: “What’s with the crazy air traffic controller chick?!?!” 😀

About half-way down the 375, in Rachel, NV, you actually come to the a sign that declares this to be the Extraterrestrial Highway, right before the Little A’Le’Inn – most people pronounce it little alien inn. As CJ said: you cannot pass up the opportunity to have lunch at a dive in the middle of nowhere! 🙂 This is where you can also find maps and photographs of the super-secret-illegal-to-photograph Area 51! The Eastern end of the highway even has some neat twisties – overall a really fun ride!

Last stop was the Alamo, NV. Brings back memories of bygone days, when I got almost abandoned by Bonnie and almost ran out of gas in the middle of the desert in the middle of the summer! This time I heeded the “No gas for next 75 miles” sign, a filled up.

This slideshow requires JavaScript.

To find Groom Dry Lake on the map, where the actual Area 51 is located, is left as an exercise for the reader.

January 6, 2012

dynamically create elements in a SoapUI request

Filed under: automation — SiKing @ 11:44 am
Tags: ,

I got this problem – took me like 8 hours to solve, so that qualifies it as a problem. In SoapUI I have a call that responds with something like <night ratePlanID="A" stayDate="B" availCodeID="C" regularPrice="D" totalPrice="E" />. There are multiple of these, the number can change depending on the inputs to this call. I need to create the same number of elements for my next call, and change the attributes around a bit to make it look something like: <hot:night ratePlanID="A" resDate="B" quotedPrice="E" />. Luckily Groovy abstracts away the need for counting things, and I naively thought that manipulating the XML would be a breeze too…

version 1.0

The first useful hints that I got were from the SoapUI tips & tricks. After that getting at the individual attributes is done with attributes.getNamedItem(). After that I just brute-forced my way through it.

// create groovyUtils and XmlHolder for response of my "find room" call
def grUtils = new
def holder = grUtils.getXmlHolder("find room#Response")

// place for my final result
def entireXmlFragment = new StringBuilder()

// get only the nodes that I am interested in, and iterate over all of them
holder.getDomNodes("//*:hotel/*:roomType/*:guestCount[1]/*:night").each {

	// create a new node one piece of string at a time
	def oneXmlFragment = new StringBuilder()
	oneXmlFragment << "<hot:night ratePlanID='"
	oneXmlFragment << it.attributes.getNamedItem("ratePlanID").getNodeValue()
	oneXmlFragment << "' resDate='"
	oneXmlFragment << it.attributes.getNamedItem("stayDate").getNodeValue()
	oneXmlFragment << "' quotedPrice='"
	oneXmlFragment << it.attributes.getNamedItem("totalPrice").getNodeValue()
	oneXmlFragment << "' />"
	oneXmlFragment << System.getProperty("line.separator")

	// add the new node to my final result
	entireXmlFragment << oneXmlFragment

// push the final result into a property
testRunner.testCase.setPropertyValue("entireXmlFragment", entireXmlFragment.toString())

Now in my next call I just insert ${#TestCase#entireXmlFragment} where I want this XML fragment to be placed. Works, but seems kinda neanderthal.

version 2.0

There has to be a way to manipulate my XmlFragments as XML objects, and there has to be a way to push them directly into the next call? The grUtils.getXmlHolder() led me to holder.getDomNodes(), which gives you back a org.w3c.dom.Node.

// create groovyUtils and XmlHolder for response of my "find room" call
def grUtils = new
def responseHolder = grUtils.getXmlHolder("find room#Response")

// create XmlHolder for request of my "bookHotelRes" call
def requestHolder = grUtils.getXmlHolder("bookHotelRes#Request")
// find the Node that I am interested in
def requestNode = requestHolder.getDomNode("//*:bookHotelResInput/*:room")
// the Document object is used to create new nodes
def requestDoc = requestNode.getOwnerDocument()

// get only the nodes that I am interested in, and iterate over all of them
responseHolder.getDomNodes("//*:hotel/*:roomType/*:guestCount[1]/*:night").each {

	// create a new Element in the Document
	def oneElement = requestDoc.createElementNS(requestNode.getNamespaceURI(), "night")
	// define all the attributes
	oneElement.setAttribute("ratePlanID", it.attributes.getNamedItem("ratePlanID").getNodeValue())
	oneElement.setAttribute("resDate", it.attributes.getNamedItem("stayDate").getNodeValue())
	oneElement.setAttribute("quotedPrice", it.attributes.getNamedItem("totalPrice").getNodeValue())
	// insert the Element
	requestNode.insertBefore(oneElement, requestNode.getFirstChild())

// write the Document out to the request

The above will write out the next Element as the first child. Also, and perhaps more importantly, the above will write it out into your request – if you run your test twice in a row, you will end up with both results (old and new) in your request. This is undesirable, but easy to take care of.

// cleanup from a "previous" run
requestHolder.getDomNodes("//*:bookHotelResInput/*:room/*:night").each {


August 22, 2011

Groovy Selenium WebDriver and SoapUI, part 3

Filed under: automation — SiKing @ 4:25 pm
Tags: , ,

So I got my environment set up and I have been busy coding up new Selenium-WebDriver test suite for a few weeks now.

I first wanted to just state that as great of a tool as SoapUI is, their community support just plain sucks! Any time I navigate to their discussion fora, I can actually hear the crickets in the distance. If you need some help, may I recommend the Service Testing using soapUI (needs login) group at LinkedIn.

The next bit of complaint that I have with SoapUI, is how poorly it integrates with Eclipse!

Now back to your regular programming …

the quick and dirty

So the most obvious, and perhaps the easiest way, to get Selenium and SoapUI to cooperate is:

  1. Install SoapUI.
  2. Download Selenium (you need the selenium-server-standalone-2.*.jar) and drop it into your SoapUI installation (into %SOAPUI_HOME%\bin\ext).
  3. Fire up SoapUI; start a new Project; create a new test case; add a new Groovy step; copy-paste the sample code into the step. I made a few modification: drop the package line, drop the class Selenium2Example and void main lines along with the closing brackets, and change the System.out.println to My final (full) test code is below.
  4. Click Play. You should see Firefox starting up, navigating to Google, and afterwards you should see the SoapUI log entries.
import org.openqa.selenium.By
import org.openqa.selenium.WebDriver
import org.openqa.selenium.WebElement
import org.openqa.selenium.firefox.FirefoxDriver

        // Create a new instance of the Firefox driver
        // Notice that the remainder of the code relies on the interface, 
        // not the implementation.
        WebDriver driver = new FirefoxDriver()

        // And now use this to visit Google

        // Find the text input element by its name
        WebElement element = driver.findElement("q"))

        // Enter something to search for

        // Now submit the form. WebDriver will find the form for us from the element

        // Check the title of the page"Page title is: " + driver.getTitle())
        // Google's search is rendered dynamically with JavaScript.
        // Wait for the page to load, timeout after 10 seconds
        (new WebDriverWait(driver, 10)).until(new ExpectedCondition() {
            public Boolean apply(WebDriver d) {
                return d.getTitle().toLowerCase().startsWith("cheese!")

        // Should see: "cheese! - Google Search""Page title is: " + driver.getTitle())
        //Close the browser

Success, the two can talk to each other. ❗ You will probably notice some errors, due to Google updating their site and the above code no longer works there; however, the proof of concept is there. For a better example, see my sample code.

the difficult way

I did not get as much chance to play with the SoapUI as I would have liked, but I wanted to get this published. The above will work for simple Selenium steps. However, for more complex steps you probably want a little more.

Unfortunately, I have not had a chance to explore this yet, but the general idea is:

  • SoapUI is a java project, it must be in some .jars somewhere, hopefully in just one.
  • Import that into your Groovy (Java) project.
  • Then you should be able to call appropriate functions from your code.

All this sounds quite easy, but I am certain that it will need more than what I have here. If anyone manages to get this to work, I would be really curious to hear from you.

August 18, 2011

the next phone?

Filed under: noki — SiKing @ 5:21 pm

My old phone is getting … old. So I started looking around at what else to get. I really like the sound of the new N9! However, in a twisty move by Nokia I suspect a lot of people are going to get rich off of this phone. I’m still looking at other possibilities…

August 8, 2011

Groovy Selenium WebDriver and SoapUI, part 2

Filed under: automation — SiKing @ 2:55 pm
Tags: , ,

I initially assumed that I would have this post up within a week of the previous, but life got in the way as it so often does. 😐

Now that I got everything set up, it’s time to move on. In this second part, I am going to concentrate on getting Selenium 2 WebDriver going with Groovy. Selenium 2 out of the box supports .NET and Java, so why Groovy? There are several reasons: 1. SoapUI (to be discussed later) supports Groovy natively, 2. I like scripted languages for test automation better than compiled languages, and 3. why not?

I had been working with Selenium RC and .NET for some time, and had put together the basis of an automation framework. So my first step was to rewrite everything in Java, and just call it Groovy. All this was actually surprisingly easy to accomplish, especially with my very limited knowledge of both Java and Groovy. I want to stress that what I have here (the previous two links) is just the beginnings of a test framework. It meets my initial requirements: that it run in Groovy, and that it use 100% WebDriver. I am certain that it can (and will) be further optimized, but I would hope that anyone starting with this will get a good idea of where this is heading.

still to do:

  • Get everything running from the command line.
  • Use it in a real-world project. :mrgreen:
  • Make everything more Groovy.

couple of surprises along the way:

  • Man, love the lack of Selenium server. No more Java memory crashes. 👿 Yay!
  • In JUnit4 the signature of asserts changed from (NUnit’s) Assert.AreEqual(expected, actual, message) to Assert.assertEquals(message, expected, actual). The message goes at the beginning?
  • In webDriver, getting the value of a textbox changed from selenium.GetValue("name=q") to txtSearch.getAttribute("value"). Nice!

July 23, 2011

Groovy Selenium WebDriver and SoapUI, part 1

Filed under: automation,linux,windows — SiKing @ 4:13 pm
Tags: , ,

I recently started a new job and a new project that called for me to make use of some things I have used separately over the past few years: combine SoapUI and Selenium into one framework, and make them work together – actually pass information from one to the other and back. While I am at it, I thought I would dust off some skillz from a box that I have not been in for some time: Eclipse and Java (I know the title says Groovy, I’ll get to that).

setting it all up on Windows

Of course at work they must run Windows. 😦

  1. Download and install (unpack?) Eclipse Classic 3.7, and run the Check for Updates. Mental note: gotta look at Eclipse for Testers, someday.
  2. You need to give it Java: set JAVA_HOME and add %JAVA_HOME%\bin to the PATH. The first one that I tried – there were like half-dozen different versions on my machine 🙄 – Eclipse complained that it is missing something called jvm.dll. Better get the real thing.
  3. If you create a shortcut to launch Eclipse from your desktop, I found that it is a good idea to set the “Start in:” field to the same thing as what your workspace is.
    Eclipse shortcut properties
  4. Install SoapUI. This plugin needs some post-install work/commentary. If you also run the SoapUI IDE, especially a different version than what you just downloaded, the two will share one %userProfile%\soapui-settings.xml and there could be collisions; I would really like to find a way to relocate this file for the Eclipse plugin. Also, if you did not start Eclipse from your workspace – point 3 above – then you are going to 1) possibly overwrite your %userProfile%\default-soapui-workspace.xml, and 2) possibly pollute your Eclipse installation with three *.log files that SoapUI always creates on startup. Lastly: what used to be %SOAPUI_HOME%\bin\ext (external jars that should be added to soapUI classpath, for example JDBC drivers) is now %userProfile%\ext; another thing I would really like to relocate for the Eclipse plugin.
  5. Install Groovy. The instructions say to use, but if you read between the lines, you will notice this is the development build and as such it changes often, like almost daily. I used and it seems to have worked right out of the box.
  6. Install SVN. I am not sure why Eclipse still comes pre-installed with CVS; does anyone still use this? When you’re done, make sure it worked. Normally there are problems.

setting it all up on Linux

Of course at home I run Linux. Surprisingly the Linux setup was a little more work. 😕

  1. I run Linux Mint 9 (Ubuntu Lucid Lynx – LTS); the repos have only Eclipse 3.5, which is way too outdated by now. Download and install (unpack?) Eclipse Classic 3.7, and run the Check for Updates.
  2. LM9 comes set up with OpenJDK. Eclipse will run with this, however, when doing this last time, I ran into some problems, like various things kept crashing the JVM. Somewhere on the Eclipse site (unfortunately, I cannot find the link now) they suggested that you use genuine Sun Java. This is accomplished with sudo apt-get install sun-java-jdk, and then you need to modify your eclipse.ini to point to /usr/lib/jvm/java-6-sun/bin/java.
  3. Install SoapUI. I’m still having problems with this one.
  4. Install Groovy. Use the same location as mentioned above, which makes it work right out of the box.
  5. Install SVN. Fix the problems.
« Previous PageNext Page »

Blog at