Author Archives: Lorenzo Bettini

About Lorenzo Bettini

Lorenzo Bettini is an Associate Professor in Computer Science at the Dipartimento di Statistica, Informatica, Applicazioni "Giuseppe Parenti", Università di Firenze, Italy. Previously, he was a researcher in Computer Science at Dipartimento di Informatica, Università di Torino, Italy. He has a Masters Degree summa cum laude in Computer Science (Università di Firenze) and a PhD in "Logics and Theoretical Computer Science" (Università di Siena). His research interests cover design, theory, and the implementation of statically typed programming languages and Domain Specific Languages. He is also the author of about 90 research papers published in international conferences and international journals.

A first look at Fedora 40 Sway

3 Replies

I started to look at the Window Manager Sway. Hopefully, in the future, I’ll post more articles on that.

In the meantime, I looked at the Fedora Sway spin (the current version is 40) and will briefly comment on that in this post.

The live environment already provides a Sway window manager and leaves documentation about how to start programs, especially the installer:

Let’s follow the suggestion and select the installer:

The installer is the usual Fedora one:

However, the next part is different from what I have always seen in a Fedora installation, at least the default Gnome one: you have more things to set:

I won’t show the other installation parts since they are standard in Fedora installation. I went with the defaults because I’m trying that in a virtual machine, so I’ll stick with the default partitioning scheme.

After the installation is concluded, let’s restart, and here’s the greeting login screen:

And once you log in:

No more help message: you’re on your own 😉

Probably, a basic knowledge of Sway is required and assumed.

At least, you may remember the SUPER + d shortcut to open the application launcher, and you can run something from there.

It’s better if you know about the basic shortcuts, which are the Sway default in this installation:

  • SUPER+SHIFT+Q: close the current window
  • SUPER+ENTER: run the default terminal, which here is “foot”
  • SUPER+SHIFT+C: reload Sway

The look and feel of the installed and configured Sway is nice; the “Waybar” is configured with a few helpful information. You have the tray icon (on the right) for network connections—the volume control opens a dialog to configure the volume and microphone. Moreover, media keys are already configured. For example, the ones for volume, and you have a visual feedback:

A few screenshot key bindings are also configured:

# Capture the currently active output
Print
# Capture the currently active window
Alt+Print
# Select and capture a custom rectangular area
Ctrl+Print

However, you have no visual feedback for such features; more effort could have been made.

Software-wise, you don’t have much installed: you have Thunar as a file manager but no text editor, for example.

The disappointing part is the configuration of Sway: you might expect you have everything already created in the “~/.config” subdirectories, following the standard Sway and other application structures. Unfortunately, it’s not like that: you have nothing in your home directory in that respect. Everything is configured system-wide. Of course, you can customize everything, but you must go through the documentation: https://docs.fedoraproject.org/en-US/fedora-sericea/configuration-guide/.

Several precedence rules are documented in the link, but I find that mechanism quite cumbersome. There are configuration files spread in many places:

You have to add additional files to your home folder or completely override a configuration file with one with the same name in your configuration folder.

I’ve just started experimenting with Sway; such a mechanism is hard to grasp and use.

For example, the installation procedure completely forgot the “Italian” layout I specified for the keyboard! There’s no “~/.config/swat/config” file to modify quickly. Should I copy the default one there and modify it; however, the part about the keyboard layout is not even commented on.

After reading the documentation, I came up with this (the configuration file’s name is my own; I haven’t followed a pattern; the important thing is the directory where the “.conf” file is):

Then, I reloaded Sway with SUPER+SHIFT+C and got the Italian keyboard layout.

But it wasn’t easy…

In general, I had the impression that Fedora Sway is not for beginners of Sway; however, it doesn’t seem to be for Sway experts either: they’d expect to customize Sway as they see fit anyway, and probably they have their dotfiles ready to be used.

However, maybe Fedora Sway is not bad for starting to experiment with Sway in the end. 🙂

Environment Variables in Sway

Leave a reply

Setting environment variables in Hyprland is easy: just put them in its config file. Setting environment variables in Sway is a bit harder, and there seems to be some confusion. The documentation is unclear about that, at least in my humble opinion.

This blog post documents my way of setting environment variables in Sway.

Let’s install qt6ct for some experiments.

If we run it, we get the following problem:

Where can environment variables be specified when using Sway?

In my experiments, “~/.profile” is not loaded (either when logging in or using SDDM). Instead, “~/.bash_profile” and “~/.zshenv” should be used for BASH and ZSH, respectively.

So, in those files, source “~/.profile” explicitly

Let’s put the environment variable declaration and export into “~/.profile”

Exit Sway and get back in, and now qt6ct is happy:

If we want also to have our environment variables available to systemd, we can follow another strategy to specify environment variables in one place.

First of all, let’s create a file (or any, if you want to have several environment variables categorized in different files) that ends with “.conf” in the directory “~/.config/environment.d/”.

For example, I have “~/.config/environment.d/10-env.conf” (these files are read by systemd alphabetically); I move the environment variable definition in this file (so, I remove it from “~/.profile”):

