We Keep Coding

Override google-java-format with spotless-maven plugin

I'm looking to implement a pre-commit automatic formatter for my team because the code is a bit all over the place. I like spotless and the google style but a sticking point seems to be 4-space indents, whereas it's currently outputting 2-space indents.
Is there a way to override this value via pom.xml, either on spotless side or the google side?

As instructed in Github issue comments here: https://github.com/diffplug/spotless/issues/420
You can solve this in Gradle build with:
indentWithTabs(2)
indentWithSpaces(4)
For Maven the same code would be:
<java>
<googleJavaFormat>
<version>1.8</version>
<style>GOOGLE</style>
</googleJavaFormat>
<indent>
<tabs>true</tabs>
<spacesPerTab>2</spacesPerTab>
</indent>
<indent>
<spaces>true</spaces>
<spacesPerTab>4</spacesPerTab>
</indent>
</java>

Google java format is not configurable by design: https://github.com/google/google-java-format/pull/57#issuecomment-233450426
There is no configurability as to the formatter's algorithm for formatting. This is a deliberate design decision to unify our code formatting on a single format.
Also see: https://github.com/google/google-java-format/wiki/FAQ#i-just-need-to-configure-it-a-bit-differently-how

A quick update: the spotless plugin can now be configured to do what you want. I.e. google-java-format with 4 spaces.
As mentioned in the docs: https://github.com/diffplug/spotless/tree/main/plugin-maven
you can now use the AOSP 'style' which does what you need.
<googleJavaFormat>
<version>1.8</version>
<style>AOSP</style>
</googleJavaFormat>

Similar to the other answer, I tried to indent with Tabs(1) and Spaces(2). It also worked.
spotless {
java {
googleJavaFormat("1.7")
indentWithTabs(1)
indentWithSpaces(2)
}
}

Apache FOP in a Java Applet - No ImagePreloader found for data

I'm looking at an issue in a mature commercial product.
In a nutshell, we are using part of the Apache POI library to read in a Word .DOC or .DOCX file, and convert it into XSL-FO so that we can do token replacements. We then use FOP – embedded into the Java program - to convert the FO data into a PDF for printing. The catch is, all this is being done on the client inside a Java applet running inside Internet Explorer.
Originally we were using FOP 0.93, which worked reasonably well. However, it was not able to utilise the fonts inside the DOC file when generating the PDF and would map everything to Times, which one of the customers did not like. In theory it could be made to work by adding some kind of font metrics data, but that would require a relatively complex definition for every font it was likely to encounter and we can’t predict what the client is liable to use outside of the MS core fonts set.
To fix this, FOP was upgraded to 1.0, which added support for autodetecting the fonts from the operating system. This worked, but we noticed that the image processing had stopped working and the letterheads had disappeared.
What appears to have happened is that the image loader inside FOP was rewritten at some point between 0.93 and 0.95 so that instead of using Jimi and JAI it now uses ImageIO. The earlier implementation worked fine, but the new code doesn’t like being run as an applet.
Images are embedded in URIs in the FO data so we get an error like this:
2014-09-30 17:00:10,607 ERROR [org.apache.fop.apps.FOUserAgent] Image not available. URI:
data:image/jpeg;base64,iVBORw0KGgoAAAANSUhEUgAAALQAAABSCAIAAABysmn6AAA...
...ggg==. Reason: org.apache.xmlgraphics.image.loader.ImageException: The file format is not supported. No ImagePreloader found for data:image/jpeg;base64,iVBORw0KGgoAAAANSUhEUgAAALQAAABSCAIAAABysmn6AAAA...
When run through a test harness, the correct output is generated, but when run as an applet inside the browser we get the above error which makes me suspect that the browser applet security is jamming the ImageIO plugin loader somehow.
The guts of the FOP transformation, i.e. the bit which is triggering the error is this:
// Step 4: Setup JAXP using identity transformer
TransformerFactory factory = TransformerFactory.newInstance();
Transformer transformer = factory.newTransformer(); // identity transformer
transformer.transform(src, res);
...which is all being run inside a PrivilegedAction block since in FOP 1.0 it needed file I/O access to manage the font cache.
Running the standalone FOP 0.93 and 1.0 programs under linux and using strace shows that it is writing out temporary files for the image data, but both 0.93 and 1.0 do similar things, so it shouldn’t be that by itself, especially since it should have permission to create temp files already.
I've tried different versions of the JRE since some builds a few years back apparently had security issues with the ImageIO library, but to no avail.
Any ideas?
Thanks,

