Not able to deploy mule 4 application in on-premise using Jenkins pipeline - jenkins

I'm trying to deploy mule 4 application using jenkin pipeline but in the deployement process getting the below mentioned error:
[ERROR] Failed to execute goal org.mule.tools.maven:mule-maven-plugin:3.3.5:deploy (default-deploy) on project helloworld: Execution default-deploy of goal org.mule.tools.maven:mule-maven-plugin:3.3.5:deploy failed: Mule Runtime is not running!
Adding my pom.xml.
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.mycompany</groupId>
<artifactId>helloworld</artifactId>
<version>1.0.0-SNAPSHOT</version>
<packaging>mule-application</packaging>
<name>helloworld</name>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
<app.runtime>4.2.2</app.runtime>
<mule.maven.plugin.version>3.3.5</mule.maven.plugin.version>
<proejct.site.deploy.url>E:\IDFC\mule-enterprise-standalone-4.2.2\apps</proejct.site.deploy.url>
</properties>
<build>
<plugins>
<plugin>
<groupId>org.mule.tools.maven</groupId>
<artifactId>mule-maven-plugin</artifactId>
<version>${mule.maven.plugin.version}</version>
<extensions>true</extensions>
<configuration>
<standaloneDeployment>
<muleHome>E:\IDFC\mule-enterprise-standalone-4.2.2</muleHome>
<muleVersion>4.2.2</muleVersion>
</standaloneDeployment>
</configuration>
</plugin>
<plugin>
<artifactId>maven-deploy-plugin</artifactId>
<executions>
<execution>
<id>default-deploy</id>
<phase>deploy</phase>
<goals>
<goal>deploy</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
<dependencies>
<dependency>
<groupId>org.mule.connectors</groupId>
<artifactId>mule-http-connector</artifactId>
<version>1.5.11</version>
<classifier>mule-plugin</classifier>
</dependency>
<dependency>
<groupId>org.mule.connectors</groupId>
<artifactId>mule-sockets-connector</artifactId>
<version>1.1.5</version>
<classifier>mule-plugin</classifier>
</dependency>
<dependency>
<groupId>org.mule.connectors</groupId>
<artifactId>mule-db-connector</artifactId>
<version>1.5.5</version>
<classifier>mule-plugin</classifier>
</dependency>
</dependencies>
<repositories>
<repository>
<id>anypoint-exchange-v2</id>
<name>Anypoint Exchange</name>
<url>https://maven.anypoint.mulesoft.com/api/v2/maven</url>
<layout>default</layout>
</repository>
<repository>
<id>mulesoft-releases</id>
<name>MuleSoft Releases Repository</name>
<url>https://repository.mulesoft.org/releases/</url>
<layout>default</layout>
</repository>
</repositories>
<pluginRepositories>
<pluginRepository>
<id>mulesoft-releases</id>
<name>mulesoft release repository</name>
<layout>default</layout>
<url>https://repository.mulesoft.org/releases/</url>
<snapshots>
<enabled>false</enabled>
</snapshots>
</pluginRepository>
</pluginRepositories>
in Jenkins till build it's working but while deploying i'm getting error.
For the deploy process Using custom workspace Directory and executing the custom batch command mvn package deploy -DmuleDeploy.
Here it's failing with the below added error.
This is my standalone server where i have to deploy: C:\AnypointStudio\mule-enterprise-standalone-4.2.2\apps
Can you please check my pom.xml anything else do i need to add there?
let me know where I am doing wrong to deploy on standalone server?

The Mule Maven Plugin is complaining that the target standalone Mule Runtime at C:\AnypointStudio\mule-enterprise-standalone-4.2.2\ is not running. The log error says as much: Mule Runtime is not running!. The documentation for the standalone deployment configuration seems to imply that it should be executing.
You'll need to ensure it is up and running before trying to deploy to it.
Note, installing a standalone Mule Runtime inside a directory called AnypointStudio is a bit confusing. The standalone runtime is not part of Anypoint Studio nor it interacts with Studio in any way.

Related

How to upgrade from Vaadin 23 to Vaadin 24?