Note that in this file, you only have to use the syntax “key=value” (to see the full syntax: https://www.freedesktop.org/software/systemd/man/latest/environment.d.html)

Each time you modify that directory, you have to run this command:

To verify that systemd read this file, run

And you should see the line:

If you restart Sway and run qt6ct, you will see that qt6ct complains again. The environment variable is only visible to the systemd. We have to export the variables read by systemd.

To avoid duplication, we can use the program “/usr/lib/systemd/user-environment-generators/30-systemd-environment-d-generator”, which does precisely that (of course, it handles all the environment variables in the “.conf” files in the environment.d directory). In “~/.profile” we now put this line:

Restart Sway and run qt6ct, and now everything went back to work!

You can also open a terminal from Sway and verify the environment variable is there!

I hope you find this blog post helpful 🙂

Modifier-only shortcuts in KDE Plasma 6.1

Leave a reply

Before KDE Plasma 6.1 (released a few days ago and already available in Arch), if you wanted to configure a “modifer-only” shortcut (e.g., SUPER key, also known as META, to activate the “Overview” effect), you had to manually modify the “~/.config/kwinrc” file and add these lines:

Another example is if you wanted the SUPER key to activate the “Present Windows” (AKA “Expose”) effect:

In Plasma 6.1, modifier-only shortcuts must not be specified in “~/.config/kwinrc”: they are in “~/.config/kglobalshortcutsrc” and, as such, can be visually specified through the standard KDE shortcut system settings:

By default, SUPER is configured to start the “Application Launcher” (this means that previous specifications in “ModifierOnlyShortcuts” in “~/.config/kwinrc” are not considered anymore).

If we want to assign it to “Overview”, we first search for current shortcuts for “Overview”:

Click on “Add custom shortcut” and press SUPER. You are notified about an existing binding for the “Meta” key:

And, of course, we choose to reassign it.

Done!

Thus, such a setting will be stored in “~/.config/kglobalshortcutsrc”:

Nice feature, though it breaks existing configurations, which need to be adapted 😉

KDE theming and styling in Hyprland

5 Replies

Recently, I blogged about using KDE applications in Hyprland.

But what about theming and styling them?

I’ll show how to do that in this blog post, assuming you’ve already installed a few KDE applications, like Dolphin, Konsole, and Kate (see the above-linked blog post).

WARNING: the strategy shown in this post is not optimal, in my humble opinion. There’s a more recent post where I show a better strategy (in my opinion).

As in all my Hyprland posts, this is based on Arch Linux; I mainly use EndeavourOS.

Let’s install a few packages:

The crucial ones are the “qt5ct” and “qt6ct” packages. We’ll use the latter but also install the former for possible old Qt 5 applications, just in case. The “Hack” font is the standard KDE monospace font, and Kvantum is the theme engine.

Then, we have to set this environment variable in “~/.config/hypr/hyprland.conf” (note that we specify qt5ct, but for Qt 6 applications, qt6ct will be used automatically):

Let’s restart Hyprland (I’m assuming “env = QT_QPA_PLATFORM,wayland” is also set).

That’s the standard style of Dolphin, Kate, and Konsole with the default settings:

Let’s open the “Qt6 Settings” application (corresponding to “qt6ct”).

Remember that Qt6 settings will be stored in the file “~/.config/qt6ct/qt6ct.conf”.

First of all, I’m changing the fonts to match the standard ones of KDE:

Remember always to click “Apply” after changing something”.

By restarting the above applications, the fonts now look like in a standard KDE system:

Let’s try to change the appearance colors to a darker setting in the palette:

Unfortunately, the result is a small disaster:

Dolphin is the only application that reacted to the change but in a wrong way.

Instead, let’s revert to the default palette and change the Style to Kvantum (“kvantum-dark”):

The result is improving:

However, it’s still ugly: the icons are mostly invisible, and the Konsole menu bar does not like this change.

Let’s fix the icons first: we select “Breeze Dark.” (Remember: We installed them at the beginning.)

The result has improved: icons are better visible, and in Dolphin, folder icons all look fine:

The rest of the ugly look is due to the default Kvantum theme.

So, from now on, we can try to select a Kvantum theme that makes the KDE applications look nice.

Let’s open Kvantum (“Kvantum Manager”) and try with another theme, e.g. “KvAdaptaDark”:

Now KDE applications look better:

Unfortunately, there’s a white bar in Konsole.

Moreover, Kate does not use the dark settings for the editor. However, Kate allows you to select a color scheme:

For example, by selecting “KvAdaptaDark” here as well, we get a nice-looking Kate:

Remember that Kvantum settings will be stored in the file “~/.config/Kvantum/kvantum.kvconfig”.

Now, you can experiment with other Kvantum themes.

For example, this is “KvArcDark”, which still has problems with Konsole menus:

Or “KvGnomeDark”, which doesn’t look bad after all (probably it’s the best up to now: we don’t even have the white bar in Konsole):

You can further tweak each Kvantum theme and change other settings in qt6ct.

In particular, you can install other icon packages and select another icon set in qt6ct.

Stay tuned for another post for styling Qt and KDE applications.

The new Xbase JvmGenericTypeValidator in Xtext

Leave a reply

The new release of Xtext 2.35.0 comes with many new cool features. I personally worked on the introduction of the JvmGenericTypeValidator.

Quoting from the release notes:

Automatic validation for Xbase languages

The new JvmGenericTypeValidator was introduced to automatically perform several Java-related checks in the hierarchy of the inferred JvmGenericTypes of an Xbase language, with the corresponding error reporting.
For example, cycles in a hierarchy, extension of a final class, proper extension of an abstract class (do you implement all the abstract methods or declare the inferred class as abstract?), proper method overriding, etc. It also performs duplicate elements checks, like duplicate parameter names, duplicate fields and duplicate methods (keeping the type-erasure into consideration when using types with arguments).

This mechanism assumes that you implement the JvmModelInferrer “correctly”.
It only checks the first inferred JvmGenericType for the same DSL element (i.e., if for an element Entity you infer two JvmGenericTypes, t1 and t2, only the first one will be checked).
Moreover, it only checks Jvm model elements with an associated source element.
Concerning intended classes to extend and interfaces to extend/implement, it assumes the model inferrer uses the new JvmTypesBuilder#setSuperClass(JvmDeclaredType, JvmTypeReference) and JvmTypesBuilder#addSuperInterface(JvmDeclaredType, JvmTypeReference), respectively.

Currently, this validator must be enabled explicitly through the composedCheck in the MWE2 file or the @ComposedChecks annotation in the validator, e.g., @ComposedChecks(validators = JvmGenericTypeValidator.class).

The Domainmodel example now uses this validator.
The Xtend validator has been refactored to also use this validator.

This means that if you implement your model inferrer “correctly” and enable this validator, you get lots of valuable checks, which you would usually have to implement yourself (if you ever did that).

Let’s see that in action in the Domainmodel example (you can materialize that in your workspace through the Xtext wizard).

The example used in this tutorial can be found online at https://github.com/LorenzoBettini/jvm-generic-type-validator-example. Remember that if you clone the example from GitHub, you’ll have to run the MWE2 workflow after importing the projects.

As reported in the release notes, the Domainmodel validator already uses the JvmGenericTypeValidator:

Moreover, its model inferrer uses the above-mentioned API in JvmTypesBuilder for specifying the expected superclass, if present (note that setSuperClass is used here as an Xtend extension method and uses the syntactic sugar for setter):

Let’s start another Eclipse instance (in the GitHub project, you can use the launch “/org.eclipse.xtext.example.domainmodel.ui/Domainmodel Eclipse.launch”).

Let’s create an Eclipse plug-in project; in the MANIFEST, let’s add the Xbase lib as a dependency, and in the “src” folder, we create a file “Example.dmodel”, accepting to convert the project to an Xtext project.

Let’s start with a method with two parameters with the same name and see the reported error:

Let’s add two methods with the same name and a parameter but with the same type-erasure in the generic type:

Remember using setSuperClass to express that the extended class must be a class, not an interface? Let’s see that in action:

And don’t try to extend a final class 😉

Let’s see what happens if you try to extend an abstract class without defining all the abstract methods (remember that in the Domainmodel, all entities are mapped to concrete Java classes):

Of course, the error goes away if you implement the abstract methods:

Before going on, remember that implementing these validation checks manually is not trivial: you have to consider type-erasure and inherited methods. You get them for free thanks to the JvmGenericTypeValidator 🙂

Note that the error about missing implemented abstract methods, as the one above, contains information (i.e., in Xtext, “issue data”) about the missing methods, their types, and parameters. Thus, you could implement a quickfix to add the implementation methods automatically. This is not trivial, but it’s doable with the provided information. You might want to take inspiration from what Xtend does (remember that now Xtend uses the JvmGenericTypeValidator).

Let’s extend the Domainmodel a bit:

  • we add the optional “abstract” keyword for entities
  • we add the “implements” interfaces feature

These are the relevant parts in the modified grammar:

Let’s run MWE2 to regenerate the language, and let’s adapt the model inferrer accordingly (note the use of the new method JvmTypesBuilder.addSuperInterface; this method should also be used in the case your Xbase DSL has elements that are mapped to interfaces extending other interfaces):

Let’s restart the running Eclipse and see the new features in action, according to checks automatically performed by the JvmGenericTypeValidator.

For example, similarly to extended classes, we have the check for implemented interfaces:

Moreover, declaring a mapped Java class as abstract is taken into consideration: now we don’t have errors anymore with an abstract entity:

And, of course, mapped implemented interfaces are considered when checking whether a concrete class implements all the abstract methods:

Speaking of quickfixes, we can create a quickfix that intercepts the problem of a concrete entity missing implemented methods to turn the entity into an abstract one:

Let’s restart Eclipse and see the quickfix in action:

Unfortunately, as implemented, the semantic model quickfix leaves the resulting program text poorly formatted.

This version works fine, though it requires manual modification of the textual file:

Here’s the result after applying the quickfix:

Other features not shown in this blog post and not implemented by the Domainmodel example are related to declared thrown exceptions in operations. The JvmGenericTypeValidator will check that the thrown exceptions are correct in the case of overridden methods, according to the Java semantics.

Note that the JvmGenericTypeValidator can be customized if needed. For example, Xtend customizes it.

On a side note, while I took care of implementing and testing the JvmGenericTypeValidator and refactoring Xtend validation accordingly, most of the code extracted in JvmGenericTypeValidator comes from the original implementation in the XtendValidator made by Sebastian Zarnekow!

Happy validation-made-easy! 🙂

Customizing Grub during the EndeavourOS installation

Leave a reply

I typically have several EndeavourOS installations on my computers: one for KDE, one for Hyprland, etc. Thus, I want to have different UEFI entries, but they would all have “endeavouros”, each overriding the others.

You can change the grub ID later by issuing a proper “grub-install” program from the running system or by booting it with the live ISO and then chrooting it.

Why not specify a different grub ID during the installation?

It’s easy to do so:

  • Once you boot the live ISO, before starting the installation, open a terminal (in the current version, the live environment is KDE, so you open Konsole);
  • Open the file “/etc/calamares/modules/bootloader.conf” with an editor (e.g., “sudo nano /etc/calamares/modules/bootloader.conf”; you need sudo but no password in the live environment);
  • Look for the line (near the end):

    and change it to a different string (e.g., “eos-kde” when you install KDE, “eos-gnome” when you install GNOME, etc.);
  • Save the file and go on with the installation as usual!

Now, each installation will have a separate and different grub id.

Fixing the empty “open with” in Dolphin in Hyprland

13 Replies

I have already blogged about KDE applications in Hyprland.

However, with the latest updates, things broke a bit especially with Dolphin, which does not recognize file associations anymore: double-clicking on a file always shows this empty menu, as if it could not find any associations for any file:

On the Arch forum that has already been reported and claimed as solved: https://bbs.archlinux.org/viewtopic.php?pid=2167442. However, the reported solution only temporarily solves the problem, at least in Hyprland.

The steps to solve the problem and make it permanent are the following:

Install this package:

Check that it works by running:

Now, if you run Dolphin you should be able to open the files again.

However, as soon as you install/update KDE packages, the problem shows up again. To solve this permanently, add this line in the file “~/.config/hypr/hyprland.conf”:

Exit Hyprland and get back in.

Now the problem should be solved for good! 🙂

Dual boot in a KVM Virtual Machine

Leave a reply

If you want to experiment with multi-booting in Linux (for example, see this other post), you might want to consider experimenting with a virtual machine.

In this blog post, I’ll show you how to install two Linux distributions on the same KVM virtual machine.

I’ll use Fedora 40 and EndeavourOS Gemini. Make sure you download their ISOs.

Let’s create the virtual machine:

You need to specify enough space for the storage for two Linux distributions.

Of course, I’m going to use UEFI:

And 3d acceleration:

Let’s start the installation of Fedora:

I’m going to use manual partitioning, e.g., in Fedora, the only usable tool I can think of: Blivet-GUI:

I’m creating the partition for UEFI:

And the partition for the main system. Although I could choose the entire disk, and then resize it later when installing EndeavourOS, let’s make things simpler and only use half of the space of the VM’s disk:

We can continue the installation til the end.

Restart the virtual machine and finalize the Fedora installation.

Shut down the virtual machine.

You might want to create a snapshot in case you want to return to this step.

Now, we must configure the virtual machine to give precedence to the CD ROM as a boot device and “insert” in the CD drive the ISO of EndeavourOS Gemini (see my review).

Let’s edit its “Details” accordingly:

First, enable “SATA CDROM 1” and move it up in order:

Then, load the ISO in the SATA CDROM 1:

Let’s start the virtual machine, which will now boot from the EndeavourOS Live ISO:

Now, we can install EndeavourOS Gemini (see my review). The critical part are choosing GRUB:

And the partitioning: we must choose manual partitioning:

Now, we must mount the existing EFI partition (the one we created during the Fedora installation above) as “/boot/efi”

And allocate the rest of the free space to EndeavourOS (I choose BTRFS here); if you want to add another installation later, you might want to leave some free space.

Here’s the result:

You then get a warning about the EFI partition expected to be FAT32, while Fedora created it as FAT16, but you can ignore it: the installation will succeed anyway:

That’s the summary:

Let’s conclude the installation.

At the end of the installation, instead of “restart”, shut the machine down.

In fact, we have to “virtually” remove the CD ROM as the first boot media; otherwise, the virtual machine will always boot from the ISO (you can also remove the ISO from the virtual CD ROM). We basically revert the operations we performed before installing EndeavourOS:

Now, the EndeavourOS GRUB menu will appear instead of the Fedora one:

Let’s boot into it and make sure everything works.

Now, let’s reboot the virtual machine; this time, we select the “UEFI Firmware Settings” in the GRUB menu:

And we’re into the “Tiano” UEFI:

By selecting “Boot Manager”, we access the list of available UEFI entries:

We can select “Fedora”, now in the second position, and temporarily boot that.

Alternatively, we can change the boot order:

That’all! Now, you can experiment with multi-booting.

Happy “virtual” multi-booting! 😉

Disabling tracker-extract in Gnome 46

Leave a reply

I like the tracker service in Gnome, which indexes files so that you can easily search for them from the Activity view or the file manager. However, I don’t like tracker-extract, which also indexes the file contents: I use Recoll for such a service, and tracker-extract uses too much CPU (it indexes new or modified files as you create/change them).

In the past, up to Gnome 45, I could disable tracker-extract only with

However, in Gnome 46, that service has gone, so tracker extract always runs, and I couldn’t find a way to disable it. I discovered it when I upgraded to Fedora 40 or EndeavourOS, which both provide Gnome 46. I bet it will be the same for Ubuntu 24.04.

Luckily, I found help on the Gnome discourse forum: https://discourse.gnome.org/t/can-tracker-extract-be-disabled-in-gnome-46/20782.

There’s no supported way to disable tracker-extract, but I was suggested to simply wipe the tracker-extract rules from “/usr/share/tracker3-miners/extract-rules/”.

For example,

If you want to keep a backup, you might want to move those files somewhere.

That works!

But be warned: as soon as tracker-extract is updated to a new version, those files will show up again, and you’ll have to remove them again. Possibly, before logging into Gnome, to avoid that tracker-extract starts eating your CPU.

In the meantime, I also created this issue for Gnome: https://gitlab.gnome.org/GNOME/tracker-miners/-/issues/342.

Getting started with Rust with Visual Studio Code

Leave a reply

I started learning Rust, and I found Visual Studio Code an excellent IDE for experimenting with Rust (in the future, I’ll also evaluate my beloved Eclipse).

I thought I’d share this experience.

Assuming you have already installed Rust, let’s create a project

Open Visual Studio Code in the “hello” directory

We get syntax highlighting for the Rust source but nothing more:

Let’s install the “Rust Extension Pack”, which includes several Rust-related plugins:

Returning to our Rust project, we can see that the “target” folder has been created with compiled binaries, thanks to the installed extension:

Moreover, we now have the code lens to run our Rust program in the Rust editor. And we also have hovering (and, of course, code completion!):

Moreover, we also get live validation in the editor with possible error markers and quickfixes when available.

Let’s run our Rust program and see the output (after compilation) in the Console:

Let’s try to debug it, and we get a message telling us to install another extension:

Let’s go with CodeLLB:

And here we are: I set a breakpoint, and the debugger correctly stopped there:

Happy learning and coding with Rust! 😉

EndeavourOS Gemini

3 Replies

I haven’t blogged about the EndeavourOS installation for a while.

Let’s have a look at the new EndeavourOS Gemini. I’m going to install it into a KVM virtual machine.

The installer now features KDE Plasma instead of Xfce as in the past (and the Arm installer has been removed, unfortunately):

As usual, I update the mirrors through the Welcome app; note that you also have the partition manager if you want to partition in advance. I’ll use the partition program during the installation.

Let’s start the installer; I choose “Online” because I want to install GNOME:

The installer is still the good Calamares:

In that respect, nothing has changed since the last time I used that. It has been a bit polished and uses the KDE dark theme. The following steps are as usual:

As I said, I’ll go for GNOME:

Then, you can refine the package selection; note that for GNOME, there are a few small customizations implemented by EndeavourOS, but if you scroll down, you can also go for a Vanilla GNOME:

By default, the most interesting applications are already selected:

As for the boot loader, the default is systemd-boot, but I prefer the good ol’ grub:

Since I’m testing this in a virtual machine, I’ll have the partitioner erase the whole disk, but you can always opt for manual partitioning:

Time to insert the user information, a quick recap, and then the installation starts with the usual slide show:

And we’re done: ready to reboot into the installed system:

Here’s the installed system:

Remember that GNOME defaults to Wayland (it’s been like that for a few years now):

Now that we’re in the installed system, thanks to the automatically installed spice agent, I can scale the virtual machine:

(I had to install Neofetch; I remember that it was automatically installed in the past.) We have GNOME 46.1 (at the time of writing):

“Gnome Tweaks” has already been installed, so a few aspects of GNOME can be easily customized.

Firefox is there, but as in the past, you must install Thunderbird (same for LibreOffice).

Concerning the theme, EndeavourOS uses “Qogir” for the cursor and icons, which look very nice.

Note that the tracker3-miners package is not installed by default, so “Search Locations” is disabled:

I use Tracker often, and it might be a bit confusing not to install this component by default. On the other hand, if not configured correctly, Tracker becomes a resource hog, so EndeavourOS’ choice might be a good one.

As usual, EndeavourOS proved to be an awesome Arch Linux experience! Very well done!

Now it’s time to run my Ansible playbook to install and configure Gnome 🙂

Installing Amarok in Fedora Linux

Leave a reply

I have always liked Amarok, the (initially) default KDE media player. It’s very feature-rich, nothing compared to Elisa. Moreover, it has two crucial features that I haven’t found in any other players:

  • it saves statistics (play count and stars) directly into the music file
  • it synchronizes statistics with the iPod.

I have always liked Amarok, the (initially) default KDE media player, and I have already blogged on installing it in Arch Linux.

Fedora always provided an old version of Amarok in its repositories. Recently, they started to provide an up-to-date version as a Flatpak application from their Flatpak repository, which should be automatically enabled:

You can also find it from the command line;

Let’s install it either from the Gnome Software dialog shown above or from the command line:

It’s also best to install Flatseal for configuring the flatpak application permission (it’s available both from the Fedora flatpak repository or from the standard Flathub, in case you configured that as well):

Let’s start Flatseal and check the Amarok permissions. Some settings are already configured to allow Amarok access to a few standard directories and databases. In my case, I also configure the access to all my files and a mount point because I have my music stored on an external drive, which I mount at that mount point “/media/bettini/backuplinux”):

