Let's suppose that I have a bunch of code that I need across a lot of projects, but just in tests.
So, I want to create a separated maven project for it, for example, carlos-test-utils, and ad it as a test dependency in my projects.
But, in my carlos-test-utils project, I also need JUnit. So, I add it as a test dependency, which obviously doesn't work, because I put my code in src/main/java.
I would like to hear which is the best way to deal with this kind of thing.
Put deps as provided?
Some dirty tricky thing to copy .java files across the projects?
Any other thing?
You can manage that via the maven-jar-plugin which should be used for such cases in the following way:
This should be done in the module/project which should provide the test classes and
the code should be put in the usual folder for test code src/test/java and not in src/main/java. All the dependencies your Test code needs should be added as usual dependencies with scope test.
<project>
...
<build>
<plugins>
...
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.6</version>
<executions>
<execution>
<goals>
<goal>test-jar</goal>
</goals>
</execution>
</executions>
</plugin>
...
</plugins>
</build>
...
</project>
In the project you like to use the test dependencies just use it like this:
<project>
...
<dependencies>
<dependency>
<groupId>groupId</groupId>
<artifactId>artifactId</artifactId>
<type>test-jar</type>
<version>version</version>
<scope>test</scope>
</dependency>
</dependencies>
...
</project>
Related
I'm tring to include a custom jar in my Spingboot application. In my case the additional jar contains a custom font for jasper Report.
This is my "system" decendency
<dependency>
<groupId>jasperFontOverrides</groupId>
<artifactId>jasperFontOverrides</artifactId>
<version>1.0.0</version>
<scope>system</scope>
<systemPath>${basedir}/lib/MyriadPro.jar</systemPath>
</dependency>
...
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<configuration>
<includeSystemScope>true</includeSystemScope>
</configuration>
</plugin>
</plugins>
</build>
The system package is visible while I debug my application in my IDE but when I'm done and I what to generate the package for production deploy
mvn install -DskipTests
My system package is not included the final jar.
Is there anything missing in my maven configuration?
If this is a multi-module project, you probably need to define the configuration section in the parent pom.
<configuration>
<includeSystemScope>true</includeSystemScope>
</configuration>
I have spent almost a day debugging this and it seems the configuration set in the child pom is not enough to get this to work. My guess is that the dependencies are calculated early in the build and the includeSystemScope option set in the child module is processed too late to be applied.
Is there a specific recommended approach to the inclusion of the spring-boot parent pom into projects that already have a required parent POM?
What do you recommend for projects that need to extend from an organizational parent (this is extremely common and even something many/most projects published to Maven central depending on the feeder repos they come from). Most of the build stuff is related to creating executable JARs (e.g. running embedded Tomcat/Jetty). There are ways to structure things so that you can get all the dependencies without extending from a parent (similar to composition vs. inheritance). You can't get a build stuff that way though.
So is it preferable to include all of the spring-boot parent pom inside of the required parent POM or to simply have a POM dependency within the project POM file.
Other options?
TIA,
Scott
You can use the spring-boot-starter-parent like a "bom" (c.f. Spring and Jersey other projects that support this feature now), and include it only in the dependency management section with scope=import.That way you get a lot of the benefits of using it (i.e. dependency management) without replacing the settings in your actual parent.
The 2 main other things it does are
define a load of properties for quickly setting versions of dependencies that you want to override
configure some plugins with default configuration (principally the Spring Boot maven plugin). So those are the things you will have to do manually if you use your own parent.
Example provided in Spring Boot documentation:
<dependencyManagement>
<dependencies>
<dependency>
<!-- Import dependency management from Spring Boot -->
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-dependencies</artifactId>
<version>2.1.3.RELEASE</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
Update 2022-05-29 with 1.5.9.RELEASE.
I have full code and runable example here https://github.com/surasint/surasint-examples/tree/master/spring-boot-jdbi/9_spring-boot-no-parent (see README.txt to see that you can try)
You need this as a basic
<dependencyManagement>
<dependencies>
<dependency>
<!-- Import dependency management from Spring Boot -->
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-dependencies</artifactId>
<version>${springframework.boot.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
But that is not enough, you also need explicitly define goal for spring-boot-maven-plugin (If you use Spring Boot as parent, you do not have to explicitly define this)
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<version>${springframework.boot.version}</version>
<executions>
<execution>
<goals>
<goal>repackage</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
Otherwise you cannot build as executable jar or war.
Not yet, if you are using JSP, you need to have this:
<properties>
<failOnMissingWebXml>false</failOnMissingWebXml>
</properties>
Otherwise, you will get this error message:
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-war-plugin:2.2:war (default-war) on project spring-boot-09: Error assembling WAR: webxml attribute is required (or pre-existing WEB-INF/web.xml if executi
ng in update mode) -> [Help 1]
NO NO , this is still not enough if you are using Maven Profile and Resource Filter with Spring Boot with "#" instead of "${}" (like this example https://www.surasint.com/spring-boot-maven-resource-filter/). Then you need to explicitly add this in
<resources>
<resource>
<directory>src/main/resources</directory>
<filtering>true</filtering>
</resource>
</resources>
And this in
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-resources-plugin</artifactId>
<version>2.7</version>
<configuration>
<delimiters>
<delimiter>#</delimiter>
</delimiters>
<useDefaultDelimiters>false</useDefaultDelimiters>
</configuration>
</plugin>
See the example in the link https://www.surasint.com/spring-boot-with-no-parent-example/.
As per Surasin Tancharoen's answer, you may also want to define maven surefire plugin
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>${maven-surefire-plugin.version}</version>
</plugin>
and possibly include fail-fast plugin
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-failsafe-plugin</artifactId>
<version>${maven-failsafe-plugin.version}</version>
<executions>
<execution>
<goals>
<goal>integration-test</goal>
<goal>verify</goal>
</goals>
</execution>
</executions>
</plugin>
I have a project Test-A, in this I have junit test class for the application.
Now, I have another project called Test-B, in this I have junit test class for the application.
Test-B, I have included project-A i.e modified POM.xml and included as:
POM.xml:
<dependency>
<groupId>com.abc.test-A</groupId>
<artifactId>TestA</artifactId>
<version>1.7</version>
<scope>test</scope>
</dependency>
question:
When I run mvn test for Test-B project, this has to run Test-A junit test files also. how can I run this kind of tests?
I am junit 4.9 version.
You will have to use the Maven Source Plugin to package the test source.
Here is an example for the build plugin to package the test source when you install or deploy the project:
<project>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-source-plugin</artifactId>
<version>2.2.1</version>
<executions>
<execution>
<id>attach-sources</id>
<phase>verify</phase>
<goals>
<goal>test-jar-no-fork</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>
You will have to add the dependency for the tests as a test-jar type:
<dependency>
<groupId>com.abc.test-A</groupId>
<artifactId>TestA</artifactId>
<version>1.7</version>
<type>test-jar</type>
<scope>test</scope>
</dependency>
Now you have access to the tests from artifact TestA that you can run directly.
Running tests for your project B will not run tests for any dependency. For example your project would also have a dependency to junit. You don't expect those tests to run.
I am following this Contract first using CXF tutorial and while the resulting pom.xml generates sources and even completes build successfully, it fails to create a WAR file.
Instead, it creates a JAR file.
My understanding is that the part in the pom.xml that's responsible for creating the WAR is:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.1.1</version>
<configuration>
<outputDirectory>D:/path/to/profile/autodeploy</outputDirectory>
</configuration>
</plugin>
I don't see any <goal> or <execution> element there (unlike in the build-helper-maven-plugin one), but I also understand that with this plugin this is implied as even the official usage page demonstrates:
<project>
...
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.4</version>
<configuration>
<webappDirectory>/sample/servlet/container/deploy/directory</webappDirectory>
</configuration>
</plugin>
</plugins>
</build>
...
</project>
So... what am I missing?
What could possibly explain a maven-war-plugin that behaves in unexpected way like this and produces a JAR instead of a WAR by default?
Is there a way to force it to produce a WAR?
packaging should be as below.
<packaging>war</packaging>
if it won't help then try binding your plug-in configuration with a lifecycle phase.
in your project definition , please check if packaging is missing or not , it should be some thing like this .
<groupId>some.groupid</groupId>
<artifactId>My Web Application</artifactId>
<version>0.0.1</version>
<packaging>war</packaging>
<description>My First Web Application</description>
By default maven war plugin binds to package phase of the lifecycle ,so its important that we should mention the type of packaging we want once the build is done.
I would like to suggest to have a look at the Maven specs for war plugin.
I have created a Maven plugin (called unpackTemplates) that unpacks a dependency jar file and copies resource files (in this case, templates) from it into a specific location in a project.
Right now, I put the following into the pom file of every project that has a dependency with templates. It looks like:
<project>
<groupId>DuriansAreDope</groupId>
<artifactId>DuriansAreDope</artifactId>
<version>0.0.1-SNAPSHOT</version>
<build>
<plugin>
<groupId>mycorp</groupId>
<artifactId>unpackTemplates</artifactId>
<version>1.0</version>
<executions>
<execution>
<configuration>
<groupId>com.mycorp.lib</groupId>
<version>1.0</version>
<artifactId>Lib-With-Templates</artifactId>
</configuration>
<goals>
<goal>unpackTemplates</goal>
</goals>
<phase>generate-sources</phase>
</execution>
</executions>
</plugin>
<pluginManagement>....</pluginManagement>
</build>
<dependencies>
<dependency>
<groupId>com.mycorp.lib</groupId>
<artifactId>Lib-With-Templates</artifactId>
<version>1.0</version>
</dependency>
</dependencies>
</project>
The above project pom works for us. It calls the plugin and the plugin does it's job. However, we'd like to avoid adding the plugin section to the pom of every project.
It would make more sense to put that plugin section in the dependencies pom. This way the project pom does not need to be modified beyond adding the <dependency> tags as usual. And the dependency has it's plugin run wherever it is installed.
I've seen that the pom file for Gson contains a <build><plugins>...</plugins></build> section in it. When I give my dependencies the following pom files, however, the plugin is not run (although the dependency is found, downloaded, installed, etc correctly).
<project>
<groupId>com.mycorp.lib</groupId>
<artifactId>Lib-With-Templates</artifactId>
<version>1.0</version>
<build>
<plugin>
<groupId>mycorp</groupId>
<artifactId>unpackTemplates</artifactId>
<version>1.0</version>
<executions>
<execution>
<configuration>
<groupId>com.mycorp.lib</groupId>
<version>1.0</version>
<artifactId>Lib-With-Templates</artifactId>
</configuration>
<goals>
<goal>unpackTemplates</goal>
</goals>
<phase>generate-sources</phase>
</execution>
</executions>
</plugin>
<pluginManagement>....</pluginManagement>
</build>
</project>
Any ideas what I'm doing wrong, or if the Gson pom is simply doing something else entirely?
(NB: The groupId/version/artifactIds in <configuration> are necessary because they are (string) parameters to the plugin; presumably if I got the run-straight-from-dependency approach working I could refactor them away, but again, it's not even running the kludgy version with parameters.)
two points:
First I agree with khmarbaise in that you don't need a plugin of your own for those tasks. To unpack to a specific location you can use dependency:unpack-dependencies and outputDirectory parameter.
If you need more configuration you can use the assembly plugin to structure your artifact (which you want to unpack).
For the second point it seems to me that you want to use the contents of your lib-with-templates in many projects. Why don't you add the plugin and dependency to a parent pom which you include in every pom where you need it? Then you don't need to declare it in "every pom". If you don't really need it in every pom you can put it in a profile and choose a proper activation for it.
HTH!