I used the Plain Java starter app from the Hello World Starters page of downloads.
I updated its Maven POM to the latest versions of dependencies. So Vaadin 23.3.1, Java 19, jetty-maven-plugin 10.0.12, and so on. The POM looks like this:
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns = "http://maven.apache.org/POM/4.0.0"
xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation = "http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.example</groupId>
<artifactId>project-base</artifactId>
<name>Project base for Vaadin</name>
<version>1.0-SNAPSHOT</version>
<packaging>war</packaging>
<properties>
<maven.compiler.source>19</maven.compiler.source>
<maven.compiler.target>19</maven.compiler.target>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
<failOnMissingWebXml>false</failOnMissingWebXml>
<vaadin.version>23.3.1</vaadin.version>
<drivers.downloader.phase>pre-integration-test</drivers.downloader.phase>
</properties>
<repositories>
<!-- The order of definitions matters. Explicitly defining central here to make sure it has the highest priority. -->
<repository>
<id>central</id>
<url>https://repo.maven.apache.org/maven2</url>
<snapshots>
<enabled>false</enabled>
</snapshots>
</repository>
<repository>
<id>vaadin-prereleases</id>
<url>
https://maven.vaadin.com/vaadin-prereleases/
</url>
<snapshots>
<enabled>false</enabled>
</snapshots>
</repository>
<!-- Repository used by many Vaadin add-ons -->
<repository>
<id>Vaadin Directory</id>
<url>https://maven.vaadin.com/vaadin-addons</url>
<snapshots>
<enabled>false</enabled>
</snapshots>
</repository>
</repositories>
<pluginRepositories>
<!-- The order of definitions matters. Explicitly defining central here to make sure it has the highest priority. -->
<pluginRepository>
<id>central</id>
<url>https://repo.maven.apache.org/maven2</url>
<snapshots>
<enabled>false</enabled>
</snapshots>
</pluginRepository>
<pluginRepository>
<id>vaadin-prereleases</id>
<url>
https://maven.vaadin.com/vaadin-prereleases/
</url>
<snapshots>
<enabled>false</enabled>
</snapshots>
</pluginRepository>
</pluginRepositories>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>com.vaadin</groupId>
<artifactId>vaadin-bom</artifactId>
<type>pom</type>
<scope>import</scope>
<version>${vaadin.version}</version>
</dependency>
</dependencies>
</dependencyManagement>
<dependencies>
<dependency>
<groupId>com.vaadin</groupId>
<!-- Replace artifactId with vaadin-core to use only free components -->
<artifactId>vaadin</artifactId>
</dependency>
<!-- Added to provide logging output as Vaadin uses -->
<!-- the unbound SLF4J no-operation (NOP) logger implementation -->
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-simple</artifactId>
</dependency>
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>javax.servlet-api</artifactId>
<version>4.0.1</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>com.vaadin</groupId>
<artifactId>vaadin-testbench</artifactId>
<scope>test</scope>
</dependency>
<!-- https://mvnrepository.com/artifact/io.github.bonigarcia/webdrivermanager -->
<dependency>
<groupId>io.github.bonigarcia</groupId>
<artifactId>webdrivermanager</artifactId>
<version>5.3.1</version>
<scope>test</scope>
</dependency>
</dependencies>
<build>
<defaultGoal>jetty:run</defaultGoal>
<plugins>
<!-- Define newer versions of Java compiler and war plugin to
better support the latest JDK versions. -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.10.1</version>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>3.3.2</version>
</plugin>
<!-- Jetty plugin for easy testing without a separate server -->
<plugin>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-maven-plugin</artifactId>
<version>10.0.12</version>
<configuration>
<!--
Configures automatic reload of Jetty server
(with 2 second timeout) when new classes are compiled
(e.g. by IDEs).
Should be disabled when using a proper live reload system,
such as JRebel.
If using IntelliJ IDEA with autocompilation, this
might cause lots of unnecessary compilations in the
background. Consider using "0" and trigger restart manually
by hitting enter.
-->
<scan>2</scan>
<!-- Use war output directory to get the webpack files -->
<!--<webAppConfig>-->
<!-- <allowDuplicateFragmentNames>true</allowDuplicateFragmentNames>-->
<!--</webAppConfig>-->
</configuration>
</plugin>
<!--
Take care of synchronizing java dependencies and imports in
package.json and main.js files.
It also creates webpack.config.js if not exists yet.
-->
<plugin>
<groupId>com.vaadin</groupId>
<artifactId>vaadin-maven-plugin</artifactId>
<version>${vaadin.version}</version>
<executions>
<execution>
<goals>
<goal>prepare-frontend</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
<profiles>
<profile>
<!-- Production mode is activated using -Pproduction -->
<id>production</id>
<build>
<plugins>
<plugin>
<groupId>com.vaadin</groupId>
<artifactId>vaadin-maven-plugin</artifactId>
<version>${vaadin.version}</version>
<executions>
<execution>
<goals>
<goal>build-frontend</goal>
</goals>
<phase>compile</phase>
</execution>
</executions>
<configuration>
<productionMode>true</productionMode>
</configuration>
</plugin>
</plugins>
</build>
</profile>
<profile>
<id>it</id>
<build>
<plugins>
<plugin>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-maven-plugin</artifactId>
<configuration>
<!--<scanIntervalSeconds>0</scanIntervalSeconds>-->
<stopPort>8081</stopPort>
<stopWait>5</stopWait>
<stopKey>${project.artifactId}</stopKey>
</configuration>
<executions>
<execution>
<id>start-jetty</id>
<phase>pre-integration-test</phase>
<goals>
<goal>start</goal>
</goals>
</execution>
<execution>
<id>stop-jetty</id>
<phase>post-integration-test</phase>
<goals>
<goal>stop</goal>
</goals>
</execution>
</executions>
</plugin>
<!-- Runs the integration tests (*IT) after the server is started -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-failsafe-plugin</artifactId>
<version>3.0.0-M7</version>
<executions>
<execution>
<goals>
<goal>integration-test</goal>
<goal>verify</goal>
</goals>
</execution>
</executions>
<configuration>
<trimStackTrace>false</trimStackTrace>
<enableAssertions>true</enableAssertions>
</configuration>
</plugin>
</plugins>
</build>
</profile>
</profiles>
</project>
Now I would like to try the pre-release of Vaadin 24.
I understand this new version will have little new in terms of features or fixes. Instead, this new version is aimed at making the transition from being based on Java EE 8 to being based on Jakarta EE 10. As discussed in this Vaadin company blog page, this leap involves (a) the dropping of some deprecated features, and (b) the switching of package names from javax.* to jakarta.*. These changes are part of the transition from Oracle donating Java EE technologies to the Eclipse Foundation to become Jakarta EE.
Official instructions, plus my details
The Vaadin company blog page Vaadin 24 pre-release available for Spring Boot 3.0, provides some instructions for migrating from Vaadin 23 to Vaadin 24. I can supplement that page with more details.
First, migrate to latest Vaadin 23
That page first instructs us to migrate to the latest version of Vaadin 23, currently 23.3.5. We see you did that your existing Maven POM file.
Just be sure to run your app to verify Vaadin 23 is working well before trying Vaadin 24.
Java version
That page says to next ensure that your project can run on Java 17, the latest long-term support version.
We see you did that too in your existing POM, running on Java 19 (the current Java release).
Vaadin version
The official instructions point us to this GitHub page to capture the current latest version of Vaadin 24. There we find 24.0.0.alpha10.
So we paste that version number into the POM.
Servlet spec
Next, look for the javax.servlet-api entry in your POM.
Vaadin 23 and earlier was designed for Java Servlet Specification version 3.1, and is compatible with Java Servlet Spec 4.0.1.
As we jump to Jakarta 10, the name of the spec changes to Jakarta Servlet. And the Servlet Spec is version 6 in Jakarta EE 10. We can verify with a Maven repository such as this one that the latest subversion of Servlet 6 is 6.0.0.
So we change this part of the POM:
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>javax.servlet-api</artifactId>
<version>4.0.1</version>
<scope>provided</scope>
</dependency>
… to:
<!-- https://mvnrepository.com/artifact/jakarta.servlet/jakarta.servlet-api -->
<dependency>
<groupId>jakarta.servlet</groupId>
<artifactId>jakarta.servlet-api</artifactId>
<version>6.0.0</version>
<scope>provided</scope>
</dependency>
Jetty
Your Vaadin 23 app is bundled with an embedded version of Jetty. This enables you to run your Vaadin web app using Jetty as the deployment web app server within your IDE. This arrangement is convenient, relieving you of the chore of configuring an external web app server.
You may nevertheless choose to use an externally web app server running in its own process, such as Tomcat, a separately-installed Jetty, Glassfish, WildFly, Payara, OpenLiberty, or any of several other such products. But if you wish to use the embedded Jetty within your IDE, read on.
Your existing POM is set to use jetty-maven-plugin version 10.0.x. That corresponds to Jetty 10. That version of Jetty supports Servlet 4.
But we are moving to Servlet 6. That requires a different version of Jetty, Jetty 12. Unfortunately, Jetty 12 seems to be still in development, hosted on GitHub. But 12 is at the alpha stage as of 2023-01. If curious, see this 2022-04 talk on YouTube, Jakarta Tech Talk - Implementing Servlet 6.0 in Jetty.
So we have a predicament, if we want to run Jetty embedded conveniently within our IDE. Technically Vaadin 24 is built for Jakarta 10, which implies Servlet 6. But we only have Jetty 11 available to us, which supports Servlet 5 rather than Servlet 6. But perhaps we might be lucky to find that Vaadin 24, because it has no significant feature changes from Vaadin 23, may not actually be using any new features available only in Servlet 6, nor using any old features deleted from Servlet 6. If so, we may get away with using version of 11.0.13 of jetty-maven-plugin to utilize Jetty 5.
<!-- Jetty plugin for easy testing without a separate server -->
<plugin>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-maven-plugin</artifactId>
<version>11.0.13</version>
<configuration>
<!--
Configures automatic reload of Jetty server
(with 2 second timeout) when new classes are compiled
(e.g. by IDEs).
Should be disabeld when using a proper live reload system,
such as JRebel.
If using IntelliJ IDEA with autocompilation, this
might cause lots of unnecessary compilations in the
background. Consider using "0" and trigger restart manually
by hitting enter.
-->
<scan>2</scan>
<!-- Use war output directory to get the webpack files -->
<!--<webAppConfig>-->
<!-- <allowDuplicateFragmentNames>true</allowDuplicateFragmentNames>-->
<!--</webAppConfig>-->
</configuration>
</plugin>
Let’s try it, fingers crossed 🤞 … yes, success! Using embedded Jetty 11 with Vaadin 24 is working, at least for now.
Voilà
And that is all we need to do to migrate your Vaadin 23 app to Vaadin 24 (alpha 6).
You can use the Maven Jetty plugin command jetty:run to launch your web app just as you do with Vaadin 23.
Here is my resulting Maven POM file.
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns = "http://maven.apache.org/POM/4.0.0"
xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation = "http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.example</groupId>
<artifactId>project-base</artifactId>
<name>Project base for Vaadin</name>
<version>1.0-SNAPSHOT</version>
<packaging>war</packaging>
<properties>
<maven.compiler.source>19</maven.compiler.source>
<maven.compiler.target>19</maven.compiler.target>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
<failOnMissingWebXml>false</failOnMissingWebXml>
<vaadin.version>24.0.0.alpha6</vaadin.version>
<drivers.downloader.phase>pre-integration-test</drivers.downloader.phase>
</properties>
<repositories>
<!-- The order of definitions matters. Explicitly defining central here to make sure it has the highest priority. -->
<repository>
<id>central</id>
<url>https://repo.maven.apache.org/maven2</url>
<snapshots>
<enabled>false</enabled>
</snapshots>
</repository>
<repository>
<id>vaadin-prereleases</id>
<url>
https://maven.vaadin.com/vaadin-prereleases/
</url>
<snapshots>
<enabled>false</enabled>
</snapshots>
</repository>
<!-- Repository used by many Vaadin add-ons -->
<repository>
<id>Vaadin Directory</id>
<url>https://maven.vaadin.com/vaadin-addons</url>
<snapshots>
<enabled>false</enabled>
</snapshots>
</repository>
</repositories>
<pluginRepositories>
<!-- The order of definitions matters. Explicitly defining central here to make sure it has the highest priority. -->
<pluginRepository>
<id>central</id>
<url>https://repo.maven.apache.org/maven2</url>
<snapshots>
<enabled>false</enabled>
</snapshots>
</pluginRepository>
<pluginRepository>
<id>vaadin-prereleases</id>
<url>
https://maven.vaadin.com/vaadin-prereleases/
</url>
<snapshots>
<enabled>false</enabled>
</snapshots>
</pluginRepository>
</pluginRepositories>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>com.vaadin</groupId>
<artifactId>vaadin-bom</artifactId>
<type>pom</type>
<scope>import</scope>
<version>${vaadin.version}</version>
</dependency>
</dependencies>
</dependencyManagement>
<dependencies>
<dependency>
<groupId>com.vaadin</groupId>
<!-- Replace artifactId with vaadin-core to use only free components -->
<artifactId>vaadin</artifactId>
</dependency>
<!-- Added to provide logging output as Vaadin uses -->
<!-- the unbound SLF4J no-operation (NOP) logger implementation -->
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-simple</artifactId>
</dependency>
<!-- https://mvnrepository.com/artifact/jakarta.servlet/jakarta.servlet-api -->
<dependency>
<groupId>jakarta.servlet</groupId>
<artifactId>jakarta.servlet-api</artifactId>
<version>6.0.0</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>com.vaadin</groupId>
<artifactId>vaadin-testbench</artifactId>
<scope>test</scope>
</dependency>
<!-- https://mvnrepository.com/artifact/io.github.bonigarcia/webdrivermanager -->
<dependency>
<groupId>io.github.bonigarcia</groupId>
<artifactId>webdrivermanager</artifactId>
<version>5.3.1</version>
<scope>test</scope>
</dependency>
</dependencies>
<build>
<defaultGoal>jetty:run</defaultGoal>
<plugins>
<!-- Define newer versions of Java compiler and war plugin to
better support the latest JDK versions. -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.10.1</version>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>3.3.2</version>
</plugin>
<!-- Jetty plugin for easy testing without a separate server -->
<plugin>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-maven-plugin</artifactId>
<version>11.0.13</version>
<configuration>
<!--
Configures automatic reload of Jetty server
(with 2 second timeout) when new classes are compiled
(e.g. by IDEs).
Should be disabled when using a proper live reload system,
such as JRebel.
If using IntelliJ IDEA with autocompilation, this
might cause lots of unnecessary compilations in the
background. Consider using "0" and trigger restart manually
by hitting enter.
-->
<scan>2</scan>
<!-- Use war output directory to get the webpack files -->
<!--<webAppConfig>-->
<!-- <allowDuplicateFragmentNames>true</allowDuplicateFragmentNames>-->
<!--</webAppConfig>-->
</configuration>
</plugin>
<!--
Take care of synchronizing java dependencies and imports in
package.json and main.js files.
It also creates webpack.config.js if not exists yet.
-->
<plugin>
<groupId>com.vaadin</groupId>
<artifactId>vaadin-maven-plugin</artifactId>
<version>${vaadin.version}</version>
<executions>
<execution>
<goals>
<goal>prepare-frontend</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
<profiles>
<profile>
<!-- Production mode is activated using -Pproduction -->
<id>production</id>
<build>
<plugins>
<plugin>
<groupId>com.vaadin</groupId>
<artifactId>vaadin-maven-plugin</artifactId>
<version>${vaadin.version}</version>
<executions>
<execution>
<goals>
<goal>build-frontend</goal>
</goals>
<phase>compile</phase>
</execution>
</executions>
<configuration>
<productionMode>true</productionMode>
</configuration>
</plugin>
</plugins>
</build>
</profile>
<profile>
<id>it</id>
<build>
<plugins>
<plugin>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-maven-plugin</artifactId>
<configuration>
<!--<scanIntervalSeconds>0</scanIntervalSeconds>-->
<stopPort>8081</stopPort>
<stopWait>5</stopWait>
<stopKey>${project.artifactId}</stopKey>
</configuration>
<executions>
<execution>
<id>start-jetty</id>
<phase>pre-integration-test</phase>
<goals>
<goal>start</goal>
</goals>
</execution>
<execution>
<id>stop-jetty</id>
<phase>post-integration-test</phase>
<goals>
<goal>stop</goal>
</goals>
</execution>
</executions>
</plugin>
<!-- Runs the integration tests (*IT) after the server is started -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-failsafe-plugin</artifactId>
<version>3.0.0-M7</version>
<executions>
<execution>
<goals>
<goal>integration-test</goal>
<goal>verify</goal>
</goals>
</execution>
</executions>
<configuration>
<trimStackTrace>false</trimStackTrace>
<enableAssertions>true</enableAssertions>
</configuration>
</plugin>
</plugins>
</build>
</profile>
</profiles>
</project>
External app servers
You may want your IDE to execute with an external app server rather than use the embedded Jetty discussed above.
If so, you’ll need to use a version of your desired server that supports Jakarta EE 10. Here is a partial list.
Apache Tomcat 10.1
Eclipse Jetty 12
Eclipse GlassFish 7
Payara 6
IBM Open Liberty 22
Red Hat WildFly 27
… and more

