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.
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 have a custom checkstyle.xml imported and set as the default. It works great. I just upgraded to the newest version of checkstyle and now I have a warning on just about every line of code. It looks like the warnings are coming from the two build in checkstyle xml's but they are not removable!
How can I disable these two checkstyle rule files so they stop bothering me?
The built-in configurations are not removable and cannot be changed or edited. Instead, people are supposed to create their own configurations, which is just what you did.
There are a few things you can try:
Make sure that your upgrade of the Checkstyle Eclipse plugin was performed correctly. Stop Eclipse. Check the plugins and features folders for contained folders called edu.umd.cs.findbugs.plugin.eclipse_version. There should only be one such folder in plugins and one in features, both with the same version number. If there are more, delete the ones with the older version numbers. Restart Eclipse with the -clean option as first argument.
Make sure that your custom Checkstyle configuration is still the default after the plugin upgrade.
Check the Eclipse projects in your workspace and make sure that they do not have project-specific settings for Checkstyle. Right-click on project, select Properties, then Checkstyle. Make sure that the selected configuration is correct.
Configuration names are case sensitive. This can be an issue if someone made a case mistake in the .checkstyle file located in each project's root directory. Or the configuration name was mistyped on import. This last point should result in different errors though (such as configuration not found).
Looks like Checkstyle locks in the 2 default rule sets. Two options occur to me: 1) Edit the default rules to diable the conflicting rules (or all of them). Or 2) delete the two xml files off the files system from the plugins/checkstyle (whatever the actual dir name is called).
Put the following in the projects that you want check-style disabled for, edit your pom.xml change the check-style skip to true :
<properties>
<!-- Checkstyle -->
<checkstyle.skip>true</checkstyle.skip>
</properties>
you should also configure it like this:
<plugin>
<artifactId>maven-checkstyle-plugin</artifactId>
<version>2.17</version>
<executions>
<execution>
<id>validate</id>
<phase>verify</phase>
<goals>
<goal>check</goal>
</goals>
<configuration>
<configLocation>checkstyle.xml</configLocation>
<encoding>UTF-8</encoding>
<consoleOutput>true</consoleOutput>
<outputFileFormat>xml</outputFileFormat>
<failsOnError>false</failsOnError>
<failOnViolation>true</failOnViolation>
<skip>true</skip>
</configuration>
</execution>
</executions>
<configuration>
<skip>true</skip>
</configuration>
</plugin>
Checkstyle will still run, but will perform a no-op...
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...)