I have a EAR project that I want automatize the building process using maven exclusively.
The EAR project has
Standard jar modules
Web modules
EJB modules
RAR modules
To be able to execute the product in Jboss 4.2.3 and WebSphere 7 the EJB and RAR descriptors must be configured in different way. Also we have one jar library for each app server.
What I want is to be able to build one EAR for each apps server using the same projects, and for that I need
Include a JAR module depending of the app server
Use the customized descriptor in the EJB/RAR modules depending of
the app server
Package all this customized modules in an EAR
Can this be done using the same set of project in maven?
Sure. Have a look at profiles in maven. They allow you to adjust various things (from the link) like:
<repositories>
<pluginRepositories>
<dependencies>
<plugins>
<properties> (not actually available in the main POM, but used behind the scenes)
<modules>
<reporting>
<dependencyManagement>
<distributionManagement>
a subset of the element, which consists of:
<defaultGoal>
<resources>
<testResources>
<finalName>
The best is to create separate modules like ear-websphere, or ear-jboss and make an appropriate pom file which contains the needed configuration for maven-ear-plugin.
Related
We have a project called core-services. This builds three jars:
core-services-client Contains all client classes
core-services-server: Contains all server and client classes
core-services-test: Contains all junit classes
Right now, I build the core-services-server jar by default, and then use assemblies to build the client and test jars. If a developer wants to use the client or test jars, they must specify a classifier. However, when they want to depend upon the server jar, they don't specify a classifier.
This will lead to developers just using the server jar when they really should be using the client jar. I'd like to build all three jars to require a classifier when using them as a dependency. However, I can't do this when specifying the project:
<groupId>com.vegicorp</groupId>
<artifactId>core-services</artifactId>
<version>1.0.0</version>
<classifier>server</classifier>
<packaging>jar</packaging>
I know I can use <finalName> to call the default jar core-services-server, but I want to make sure that if a developer depends upon the core-services, they must say whether they want the server, the client, or the testing classes. If I merely rename it, they will get the server jar by default.
How can I specify that the default jar has a classifier of server?
I figured it out. I can put the default classifier into the maven-jar-plugin configuration in my pom.xml:
<plugin>
<artifactId>maven-jar-plugin</artifactId>
<!-- All other configuration information is in the parent pom -->
<configuration>
<classifier>server</classifier>
</configuration>
</plugin>
When I do mvn deploy, I get a warning that No primary artifact to deploy, deploying attached artifacts instead, and all three jars deploy with classifiers.
I have a multi-module spring-boot project that I want to deploy on Openshift, where I have installed Jenkins as well. Source code is hosted in Github.
Each module consists in a war, in order to have a microservices structure:
<modules>
<module>xyz-common</module>
<module>xyz-data-services</module> <!--a REST service to interact with mongodb-->
<module>xyz-batch-importer</module> <!--a service to import files into Mongo-->
<module>xyz-frontend</module>
</modules>
I found tutorial to deploy single spring-boot application, but I cannot figure out how this applies to a multi-module maven project.
If you want to work with multi-module maven project on openshift, then you have to tell openshift how to build them. You can achieve this task by defining build environment variables or writing custom build scripts which can be interpreted by Openshift.
For both method you can follow this tutorial:
If you want to work with first method, you can tell openshift to use additional maven commands while building process by defining "MAVEN_ARGS_APPEND" variable for build config.
So when the build operation starts on openshift, it will tell Maven that build the application with these additional parameters.
Define additional build environment variables that listed below to deploy war modules independently:
MAVEN_ARGS_APPEND: -pl modulename --also-make
ARTIFACT_DIR: modulename/target/
MODULE_DIR: modulename
In here "-pl" command provides to build "xyz-data-services" with its all dependencies. So if your "xyz-data-services" module has dependency to "xyz-common", then maven will build "xyz-common", create related artifacts for "xyz-data-services" ,package them together and deploy "xyz-data-services" as war on the pod.
In your case, suppose that you want to package "xyz-data-services" module and "xyz-front-end" module as war and deploy them.
Case 1:
If you want to make these modules self deployable, then you have to create two applications which will run on different pods.
First application will have these build environment variables:
MAVEN_ARGS_APPEND: -pl xyz-data-services --also-make
ARTIFACT_DIR: xyz-data-services/target/
MODULE_DIR: xyz-data-services
And the second one will have these guys:
MAVEN_ARGS_APPEND: -pl xyz-front-end --also-make
ARTIFACT_DIR: xyz-front-end/target/
MODULE_DIR: xyz-front-end
Case 2:
If you want to deploy these modules into same pod, then you can add an additional module to your project which packages both wars into single ear and define the variables for this ear.
So let this ear be "webapp", your parent pom will look like;
...
<modules>
<module>xyz-common</module>
<module>xyz-data-services</module>
<module>xyz-batch-importer</module>
<module>xyz-frontend</module>
<module>xyz-webapp</module>
</modules>
...
and the xyz-webapp pom will look like;
....
<artifactId>xyz-webapp-</artifactId>
<dependencies>
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>xyz-common</artifactId>
<version>${project.version}</version>
<type>jar</type>
</dependency>
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>xyz-data-services</artifactId>
<version>${project.version}</version>
<type>war</type>
</dependency>
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>xyz-frontend</artifactId>
<version>${project.version}</version>
<type>war</type>
</dependency>
</dependencies>
....
So your build environment variables will be;
MAVEN_ARGS_APPEND: -pl xyz-webapp --also-make
ARTIFACT_DIR: xyz-webapp/target/
MODULE_DIR: xyz-webapp
If you want to work with just single war and single pod then;
Case 3:
You can just package front-end application as war and declare dependencies to other modules which all packaged as ".jars"
You can go on with which case do you want. It's important here that it depends on your "microservices" implementation. Because the "microservice" term and the implementation is not explicitly defined and it can vary on the architecture or some business requirements, it's your decision that packaging front-end,api,backend together or manage them independently.
I have a project with a couple of dozen Eclipse plugins, all inter-related and living in different subfolders. The build was converted to a multi-module manifest-first Tycho build a couple of years ago and it works quite well.
One of the plugins is rather key, and can also be built as a standalone Java app, which doesn't use an Eclipse runtime. Currently it has its own POM file (pom-standalone.xml) so that Jenkins can build the standalone app separately and the Tycho build knows nothing about it - the pom-standalone just lists the previously-built plugin jars (thanks Tycho!) and Eclipse libraries that it needs as dependencies. Couple problems with this approach though:
I cannot easily use IntelliJ to work on the standalone project with Maven dependency management, because it doesn't recognize the custom pom-standalone.xml filename as a POM.
The many jars that this project relies on are checked in to the project for the sake of Tycho and the Eclipse Manifest file, but they're also managed by Maven for the standalone build. So any dependencies have to be added to the pom-standalone.xml file AND entered into the OSGi manifest AND checked in to the source control for Eclipse purposes.
It seems like a straightforward workaround would be to tell Tycho/modules to use something other than pom.xml for the submodule's POM, or perhaps all the multimodule POM files, since Eclipse doesn't use those anyway - then the pom-standalone.xml can be converted to pom.xml and then IntelliJ will be fine with it.
I know you can specify the -f attribute to Maven builds, but will that really apply to all submodules? Can you specify the POM filename for just ONE submodule?
Are there alternative solutions? Eclipse/Tycho/p2 builds seem somewhat of a headache requiring manual library management and checking in libraries to source control, but maybe there have been changes I'm not aware of in the Eclipse build world the last few years.
Found a Similar Question that didn't help much.
You can include projects in an aggregator POM by specifying the full name to the POM file with custom name. Example:
<modules>
<module>org.example.bundle1</module>
<module>org.example.bundle2</module>
<module>org.example.keybundle/pom-tycho.xml</module>
</modules>
This both works in a pure Maven and Maven/Tycho build.
To extend #oberlies answer a little bit:
SCENARIO: top aggregation POM comes in multiple flavors, so any style can be built from the top.
<!-- in file pom.xml -->
<modules>
<module>org.example.bundle1</module>
<module>org.example.bundle2</module>
<module>org.example.keybundle</module>
</modules>
All submodules will be built using their standard pom.xml
and
<!-- in file pom-tycho.xml -->
<modules>
<module>org.example.bundle1/pom.xml</module>
<module>org.example.bundle2/pom.xml</module>
<module>org.example.keybundle/pom-tycho.xml</module>
</modules>
Submodules will be built using the specifically named POM file.
and, likewise:
<!-- in file pom-special.xml -->
<modules>
<module>org.example.bundle1/pom.xml</module>
<module>org.example.bundle2/pom-special.xml</module>
<module>org.example.keybundle/pom-tycho.xml</module>
</modules>
Submodules that have custom POM files use them, and others state they still want the normal POM file, all independent of the name of the top aggregation POM file.
Because mvn -f pom-tycho.xml assumes that file name in all submodules. So if you do want pom.xml in any submodule when the top file isn't named pom.xml you need to fully specify for each submodule.
Is there a way to have a single Spring Boot project be packagable into both JAR and WAR without changing the pom.xml or the application source?
I've read Converting a Spring Boot JAR Application to a WAR, but it converts the project to WAR and it loses the ability to be packaged as JAR.
I don't expect mvn package to do both. What I want is something like mvn i-want-a-jar and it would package the project as JAR. Or I could run mvn i-want-a-war and it would package the project as WAR.
Is this possible?
I managed to do it by adding
<packaging>${packaging.type}</packaging>
to the POM file and then setting different profiles for JAR and WAR:
<profiles>
<profile>
<id>jar</id>
<properties>
<packaging.type>jar</packaging.type>
</properties>
</profile>
<profile>
<id>war</id>
<properties>
<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>
Now mvn package -P war produces a WAR and mvn package -P jar produces a JAR.
Another option is to create separate modules for JAR and WAR, but I didn't go that route.
What's wrong with a WAR file that's executable? Isn't that what you really need?
P.S. like
java -jar name.war
We've recently had a similar requirement, where an existing Spring Boot based project that was originally packaged as an executable Jar needed to support Tomcat and WildFly deployments.
Due to some dependencies used in this project (for example WebJars), a simple switch to WAR package wasn't an option since some of those dependencies were required for WildFly (VFS support) but not for other deployment.
The solution was to restructure the project modules in a way that core module contained the actual project but without having Spring Boot’s plugin applied, while several package modules would depend on core module and configure deployment artifact specifics (Boot and other plugins, deployment specific dependencies etc.).
That way project build was able to generate multiple deployment artifacts (Boot's executable JAR, traditional WAR and WildFly specific WAR) in a single build run.
In case anyone finds this useful, the sample project to demonstrate the approach is available on Github. The project can be built by either Gradle or Maven.
I am using Spring in two 2 projects. First, I have a "web" project which depends on my second project that is a normal java project with maven nature enabled that I named "core".
So, in my "web" project I just add the reference of my "core" project:
<dependency>
<groupId>com.stackoverflow</groupId>
<artifactId>core</artifactId>
<version>0.0.1-SNAPSHOT</version>
<type>jar</type>
</dependency>
If I set the property "useProjectReferences" to false like here, everything works fine, But I am in developing phase, I don't wanna run maven install everytime I have a change in my "core" project.
I am running my projects in tomcat, so I can't package them in ear. All that I want is Maven export my "src/main/resources" source folder to Spring be able to find my coreContext.xml and bind my beans. What I have tried in my "core" pom.xml:
<build>
<resources>
<resource>
<directory>${basedir}src/main/resources</directory>
<targetPath>${basedir}WEB-INF/resources</targetPath>
</resource>
...
I tried to use shade-plugin but without success too. Any tip would be appreciated.
My suggestion would be to create a Multi Module Maven Project which contains both the core and web projects.