Multi-module maven microservices deploy to Heroku

I have a microservices project with a parent POM and all the other modules with an internal POM.
Locally, if I run mvn clean install -DskipTests everything works.
I want to deploy all the microservices to Heroku, how can i do this?
The project works also for Docker & Kubernetes, is there a way to integrate also Docker in Heroku?
So it will be beautiful if I can deploy all the microservices as 1 project in Heroku, with every microservices as a Docker image.
Thank you in advance!
This is an example of my project:
Parent POM:
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.petcare</groupId>
<artifactId>website-petcare-backend</artifactId>
<version>1.0-SNAPSHOT</version>
<packaging>pom</packaging>
<name>parent-pom</name>
<modules>
<module>apiGateway</module>
<module>reservationService</module>
<module>userService</module>
<module>eurekaServer</module>
<module>mapService</module>
<module>authService</module>
</modules>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<maven.compiler.source>1.7</maven.compiler.source>
<maven.compiler.target>1.7</maven.compiler.target>
</properties>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.11</version>
<scope>test</scope>
</dependency>
</dependencies>
<build>
<pluginManagement><!-- lock down plugins versions to avoid using Maven defaults (may be moved to parent pom) -->
<plugins>
<!-- clean lifecycle, see https://maven.apache.org/ref/current/maven-core/lifecycles.html#clean_Lifecycle -->
<plugin>
<artifactId>maven-clean-plugin</artifactId>
<version>3.1.0</version>
</plugin>
<!-- default lifecycle, jar packaging: see https://maven.apache.org/ref/current/maven-core/default-bindings.html#Plugin_bindings_for_jar_packaging -->
<plugin>
<artifactId>maven-resources-plugin</artifactId>
<version>3.0.2</version>
</plugin>
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.8.0</version>
</plugin>
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.22.1</version>
</plugin>
<plugin>
<artifactId>maven-jar-plugin</artifactId>
<version>3.0.2</version>
</plugin>
<plugin>
<artifactId>maven-install-plugin</artifactId>
<version>2.5.2</version>
</plugin>
<plugin>
<artifactId>maven-deploy-plugin</artifactId>
<version>2.8.2</version>
</plugin>
<!-- site lifecycle, see https://maven.apache.org/ref/current/maven-core/lifecycles.html#site_Lifecycle -->
<plugin>
<artifactId>maven-site-plugin</artifactId>
<version>3.7.1</version>
</plugin>
<plugin>
<artifactId>maven-project-info-reports-plugin</artifactId>
<version>3.0.0</version>
</plugin>
</plugins>
</pluginManagement>
</build>
</project>
Build
You can build all images for the sub-modules using the docker-maven-plugin.
Each sub-module must have its own Dockerfile, then in the parent POM add:
<plugin>
<groupId>io.fabric8</groupId>
<artifactId>docker-maven-plugin</artifactId>
<version>0.38.1</version>
<executions>
<execution>
<id>start</id>
<phase>pre-integration-test</phase>
<goals>
<goal>build</goal>
<goal>start</goal>
</goals>
</execution>
<execution>
<id>stop</id>
<phase>post-integration-test</phase>
<goals>
<goal>stop</goal>
</goals>
</execution>
</executions>
</plugin>
When running mvn clean package docker:build all projects are built and Dockerized
Deploy
Deploying all images (each image into its own web Dyno) is a little bit more complicated. You have few options:
Script from the command line: typically you can push the image with the following commands
heroku container:push web -a appname
heroku container:release web a appname
You could build a script that performs those steps for each and (very important) performs both the heroku login and heroku:container login using the credentials
Using heroku.yml where you can define at once all the containers to be deployed. It is a good approach but you need to git push your changes (see here)
Use CI/CD application like Github Actions. In this case your workflow compiles, tests, builds and pushes the application.
This is my preferred approach: you can decide when to build/deploy (on master push? manually?), you save the Heroku credentials as secrets, you can automate the release pipeline.
You can read more here
You can also try the Heroku Docker Maven plugin if you like to control all services using Maven