In case anyone else has something similar, this turned out to be caused by the way the project was being built in Maven.
Fop 1.0 and above use the xml-graphics-commons library to facilitate the image rendering. As mentioned in the question, this uses a plugin registry which is configured using the following files inside the JAR:
META-INF/services/org.apache.xmlgraphics.image.loader.spi.ImageConverter
META-INF/services/org.apache.xmlgraphics.image.loader.spi.ImageLoaderFactory
META-INF/services/org.apache.xmlgraphics.image.loader.spi.ImagePreloader
...each of these contains a list of the image decoders which will be supported.
The problem is that xml-graphics-common ships these files with a sensible list of defaults, while FOP also has a conflicting set of defaults, which for some weird reason disable all of the image decoders, and that one was taking priority.
To solve the problem, I made sure that my maven pom.xml file imported xml-graphics-common before FOP, so that its defaults took precedence, and at that point everything sprang to life.
I am still not sure why the code was working correctly as a standalone test program, but I suspect it was the way the classpath was being handled being different to it running in plugin mode.

In my case the plugin registry loaded ImagePreloaders from both the plugin files and mixed them together. Yet the error still appeared. I was inserting an SVG file into a PDF file. The root cause was incorrect version of org.apache.xmlgraphics:batik-svg-dom. The 1.7 version was required by the org.apache.xmlgraphics:fop:1.1, however, the 1.8 version was on the classpath.
There is a key difference between the two versions: the org.apache.fop.image.loader.batik.PreloaderSVG class needs org.apache.batik.dom.svg.SAXSVGDocumentFactory from the version 1.7 on the classpath. If it gets org.apache.batik.anim.dom.SAXSVGDocumentFactory from the 1.8 version it does not work as expected.
This SO question: Where has org.apache.batik.dom.svg.SVGDOMImplementation gone? was helpful to me when resolving this issue.

Just been struggling with this one. If you're using the maven-shade-plugin to create an uber jar, use the ServicesResourceTransformer to merge all the services configuration:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>2.2</version>
<executions>
<execution>
<!-- snip -->
<configuration>
<transformers>
<!-- snip -->
<transformer implementation="org.apache.maven.plugins.shade.resource.ServicesResourceTransformer"/>
</transformers>
</configuration>
</execution>
</executions>
</plugin>

thanks for the post!
I can assert that this also works by changing ordering in Eclipse!
in my case, under Windows it was working fine, but same JAR file in RHEL raised an error

SVN revision number accessible in compiled GWT package

