Over the weekend the Jenkins build started failing. The error leads me to believe that someone didn’t verify their build before committing code, and that the configuration file now has a problem:

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.

*le sigh*

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

 

Particularly deployment automation, in my case something like capistrano. It goes further than just the application, however. It goes into being able to ensure that the deployment environment, including the database and the application container all behave nicely. I have failed in this aspect, as my rails app is no longer behaving, and I’ve been reduced to updating things in the hopes that one of the things will fix it :(

Continue reading »

 

I know it’s not something you have to do. But when it arrives an entire ay early, would it be that difficult to put it on the truck and deliver it?

Instead, it’s simply “not due for delivery,” and so you keep it. I wish I’d checked before I left work, then I could’ve gone and picked it up, because you’re too lazy to get it to my house today.

If you weren’t better than UPS at smashing boxes for me, I’d have shipped it UPS, and they’d have delivered it a day early.

 

cuke4duke support has been dropped in favor of work on cucumber-jvm. Which is all well and good, except that cucumber-jvm isn’t fully baked yet. It’s not quite there regarding features, but it’s getting there fast.

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 :)

 

Blarg. Gcc.

I kept having a horrible error building collectd 4.10.x on my Source Mage servers:

libiptc.c:85: error: redefinition of ‘struct xt_error_target’

The internets couldn’t really help me with the error, I think I was searching for the wrong words. There was also issues regarding warnings that gcc now treats as errors.

I ended up spending probably about an hour cloning their git repo, cherry-picking a few commits into the 4.10.3 tag, and then submitting the patches to the bug I created.

End result is that collectd-4.10.3 now builds on gcc 4.4.3 and 4.6.1. The fix is in the Grimoire on Source Mage, and should trickle out to stable eventually. I think I’m the only one who uses collectd, so it’s not all that important, heh.

© 2011 Shlrm.org Blag Suffusion theme by Sayontan Sinha