doxia-module-markdown is a Maven plugin that enables Markdown in Maven documentations. In version 1.8, the developers have moved from Pegdown to Flexmark as Markdown parser. It’s a good choice, as Flexmark is considerable faster and is still being maintained, while Pegdown officially reached its end of life in 2016.
However, with that switch, code blocks are not syntax highlighted any more. The reason is that the maven-fluido-skin uses code-prettify for syntax highlighting. It runs browser-side, highlighting all <pre> and <code> blocks selecting the prettyprint CSS class. This was true with Pegdown, but Flexmark selects a source class instead.
An obvious workaround is to use a small JavaScript snippet that adds a prettyprint class to all blocks selecting a source class, and then running prettyPrint() again. To do so, this block needs to be added to the <head> section of site.xml:
<head>
<!-- Workaround for https://issues.apache.org/jira/browse/DOXIA-571 -->
<![CDATA[<script type="text/javascript">
$(document).ready(function () {
$(".source").addClass("prettyprint");
prettyPrint();
});
</script>]]>
</head>
It’s hard to tell if this is a bug in doxia-module-markdown or in maven-fluido-skin. Also see my bug report at Apache’s JIRA.
This was a Google Plus comment that I have now moved to my blog as Google Plus is going to be closed. Thanks to Clement Escoffier for the inspiration.
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.
After hours of trying and wondering why my release scripts suddenly stopped working, I found out that maven-release-plugin seems to have an issue with git on recent systems. If you invoke mvn release:prepare and find out that the release process just runs against the current SNAPSHOT instead of the release version, you likely stumbled upon bug MRELEASE-812.
The reason for this issue seems to be that mvn release:prepare parses the output of git status. However the status is localized in recent versions of git, and maven-release-plugin fails to parse the localized output.
The coming fix will probably use git status --porcelain, which returns a machine-readable output. However, for the time being
LANG='en_US.UTF-8'
mvn release:prepare
is a valid workaround.
If you’re using Maven’s hibernate3-maven-plugin for creating a DDL file from your entities, you might encounter the following error when using Java 1.7:
Execution default of goal org.codehaus.mojo:hibernate3-maven-plugin:2.2:hbm2ddl failed:
An AnnotationConfiguration instance is required
The reason seems to be a broken JRE detection in the Mojo code, which mistakenly assumes that Java 1.7 does not support annotations. However, I haven’t checked that in depth.
The fix is pretty easy. In the plugin configuration of the hibernate3-maven-plugin, add an implementation property to the componentProperties like this:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>hibernate3-maven-plugin</artifactId>
<version>2.2</version>
<configuration>
<componentProperties>
<implementation>annotationconfiguration</implementation>
</componentProperties>
</configuration>
</plugin>
This enforces the use of an AnnotationConfiguration instance.