Wrangling the package repo!

Once you're using a builder from day-to-day frequently adding new packages to the ControlTier (WebDAV) repository, it's alarming how quickly their numbers and the amount of disk space they consume can rise!

A couple of new Builder base type commands were introduced with ControlTier 3.1 to facilitate managing the package repository: "repoFind" & "repoPurge".

The "repoFind" command's "-purge" option comes to the rescue by providing the antidote to "repoImport":

repoFind [Builder] [-buildstamp <.*>] [-packagetype <>] [-session ] [-version <.*>] [-purge]
Find package objects in the repository.

Essentially, the command queries the object model matching package objects by "buildstamp" and "packagetype" regex patterns to create a list of candidate packages, the (optionally) calling the "repoPurge" command which invokes each package's "purge" command:

purge -url <>
removes the file from the repository

... which in turn deletes the package file using the Ant "davdelete" task. Finally, the "repoPurge" command executes a batched deletion of all the selected package objects. Note that only package that do not have referrer relationships are deleted (i.e. packages that are not in use).

Here are a couple of examples:

• Purge all packages regardless of their type associated with a given buildstamp:
  

  $ ad -p rhbc -t AtgDasModuleBuilder -o babyandchild -c repoFind --
     -buildstamp 8734 -purge
  

• Purge all packages of a given type regardless of their buildstamp (the "packagetype" option value can be a regex too):
  

  $ ad -p rhbc -t AtgDasModuleBuilder -o babyandchild -c repoFind -- -buildstamp '.*'
     -packagetype AtgModuleJar  -purge
  

By the way, having just run through using "repoFind" with one of our client's projects, I can report a subtle bug that I've just fixed in the "repoPurge" command. It turns out that the command assumes that the required Package module is installed in order to be able to run the "purge" commands. This is always the case if you invoke the "repoPurge" command from a node which has previously been used for a "repoImport" (e.g. your build system), but if you choose another system (e.g. the ControlTier server), the module is not available and the command fails.

Here's the fix using the same logic used in "repoImport":

$ svn diff repoPurge.xml
Index: repoPurge.xml
===================================================================
--- repoPurge.xml       (revision 8087)
+++ repoPurge.xml       (working copy)
@@ -88,6 +88,13 @@
    <session-get session="${session.command}" resultproperty="pkg.mapref-uri" key="purge.package.@{pkgType}.@{pkgName}.mapref-uri"/>
    <session-get session="${session.command}" resultproperty="pkg.repo-url" key="purge.package.@{pkgType}.@{pkgName}.repo-url"/>
    <propertyregex property="filetype" override="true" input="@{pkgName}" regexp="[^\.]*.([^\.]*)$" select="\1"/>
+         <controller>
+           <execute>
+             <context/>
+             <command name="Install-Module" module="Managed-Entity" depot="${context.depot}"/>
+             <arg line="-depot ${context.depot} -module @{pkgType} -version head"/>
+           </execute>
+         </controller>
    <controller>
      <execute>
        <context/>

The fix will make the next 3.1 point release and will be merged into the 3.2 development brach and posted to Sourceforge soon.

Thanks,

Anthony.

See you at JavaOne

This year marks the first we go to JavaOne as an exhibitor. It's about time, given our deep experience in automating development and operations for our predominantly Java-using customer base. Our Java Server Library, "Elements", has been evolving over the last couple years, and has really been an instrumental part of improving customer's life cycle reliability and speed.
Java is front and center at ControlTier. Our new CTL control dispatcher has special documentation areas for Ant and Maven users. There's still a lot of functionality useful to Java users that we are in the midst of packaging and documenting.
Of course, all the Open.ControlTier software is Java-based, and as one of ControlTier's developers, it's exciting to be at JavaOne to see what's new.
If you are going to be there, swing by the ControlTier booth and say hello.