I have a project which can be packaged and deployed two different ways, it's either a WAR for Tomcat, or a shaded JAR for AWS Lambda. Currently this isn't working very well, I have to keep changing the pom.xml back and forth when doing a release. Is there a way to accomplish this with Maven profiles?
e.g., I'd like to do
mvn install -Pwar
to generate the WAR, and
mvn install -Plambda
to generate the shaded JAR.
Is this possible?
You can try to include the following in your pom.xml
<packaging>${packaging.type}</packaging>
<profiles>
<profile>
<id>lambda</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<properties>
<packaging.type>jar</packaging.type>
</properties>
</profile>
<profile>
<id>war</id>
<properties>
<packaging.type>war</packaging.type>
</properties>
</profile>
</profiles>
Related
I need to create different application properties for a spring boot project and include the proper one in the generated war. I'm able to generate a war, but no to include the proper file in it. I have different profiles created, and different application.properties following the pattern application-env.properties where env is (dev, cert...), all of then placed in src/main/resources but I'm not able to pick the proper one and include in the generated war, even including "-Dspring.profiles.active=cert" to define the profile active. The war is generated with all of them. Any idea?
<profiles>
<profile>
<id>dev</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<properties>
<build.profile.id>dev</build.profile.id>
<packaging.type>jar</packaging.type>
<spring.profiles.active>dev</spring.profiles.active>
</properties>
</profile>
<profile>
<id>cert</id>
<properties>
<build.profile.id>cert</build.profile.id>
<spring.profiles.active>cert</spring.profiles.active>
<packaging.type>war</packaging.type>
</properties>
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-tomcat</artifactId>
<scope>provided</scope>
</dependency>
</dependencies>
</profile>
</profiles>
I am developing one java app and I made pom.xml with database URL I am using:
<profiles>
<profile>
<id>development</id>
<properties>
<db.url>jdbc:mysql://project.******.eu-central-1.rds.amazonaws.com:3306</db.url>
</properties>
</profile>
<profile>
<id>validation</id>
</profile>
</profiles>
Problem is I am using version control and I would not want to submit my specific configuration. What is the best way to handle this?
You can put the information in your personal settings.xml.
edit: And you should use encryption to save your credentials.
Put this type of configuration outside of your pom file. There is no one right answer here... just use a personal settings or properties file or something to that effect. Then just omit that file from version control.
in user home folder /.m2/settings.xml I have put this, works nice. Thanks!
<settings>
<profiles>
<profile>
<id>development</id>
<properties>
<db.url>jdbc:mysql://project.******.eu-central-1.rds.amazonaws.com:3306</db.url>
</properties>
</profile>
<profile>
<id>validation</id>
</profile>
</profiles>
<settings>
I have a spring boot application where I want to package it according to the profile I am building with, for example when I issue profile x, I want maven to build as a jar; but when building with profile y, I want maven to build as a war.
I want something like:
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.mycompany.app</groupId>
<artifactId>my-app</artifactId>
<version>1.0.0</version>
<package>${buildMethod}</package>
</project>
Where ${buildMethod} is the type of packaging.
This would be decided by executing a command i.e. mvn package -P buildProfile.
Maybe this would help:
<profiles>
<profile>
<id>war</id>
<properties>
<deploy.type>war</deploy.type>
</properties>
</profile>
<profile>
<id>jar</id>
<properties>
<deploy.type>jar</deploy.type>
</properties>
</profile>
</profiles>
And then just use this property placeholder ${deploy.type}.
You can easily add profiles, with a list of properties, to your pom file.
Build using:
mvn package - Builds a WAR by default (implicit)
mvn package -P deployWar - Builds a WAR
mvn package -P deployJar - Builds a JAR
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.mycompany.app</groupId>
<artifactId>my-app</artifactId>
<version>1.0.0</version>
<package>${deployment.type}</package>
<profiles>
<!-- This profile deploys the application as a WAR (default) -->
<profile>
<id>deployWar</id>
<properties>
<deployment.type>war</deployment.type>
</properties>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
</profile>
<!-- This profile deploys the application as a JAR -->
<profile>
<id>deployJar</id>
<properties>
<deployment.type>jar</deployment.type>
</properties>
</profile>
</profiles>
</project>
We have a Maven 2 project with lots of modules in it. Example:
<modules>
<module>common</module>
<module>foo</module>
<module>data</module>
<module>bar</module>
... more ...
</module>
Let's say the "data" module is time consuming to build and we want to exclude it when the project is build by a CI server. Currently we use two pom.xml files to achieve this. One has all modules in it and the other one has all modules except the ones which can be left out for CI. But that's pretty annoying because sometimes we forget to put a new module into both files.
Is there a solution which doesn't need two separate module lists?
With Maven 3.2.1, you can now use -pl !<module_name>,!<module_name> to exclude certain modules from the reactor build.
See this feature request: https://issues.apache.org/jira/browse/MNG-5230
The easiest might be to use profiles like this:
<project>
...
<modules>
<module>common</module>
<module>foo</module>
<module>bar</module>
<modules>
...
<profiles>
<profile>
<id>expensive-modules-to-build</id>
<modules>
<module>data</module>
</modules>
</profile>
</profiles>
</project>
You should then check out ways you can activate profiles
The projects to build can also be specified on the mvn command line. This would remove the need for a separate pom, but instead you would have to change the CI configuration everytime there is a new module.
-pl,--projects <arg> Comma-delimited list of specified
reactor projects to build instead
of all projects. A project can be
specified by [groupId]:artifactId
or by its relative path.
Maybe a combination of this flag and --also-make-dependents or --also-make would reduce this maintenance burden again.
-am,--also-make If project list is specified, also
build projects required by the
list
-amd,--also-make-dependents If project list is specified, also
build projects that depend on
projects on the list
I assume you want the default build to always build everything, regardless of speed, so that new developers can get started quickly without having to understand lots about the POM. You can use profiles like this:
<modules>
<module>common</module>
<module>foo</module>
<module>bar</module>
</modules>
...
<profiles>
<profile>
<id>expensive-modules-to-build</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<modules>
<module>data</module>
</modules>
</profile>
</profiles>
</project>
The problem with this is that if a developer specifies another profile on the command line, then the expensive-modules-to-build isn't included (unless the developer also specifies it). This makes it complicated to remember which profiles need to be included.
Here is a hacky way around that. Both profiles are always included, because the pom.xml file always exists. So to exclude the expensive modules, you can use -P!full-build on the command line.
<profiles>
<profile>
<id>full-build</id>
<activation>
<file>
<exists>pom.xml</exists>
</file>
</activation>
<modules>
<module>data</module>
</modules>
</profile>
<profile>
<id>short-build</id>
<activation>
<file>
<exists>pom.xml</exists>
</file>
</activation>
<modules>
<module>common</module>
<module>foo</module>
<module>bar</module>
</modules>
</profile>
</profiles>
Another idea: Reactor modules can be nested, so it should be possible to group your fast and slow-building modules into separate poms and then add another aggregator pom containing these two as modules. Your CI Server could then only reference the pom containing the fast building modules.
<artifactId>fast</artifactId>
<modules>
<module>fast-a</module>
<module>fast-b</module>
<module>fast-c</module>
</module>
<artifactId>all</artifactId>
<modules>
<module>fast</module>
<module>slow</module>
</module>
You could be to use maven profiles. In our build environment, we created a profile quick that disables many plugins and test execution.
This is done by
<profile>
<id>quick</id>
<properties>
<skipTests>true</skipTests>
<!-- others... -->
</properties>
<build>
<plugins>
<!-- configuration... -->
</plugins>
</build>
</profile>
And then we invoke maven the following way
mvn groupId:artifactId:goal -P quick
You could maybe disable compilation and other standard plugins in the pom of your module to speed it up.
Not exactly the answer these folks were asking for. My situation was I wanted to deploy only the parent pom. I'm using the spring-boot-thin-layout in a child module. This requires the parent module be deployed into artifactory. I added the following into my project. It enables skipping of install and/or deploy phase.
In my parent pom:
<properties>
<disable.install>true</disable.install>
<disable.deploy>true</disable.deploy>
<enable.deployAtEnd>true</enable.deployAtEnd>
</properties>
<profiles>
<profile>
<id>deploy-parent</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<properties>
<disable.install>true</disable.install>
<disable.deploy>true</disable.deploy>
<deployAtEnd>${enable.deployAtEnd}</deployAtEnd>
</properties>
<build>
<finalName>${project.version}</finalName>
</build>
</profile>
</profiles>
And the in my child pom(s) or any module you don't want deployed with parent:
<properties>
<maven.install.skip>${disable.install}</maven.install.skip>
<maven.deploy.skip>${disable.deploy}</maven.deploy.skip>
<deployAtEnd>${enable.deployAtEnd}</deployAtEnd>
</properties>
So effectively when I run mvn deploy on the parent pom, it will compile all the modules, not run install on anything, and then at the end deploy any module not having <maven.deploy.skip>${disable.deploy}</maven.deploy.skip> in it's properties. So in my case only deploying the parent.
I've set up a Maven project for a SWT application. This application runs on several platforms (OS X, Windows 64-bit, Windows 32-bit, Linux 64-bit and Linux 32-bit) and I've set it up so that the platform is detected when Maven is run and the packaged application goes to different destination directories. Here are the relevant parts from pom.xml to achieve this:
<profiles>
<profile>
<id>linux_x86_64</id>
<activation>
<os>
<name>linux</name>
<arch>amd64</arch>
</os>
</activation>
<build>
<directory>${project.basedir}/target/${project.version}/linux_x86_64</directory>
</build>
</profile>
<profile>
<id>win32_x86_64</id>
<activation>
<os>
<name>linux</name>
<arch>i386</arch>
</os>
</activation>
<build>
<directory>${project.basedir}/target/${project.version}/win32_x86_64</directory>
</build>
</profile>
...
</profiles>
And the dependency used for SWT is this:
<dependencies>
<dependency>
<groupId>org.eclipse</groupId>
<artifactId>swt</artifactId>
<version>3.7.2.v3740</version>
</dependency>
...
</dependencies>
To make things clear, I have installed in my local repository the SWT dummy package (org.eclipse.swt_3.7.2.v3740f.jar) and all the platform-specific ones (org.eclipse.swt.gtk.linux.x86_64_3.7.2.v3740f, org.eclipse.swt.win32.x86_64_3.7.2.v3740f, etc.).
The way I pack dependencies is with a "lib" folder using the maven-dependency-plugin and Maven is smart enough to copy both the SWT dummy package and the platform-specific one of the machine where I'm packaging the application. So far so good...
The problem is that I would like to compile the application for the different platforms from a single machine. How would I achieve this?
I've tried setting up a property in each profile with the SWT jar needed for each platform, like this (example for Windows 64-bit):
<properties>
<swt.artifactId>swt.win32.x86_64</swt.artifactId>
<swt.version>3.7.2</swt.version>
</properties>
But taking this approach both the profile-specific SWT jar and the platform-specific one where I'm running Maven get copied into the "lib" directory, ending up with three jars:
swt-3.7.2.v3740.jar
swt.gtk.linux.x86_64-3.7.2.jar
swt.win32.x86_64-3.7.2.jar
Is there a way in which I could specify a profile ignoring the machine where I'm running it so that I don't need to manually remove its SWT jar?
Thanks in advance.
Not sure how the depency-plugin handles it, but it should work if you have only one dependency like this one:
<dependency>
<groupId>${swt.groupId}</groupId>
<artifactId>${swt.artifactId}</artifactId>
<version>3.7.2</version>
<scope>compile</scope>
</dependency>
And then profiles like these:
<profile>
<id>gtk_linux_x86_64</id>
<activation>
<os>
<name>linux</name>
<arch>x86_64</arch>
</os>
</activation>
<properties>
<swt.groupId>org.eclipse.swt.gtk.linux</swt.groupId>
<swt.artifactId>x86_64</swt.artifactId>
</properties>
</profile>
Now the needed version of SWT get's used automatically, but can be set to what you need (e.g. when building a release) as well using:
mvn -P gtk_linux_x86_64
Note: Change your groupId and artifactId as needed.