org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.codehaus.mojo:hibernate3-maven-plugin:2.2:hbm2ddl (create-schema) on project incident-service:
   Execution create-schema of goal org.codehaus.mojo:hibernate3-maven-plugin:2.2:hbm2ddl failed:
    Could not parse configuration: file:/var/lib/jenkins/jobs/IncidentService/workspace/target/classes/hibernate.cfg.xml

Except, there were no changes to the code; nothing changed in this file, and it’s been working fine for about a month or two. The environment the build server is on changed however. It cannot get to certain parts of the internet:

jenkins@hudson1:~$ wget http://www.hibernate.org/dtd/hibernate-configuration-3.0.dtd
--2011-10-10 10:48:06--  http://www.hibernate.org/dtd/hibernate-configuration-3.0.dtd
Resolving www.hibernate.org... 209.132.182.21
Connecting to www.hibernate.org|209.132.182.21|:80... failed: Connection timed out.
Retrying.

It’s not actually able to get to the internet to validate the DTD within that hibernate.cfg.xml file. This should not break our build. It was a source of much frustration for about 4 hours of the day. Various hibernate forums were of limited help.

Apparently it should get it from the jar, rather than the internet, if the jar is available on the class path and the DTD matches. First our DTD was incorrect. Rectified that, and yet it still tried to get it off the internet. WTF?

Turns out the hibernate3-maven-plugin doesn’t include any hibernate jars when it executes.

Solution is to duplicate the necessary hibernate dependencies for the plugin to have the necessary DTD data available:

<dependencies>
  <!--
    Need to include the following hibernate dependencies so that it can find the DTD
    without having to get it off the internet.
  -->
  <dependency>
    <groupId>org.hibernate</groupId>
    <artifactId>hibernate-core</artifactId>
    <version>${hibernate.version}</version>
  </dependency>
  <dependency>
    <groupId>org.hibernate</groupId>
    <artifactId>hibernate-validator</artifactId>
    <version>4.0.0.GA</version>
    <exclusions>
      <exclusion>
        <groupId>org.slf4j</groupId>
        <artifactId>slf4j-api</artifactId>
      </exclusion>
    </exclusions>
  </dependency>
  <dependency>
     <groupId>org.hibernate.javax.persistence</groupId>
     <artifactId>hibernate-jpa-2.0-api</artifactId>
     <version>1.0.0.Final</version>
  </dependency>
</dependencies>

So some context: This is to support preventing the hibernate3-maven-plugin from going to the internet to get the DTD every time it parses that hibernate.cfg.xml file. There’s no data in this file, only a shell of a hibernate.cfg.xml; just enough of a placeholder to keep the hbm2ddl Goal from failing, as we’ll eventually have it build DDL for us.

Content:

<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE hibernate-configuration PUBLIC
    "-//Hibernate/Hibernate Configuration DTD 3.0//EN"
    "http://www.hibernate.org/dtd/hibernate-configuration-3.0.dtd">

<hibernate-configuration>

    <session-factory>
        <!-- specify annotated classes here, because the hbm2ddl plugin isn't capable of searching for them :( -->
    </session-factory>

</hibernate-configuration>

Quite an irritating error for something that seems to actually do nothing. Apparently it does. Stupid XML

I updated my postgresql database, as it was version 8 and version 9 has been out for quite a while. That actually went painlessly. Backup the SQL, terminate the db server, build/install the new one, and restore the SQL. Then tewak configuration files to get everything back the way it was before. No problem.

Then realized I needed to rebuild a pg gem on the deployed host so that it’d talk to postgresql 9 now. Did that. Suddenly the app server no longer responds. it just sits there forever waiting on … something. No amount of debugging output from Passenger will help. It must be something else. So now I’m updating ruby and rebuilding a new Passsenger against it in the hopes that it’s a bug in ruby that I’ve encountered that evidences itself with postgresql 9 or something. Otherwise, I might be spending the day getting the newer revision of my application ready to go a bit earlier than I had planned.

Had I had an automated deployment script built in, I could’ve just clobbered the environment and redeployed within the new fresh environment. Instead I’m having to monkey around getting everything to behave well, and generally failing at it.

Unfortunately, that means for those that are still using cuke4duke, you’ve got problems to deal with. The voodoo magic that is cuke4duke does not install gems very well. I don’t know precisely why this is, but it ends up with many problems. Things that will install just fine using a jruby command line, or in native ruby barf a horrible death. Often regarding some YAML::Syck thing.

ERROR:  While executing gem ... (ArgumentError)
      undefined class/module YAML::Syck::DefaultKey

Really sucks and makes it difficult to actually use cuke4duke unless you’ve already got all the gems you need installed.

After much investigation, I discovered that cuke4duke uses a GEM_HOME of ~/.m2/repository/.jruby . So a simple command can get the gems you want installed into that folder:

java -jar jruby-complete-1.6.4.jar -S gem install json --version=1.5.4 --no-rdoc --no-ri -i /home/dkowis/.m2/repository/.jruby

Unfortunately, if there’s another “gem” command in your path, it will use that instead of the one in your jar file, so you have to munge your path as well to prevent it from doing so.