You can now start Amarok either from the Gnome menu or from the command like:

IMPORTANT: The flatpak version of Amarok stores its files in

instead of the standard directories “.config” and “.local”.

If you want to connect your IPOD, first you must ensure that the “libgpod” package is installed, and then you have to add the permission access in Flatseal to the mount point of your IPOD. Otherwise, Amarok will detect your iPod but as a non-initialized one because it cannot access its contents:

If the flatseal permissions are set correctly, you can also enjoy your iPod from Amarok!

Enjoy your music! 🙂

Getting Started with Gnome Boxes

2 Replies

Gnome Boxes is meant to be an easy and quick-starting software for Qemu virtual machines.

I have already blogged about Qemu with KVM Virtual Machine Manager. These tools are powerful but require time to get familiar with them and tweak them correctly (I tried to provide some hints in my previous posts about these tools).

Today, I’ll write about Gnome Boxes. It is effectively easier than the above tools, and since it’s based on Qemu, the created virtual machines can be used by virt-manager and vice-versa (more on that at the end of the post).

I will use the version of Gnome Boxes that comes installed by default in Fedora 39.

The first time you start it, you’re greeted by a few introductory pictures about its main features:

Concerning “Expression Installation”, I still haven’t tried that, but I’m not interested in that feature either.

This “Easy Downloads” is an excellent feature that I’ll use for the supported OSes. In that respect, Quickemu provides many more supported systems. For example, Gnome Boxes does not provide an easy download for my favorite distro, EndeavourOS.

