A backup in my pocket

Posted on by
Reply

As I get more paranoid about losing the work I’ve been doing. I’ve adopted the extra precaution of putting a backup of my most important work in my pocket whenever I walk out of the door. This way I’ve got my latest work off the premises and I’ve covered that crucial period since the most recent nightly backup.

I simply use a USB memory key which is encrypted, so should I lose it it can’t be read, and a program called duplicity to create incremental backups.

Making the backup

The backups I do by mounting the USB drive, entering the encryption key and using the following command:

$ duplicity --no-encryption /home/rcm/my-important-data/ file:///media/memory-key/duplicity

In no time at all I’m ready to go. If I run out of space, due to too many incremental files, then I simply clear the existing duplicity directory and start a new backup. (This is safe as long as my nightly backup is doing its job.)

Getting it back

Luckily I’ve never needed to use the files, but I do test it now and then. So mount the USB drive again and make it accessible by entering the encryption key.

To see what backups this drive contains, use

$ duplicity  collection-status file:///media/memory-key/duplicity/
 To check what file are on it, use
$ duplicity list-current-files file:///media/memory-key/duplicity/ | less

To restore it (to a temporary directory), use

$ cd /tmp
$ duplicity --no-encryption  restore file:///media/memory-key/duplicity/ restore-test

A quick diff will indicate how well it has worked, using

 $ diff -qr restore-test /home/rcm/my-important-data

should show any files changed since the backup was made. (An alternative is to use the graphical program meld to navigate the differences.)

Displaying a version number on the page

Posted on by
Reply

There is version element available within scimpi that gets the current version number and displays it on a web page. Add

<swf::version-number />

to your page to get the version number from the manifest file – held in the war at `/META-INF/MANIFEST.MF`.  It looks for a line starting with “Implementation-Build: ” and uses the remainder of the line as the value that gets added to the page.

If you use Subversion and build you web app using Maven, then the following snippet can be used to add the project version and the Subversion revision number to manifest to give a page version like 2.0.3421.

            <plugin>
                <groupId>org.codehaus.mojo</groupId>
                <artifactId>buildnumber-maven-plugin</artifactId>
                <version>1.0-beta-4</version>
                <executions>
                  <execution>
                    <phase>validate</phase>
                    <goals>
                      <goal>create</goal>
                    </goals>
                  </execution>
                </executions>
                <configuration>
                  <doUpdate>true</doUpdate>
                </configuration>
            </plugin>

              <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-war-plugin</artifactId>
                <version>2.0.2</version>
                <configuration>
                  <archive>
                    <manifest>
                      <addDefaultImplementationEntries>true</addDefaultImplementationEntries>
                    </manifest>
                    <manifestEntries>
                      <Implementation-Build>${project.version}.${buildNumber}</Implementation-Build>
                    </manifestEntries>
                  </archive>
                </configuration>
              </plugin>

Using Maven to set up Eclipse

Posted on by
1

I’m still not using the m2eclipse plug-in for Eclipse and just rely on the Eclipse plug-in within Maven.  This causes one small problem when loading up the Isis code in Eclipse.  That said, it’s very quick to get running and to update.  Essentialy: check out the the code; create project files using Maven; and then import into Eclipse.

Preparing the modules to work as a Eclipse project requires you to run Maven with the Eclipse plug-in.

$ mvn eclipse:eclipse

Import the modified directories into Eclipse using the File/Import… menu and select the Existing Projects into Workspace source option.  Using the .project, .classpath and .setting resources that Maven created Eclipse will be set up ready to compile and run.

Now the problem. Running an application using the Isis framework gives an error like this:-

Exception in thread "main" org.apache.isis.core.commons.exceptions.IsisException: No resource found: installer-registry.properties
 at org.apache.isis.runtimes.dflt.runtime.installers.InstallerLookupDefault.getInstallerRegistryStream(InstallerLookupDefault.java:365)
 at org.apache.isis.runtimes.dflt.runtime.installers.InstallerLookupDefault.loadInstallers(InstallerLookupDefault.java:111)
 at org.apache.isis.runtimes.dflt.runtime.installers.InstallerLookupDefault.<init>(InstallerLookupDefault.java:107)
 at org.apache.isis.runtimes.dflt.runtime.runner.IsisRunner.<init>(IsisRunner.java:95)
 at org.apache.isis.runtimes.dflt.webserver.WebServer.run(WebServer.java:82)
 at org.apache.isis.runtimes.dflt.webserver.WebServer.main(WebServer.java:68)
 at org.apache.isis.WebServer.main(WebServer.java:25)

All that has happened is that the filters in one of the project’s properties is not quite right.

To fix it, open the properties for the org.apache.isis.runtimes.dflt.runtime project and select the Java Build Path section. Within that select the Source tab and remove the entry Included: isis-version.properties from the org.apache.isis.runtimes.dflt.runtime/src/main/resources folder.

Run it again and the error will no longer appear.

 

Creating a patched Isis module

Posted on by
Reply

I recently ran into a problem with one of the Isis modules that I’m using on a live system. As a new release of the framework wasn’t imminent, and I didn’t have the time to upgrade anyway, I decided to create a patched version of the module instead.  I ran into a few problems that slowed me down while doing this, so here is what I had to do in the hope that it might make your job easier should you need to do the same thing.  In this instance I needed to update the NoSql object store so I’m using it in this example.

Start off by creating a copy of the original code in a place that you can store it (ideally add it to your own repository so it can be rebuilt easily if needed). Use Subversion’s export command to get a copy (without the Apache SVN artifacts) of the needed module at the version you are currently using.  I’ve been using the 0.1.2 version so I used this command:

$ svn export https://svn.apache.org/repos/asf/incubator/isis/tags/isis-0.1.2-incubating/runtimes/dflt/objectstores/nosql nosql-patch

In theory you should be able to rebuild a module like this quite simply, but Isis has a complex build path and requires something extra. Within this module’s directory, if you run Maven with the install goal you’ll probably get one or two errors.

  • The enforcer plugin might fail if you are using a different version of Maven and an early version of Isis, as I was in this example.
  • The remote resources plugin will fail because you are building a module in isolation (this occurs as you ideally you don’t want to keep a copy of the whole framework, just the relevant module, which is all we exported).

Both of these things can be fixed using the relevant plugins’ parameters.  As I had both problems I used the following command to compile the module.

$ mvn install -Denforcer.skip=true -Dremoteresources.skip=true

With it now building successfully you are ready to make your changes to fix or adapt the module.

Before you use install again you should modify the version element in the module’s POM so that you have a unique version and are never faced with the question of whether a specific jar that you are using is the patched version or not.  To do this edit the pom.xml file and add something akin to -patch-01 to the existing version element. Make sure it is the version element within the project element and not the one within the parent element.

For example the change I made looked like this:-

    <parent>
        <groupId>org.apache.isis.runtimes.dflt</groupId>
        <artifactId>objectstores</artifactId>
        <version>0.1.2-incubating</version>
    </parent>

    <groupId>org.apache.isis.runtimes.dflt.objectstores</groupId>
    <artifactId>nosql</artifactId>
    <version>0.1.2-incubating-patch-01</version>

When install now completes a new version of the jar will be added to the Maven repository distinct from the original jar.  Now all that’s left to be done is to use the patched version in your code.  This is achieved by adjusting the version referenced in your application’s POM to match the one you just created. For our example this meant making the following change to my root POM.

            <dependency>
                <groupId>org.apache.isis.runtimes.dflt.objectstores</groupId>
                <artifactId>nosql</artifactId>
                <version>0.1.2-incubating-patch-01</version>
            </dependency>