The sonar-gitlab-plugin is an useful plugin to connect SonarQube with GitLab. After pushing, the branch is inspected by SonarQube, and code smells are immediately commented in the commit.
Unfortunately, the error messages of that plugin are a little difficult to understand. It took me a while to collect this little cookbook of error fixes.
Unable found project for null project name
In SonarQube, as Administrator, select the project. Then in Administration ⭢ General Settings ⭢ GitLab, enter the project ID of your project and save it. The project ID is the group name in GitLab, followed by a slash and the name of the project, e.g.shred/timemachine.Unable found project for mygroup/myproject
In SonarQube, check that the project ID is correct and there are no spelling mistakes. In GitLab, make sure that SonarQube’s GitLab user is actually a member of the project, and that the user has Developer rights. I hit a strange bug in GitLab here. The SonarQube user was a member of the project, but still this error occured. When logging in as the SonarQube user, the project was not on the roll of projects. Removing and adding Developer rights to the user didn’t help. The only thing that finally worked was to add the SonarQube user to a different project, even if just for a moment. It seems to be a caching problem in GitLab.Multiple found projects for mygroup/myproject
You should never see this error, but if you do, be more specific with the projectID.
I just had a stream of objects I wanted to sort and convert to a list. Optionally it should also be limited to a maximum number of entries. Piece of cake with Java 8:
Stream<T> stream = collection.stream().sorted(comparator);
if (max >= 0) {
stream.limit(max);
}
List<T> result = stream.collect(Collectors.toList());
Or so I thought… The code above throws an IllegalStateException at runtime, stating that the “stream has already been operated upon or closed”.
The cause should be obvious. However it took me a while to find it, so I am posting it in case other people (possibly you when you came here via search engine) get stuck at the same place. Stream operations are very likely to return a different Stream object. The limit() method is such an example. In my code above, limit() operates on the stream and returns a limited stream. However I just throw away the returned stream and invoke collect() on the original stream, which was now already operated upon.
The solution is simple:
if (max >= 0) {
stream = stream.limit(max);
}
UPDATE: It seems that starting with hardware version 2, these switches have an actual web interface. Too sad my ones are version 1. 😢
Frankly, I didn’t expect it and I was somewhat disappointed when I found out that the TP-Link TL-SG108E Easy Smart Switch (and its little brother TL-SG105E) cannot be configured via web browser. And I was even more disappointed when I found out that, even though Linux and MacOS were listed on the retail box, the configuration tool Easy Smart Configuration Utility runs on Windows only. And they mean it! When started in a Windows VM, the utility does not see any switches.
So the devices are rather cheap for a smart switch, but they still come with a price: no web interface.
However, thanks to some help in the interwebs, I was finally able to run the Configuration Utility on Fedora Linux. It’s not that easy, though.
Before we start, please be aware that this is a hack! I don’t know if running the Configuration Utility on Linux comes with side effects to the switch configuration and security. Maybe the switch can even suffer permanent damage that way. So use it at your own risk!
Running the Configuration Utility on Linux
The good news is: The Easy Smart Configuration Utility is written in JavaFX, so it runs on Linux even without Wine! First you need to download the utility from the TP-Link home page. It is a zip file containing an exe file. Unfortunately you have to run the exe file on a Windows machine to unpack it. I promise this is the only time you will actually need Windows. After that, you will find a file called Easy Smart Configuration Utility.exe in the installation directory. This is the only file we will need. Copy it to your Linux machine, and while you’re at it, also rename it from .exe to .jar. Yes, it’s just a Java archive file!
In a next step, you need to download and install the official Oracle Java on your Linux machine. OpenJDK will not be sufficient, as it does not contain JavaFX (yet).
When you are done, you should be able to start the Easy Smart Configuration Utility with this command:
java -jar "Easy Smart Configuration Utility.jar"
However, it does not find any switches. This is because the software discovers the switches via UDP broadcast, but unfortunately the interface is bound to the local IP address instead of any address, as it is required on Linux. We need to tweak the firewall…
If your system is running firewalld (e.g. on Fedora), execute these lines to add a firewall rule (and replace $your_ip with your local IP address):
firewall-cmd --add-port=29809/udp
firewall-cmd --zone=public --add-forward-port=port=29809:proto=udp:toaddr=$your_ip
If your system is running iptables, you need to execute these lines:
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A PREROUTING -p udp -d 255.255.255.255 --dport 29809 -j DNAT --to $your_ip:29809
Now hit the Refresh button on the Configuration Utility, and your switches should finally appear. The GUI is still a little ugly with the input elements being too tall, but that is rather a cosmetical issue.
Firmware Upgrades
Firmware updates still failed with a strange error, and the switch needing to be powered off and on again. To successfully perform a firmware upgrade, I had to do these steps:
- Connect the switch directly to the computer, and disconnect everything else from the switch.
- Shut down NetworkManager (
systemctl stop NetworkManager). - Set up the ethernet interface manually (e.g.
ifconfig em0 192.168.0.2 up, it must be in the same subnet as your switch). - Invoke the iptables command from above again (use the IP address from the step above as
$your_ip).
After that, firmware updates finally succeeded, too.
Strange enough, the firmware image is transported to the switch via HTTP. It appears that there actually is a HTTP server running on the switch. An ASCII dump of the firmware file also reveals some HTML forms, so it seems like the switch is technically able to be configured via web frontend, but the feature has been disabled. Maybe it will be possible in a future firmware version, but I rather guess they found out that they ran out of memory when the switch was already on the production line. That would also explain the non-existing MacOS/Linux compatibility mentioned on the box.
Sass is a kind of precompiler for CSS that offers additional features like nested styles, variables or includes. The syntax of scss files is similar to standard CSS, so it’s very easy to learn.
My goal is to:
- nicely integrate Sass into the Maven build process,
- use Jetty to see the web application with the compiled css files, and
- see changes to a Sass file live (without running Maven or restarting Jetty).
There is a sass-maven-plugin by the Apereo Foundation that already offers Maven integration and watching changes to sass files. However, I don’t fancy the default settings. The default location of sass files is the webapp directory, which means that the sass files are packed into the war file as well, exposing silent comments, variable names and maybe other things that are not meant to be published.
I prefer src/main/sass as source directory. As target, I choose a directory called generated-webapp, which is ought to contain all generated webapp stuff. In this directory, a css directory will contain the compiled css files. The sass-maven-plugin configuration now looks like this:
<plugin>
<groupId>org.jasig.maven</groupId>
<artifactId>sass-maven-plugin</artifactId>
<version>1.1.1</version>
<executions>
<execution>
<id>package</id>
<phase>prepare-package</phase>
<goals>
<goal>update-stylesheets</goal>
</goals>
</execution>
</executions>
<configuration>
<resources>
<resource>
<source>
<directory>${basedir}/src/main/sass/</directory>
</source>
<destination>${project.build.directory}/generated-webapp/css</destination>
</resource>
</resources>
</configuration>
</plugin>
The reason for using generated-webapp instead of ${project.build.directory}/${project.build.finalName} is that Jetty only looks into src/main/webapp for static resources by default. However, if ${project.build.directory}/${project.build.finalName} was added, Jetty would also scan all compiled classes twice, which may result in errors (especially when Spring is involved). What needs to be done now is to add generated-webapp to the list of webapp resources:
<plugin>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-maven-plugin</artifactId>
<version>9.2.2.v20140723</version>
<configuration>
<webApp>
<resourceBases>
<directory>${basedir}/src/main/webapp</directory>
<directory>${project.build.directory}/generated-webapp</directory>
</resourceBases>
</webApp>
</configuration>
</plugin>
After starting Jetty with mvn jetty:run, it nicely returns our css resources.
To make changes to Sass files immediately available, the Sass watcher is started in a second terminal with mvn sass:watch. Jetty will deliver all changes in src/main/sass now, without the need to restart.
A final problem to solve is that the generated-webapp target is not included in the war file by default. The maven-war-plugin needs to be configured properly:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.4</version>
<configuration>
<webResources>
<resource>
<directory>${project.build.directory}/generated-webapp</directory>
</resource>
</webResources>
</configuration>
</plugin>
While upgrading my blog software Cilla to Java 8 and Hibernate 4, I found out that the old hibernate3-maven-plugin refused to create schema.sql files. Well, it wasn’t really surprising. The name of the plugin already implied that the plugin won’t play with the next major release of Hibernate.
I could not spot an official update of the plugin. Instead, I found Kai Moritz new Hibernate 4 maven plugin, which turned out to be very useful.
One key feature is to set up and initialize a local database for unit testing. I don’t need this feature for Cilla (yet 😉). All I need is a hbm2ddl style generation of a SQL schema file for setting up new instances of my blog software from scratch. It turned out that the plugin was easily configured that way, and so it got almost a drop-in replacement for the old plugin.
This is what the <plugins> section of the project’s pom file looks like:
<plugin>
<groupId>de.juplo</groupId>
<artifactId>hibernate4-maven-plugin</artifactId>
<version>1.0.4</version>
<executions>
<execution>
<goals>
<goal>export</goal>
</goals>
</execution>
</executions>
<configuration>
<hibernateDialect>org.hibernate.dialect.PostgreSQL82Dialect</hibernateDialect>
<target>NONE</target>
<type>CREATE</type>
</configuration>
</plugin>
With the target set to NONE, the schema.sql file is quietly generated while building the project. If set to SCRIPT, a copy will be dumped to stdout.
A CREATE type only generates create statements of the database. The default is BOTH, which creates drop and create statements.
Since no actual database is created, there is no need to add user, password and url parameters.
A list of all configuration options can be found here. The plugin is available at Maven Central.