That is also an excellent feature that worked in all my experiments.

Here’s the main interface, which, like many Gnome software, is minimal: you have the “+” toolbar icon on the left-most corner to create a new virtual machine, either by an existing ISO file (or even existing .qcow2 machine, which I’ve never tested) or by downloading one of the supported ISOs.

Let’s start installing a few virtual machines and see how it goes.

Installing Fedora 39

I’ll use the option to download Fedora Workstation 39 directly from Boxes (you have to wait a few seconds for the list to get populated):

See the download feedback on the other side of the window. You might want to explore those menus, especially when a virtual machine has started.

The ISO will be saved in your “Downloads” folder when finished.

Then, the main dialog for configuring the virtual machines appears; these are the default settings:

I changed the Firmware to UEFI and gave more RAM and disk to the machine (remember that the machine is saved on a qcow file, so its effective disk occupation is not the effective size of the file: only the real occupied space is used on your hard disk):

Let’s press “Create,” and the VM is started.

Take note of the following shortcut:

REMEMBER: you can use left Ctrl + Alt to “ungrab” the keyboard from/to the virtual machine/your host (or click on anything on your host desktop if you don’t have Gnome Boxes full screen).

Now, you can install Fedora as usual (I’m not covering this here).

While waiting for the installation to finish, you might want to take note of the menus in the top-right corner, available when a virtual machine is in execution, to send special key combinations to the virtual machine…

