Workaround the Grub installation issue in Debian Wheezy

The current testing version of Debian, aka Wheezy, contains a rather annoying bug that prevents the installation of Grub, the multi-OS bootstrapper of Linux. Although this bug will be corrected at some point in the possibly near future, it is already present for a few months, making life harder for the fresh installations. The traditional workaround in order to install Debian Testing is to install a stable version (Squeeze) and then modify your mirrors to upgrade it to a testing version. In this way Grub will be installed correctly. However, if you have encountered the Grub issue, this means you have already completed your install from a broken edition (if you encounter the issue but you haven’t completed the install yet, just finish it in a clean way without a bootloader, and then continue reading here). So, maybe you don’t want to download a new ISO image, burn a new DVD or write a new USB key with it, and then restart the installation process from scratch. The other solution is then to keep the installation that you have just done and to setup the installation of Grub from the stable mirrors. It’s quite straightforward once you know how to do this.

First you need to boot your fresh installation. In order to do this, you can use any valid Debian bootable media, like for example the media you have used to do your installation. In the boot menu, you should select ‘Advanced Options’ and then the ‘Rescue Mode’. This will launch a recovery shell as root user (be careful). In the following screens, select the root partition where Debian is installed in order to mount it (mountpoint /).

The first thing to do now is to make sure the network is started and accessible. You can try a ‘ping debian.org‘.

Next, use vi to modify the /etc/apt/sources.list file. Make sure the installation media (CD, DVD, USB, etc.) is commented out and replace ‘wheezy’ by ‘squeeze’ in the lines where the networked mirrors are specified (lines starting with deb and deb-src followed by a URL, do not modify the ones that contain the URL for the security patches). Save, quit the editor and update aptitude in order to apply the changes: ‘aptitude update‘. Now you can download the grub-pc package from the Squeeze mirrors: ‘aptitude install grub-pc‘. During the install process, you will be asked the partition where you want to get it installed. When this is finished, run ‘update-grub‘ in order to be sure the configuration files are correctly generated. This last step is probably not necessary, but let’s play it on the safe way just in case.

Now, you can remove your bootable media and cleanly reboot the computer: ‘shutdown now -r‘. It should restart fine.

The next thing to do, as root, is to modify back the /etc/apt/sources.list file with ‘wheezy’ instead of ‘squeeze’ and launch again the command ‘aptitude update‘ to apply the change.

How to “OSGIfy” an Oracle jdbc driver with Spring Roo

If you want to use Spring Roo to reverse engineer an existing Oracle database, you need to bundle the Oracle driver in an OSGI format (this is not required if you want to use Spring Roo with Oracle in a top down approach). For copyrights reasons, the OSGI driver for Oracle is not furnished by Spring Roo. And Oracle doesn’t provide it either: I have checked on their “Metalink” support website. So, you’ll need to create it yourself. But, as many Spring Roo beginners have certainly already noticed thus far, this is not always an easy task.

I introduce here a recipe that has been tested with the Oracle jdbc driver 11.2.0.2 and with Spring Roo 1.1.4 and 1.1.5. It is susceptible to work with other versions too, however I can’t offer any guarantee of result (anyway I’m convinced you’re an adventurer and, as such, you don’t need guarantees ). I’m also purposely verbose in the explanation of the process in order to give more chances to make it reproducible with other versions.

1. Download the driver from Oracle.

2. Install the driver in your local maven repository.

Maven command:
mvn install:install-file -Dfile=filename.jar -DgroupId=groupid -DartifactId=artifactId -Dversion=version -Dpackaging=jar

Example:
mvn install:install-file -Dfile=ojdbc5-11.2.0.2.jar -DgroupId=com.oracle -DartifactId=ojdbc5 -Dversion=11.2.0.2 -Dpackaging=jar

3. Create a new folder and “cd” into it. I use “C:\eclipse_workspaces\roo\osgi\” below.

4. Launch the Roo shell.

5. Create an addon wrapper for your jar. The addon wrapper command will create a maven project (pom.xml) that will be used to transform your normal driver into an OSGI driver.

Make sure the parameters match with the ones used to install the driver in your local maven repository (step 2).

Roo command:
addon create wrapper --topLevelPackage com.oracle.roo.JDBC --groupId groupid --artifactId artifactId --version version --vendorName Oracle --licenseUrl http://www.oracle.com

Example:
addon create wrapper --topLevelPackage com.oracle.roo.JDBC --groupId com.oracle --artifactId ojdbc5 --version 11.2.0.2 --vendorName Oracle --licenseUrl http://www.oracle.com

6. Quit the Roo shell and launch the maven goal mvn bundle:bundle. This command will generate the OSGI version of the driver under the target directory. Alternatively if you don’t want to quit the roo shell, you can also execute: perform command --mavenCommand bundle:bundle

7. Install the OSGI driver in Spring Roo. Run one of the following equivalent commands in the roo shell:

osgi install --url file:///C:\eclipse_workspaces\roo\osgi\target\com.oracle.roo.jdbc..jar

or

osgi start--url file:///C:\eclipse_workspaces\roo\osgi\target\com.oracle.roo.jdbc..jar

Example:
osgi install --url file:///C:\eclipse_workspaces\roo\osgi\target\com.oracle.roo.jdbc.ojdbc5-11.2.0.2.0001.jar

On successful completion, the command will return a Bundle ID that corresponds to the location of the OSGI file in the “Apache Felix” OSGI repository embedded by Spring Roo.