Unable to find artifact from artifactory

I am using JFrog artifactory 3.2.1.1 with Maven 3.2.1.
I uploaded a built project that exists in libs-snapshot-local under the repository browser. If I browse to com.foo.project, I will see the project-1.0-20151113.133436-1.jar file and pom and metadata in the artifactory browser.
Even accessing http://example.com:8081/artifactory/webapp/browserepo.html?42&pathId=libs-snapshot-local:com/foo/project/1.0-SNAPSHOT/project-1.0-20151113.133436-1.jar shows me the jar file inside.
I used the settings.xml generator from the artifactory to generate the <repository> tag that I use in the following pom.xml:
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.foo.bar</groupId>
<artifactId>exampleApp</artifactId>
<packaging>jar</packaging>
<version>1.0-SNAPSHOT</version>
<name>exampleApp</name>
<url>http://maven.apache.org</url>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
</dependencies>
<repositories>
<repository>
<snapshots />
<id>snapshots</id>
<name>libs-snapshot</name>
<url>http://example.foo:8081/artifactory/libs-snapshot</url>
</repository>
</repositories>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<id>unpack</id>
<phase>prepare-package</phase>
<goals>
<goal>unpack</goal>
</goals>
<configuration>
<artifactItems>
<artifactItem>
<groupId>com.foo</groupId>
<artifactId>project</artifactId>
<version>1.0</version>
<type>jar</type>
<includes>myFolder</includes>
<outputDirectory>${project.build.directory}/newFolder/js/gmoketest</outputDirectory>
</artifactItem>
</artifactItems>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>
I just get:
Failed to execute goal
org.apache.maven.plugins:maven-dependency-plugin:2.8:unpack (unpack)
on project exampleApp: Unable to find artifact. Failure to find
com.foo:project:jar:1.0 in
http://example.com:8081/artifactory/libs-snapshot was cached in the
local repository, resolution will not be reattempted until the update
interval of snapshots has elapsed or updates are forced
And if I change
http://example.foo:8081/artifactory/libs-snapshot
to
http://example.foo:8081/artifactory/libs-snapshot-local
Then I get:
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-dependency-plugin:2.8:unpack (unpack)
on project exampleApp: Unable to resolve artifact. Could not transfer
artifact com.foo:project:jar:1.0 from/to snapshots
(http://example.com:8081/artifactory/libs-snapshot-local): Failed to
transfer file:
http://example.com:8081/artifactory/libs-snapshot-local/com/foo/project/1.0/project-1.0.jar.
Return code is: 409 , ReasonPhrase:Conflict.
I will keep deploying new snapshots now and then to the same project-1.0 and would like this pom file to just include the latest SNAPSHOT build when building from the artifactory.
The answer was, as I quickly figured out that the version needs to be specified as:
<version>1.0-SNAPSHOT</version>

Vaadin + maven problems

I'm trying to setup Vaadin for a new project.
I'm following the steps documented in https://vaadin.com/wiki/-/wiki/Main/Creating+a+Maven+project
The following command in empty directory:
mvn archetype:generate -DarchetypeGroupId=com.vaadin -DarchetypeArtifactId=vaadin-archetype-application -DarchetypeVersion=7.1.8
Gives me a following error:
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-archetype-plugin:2.2:generate (default-cli) on project standalone-pom: The desired archetype does not exist (com.vaadin:vaadin-archetype-application:7.1.8) -> [Help 1]
I've also tried creating pom with:
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>group</groupId>
<artifactId>artifact</artifactId>
<version>1.0-SNAPSHOT</version>
<packaging>war</packaging>
<name>name</name>
<description>description</description>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<vaadin.version>7.1.6</vaadin.version>
</properties>
<dependencies>
<dependency>
<groupId>com.vaadin</groupId>
<artifactId>vaadin-server</artifactId>
<version>${vaadin.version}</version>
</dependency>
<dependency>
<groupId>com.vaadin</groupId>
<artifactId>vaadin-client-compiled</artifactId>
<version>${vaadin.version}</version>
</dependency>
<dependency>
<groupId>com.vaadin</groupId>
<artifactId>vaadin-client</artifactId>
<version>${vaadin.version}</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>com.vaadin</groupId>
<artifactId>vaadin-themes</artifactId>
<version>${vaadin.version}</version>
</dependency>
</dependencies>
</project>
Running mvm clean install results in the following error:
[ERROR] Failed to execute goal on project artifact: Could not resolve dependencies for project group:artifact:war:1.0-SNAPSHOT: The following artifacts could not be resolved: com.vaadin:vaadin-server:jar:7.1.6, com.vaadin:vaadin-client-compiled:jar:7.1.6, com.vaadin:vaadin-client:jar:7.1.6, com.vaadin:vaadin-themes:jar:7.1.6: Failure to find com.vaadin:vaadin-server:jar:7.1.6 in http://10.255.251.14:9991/nexus/content/groups/public was cached in the local repository, resolution will not be reattempted until the update interval of nexus has elapsed or updates are forced -> [Help 1]
Also there are the following warnings seen:
[WARNING] The POM for com.vaadin:vaadin-server:jar:7.1.6 is missing, no dependency information available
[WARNING] The POM for com.vaadin:vaadin-client-compiled:jar:7.1.6 is missing, no dependency information available
[WARNING] The POM for com.vaadin:vaadin-client:jar:7.1.6 is missing, no dependency information available
[WARNING] The POM for com.vaadin:vaadin-themes:jar:7.1.6 is missing, no dependency information available
At first we thought there might be some problems with our nexus installation, but we also tried running these commands from external machine without nexus. Same issues.
Try to add
<dependency>
<groupId>com.vaadin</groupId>
<artifactId>vaadin-client-compiler</artifactId>
<version>${vaadin.version}</version>
<scope>provided</scope>
</dependency>
Add this to your pom.xml:
<repositories>
<repository>
<id>vaadin-addons</id>
<url>http://maven.vaadin.com/vaadin-addons</url>
</repository>
<repository>
<id>vaadin-snapshots</id>
<url>http://oss.sonatype.org/content/repositories/vaadin-snapshots/</url>
<releases>
<enabled>false</enabled>
</releases>
<snapshots>
<enabled>true</enabled>
</snapshots>
</repository>
</repositories>
<pluginRepositories>
<pluginRepository>
<id>vaadin-snapshots</id>
<url>http://oss.sonatype.org/content/repositories/vaadin-snapshots/</url>
<releases>
<enabled>false</enabled>
</releases>
<snapshots>
<enabled>true</enabled>
</snapshots>
</pluginRepository>
</pluginRepositories>
Then you have to force the update. Example: mvn install -U
It seems that the problem is related to maven repositories and not vaadin.
I've tried locating computer in other country (most likely different maven repository mirror too) and it worked.
Update: I had it working for an hour or so without changing anything and then it started failing again.
This might be related to the heartbleed bug everyone is going crazy about at the moment. Admins probably patching it all over the place and there might be some disruptions to repository services or our own network.
Looks like the list of available archetypes isn't up to date.
Run this command mvn archetype:update-local-catalog

Cannot resolve Mockito dependency in a Tycho project [duplicate]

This question already has an answer here:
Closed 10 years ago.
Possible Duplicate:
How to reference mockito within tycho?
I am trying to get a test feature project building with Tycho, but it fails to resolve dependencies listed in my pom from the Maven central repository that is listed in my parent pom. Here is the relevant part from my parent pom:
<properties>
<tycho-version>0.12.0</tycho-version>
</properties>
<repositories>
<repository>
<id>helios</id>
<layout>p2</layout>
<url>http://download.eclipse.org/releases/helios/</url>
</repository>
</repositories>
<pluginRepositories>
<pluginRepository>
<id>central</id>
<name>Maven Plugin Repository</name>
<url>http://repo1.maven.org/maven2</url>
<layout>default</layout>
<snapshots>
<enabled>false</enabled>
</snapshots>
<releases>
<updatePolicy>never</updatePolicy>
</releases>
</pluginRepository>
</pluginRepositories>
<build>
<plugins>
<plugin>
<groupId>org.eclipse.tycho</groupId>
<artifactId>tycho-maven-plugin</artifactId>
<version>${tycho-version}</version>
<extensions>true</extensions>
</plugin>
<plugin>
<groupId>org.eclipse.tycho</groupId>
<artifactId>target-platform-configuration</artifactId>
<version>${tycho-version}</version>
<configuration>
<pomDependencies>consider</pomDependencies>
<resolver>p2</resolver>
<environments>
<environment>
<os>linux</os>
<ws>gtk</ws>
<arch>x86_64</arch>
</environment>
<environment>
<os>win32</os>
<ws>win32</ws>
<arch>x86</arch>
</environment>
</environments>
</configuration>
</plugin>
</plugins>
</build>
and here my feature pom:
<modelVersion>4.0.0</modelVersion>
<parent>
<artifactId>parent</artifactId>
<groupId>com.example</groupId>
<version>1.0.0-SNAPSHOT</version>
</parent>
<groupId>com.example</groupId>
<artifactId>com.example.testing.feature</artifactId>
<version>1.0.0-SNAPSHOT</version>
<packaging>eclipse-feature</packaging>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.mockito</groupId>
<artifactId>mockito-all</artifactId>
<version>1.8.5</version>
</dependency>
</dependencies>
</dependencyManagement>
<dependencies>
<dependency>
<groupId>org.mockito</groupId>
<artifactId>mockito-all</artifactId>
</dependency>
</dependencies>
when I run mvn clean package on my feature project, I get the following:
[INFO] Adding repository http://download.eclipse.org/releases/helios/
[INFO] Adding repository http://download.eclipse.org/releases/helios/
[DEBUG] Added p2 repository helios (http://download.eclipse.org/releases/helios/
)
[DEBUG] Ignoring Maven repository central (http://repo1.maven.org/maven2)
and then my build fails, because my dependency cannot be resolved. Am I missing something? Is this because of the p2 resolver configured for target-platform-configuration?
Indeed it seems you are correct.
First, create a Target Definition file (.target) and put it inside a Maven project, see here for example target: https://github.com/eclipsesource/com.eclipsesource.tycho.aspectj.demo/blob/master/platform/indigo.target
You need to attach the .target file to the artifact, using the build helper:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>1.3</version>
<executions>
<execution>
<id>attach-artifacts</id>
<phase>package</phase>
<goals>
<goal>attach-artifact</goal>
</goals>
<configuration>
<artifacts>
<artifact>
<file>indigo.target</file>
<type>target</type>
<classifier>indigo</classifier>
</artifact>
</artifacts>
</configuration>
</execution>
</executions>
</plugin>
(from https://github.com/eclipsesource/com.eclipsesource.tycho.aspectj.demo/blob/master/platform/pom.xml )
Then, in the parent POM or the plug-in projects that use that target definition file, you need to configure the "target" of target-platform-configuration Maven plugin, for example:
<plugin>
<groupId>org.eclipse.tycho</groupId>
<artifactId>target-platform-configuration</artifactId>
<version>${tycho-version}</version>
<configuration>
<resolver>p2</resolver>
<ignoreTychoRepositories>true</ignoreTychoRepositories>
<target>
<artifact>
<groupId>com.eclipsesource.sandbox.weaving.demo</groupId>
<artifactId>com.eclipsesource.sandbox.weaving.demo.platform</artifactId>
<version>0.1.0-SNAPSHOT</version>
<classifier>indigo</classifier>
</artifact>
</target>
<environments>
<environment>
<os>${build.os}</os>
<ws>${build.ws}</ws>
<arch>${build.arch}</arch>
</environment>
</environments>
</configuration>
</plugin>
(taken from https://github.com/eclipsesource/com.eclipsesource.tycho.aspectj.demo/blob/master/releng/pom.xml )
Then your project(s) should build very nicely using Tycho. :-) If your .target references remote p2 repositories and not already in the p2 bundle pool, the necessary artifacts will be downloaded automatically.
Good luck!
Known Issue:
[WARNING] Target location type: Profile is not supported
As of Tycho 0.12.0, It means the "Eclipse Installation" target source type cannot be used with Tycho (yet?), along with "Directory" and "Features".
Solution: Use the "Update Site" target source.
If you don't have yet an update site, here's to generate an update site from an Eclipse (or from any folder containing bundles, for that matter):
/opt/eclipse_rcp/eclipse -consolelog -nosplash -verbose \
-application org.eclipse.equinox.p2.publisher.FeaturesAndBundlesPublisher \
-metadataRepository file:/home/ceefour/p2/bonita/ \
-artifactRepository file:/home/ceefour/p2/bonita/ \
-source /home/ceefour/BOS-5.5.1/studio/ \
-publishArtifacts
Note:
change /opt/eclipse_rcp to your own Eclipse SDK installation
metadataRepository and artifactRepository is the folder where the new update site will be created
source is --you guessed it-- the folder/installation containing the original bundles

Resources