… or for other tasks.

Once the installation has finished, you can restart the virtual machine, e.g., using the Gnome menu.

Note that when a virtual machine is running, you can see its executing thumbnail in the main Gnome Boxes window:

Click on that to see the virtual machine itself.

Note that since “spice agent” is automatically installed when installing Fedora (it detects you’re installing it on a virtual machine), the virtual machine screen is automatically resized and scaled according to the size of the Gnome Boxes window. For example, this is the Gnome Boxes window full screen:

and this when slightly resized as smaller (not how the virtual machine desktop has been automatically resized):

You have bidirectional copy-and-paste from the virtual machine and the host and vice-versa.

You can also drag some files (not directories) from the host to the virtual machine: in the virtual machine, they will appear in the “Downloads” folder.

Let’s shut down the machine, right-click on its icon in the Gnome Boxes window, and explore its “Preferences” (note that you can also create a full clone of the virtual machine):

In the “Resources” tab, I can enable 3D acceleration so the virtual machine will use my computer’s graphical card instead of relying on “Software rendering.” This will allow you to have fluid and smooth 3d effects in the virtual machine desktop environments.

Then, we can share devices and folders with the machine (I’m not covering that; note that you must install additional software in the virtual machine; in the Fedora virtual machine, “spice-webdav” has already been installed):

Then, we have the tab to create snapshots of the machine for “going back in time” in the virtual machine (note that this is different from cloning, which will give a full and independent machine clone). For example, I create a snapshot and give it a meaningful description:

Remember that, later, if you restore a snapshot, you lose everything you’ve done in the virtual machine from when you created the snapshot.

NOTE: if you start the Fedora virtual machine after the first boot on the installed system, chances are that you will have to wait for it to download and install updates on the next boot.

With the 3d acceleration set, if we boot in the virtual machine, the Gnome effects will be enabled and fluid (depending on your host CPU and graphic card, of course). If we inspect the system details of the virtual machine through the Gnome “About,” we can see that the graphic card is Virgl. Without 3d acceleration, you would see “Software rendering”:

WARNING: in my experiments, starting the Fedora virtual machine with 3d acceleration sometimes hangs. I have to quit Gnome Boxes, reopen it, and then the machine correctly starts.

Installing EndeavourOS

As said above, this is not one of the ISO automatically downloadable, so I had first to download the ISO and then choose the other menu to start from an existing ISO:

Note that the “Operating System” must be specified: use the search box below to select the closest one, in this case, “Arch Linux”:

As before, I increased RAM and disk size.

In the first experiment, I selected “UEFI”, but then the virtual machine did not start at all due to a missing UEFI:

I did not investigate further… I deleted the virtual machine and started from scratch with the good old BIOS, and this time, the virtual machine started:

I then installed EndeavourOS GNOME, and after shutting the installed virtual machine, I could select “3D acceleration”.

EndeavourOS GNOME also works fine in the virtual machine: fluid 3d effects, automatic resolution resize, bidirectional shared clipboard, and drag and drop in the machine (the “spice agent” has also been automatically installed).

Unfortunately, the host touchpad scroll is not recognized in the virtual machine. Since it works in the Fedora and Ubuntu VM, I guess it’s just a problem with the new GNOME 46 version already landing in Arch.

Installing Ubuntu 23.10

Ubuntu 23.10 is one of the supported ISOs, so I let Gnome Boxes download the ISO for me, as I’ve done above for Fedora.

The initial configuration of the Virtual Machine is the same as that of Fedora.

