Much ado about scripting, Linux & Eclipse: card subject to change


HOWTO: See what happened in SVN between builds

I was recently asked how to determine what changed between two builds. Jenkins provides nice interlinks into JIRA (issues), Fisheye (source changes), SVN (sources), but let's say you want to kick things a little more old school and investigate the old way... or the builds you want to compare are no longer shown in Jenkins because they expired and their metadata was automatically purged.

If you can't just look at the changelog in Jenkins to see what revision of source was used for the build, you can check the SVN log to find revision numbers based on the timestamp of the build.

So, if your build was generated on 2011-10-18, you can see that the log shows the last commit before that build was this:

$ svn log


r35735 | bfitzpat | 2011-10-17 15:35:23 -0400 (Mon, 17 Oct 2011) | 2 lines
Changed paths:
   A esb/plugins/.project
   M esb/plugins/

JBDS-1889 - Now checking for juddi-client-3.1.2.jar as well as 3.1.0 and 3.1.1 when seeing if the runtime includes ESB 4.10


Want to see actual diffs between that build and the latest one?

$ svn diff

Or, if you want to collect just the section of log relevant to the change:

$ svn log -r35735:HEAD

Of course if you have all the sources locally, you don't need to log or diff via a URL - you can simply use local file paths. And if like me you use git-svn instead of pure svn, you can use that to diff or log too.

If you want to easily determine when a branch was created and get the SVN revision number for that branch point, use this:

# from r28571, returns -r28571:HEAD
rev=$(svn log --stop-on-copy \ \
  | egrep "r[0-9]+" | tail -1 | sed -e "s#\(r[0-9]\+\).\+#-\1:HEAD#")

If you'd like to view a specific svn revision in your browser, use !svn/bc/REVISION_NUMBER/ before the branch and path to file or folder:!svn/bc/35735/branches/jbosstools-3.2.x/


HOWTO: Use Maven, Ant, and XSLT to scrub unwanted p2 metadata from an update site

Some time ago, I wrote about Using p2.inf to add/remove update sites. Tonight I found a simpler way to remove references in p2 metadata to external 3rd party sites.

For example, say you're repackaging some 3rd party features onto your own site, but don't want those features to provide references to the vendor's own update sites because you want to ensure that your product's site will only result in your sanctioned version being installed.

When you generate an update site, p2 pulls the information in the included features and will result in a section of references in the site's metadata that looks like this:

  <references size="6">
    <repository uri="" url="" type="0" options="0"/>
    <repository uri="" url="" type="1" options="0"/>
    <repository uri="" url="" type="1" options="0"/>
    <repository uri="" url="" type="0" options="0"/>
    <repository uri="" url="" type="0" options="0"/>
    <repository uri="" url="" type="1" options="0"/>
To remove that, you can play with p2.inf directives, or you can simply perform an XSL transformation on the generated content.xml (inside content.jar, if your metadata is compressed) to remove the <references/> node:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="" version="2.0">
<xsl:template match="/">
        <xsl:apply-templates select="*"/>
<xsl:template match="*">
        <xsl:copy >
                <xsl:for-each select="@*">
                        <xsl:copy />
                <xsl:apply-templates />
<xsl:template match="references" />
If you're generating your update site w/ Tycho, this transform can be called via a simple Ant script:

       <target name="remove.references">
                <!-- requires ant-contrib only if you like using if-then-else structures -->
                        <available file="${}/content.jar" type="file" />
                                <unzip src="${}/content.jar" dest="${}" />
                                <delete file="${}/content.jar" />
                <copy file="${}/content.xml" tofile="${}/content.old.xml" overwrite="true" />
                <xslt style="remove-references.xsl" in="${}/content.old.xml" out="${}/content.xml" />
                <zip destfile="${}/content.jar" basedir="${}" includes="content.xml" />
                <delete file="${}/content.xml" />
                <delete file="${}/content.old.xml" />

Then, in your site's pom.xml, to call the Ant script, do this:

                                <!-- make sure this variable is defined, eg., set to 1.3 -->
                                                                <!-- called AFTER generating update site + zip to tweak content -->
                                                                <ant antfile="build.xml">
                                                                        <property name="SOME_ANT_VARIABLE" value="${SOME_MAVEN_VARIABLE}" />
                                        <!-- some dependencies your ant script might need -->

I suppose there's probably a way to call a transform directly from Maven w/o the Ant wrapper, but this allows unpacking and repacking of the content.jar to get at the content.xml file.