Mavenitis is not avoidable, but Configuritis is.
If you did not know: If you use maven, maven will be quite diligent and ensure that all your dependencies are up to date. This may and will lead to the behavior of downloading the whole maven universe to your machine, or at least the pieces (dependencies) that are in use by your project, directly or indirectly or transitively.
Once you get past the first symptoms of mavinitis, by simple accepting the diligence that maven exhibits, because it takes it task as serious as it does, you can avoid Configuritis by NOT configure every plugin in each and every project, but use something similiar to testeasypom as parent pom in your project. Since a parent pom can have a parent, this does not limit you when you want or need to define a multi-module project with a parent pom defining the modules.
You can use the configuration by defining testeasypom as the parent by simply adding
<parent>
<groupId>io.github.sebivenlo</groupId>
<artifactId>testeasypom</artifactId>
<version>4.0.11</version>
<relativePath/>
</parent>
to your project’s pom.
testeasypom has some goodies that make it easy to use features with maven+java without falling into an install fest. Features:
-
setup test dependencies for the latest stable junit 5 and assertj
-
Nicely formatted code in javadoc by a highlighter plugin with configuration
-
Java Coverage with JaCoCo
-
PIT testing plugin
-
PMD and SpotBugs (2.x.x branch)
-
JavaFX integration when using profile fx (e.g. mvn -P fx package).
-
easy testing of modular JPMS projects
In the table below you find all the properties testeasypom defines.
All properties have to be written in the maven format: <property-name>value</property-name>
,
where property-name
is the name, and the value
is the value.
Property | default value | meaning |
---|---|---|
project.build.sourceEncoding |
UTF8 |
source encoding of java files |
java.lib.dir |
/usr/share/java |
where the general java libs for extendsions are stored |
java.release |
11 |
java version |
mockito.core.version |
4.3.1 |
|
junit.jupiter.version |
5.8.2 |
|
assertj.core.version |
3.22.0 |
|
jacoco.version |
0.8.78 |
jacocoArgLine |
defined to be able to configure jacoco |
argLine |
|
to be able to pass extra arguments |
surefire.opens |
|
to be able to pass opens statement to the jvm during test runs |
maven.surefire.version |
|
3.0.0-M5 |
surefire version |
checkstyle.config.location |
${user.home}/.m2/sebivenlo_checks.xml |
checkstyle config |
javadoc.location |
/usr/share/doc/openjdk-11-doc/docs/api/ |
to link javadoc locally |
pmdVersion |
6.42.0 |
javafx-maven-plugin-version |
testeasypom has been derived from sebipom, with the same purpose for fontys venlo Software Engineering and Business Informatics students.
TL;DR: Don’t do mvn package
or build (in your IDE) , do mvn test
instead.
For those that are into test driven something:
Make it a habit to do mvn test
instead of mvn package
. mvn package
typically does much more work than really required to get your tests do thier work. Enjoy the better maven experience this way. With testeasypom , just typing mvn defaults to mvn test.
When you are building a JavaFX application, remember to use the fx profile defined in this pom.
You do that by invoking e.g. mvn -P fx package
. If your application is called app with version 1.0, then this will make a FAT jar named
app-1.0-jar-with-dependencies.jar
.
testeasypom provides a simple mechanism to open or exports the packages of your modular project.
Add the property <surefire.opens>
to your properties inside the pom.xml file of your project.
<properties>
<surefire.opens>
--add-opens surveyor/surveyor=ALL-UNNAMED
--add-exports javafx.graphics/com.sun.javafx.application=ALL-UNNAMED
</surefire.opens>
</properties>
In the example you see opening and exporting parts of javafx for the purpose of the tests. In normal use, the modules will still stay closed, as designed.
With testeasypom, the only configuration left to you is adding the actual dependencies of your project and maybe test libraries for JavaFX, such as testfx.
If you want to deploy an artifact using this pom as parent to maven-central, you need to do the following.
-
Add a license if you do not want the default apache license.
-
Add a description to the dependent pom.xml
-
Add the developer info to the dependent pom.xml.
-
Add the url of the project.
-
Make sure you have a working gpg config and as described in sonatype publish maven artifact.
Then deploy using the ossrh-release profile as in
mvn -P ossrh-release deploy
This will sign and upload you artifact. Then go to stagingRepositories (login required, get a login at sonatype jira).
In there, 'close' the staging upload, which will check all requirements, such completeness of the upload, signed with pgp etc. When all tests passed, click the 'release' button on the almost top menu.
Once published, the artifact will appear on the central repo under sebivenlo part of central.