I did the installation as usual and ensured the virtual machine boots correctly.

However, 3d acceleration is not available for Ubuntu. You can find many issues in that respect on the Gnome Boxes issue website, in particular, this one: https://gitlab.gnome.org/GNOME/gnome-boxes/-/issues/709; I seem to understand that’s an intentional choice because Ubuntu used to give problems when started with 3d acceleration.

And the system information in the virtual machine stays with “Software rendering”:

This means, of course, no fluid 3d effects 🙁

Accessing Boxes with Virtual Machine Manager

I’ve also installed “virt-manager” in my Fedora host.

You can access Gnome Boxes virtual machines with virt-manager if you want full configuration options. As you’ve seen, Gnome Boxes is all about simplicity and exposes a very limited number of configuration options for the Qemu virtual machines.

First, we must create a new “connection” in virt-manager: by default, virt-manager relies on a system session, while Gnome Boxes uses a user session. So, let’s open Virtual Machine Manager, select File > Add New Connection, and select user session in the “Hypervisor”:

After pressing “Connect,” we should see all the virtual machines we created with Gnome Boxes; in particular, I’m interested in the Ubuntu one:

Now, we can configure the machine using the full configuration options of virt-manager. Of course, I’m interested in enabling 3d, so first I set the “Spice” section as follows:

And then the video section accordingly:

And if I start the virtual machine from virt-manager, 3d acceleration works!

But… if I open the configured machine with Gnome Boxes, 3d acceleration will be automatically removed: Gnome Boxes automatically and silently revert the configuration since it insists on considering Ubuntu not compliant with 3d acceleration. You can verify that by reopening the machine details with virt-manager.

Summary

While it is true that Gnome Boxes is a very easy and quick solution for creating Qemu virtual machines with sensible defaults, it is still too rigid. It even resets your manual configurations if they don’t meet its expectations. If you’re already familiar with virt-manager, using Gnome Boxes might not be worthwhile unless for very quick experiments with the supported operating systems. However, I still prefer Gnome Boxes to Quickemu for the moment since at least a shared clipboard works while keeping good 3d acceleration performances (if supported). Quickemu forces you to choose one of the two.

Happy virtualization! 😉

Docker in Fedora 39

2 Replies

I haven’t been using Fedora for a few years but wanted to try it again (Fedora 39). In the past, I had a few problems with Docker in Fedora (see Fixing Docker problems in Fedora). Things are slightly improved, while others haven’t changed. For sure, I gave up using the official Docker command in Fedora: I’m using “moby-engine” instead of “docker-ce” and also “docker-compose“. In the past, Moby was mostly working out of the box, while Docker CE required a few tweaks. I don’t think it’s worthwhile insisting on tweaking it, so I’ll go straight with Moby.

This is a docker-compose file that gave me troubles in the past in Fedora:

Save it to “docker-compose.yaml” and run “docker-compose up,” and it works fine! (In the past, with Docker CE, this used to hang and eat all the memory).

Concerning the Testcontainers library, I’ll use this example project (taken from my TDD book): https://github.com/LorenzoBettini/it-docker-mongo-example. I run “mvn verify”.

When it comes to using Testcontainers, I get this error:

However, the error goes away if I update Testcontainers to a more recent version (previously, I was using 1.16.3):

So, that works!

Let’s try now by telling Docker to use another folder (for the images and containers) on another disk.

First, stop Docker

Then, change this file (remember, I’m using “moby-engine”, which uses this file with these contents) “/etc/sysconfig/docker”:

I’m adding this last line to point to a directory that mounts a partition on another disk:

And let’s reload Docker

Now, the “docker-compose.yaml” file above gives this error:

And the Maven project above fails with something like that:

This problem is due to SELinux (that figures!!!) If you temporarily disable SELinux:

Everything succeeds again!

Thus, Moby in Fedora 39 works out of the box with the default configuration. If you want images and containers in another mounted directory (not handled by Selinux), you must disable SELinux.

Better than nothing! 😉

xdg-desktop-portal-gnome strikes again!

2 Replies

I haven’t used Fedora for a few years but wanted to try it again (Fedora 39).

I was immediately hit by a problem, which is not due to Fedora itself, I seem to understand.

I’ll use this example project (taken from my TDD book): https://github.com/LorenzoBettini/demo-attsw. It is a simple Java Swing application where UI tests are written with AssertJ Swing. I run “mvn verify,” and most of the UI tests fail (when the AssertJ Swing bot tries to interact with the application window, it mostly gets the position wrong). Most of all, and this is the cause of the failure, I get this dialog popping up from Gnome “Allow remote interaction”:

Despite I click allow and share, the tests are still failing with the same behavior.

The problem of this dialog popping up, not related to UI tests, is already reported on the Fedora forum: https://discussion.fedoraproject.org/t/f39-opens-a-window-with-remote-desktop-allow-remote-interaction/100228. And the forum points in the right direction: the problem is related to xdg-desktop-portal-gnome! (https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/issues/114) This portal has already created several problems in the past, slowing down several applications. I hadn’t realized this was installed automatically in Fedora. By the way, xdg-desktop-portal-gtk is also installed, so I tried to remove the gnome version:

By the way, removing the package using “dnf” does not work because it complains that this is a requirement of “gnome-shell” (“Problem: The operation would result in removing the following protected packages: gnome-shell”).

After the removal, the dialog no longer popped up, and my UI tests are back to green! 🙂

Another solution to the problem, if you don’t want to remove the gnome portal package, is to log in to the X11 session instead of Wayland. But I prefer the more radical solution. 😉

Nerd Fonts in KDE Plasma 6

1 Reply

As I have written, I’m using “Oh-My-Zsh” with Nerd icons and fonts. It has always worked perfectly in KDE.

A few days ago, KDE Plasma 6 landed in Arch (and thus, EndeavourOS), and after upgrading, the Nerd fonts were not displayed in Konsole and Kate (and, I guess, in other KDE applications).

For example, before upgrading, Konsole looked like that:

After upgrading all the nice Nerd fonts were gone:

I reported that on the EndeavourOS forum and linked the corresponding KDE bug. It looks like it is due to an intentional change in Qt6. The Qt6 issue is https://bugreports.qt.io/browse/QTBUG-110502. The issue was fixed here: https://code.qt.io/cgit/qt/qtbase.git/commit/?id=a44b6950268214d802bc7ce7df09975261263e31, leading to this new behavior, which breaks the old behavior.

