I have a lot of Java source code that requires custom pre-processing. I'd like rid of it but that's not feasible right now so I'm stuck with it. Given that I have an unfortunate problem that shouldn't have existed in the first place, how do I solve it using maven?
(For the full story, I'm replacing a python-based build system with a maven one, so one improvement at a time please. Fixing the non-standard source code is harder, and will come later.)
Is it possible using any existing Maven plugins to actually alter the source files during compile time? (Obviously leaving the original, unprocessed code alone)
To be clear, by preprocessing I mean preprocessing in the same sense as antenna or a C compiler would preprocess the code, and by custom I mean that it's completely proprietary and looks nothing at all like C or antenna preprocessing.
There is a Java preprocessor with support of MAVEN: java-comment-preprocessor
This is something that is very doable and I've done something very similar in the past.
An example from a project of mine, where I used the antrun plug-in to execute an external program to process sources:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<executions>
<execution>
<id>process-sources</id>
<phase>process-sources</phase>
<configuration>
<tasks>
<!-- Put the code to run the program here -->
</tasks>
</configuration>
<goals>
<goal>run</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
Note the tag where I indicate the phase where this is run. Documentation for the lifecycles in Maven is here. Another option is to actually write your own Maven plug-in that does this. It's a little more complex, but is also doable. You will still configure it similarly to what I have documented here.
Maven plugins can hook into the build process at pre-compile time yes, as for whether or not any existing ones will help I have no idea.
I wrote a maven plugin a couple of years ago as part of a university project though, and while the documentation was a bit lacking at the time, it wasn't too complicated. So you may look into rolling your own, there should be plenty of open source projects you can rip ideas or code from (ours was BSD-licenced for instance...)
Related
Current state:
I have a project which is build with: Java 1.8.161, Maven 3.3.9, SpringBoot 2.0.1, tools: Jenkins and GitLab. I would like to use google java format as a standard for whole team.
My investigation / solution:
During the investigation I found solution, which sounds really easy. Just update pom file with:
<build>
<plugins>
<plugin>
<groupId>com.coveo</groupId>
<artifactId>fmt-maven-plugin</artifactId>
<version>2.5.0</version>
<executions>
<execution>
<goals>
<goal>format</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
And it works. If I run compile, package, verify, install or deploy Maven lifecycle the code is formatted.
Question:
How can I run this after i.e. each commit for all team members without any extra steps in their IDEA? Because right now, I need to run Maven before each commit. But during the run of an application it is not necessary, so the team can avoid it.. Which of course will lead to problems with history in git.
You can let pre-commit hook trigger formatter for files staged for commit.
git-code-format-maven-plugin uses google-java-format formatter and can install client-side pre-commit git hook during compile phase. It requires Maven 3.5.x, which should be enforced.
<build>
<plugins>
<plugin>
<groupId>com.cosium.code</groupId>
<artifactId>git-code-format-maven-plugin</artifactId>
<version>VERSION</version>
<executions>
<execution>
<goals>
<goal>install-hooks</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<artifactId>maven-enforcer-plugin</artifactId>
<version>VERSION</version>
<executions>
<execution>
<goals>
<goal>enforce</goal>
</goals>
<configuration>
<rules>
<requireMavenVersion>
<version>[3.5.4,)</version>
</requireMavenVersion>
</rules>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
Point to standalone Maven in IDE as git-code-format-maven-plugin does not play along nicely with embedded Maven.
mvn compile to get hook installed. For IDEA, that's it.
As git-code-format-maven-plugin only formats changed files (which is good), it is probably good to format whole project upfront once (mvn git-code-format:format-code -Dgcf.globPattern=**/*).
Workaround for Eclipse
Because of a bug in EGit, which sometimes ignores Git hooks completely, developers using Eclipse on Windows should have Cygwin in PATH. An empty cygpath.exe will do. Run 'Command Prompt' as a administrator and execute C:\>echo "" > /"Program Files"/Git/bin/cygpath.exe (kudos to hook is not working eclipse egit client).
Reboot.
A note on java import statements ordering
Optimise imports or reformat in IDE or reformat with plugins, can lead to changes in imports ordering. A nasty surprise if an older version of git-code-format-maven-plugin is being used together with fmt-maven-plugin (to format or validate code later in CI, for example).
git-code-format-maven-plugin will sort imports (since version 1.20)
fmt-maven-plugin will always sort imports
googleformatter-maven-plugin can optionally sort imports (not per default)
In order to run this formatter after each developer commit, you will have to first have a Jenkins commit hook in place, that will trigger a Jenkins build. One of the phases of the build, should execute the fmt-maven-plugin's (or any others) check functionality in order to ensure that the code is properly formatted.
Adding a webhook
First thing to do is add a webhook that will trigger a Jenkins build after every commit in your git repository. You can find how to do this here. For Gitlab specific instructions, this post from medium may be helpful.
Executing the check
This can be done by executing the check goal on the fmt-maven-plugin
Maven acceps either <plugin-prefix>:<goal> or <plugin-group-id>:<plugin-artifact-id>[:<plugin-version>]:<goal> as a means of calling a plugin goal, so for your specific problem, you can run:
mvn fmt:check
That being said, you will have to add a Jenkins build step, that will run the mentioned command. Step 5 from this tutorial shows you how to add a build step.
Hope that this actually helps :D
I need to run Maven before each commit
You do not need to run multiple maven goals. For eg no need to run maven install for the formatting to take place. A simple maven compile will formate the classes.
I think that the title is pretty self explanatory, how can I achieve that? By default Maven's javadoc plugin generates documentation only for "normal" classes.
You can set additional source paths for the maven-javadoc-plugin
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<version>2.9.1</version>
<configuration>
<sourcepath>${basedir}/src/main/java;${basedir}/src/test/java</sourcepath>
</configuration>
</plugin>
You may also want to tweak other javadoc:javadoc goal settings. You get set the complete list of options at its official site.
I've managed to solve my problem. To generate javadoc of test packages you have to go to properties of Maven project->Actions->Generate Javadoc and there add the goal: javadoc:test-javadoc.
Maven docs explicitly suggest classifiers as a solution for multiple JDK support:
The classifier allows to distinguish artifacts that were built from the same POM but differ in their content. It is some optional and arbitrary string that - if present - is appended to the artifact name just after the version number. As a motivation for this element, consider for example a project that offers an artifact targeting JRE 1.5 but at the same time also an artifact that still supports JRE 1.4. The first artifact could be equipped with the classifier jdk15 and the second one with jdk14 such that clients can choose which one to use.
I have never seen a working example of this. Is the documentation wrong, or is it somehow possible to actually make Maven build the same artifact multiple times with different JDKs (and obviously distinct source directories, since they will have different syntax (e.g. diamond or lambdas)) and, most importantly, deploy them together?
Seems like this kind of thing would be a basic requirement for potential support of JEP 238, too.
The documentation is not wrong. It is just giving an example of how classifiers can be applied, in this case by targeting several JREs.
For how this can be done, there may be several ways to do this. See How to configure Maven to build two versions of an artifact, each one for a different target JRE for a related problem. You can also trigger different execution with Maven profiles. In this case, each profile triggers a different configuration of the maven-jar-plugin with a different classifier:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.6</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>jar</goal>
</goals>
<configuration>
<classifier>jdk14</classifier>
</configuration>
</execution>
</executions>
</plugin>
I been looking around for hours and can't seem to find a solution to my problem. I am using Netbeans 8 and I would like to generate a Javadoc. I have formatted my comments to match Javadoc format. But the action menu (generate Javadoc) is disabled to any of the project.
How can I enable it? My project can be seen here: https://github.com/Daytron/SimpleDialogFX
I see that you are using Maven for your project. NetBeans' support for Maven is best-in-class since you almost never need to add anything to your Maven project in order for NetBeans to load it properly. To enable Javadoc during your build, simply add the following code to the <plugins> element within your <build> element.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<version>2.10.1</version>
<executions>
<execution>
<id>attach-javadocs</id>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
</plugin>
Note: Since generating Javadoc may take a bit of time and those outputs are not necessary for debugging, I recommend only enabling the Javadoc output for a final build. However, the simplest path is certainly to just enable it all the time, which is what I've shown above.
Netbeans 8 needs to be restarted sometimes to show the Generate Javadoc.
I apologize if this question has been answered elsewhere, but I couldn't seem to find an the exact response that I've been looking for. So I'm in the middle of altering a web application that once relied heavily on the jQuery UI to use Vaadin, instead. To make it easy for me to understand, I created a new Maven project and altered the pom.xml to include the following plugins:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>1.6</source>
<target>1.6</target>
</configuration>
<version>2.3.2</version>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>tomcat-maven-plugin</artifactId>
<configuration>
<server>local_tomcat</server>
<path>/illuminate</path>
<url>http://127.0.0.1:8080/manager/text</url>
</configuration>
<version>1.1</version>
</plugin>
Now, I can manage to build and deploy my very simple application to Tomcat just fine, but when I attempt to go to it, I get the following error:
In order to get a better understanding of how to set up this kind of project, I checked out a recent applicaiton that uses Vaadin with Maven from our repository called "Tag." Looking at the error, it looks as though it's trying to find a JavaScript file nocache.js in a directory that starts off accurate (Illuminate is my current application), but then branches off into this other project that has no link to my current one. I'm not sure if the browser has something to do with this or not, but I learned that it might have something to do with the widgets of my project having not been compiled yet. I've noticed that there are some other plugins that will do this, but these two are the only ones that this other project, Tag, makes use of, so I figured mine should work just fine. I have also been trying to follow the step-by-step process to make a simple "Hello World" like program from the Vaadin Tutorial. So... Anyone know what I am missing? If it's the compilation of the widgets (I only wish to use the defaults, I suppose), do I NEED those other plugins?
Thats problem of tomcat not deploying VAADIN dir content.
see below blog
http://fmucar.wordpress.com/2011/04/20/vaadin-maven2-eclipse/