I have a GWT project which has its source managed in SVN, is packaged using Maven and has its builds managed via Hudson. I want to get the SVN revision number of the latest check-in/build to be visible in a comment at the bottom of the application root HTML file. I don't care where in the development process this happens!
Here are the options I've Googled for so far, with no success:
Can I get Hudson to, after building, write the build/revision number
to one of its build output files (namely the application root HTML
file)? I've seen no way to do this.
Can I get Maven to write the SVN revision number to one of its build
output files (namely the application root HTML file)? I've seen ways
of Maven writing this to a JAR/WAR manifest file (which can then be
accessed in the Java code), but I'm not sure that this works in GWT
(I'm not particularly knowledgeable about the internals of GWT).
Can I get SubVersion to, as a pre-commit hook, write the version number to a particular file? I know it's easy to write the version number to the file you're editing, but not so sure about writing to a totally separate file (so that it's updated on every commit, regardless of whether it was changed in that commit).
Does anyone have a complete, end-to-end example of how to get any of these working? I keep finding little snippets of code/config which do one part of the job, but not anything that is exactly what I'm looking for.
Thanks!

You can achieve what you're looking for with a combination of Maven and Hudson. In this example let's imagine you want the file version.txt at the root of your web app to contain the revision.
version.txt:
${SVN_REVISION}
In your project's pom.xml enable filtering in the maven-war-plugin:
<plugin>
<artifactId>maven-war-plugin</artifactId>
<version>2.1</version>
<configuration>
<webResources>
<webResource>
<directory>src/main/webapp</directory>
<filtering>true</filtering>
<includes>
<include>version.txt</include>
</includes>
</webResource>
</webResources>
</configuration>
</plugin>
Make sure that Hudson is building your project via. Subversion checkout and it will set the SVN_REVISION environment variable for every build and Maven will fill it in.

This solution is for those who keep getting {SVN_REVISION} instead of the actual SVN_REVISION value inside the target file.
My solution was to also use filtering. However since I wanted the SVN_REVISION to appear inside my gwt app's main html page (as a means of "fighting" the user's cache, making sure that if we carry out a new build, then the user downloads the latest html file), I wasn't able to use Jason Terk's solution. The html file simply printed {SVN_REVISION} instead of the actual SVN_REVISION value.
So I defined a property inside <properties>:
<properties>
...
<buildVersion>${SVN_REVISION}</buildVersion>
...
</properties>
I then made sure I was filtering the appropriate html file (like described in Jason's solution), and then "extracted" the SVN_REVISION in the html file like so:
<script type="text/javascript">
...
var versionIdSuffix = '?v=${buildVersion}';
....
</script>
In a nutshell - I wasn't able to directly reference the {SVN_REVISION} property from inside the html file, so I "wrapped" it through <properties>, letting maven reference it instead.

How to generate Checkstyle reports?

I have a checkstyle report as xml file and want to generate a html report which lists what kind of errors occurred how many times and in which files they occurred. Something like this example.
Is there a tool to do that?

If you are using mvn to do this, mvn checkstyle:checkstyle will generate an xml format report, or with the option -Dcheckstyle.output.format=plain just plain text. Both of these will only list the errors and won't give any summary.
The summary html file is found in the target directory, however I found the images and the CSS are missing so it looks pretty bad.
mvn site will generate the HTML format report like your image. However it will also generate large amounts of other reporting material and takes a long time.
I've also found another problem - mvn checkstyle:checkstyle will only find your config files if you include the file:// protocol in the checkstyle plugin config, e.g.
<plugin>
<artifactId>maven-checkstyle-plugin</artifactId>
<version>2.13</version>
<configuration>
<configLocation>file://${basedir}/checkstyle/checkstyle.xml</configLocation>
</configuration>
</plugin>
However mvn site only takes a directory, and can't handle the file://

Latex Javadoc generation

Is there a way to generate a latex document from my java sourcefile's documentation?
I don't want to include LaTeX Elements in my documentation comments, I simply want to create LaTeX files instead of HTML.
Thanks

An alternative to Texdoclet is the ltxdoclet I created.
I think the main difference is that it also includes the source code, not only the Javadoc comments, though you can switch this off.
It is not very well documented on the github site - just download the code and do ant pdfdoku for an example output (ant latexdoku if you only want the LaTeX files). (It is documented in german, though.)
I really should add a readme file there.
For now, here is the jar file - download it somewhere, and then use
javadoc -docletpath ltxdoclet.jar -doclet de.dclj.paul.ltxdoclet.DocletStart -help
to see a list of options available. (This will be in german, if you have no english locale. Prefix it with "LC_ALL=en_US" or similar on bash to get the english version, or have a look at help_en.txt instead if you don't know german.)
I'm working on a webpage with some more documentation, but I'm not sure when it will be ready.
Now we have a webpage, too. It links the jar file, and also as an example the javadocs when applied to itself.

Texdoclet seems to be what you need. As for how to use it: just like any other doclet.

If you don't want to rely on any doclet dependency, but rather on a javascript one, you can just add the following javadoc param:
-header "<script type='text/javascript' src='http://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML'></script>"
and simply use clean latex inside your comments such as \(\sum_i a_i\) or \[\sum_i a_i\]