Long story short, before, when a font did not provide support for a “glyph”, that missing glyph was looked up in other fonts. After that change, that does not happen anymore.

The default monospace font in KDE is “Hack”. I have installed other Nerd fonts, but not the “Hack Nerd” version, so what worked before the upgrade no longer works.

To fix the problem, I Installed the nerd font, e.g., for Hack (the default KDE font):

Then, open “System Settings” -> “Fonts”, and change the “Fixed width” font from the default “Hack 10pt” to the corresponding Nerd font:

Restart Konsole and the Nerd fonts are back:

Note that this works if your Konsole profile does not have a custom font set; if you use another font, you’ll have to use the Nerd font corresponding to that font.

For example, I used JetBrains fonts in another Konsole profile, but I hadn’t installed the Nerd version:

I installed the Nerd version and changed the font from simply “JetBrains” to the Nerd version, and also, this profile was fixed:

The same holds for other KDE applications like Kate. If you haven’t set a custom font, then the Nerd version of Hack will be automatically used. Otherwise, you have to use the Nerd version of the specified font.

Note that other non-Qt applications will not be affected by this change. For example, for Alacritty, I have this section in its configuration:

So, I simply specify JetBrains, not its Nerd version. Still, when icons and other glyphs are to be rendered, they are automatically taken from any Nerd font providing those glyphs:

Good-looking Nerd fonts are back! 🙂

KDE Plasma 6 Desktop Cube in Arch Linux

Leave a reply

At last, KDE Plasma 6 has landed in Arch Linux (and in EndeavourOS, of course), and you’re eager to try the return of the desktop effect “Desktop Cube”! 🙂

You try to enable that in the System Settings “Desktop Effects.” You try the default shortcut “Meta + C”, and… it doesn’t work 🙁

Oh, they say you need at least 4 virtual desktops! So you make sure you have 4 virtual desktops, you try again, and… it still doesn’t work 🙁

Actually, 3 virtual desktops are enough. What you really need is this package, so make sure you install that and reboot:

Now, the Desktop Cube will finally work! 😀

Here’s that in action with 3 virtual desktops:

Here with 5 virtual desktops:

Useless but good looking! 😉

A quick look at Quickemu

1 Reply

I have already blogged in the past about kvm/qemu.

Using the “Virtual Machine Manager” might not be straightforward initially. I’ve heard about Quickemu, which has this goal:

Quickly create and run optimised Windows, macOS and Linux desktop virtual machines.

In this blog post, I’m describing my experience with quickemu in Arch. The package is available from AUR:

And you also need the package for Qemu desktop mechanisms:

Then, you use the program “quickget” to get the ISO of one of the many distributions handled by quickemu. Let’s run it without arguments:

Let’s try Zorin:

We also need to specify its version:

Now, it starts downloading into the current directory, creating a subdirectory. For example, I’m running that from a mounted drive. Here’s some output and some commands to show the layout of the directories and the created configuration file to start the virtual machine with the mounted ISO:

Let’s start it:

Note the layout after starting the machine:

Thus, it should be easy to put it on an external drive

Here’s the machine starting with the live ISO:

I pressed Ctrl+C to cancel md5sum checks.

Here’s Zorin starting (audio is working):

The screen had resized automatically and became bigger.

I started the installation, mainly choosing default options (e.g., erase the entire disk). And here’s the login screen after the installation finished and the machine rebooted:

The impressive thing is that animations are really fluid and smooth in the virtual machine: you almost don’t realize you’re using a virtual machine:

Here’s the disk layout and memory (on this computer, I have 16 GB, and quickemu automatically selected half the memory for the virtual machine):

Then, I tried Garuda:

I tried the “Garuda KDE Dr460nized”:

I edited the conf file to increase the disk size:

Let’s start it:

Even in this case, the desktop automatically resizes if I resize the Qemu window.

The installation went smoothly and fast in this case. The login screen is full of nice blurry effects:

On the first login, you’re welcomed by the Garuda assistant to perform some initial tasks.

Here’s the information about the installed system:

Animations and effects are smooth, e.g., the “Overview”:

To summarize, with quickemu, creating a new Qemu virtual machine is easy, starting from one of the many managed Linux distributions. It also works for macOS and Windows distributions, though I haven’t tried them.

Moreover, the performance of the virtual machine is fantastic. The virtual machine seems as smooth as the currently running system.

The only drawback I’ve experienced is that, with the default configuration, the shared clipboard does not work: you must start the virtual machine with the spice display (” –display spice”). For example,

Remember to install the spice agent in the virtual machine. In the two above examples I’ve tried, the installed virtual machine already has the agent installed automatically during the installation.

