I have some problem with build project on Windows system. My project uses formatter-maven-plugin with goal "validate". Before push project in GitHub, i format it and push. After, I clone it on my windows computer and try to "mvn clean install", but I get:
Failed to execute goal net.revelc.code.formatter:formatter-maven-plugin:2.9.0:validate (default) on project application: File 'C:\Users\AUser\Desktop\demo\application\src\main\java\com\myapp\Application.java' has not been previously formatted. Please format file and commit before running validation!
In Linux that problem is not exist. Why is that? Before push in Git, i did format it. Why is problem not exist on linux? Change goal on format i can't.
<plugin>
<groupId>net.revelc.code.formatter</groupId>
<artifactId>formatter-maven-plugin</artifactId>
<version>2.9.0</version>
<executions>
<execution>
<goals>
<goal>validate</goal>
</goals>
<configuration>
<configFile>${project.basedir}/../eclipse/eclipse-formatter.xml</configFile>
<encoding>UTF-8</encoding>
</configuration>
</execution>
</executions>
</plugin>
Based on the official usage documentation:
Run the plugin with the format goal.
mvn formatter:format
After doing this once, you should be able to run like normal.
I met this question, as a result, Jenkins git fench code, some file end by CRLF, because of line separator is LF of LINUX, so validate is a failure. There are two ways to solve this problem:
you can use .gitattributes set text eol = lf, keep git fench code file end by LF.
another, use formatter-maven-plugin tag lineEnding, set <lineEnding>KEEP</lineEnding>, let line separator depend on file self, Not System.
I prefer the second way, because of format should keep system independence.
I think that you have missed a file when formatting. Based on this issue on the topic, it appears that a better error message was logged which indicates the problematic file. If you upgrade Maven Formatter to the latest stable version, you should see a new error message of the form:
File 'fileName' has not been previously formatted. Please format file and commit before running validation!
Related
I'm currently stuck when deploying a single file to my Maven Registry.
I use this goal to deploy to files using the command line: https://maven.apache.org/plugins/maven-gpg-plugin/sign-and-deploy-file-mojo.html
I need to pass in 2 gpgArguments:
<gpgArguments>
<arg>--pinentry-mode</arg>
<arg>loopback</arg>
</gpgArguments>
Otherwise the signing-process will fail, because I'm using Github Actions and I get an error, if they are not set (gpg: signing failed: Inappropriate ioctl for device)
In the MOJO of the plugin there is a parameter "gpgArguments" that is marked as "List".
Is it possible to pass in a List of parameters using the CLI? I tried a lot of stuff and also googled quite a bit and nothing seems to help.
My current command looks like this, but it is not interpreting the gpgArguments:
mvn gpg:sign-and-deploy-file -DpomFile=java/pom.xml -Dfile=./executable/exe -Durl=https://oss.sonatype.org/content/repositories/snapshots -Dclassifier=linux -DrepositoryId=ossrh -Dpackaging=exe -DgpgArguments=--pinentry-mode,loopback
If that's not possible, what are my alternatives? Thanks :)
Turns out, that the "gpgArguments" has not "User Property", which is what you can pass through using the CLI.
After a lot of trial and error I found out a hack, which is the only solution I found for now.. Although it's not really elegant.
I created a shell file called "gpghack.sh" which contains gpg --pinentry-mode loopback "$#".
Then I added this parameter to my sign-and-deploy-file goal:
-Dgpg.executable="./gpghack.sh
Now when GPG is called by Maven, it will use the shell-file which always adds the options I need.
Not pretty, but it works for now..
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
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.
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://
How can we generate javadoc as a word document instead of the traditional html pages?
look into doclets, http://doclet.com which have plenty of examples of custom javadoc rendering (i.e into PDF's etc...) and also look into Apache POI (http://poi.apache.org/) for the generation of MS Office files
If you could live with pdf instead of word, you should give PDFDoclet a chance. I discovered it on doclet.com (thanks to Mark for the link). It works quite well, is easy use and allows some configuration. For my purpose, pdf is better suited than word because a pdf document is better suited for reading than a word in regard to the needed viewer application.
Here is my small windows batch file:
echo OFF
set JAVA_HOME=C:/program files/Java/jdk1.6.0_23
set PATH=%JAVA_HOME%/bin;%PATH%
set VERSION=1.0.2
set DOCLET=com.tarsec.javadoc.pdfdoclet.PDFDoclet
set JARS=jar/pdfdoclet-%VERSION%-all.jar
set PACKAGE="cvu.html"
javadoc -doclet %DOCLET% -docletpath %JARS% -pdf html.pdf -config example/html/config_html.properties -private -sourcepath example/html -subpackges %PACKAGE%
http://doclet.com/ links an RTF Doclet ("RTF Doclet generates RTF format documentation.")
The resulting RTF opens in Word and Open Office Writer.
You can use maven to run the pdfdoclet. Though I did not find any "official" maven repository the following seems more clear to me, opposed to fiddling with shell scripts or using ant-commands in maven as proposed on their website:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<version>2.9.1</version>
<configuration>
<doclet>com.tarsec.javadoc.pdfdoclet.PDFDoclet</doclet>
<docletPath>path/to/pdfdoclet-1.0.2-all.jar</docletPath>
<useStandardDocletOptions>false</useStandardDocletOptions>
</configuration>
</plugin>
Note the disabling of the standard options, otherwise javadoc complains of unknown options (apparently not supported by the pdfdoclet)
From there you can start customizing, using the ever-concise maven documentation