Controlling the screen resolution of a Windows Guest in VirtualBox

Now I wanted to create another screencast for Package Drone and stumbled over the same issue again. Time to document it ;-)

VirtualBox with the Windows Guest drivers installed allows for any screen resolution which you could ever think of. Just resize the guest window and the screen resolution of the guest system will adapt.

But what if you want to set a specific screen resolution, pixel perfect?! Windows allows you to change the screen resolution but does not allow you to enter width and height. You are stuck with a slider of presets.

Googling around you will find the idea of adding a custom screen resolution to that selection. However, it seems that for some users this works, for others it doesn’t. I am one of the latter users.

But there is simple command which will tells your guest session to change to a specific resolution, directly from the command line:

VBoxManage controlvm "My virtual machine" setvideomodehint 1280 720 32

This will tell the currently running virtual machine to change resolution to 1280×720 at 32bit.

Maven basic authentication fails

While working on Package Drone, I stumbled over an interesting issue.

Deploying to Package Drone using Maven requires a deploy key. A random token, generated by the server which has to be used as either username or password on the basic authentication process of HTTP.

This worked fine as long as I started “maven deploy” from inside the Eclipse IDE. Starting “maven deploy” using the external maven installation or from the command line caused:

Caused by: org.apache.maven.wagon.TransferFailedException: Failed to transfer file: http://localhost:8080/maven/m2test/de/dentrassi/test/felixtest1/0.0.1-SNAPSHOT/felixtest1-0.0.1-20150217.162541-1.jar. Return code is: 401, ReasonPhrase: Unauthorized.

Although I did configure Maven to use the correct credentials in the “settings.xml” file:

…
<server>
  <username></username>
  <password>abc123</password>
  <id>pdrone.test</id>
</server>
…

After several hours of googling, source code reading and debugging maven it was actually pretty easy.

First of all, the embedded Maven instance in Eclipse uses “AetherRepositoryConnector” instead of “BasicRepositoryConnector” for accessing repositories. “Aether” simply takes the username and password values, as provided, and uses them.

The “BasicRepositoryConnector” however decided that an empty username (or an empty password) is not good at all and simply dropped the whole configuration without warning.

So in the end, introducing a dummy user name did the trick.

Package Drone 0.0.6

Here is another release of Package Drone – 0.0.6!

Be sure to check out the most recent release on github.

The main changes are:

  • Add automated tests using Selenium WebDriver
  • Create a build system using Maven Tycho
  • Create start scripts for SystemD and Upstart
  • Create .deb and .rpm packages for Ubuntu 14.04 (Mint 17) and CentOS 7 (RHEL 7).
  • Provide APT and YUM repositories at http://repo.dentrassi.de

So this release was more about build, stability and ease of installation. That is why there are also no screenshots this time ;-)

Package Drone 0.0.5

I am happy to announce yet another version of Package Drone – 0.0.5.

Be sure to check out the most recent release on github.

The main changes are:

  • Switch from Pure CSS to Bootstrap
  • Clean up the UI
  • Add channel level meta data and channel aggregators

Also a few bugs where fixed. Sadly in 0.0.4 there was a bug which prevented the schema creation to fail. This one is fixed in the 0.0.5 release.

Screenshots

Package Drone 0.0.4

I am happy to announce that package drone 0.0.4 is released.

Be sure to check out the most recent release.

The new features are:

  • Support for OSGi R5 XML repository index
  • Create Eclipse source bundles from Maven source attachments
  • Manage database structure from within package drone (nor more command line SQL)

See the full release information at github.

Especially the OSGi R5 repository support allows a few more use cases, like letting Bndtools consume artifacts from a P2 build, PDE or Tycho.

Eclipse theme after Linux Mint Upgrade

A while ago I wrote about a theming issue with Linux Mint and Eclipse. It took a while longer than expected, but the change finally made it into Linux Mint in version 17.1.

However, starting with Linux Mint 17, there seems to be a new issue. Not that dramatic like the old one, but still somewhat annoying. The default Linux Mint theme (Mint-X) chooses a light gray base color value as a background. This might look nice in most applications, however the mixture of Eclipses (E4) recent approach to create its own theming over the operating system, somewhat collides with that.

Text editors and the tree view inherit a light gray background from the operating system theme, while other Eclipse background elements stay white.

There seems to be a simple fix for that however. Edit the file /usr/share/themes/Mint-X/gtk-2.0/gtkrc and change the first real line from:

gtk_color_scheme = "bg_color:#d6d6d6\nselected_bg_color:#9ab87c\nbase_color:#F7F7F7" # Background, base.

to:

gtk_color_scheme = "bg_color:#d6d6d6\nselected_bg_color:#9ab87c\nbase_color:#FFFFFF" # Background, base.

However, and that is why I stumbled over this after the upgrade to Mint 17.1, this change will be overridden after an upgrade of the theme package. This never happened one in version 17, but you never know.

Note: It is also interesting that Eclipse/SWT seems to use GTK 2 instead of GTK 3. If you have some information in that, please drop me a line!