This is not the end yet, as you’ll probably get a strange error message when using it. So, please, keep on reading…

8. Try this new driver with Roo on an existing Oracle database:

database reverse engineer --shema xxx

If you get an error message of the style “Unresolved contraint in bundle com.springsource.oracle.jdbc”, that means your OSGI bundle has a dependency on another bundle:

Example 1:

[com.springsource.oracle.jdbc [66]] FrameworkEvent ERROR
org.apache.felix.log.LogException: org.osgi.framework.BundleException: Unresolved constraint in bundle com.springsource.oracle.jdb
c [66]: Unable to resolve 66.0: missing requirement [66.0] package; (&(package=javax.resource)(version>=1.5.0)(!(version>=2.0.0)))
at org.apache.felix.framework.Felix.resolveBundle(Felix.java:3409)
at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1594)
at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:904)
[... cont.]

In this first case, the bundle has an unsatisfied dependency on javax.resource

Example 2:

[com.oracle.roo.jdbc.ojdbc5 [66]] FrameworkEvent ERROR
org.apache.felix.log.LogException: org.osgi.framework.BundleException: Unresolved constraint in bundle com.oracle.roo.jdbc.ojdbc5
[66]: Unable to resolve 66.0: missing requirement [66.0] package; (package=com.sun.security.auth.module)
at org.apache.felix.framework.Felix.resolveBundle(Felix.java:3409)
at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1594)
at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:904)
[... cont.]

In this second case, the bundle has an unsatisfied dependency on com.sun.security.auth.module

9. Go to the SpringSource Enterprise Bundle Repository website and search for your missing dependencies. Input the full package name of the missing dependency to do the search (in our example “javax.resource” and “com.sun.security.auth.module”; the second won’t give any result so keep on reading).

10. If you find the dependency, download it and install it as an OSGI bundle in Spring Roo (see 7). If you don’t find it, try to remove the dependency from the Imports entries in the Manifest: most of the times the Manifest generated from the “addon create wrapper” command is too verbose. It is the aggregated result of the inspection of the import statements and method signatures in all the classes of the provided jar that needs to be OSGIfied.

11. Remove the faulty OSGI driver from the Felix repository:
- Use “osgi ps” to retrieve the ID of the OSGI bundle to remove.
- Use “osgi headers” to get the Bundle-SymbolicName of the corresponding OSGI bundle. Probably “com.oracle.roo.jdbc.ojdbc5″ or “com.oracle.roo.jdbc.ojdbc6″.
- Use “osgi uninstall –bundleSymbolicName com.oracle.roo.jdbc.ojdbcx“

Atfer removing the faulty OSGI driver, repeat steps 7, 8, 9, 10 and 11 until it works.

Windows: find the location of the executables

After having answered this question for Linux/Unix, I have encountered the same need for Windows. This is what I have found.

Since Windows Server 2003 (including Vista and Windows 7), you can use the “where” command. Before Windows Server 2003 and since Win 98, this command can be installed via the various “Windows Resource Kit” packages.

If you have the excellent, albeit sometimes complex, Windows Powershell installed on your computer, you can also execute the “get-command” or its shorter “gcm” alias.

My colleague, Christian Baumann (@chrissbaumann), pointed me to a third option: it exists a native port of some GNU utilities to Windows, and it includes the “which” command: http://unxutils.sourceforge.net. However, the project doesn’t seem to be alive after 2003 and some commands in the package have issues, so while it’s a perfectly valid solution, in particular for Windows 2000/XP, I would caution a little bit its usage.

Continuous Integration

Continuous Integration

Linux: find the location of the executables

• How to locate the binary, source and/or man page files for a command?

$ whereis command

‘whereis’ has some options you can specify in order to limit the places to look at, or the type of files (binary, source, man page file, …etc).

The ‘whereis’ command returns all the places where the command can be found, looking into typical Unix locations. But, more frequently, you are just interested in finding where the commands you type on the command line are located on the filesystem, according to the $PATH variable.

• How to show the path of a command?

$ which command

Without parameter, it stops on the first command found in the path. If you want to list all the locations of the command in the path, you can call it with the -a option.

I encourage you to browse the man pages if you want a detailed description of these commands.

Maven: check what it really executes

 

 

 

• How to aggregate your pom?

Sometimes, the need arises to debug a pom file and then you want to have a clear idea of what Maven really executes. This command shows your pom file after the inheritance, profiles and variable substitutions have been applied.

mvn help:effective-pom

• How to aggregate your settings?

There is a similar command for the settings.xml file.

mvn help:effective-settings

• How to list the profiles that are activated?

mvn help:active-profiles

This command is particularly useful to check the profiles activated by default, when using the -P option, when using an environment variable, or any combination of these like in the following example:

mvn -Denv_variable=value help:active-profiles -P profileToActivate

The Destructive Programming Manifesto

 

 

This is a repost of the original text in case it would disappear from Pen.io

We are programmers. We strive to write good code.
We acknowledge that efficient code is often locally unclear.
We cannot stand writing more comments than code to document our hacks. We would rather not have to fix code we wrote ages ago.
We are sick of trying to decipher code others wrote.

Hence, this is how we work:
We write code as small self-contained blocks with well-defined interfaces.
Sometimes, we use software techniques to enforce them.
When a block is inefficient or behaves incorrectly, we do not read its code.
We re-implement it. Because it’s faster. And because it gives us fewer headaches.