First, at least in my experiments, the shared clipboard does not work anyway when the host is running on a Wayland session. Moreover, using the “spice” display, the virtual machine’s performance decreases significantly (see my reported issue: https://github.com/quickemu-project/quickemu/issues/933). Probably, to easily communicate and paste commands in the virtual machine, it is better to install the SSH server in the virtual machine and connect to the virtual machine via SSH.

In any case, this quick look at Quickemu impressed me a lot. 🙂

Hyprland and KDE Applications

3 Replies

Updated on 8 March 2024 (for Plasma 6)

Updated on 30 May 2024 (for Dolphin’s “Open With” empty menu)

This is another post of the Hyprland series.

I am a big fan of KDE applications for many everyday tasks. Since Hyprland is not a full desktop environment, you can choose which applications to install for text editing, images, viewers, file managers, etc.

When I started using Hyprland, I was installing Thunar as a file manager; then I switched to Nemo because it’s more powerful, then to Nautilus (but it doesn’t look right in Hyprland). Finally, I decided to use Dolphin since I already used several KDE applications in Hyprland.

This is the list of Arch packages I install in Hyprland

  • kate (for text editing)
  • gwenview (for quick image editing)
  • konsole (as a terminal, though I still use also Alacritty)
  • breeze-icons (to have nice icons in KDE application)
  • kvantum (for Kate color schemes)
  • okular (for a better PDF viewer and annotator)
  • kcalc (as a calculator)
  • dolphin (for a powerful file manager)
  • dolphin-plugins (e.g., for Dropbox folder overlay)
  • ark (for Archive management, including Dolphin context menus)

Note that some of the above applications (namely, Dolphin and Gweenview) have “baloo” (the KDE file indexer and searcher) as a dependency. In Hyprland, that’s pretty useless and since it takes some resources for indexing, it’s better to disable that for good right after installing the above packages:

 

Some updates after the original post:

UPDATE (8 March): After the update to KDE Plasma 6, the name of the baloo command has changed:

UPDATE (30 May): Dolphin cannot seem to open files anymore because it doesn’t see any association. Its “Open With” menu is also empty. I blogged about the solution.

 

Let’s look at a few features of KDE applications that I like.

Concerning Dolphin, it has several powerful features, too many to list here 😉 I mention better renaming for multiple files out of the box. This feature requires additional work for Thunar or Nemo, and I never like the final result.

Let’s see the enabling of the Dropbox plugin (see the installed “dolphin-plugins” above):

After restarting Dolphin, you’ll get the nice overlay on the “Dropbox” folder:

Another reason I like KDE applications is that they have built-in HUD (Head Up Display), that is, a global searchable menu: use the keyboard shortcut Ctrl + Alt + i and you get the menu: start typing to quickly reach the intended item (in this example, I quickly switch to a custom Konsole profile):

You may want to create or change the keybinding for the file manager, in my case it is:

Moreover, you’ll have to update the “~/.config/mimeapps.list” file accordingly, that is, specify this line and replace the corresponding existing ones:

Concerning theming, some applications like Kate allow you to choose the color scheme. For example, since we installed Kvantum, we can choose the color scheme in Kate with “Settings” -> “Window Color Scheme”.

Konsole has profiles that you can create and customize.

On the other hand, Dolphin has no such functionality, so we should theme all KDE/Qt applications. That’s the subject of another possible future post.

Enjoy your KDE applications on Hyprland as well! 🙂

Running Maven from Java: the Maven Embedder

Leave a reply

This is probably the beginning of a series of articles about testing Maven plugins.

I’ll start with the Maven Embedder, which allows you to run an embedded Maven from a Java program. Note that we’re not simply running a locally installed Maven binary from a Java program; we run Maven taken from a Java library. So, we’re not forking any process.

Whether this is useful or not for your integration tests is your decision 😉

The source code of the example used in this tutorial can be found here: https://github.com/LorenzoBettini/maven-embedder-example/

I like to use the Maven Embedder when using the Maven Verifier Component (described in another blog post). Since it’s not trivial to get the dependencies to run the Maven Embedder properly, I decided to write this tutorial, where I’ll show a basic Java class running the Maven Embedder and a few JUnit tests that use this Java class to build (with the embedded Maven) a test Maven project.

This is the website of the Maven Embedder and its description:

https://maven.apache.org/ref/3.9.6/maven-embedder/

Maven embeddable component, with CLI and logging support.

Remember: this post will NOT describe integration testing for Maven plugins; however, getting to know the Maven Embedder in a simpler context was helpful for me.

Let’s create a simple Java Maven project with the quickstart archetype

Let’s change the Java version in the POM to Java 17, use a more recent version of JUnit, and add another test dependency we’ll use later:

Let’s import the Maven Java project into Eclipse (assuming you have m2e installed in Eclipse).

Let’s add the dependencies for the Maven Embedder:

Getting all the needed dependencies right for the Maven Embedder is not trivial due to the dynamic nature of Maven components and dependency injection. The requirements are properly documented above.

Let’s replace the “App.java” inside “src/main/java/” with this Java class:

That’s just a simple example of using the Maven Embedder. We rely on its “doMain” method that takes the arguments to pass to the embedded Maven, the base directory from where we want to launch the embedded Maven, and the standard output/error where Maven will log all its information. In a more advanced scenario, we could store the logging in a file instead of the console by passing the proper “PrintStream” streams acting on files.

Let’s create the folder “src/test/resources” (it will be used by default as a source folder in Eclipse); this is where we’ll store the test Maven project to build with the Maven Embedder.

Inside that folder, let’s create another Maven project (remember, this will be used only for testing purposes: we’ll use the Maven Embedder to build that project from a JUnit test):

We rely on the fact that the contents of “src/test/resources” are automatically copied recursively into the “target/test-classes” folder. Eclipse and m2e will take care of such a copy; during the Maven build, there’s a dedicated phase (coming before the phase “test”) that performs the copy: “process-test-resources”.

Let’s replace the “AppTest.java” inside “src/test/java/” with this JUnit class:

The first test is simpler: it runs the embedded Maven with the goals “clean” and “verify” on the test project we created above. The second one is more oriented to a proper integration test since it also passes the standard system property to tell Maven to use another local repository (not the default one “~/.m2/repository”). In such a test, we use a temporary local repository inside the target folder and always wipe its contents before the test. This way, Maven will always start with an empty local repository and download everything from scratch for building the test project in this test. On the contrary, the first test, when running the embedded Maven, will use the same local repository of your user.

The first test will be faster but will add Maven artifacts to your local Maven repository. This might be bad if you run the “install” phase on the test project because the test project artifacts will be uselessly stored in your local Maven repository.

The second test will be slower since it will always download dependencies and plugins from scratch. However, it will be completely isolated, which is good for tests and makes it more reproducible.

Note that we are not running Maven on the test project stored in “src/test/reources” to avoid cluttering the test project with generated Maven artifacts: we build the test project copied in the “target/test-classes”.

In both cases, we expect success (as usual, a 0 return value means success).

In a more realistic integration test, we should also verify the presence of some generated artifacts, like the JAR and the executed tests. However, this is easier with the Maven Verifier Component, which I’ll describe in another post.

IMPORTANT: if you run these tests from Eclipse and they fail because the Embedded Maven cannot find the test project to build, run “Project -> Clean” so that Eclipse will force the copying of the test project from “src/test/resources” to “target/test-classes” directory, where the tests expect the test project. Such a copy should happen automatically, but sometimes Eclipse goes out of sync and removes the copied test resources.

If you run such tests, you’ll see the logging of the embedded Maven on the console while it builds the test project. For example, something like that (the log is actually full of additional information like the Java class of the current goal; I replaced such noise with “…” in the shown log below):

REMEMBER: this is not the output of the main project’s build; it is the embedded Maven running the build from our JUnit test on the test project.

Note that the two tests will build the same test project. In a more realistic integration test scenario, each test should build a different test project.

If you only run the second test after it finishes, you can inspect the “target/test-classes” to see the results of the build (note the “local-repo” containing all the downloaded dependencies and plugins for the test project and the generated artifacts, including test results, for the test project):

Now, you can continue experimenting with the Maven Embedder.

In the next articles, we’ll see how to use the Maven Embedder when running Maven integration tests (typically, for integration tests of Maven plugins), e.g., together with the Maven Verifier Component.

Stay tuned 🙂