Finally, I needed a way to get this into our project’s Maven POM so that we could easily set up other peoples boxes and the configuration isn’t lost in some terribly manual process of running that command over and over.

This is the solution I came up with:

        <profile>
            <id>install-gems</id>
            <build>
                <plugins>
                    <plugin>
                        <groupId>org.apache.maven.plugins</groupId>
                        <artifactId>maven-antrun-plugin</artifactId>
                        <version>1.6</version>
                        <executions>
                            <execution>
                                <phase>generate-test-resources</phase>
                                <configuration>
                                    <target>
                                        <property file="gems.properties"/>
                                        <macrodef name="install-gem">
                                            <attribute name="gem"/>
                                            <attribute name="version"/>
                                            <sequential>
                                                <java jar="${maven.dependency.org.jruby.jruby-complete.jar.path}"
                                                      fork="true"
                                                      failonerror="true"
                                                      maxmemory="64m"
                                                      newenvironment="true">
                                                    <arg value="-S"/>
                                                    <arg value="gem"/>
                                                    <arg value="install"/>
                                                    <arg value="@{gem}"/>
                                                    <arg value="--version=@{version}"/>
                                                    <arg value="-i"/>
                                                    <arg value="${user.home}/.m2/repository/.jruby"/>
                                                    <env key="PATH" path="${java.home}/bin"/>
                                                </java>
                                            </sequential>
                                        </macrodef>
                                        <install-gem gem="json" version="1.5.4"/> <!-- needed to get json to behave with jruby -->
                                        <install-gem gem="cucumber" version="1.0.3"/>
                                        <install-gem gem="cuke4duke" version="${gem.cuke4duke.version}"/>
                                        <install-gem gem="nokogiri" version="${gem.nokogiri.version}"/>
                                        <install-gem gem="rspec" version="${gem.rspec.version}"/>
                                        <install-gem gem="rest-client" version="${gem.restclient.version}"/>
                                        <install-gem gem="jruby-openssl" version="${gem.jrubyopenssl.version}"/>
                                    </target>
                                </configuration>
                                <goals>
                                    <goal>run</goal>
                                </goals>
                            </execution>
                        </executions>
                    </plugin>
                </plugins>
            </build>
        </profile>

One can then run the command ‘mvn test -Pinstall-gems’ and the gems will be installed as part of the test-resource-generation phase. This only has to be done once whenever new gems are added, or on initial setup. Once it’s done, you’re good to go with the normal cuke4duke workflow.

Hopefully this will save other people some time :)

I wanted to figure out how to require/load/import additional files into the deploy.rb file so that I would be able to drop recipes in to a config/recipes directory.

Turns out this is the solution.

I ended up using this to simply load all the recipes in the recipes directory:

#load in all the other recipes
$LOAD_PATH.unshift File.join(File.dirname(__FILE__), 'recipes')
Dir['config/recipes/**/*.rb'].each { |recipe| require  File.basename(recipe, '.rb') }

I looked into upgrading cucumber-rails, and apparently they recommend using Capybara instead of webrat for Rails 3. So I make the necessary changes. Unfortunately Capybara only has a get method. You can only visit pages. Any posts should be exercised by the web forms. This is far less than useful. It has proven to be a huge pain the butt. Hours of trying to find how people do this to no avail. Until I find an obscure answer, at the bottom of a StackOverflow posting.

That code on github is the key to testing APIs. It appears to use some of the more internal guts of the Capybara page drivers to accomplish it’s goal. Works for me.

I am surprised to see that there are few integration test frameworks that support this kind of web service test. Especially since where I work, this is what we build. Having Cucumber features describing those API calls makes everyone’s job easier. I find it unfortunate that it seems to be somewhat ignored by the testing community. Hopefully this will contain the necessary words for other people that are searching for the same thing I spent hours searching for, and will find it in far less time.

It appears that the original gem is unmaintained, and so I just forked it and updated some parts.

Someone has done no small amount of determining what the code within the minecraft_server.jar does and how you can inject hooks into it. I have forked that git repository and am trying to organize it a bit better. Possibly make it truly into just a plugin framework and nothing else.

I’m hoping that this will be useful to others and that it all won’t horribly break when the server is changed on the 31st. Otherwise, all the really awesome administrative abilities will be horribly broken. Another really awesome thing would be if Notch were to have a plugin API ready to go. Perhaps based on the work that the community is doing.

You need to install openssl-devel, zlib-devel, bison, gcc, make, patch, tar, and maybe gcc-c++ (although I don’t think this one is needed).

Go get the latest ruby 1.9 source, as of this writing 1.9-p378, and extract it somewhere. Then go get the patches on this bug, at the specific comment. You will need to apply at least the openssl-build-fix patch, since fedora uses openssl 1.0 and it’s not yet into ruby 1.9. Then follow your typical ./cofnigure, make, and make install stuff. I installed mine into a prefix of /opt/ruby so that it wouldn’t affect any fedora ruby stuff that it might want. I then added ruby’s path to the end of my user’s PATH variable.

That’ll get you a working ruby 1.9 in Fedora.

Woot.

EDIT:

Man, this guy has all sorts of good stuff: http://www.vim.org/account/profile.php?user_id=9012

cucumber, rails, ruby, git-vim integration. VIM FTW!