I'm using Java Spring as backend and Angular as frontend.
I have a system test for the Frontend that requires that the backend has already started.
In gradle I already have a npm-task that starts the frontend tests.
How can I configure gradle or which plugin do you recommend for starting the backend before that test-task and stopping it after it has finished?
I found the gretty-plugin, but I don't manage to make it work.
V4 of the plugin depends on JDK11 (I use JDK8) and all older major version throw an error in gradle like "Cannot change dependencies of dependency configuration". I judge the plugin to be not well maintained and documented.
Related
I am using Google App Engine gradle plugin with yaml file, but the plugin version for it has no task appengineRun or appengineStart like the appengine-web.xml version.
TL;DR appengineRun is only available for appengine-web.xml based projects. If you want to use app.yaml, you must provide your own server, for example Spring Boot with Jetty or Tomcat.
To run your application locally, you must provide your own server.
This guide shows how to test your application using app.yaml alongside with the app-gradle-plugin, on section Testing your application with the development server:
During the development phase, you can run and test your application at any time in the development server by invoking Gradle:
gradle jettyRun
Alternatively, you can run Gradle without installing it by using the Gradle wrapper.
As said on this comment on GitHub:
If you want to use app.yaml from your root directory, you must upgrade to Java 11. Learn more here. With the Java 11 runtime, you must provide your own server, for example Spring Boot with Jetty or Tomcat. The appengine:run goal does not work for app.yaml based projects because each server has a different start up command i.e. spring-boot:run for Spring Boot.
Hi I'm building a java REST client application that uses json. There's a conflict in my dependencies: one essential dependency requires jackson databind/core/annotations 2.10.1, another essential dependency uses an older version 2.2.2.
When running the app in Eclipse, this led to a MessageBodyProviderNotFoundException. The problem was that maven included version 2.2.2 instead of 2.10.1. So I use dependency management to resolve the conflict and include version 2.10.1. Within Eclipse this solved the issue and the app runs fine.
But after building the app with the maven shade plugin, the standalone app still fails with the MessageBodyProviderNotFoundException. The exception is thrown in a part of the code requiring version 2.10.1, not in the part depending on version 2.2.2.
Any thoughts? Thanks in advance!
EDIT: I checked my local maven repository and it only contains version 2.10.1. So the problem is not that the jar somehow still includes version 2.2.2.
Problem solved. Running the app within Eclipse apparently doesn't require explicitly registering a JacksonJsonProvider, but running the standalone app does:
ClientConfig config = new ClientConfig().connectorProvider(new ApacheConnectorProvider()).register(new JacksonJsonProvider());
Client client = ClientBuilder.newBuilder().withConfig(config) ...
I built a plugin for a web app that uses tomcat.
The plugin is registered as a servlet bean.
Now I want to use rabbitmq with the latest amqp client lib. Which has a dependency on classes in slf4j-api-1.7.25.jar.
Unfortunately the web app has also a dependency on slf4j but an older version.
So adding the the new jar file crashes the web app.
Is there anything to rescue? I have two dependencies out of my control.
No.
Use an older version of the amqp client which has the dependencies you like.
Then at your leisure upgrade the web app to the version of slf4j pulled in by the client. Might even be due diligence.
I'm not sure if this is the best place to post such a question, but here it is. I'm a test automation engineer that works primarily with backend, spring boot command line apps. My tests, at a high level, are designed to ensure that any type of data that is thrown at the app will be handled correctly. We are a Java shop.
As with any "good" testing practice, I am treating the app like a blackbox, in that I do not pull in the model objects to run my tests. I simply supply the app with data, execute a command line type script (run.sh) that takes my data and processes it. My tests are comprised mostly of JDBC (to interact with the database) and a slew of ArrayList utilities that I have put together to sort out result sets and get specific db information.
Thus far, I have been deploying my tests as a JAR. I bundle everything up and deploy it to the environment with a script that will execute the tests. The tests do not run when the app is run. Though they do live inside of the project, they are a separate entity with separate launcher classes. However, I am finding that managing dependencies in a JAR is a real headache. Is there a better way to deploy automation / integration tests for command line apps?
I'm pulling in maven shade plugin to bundle all of my dependencies into a "God JAR", but that isn't helping me to resolve the issues that occur when I attempt to execute the JAR. I get multiple bean instantiation errors, relating to the app itself, and not my tests. For this reason, I pull in the app model, and the app itself as dependencies. When I ran the tests in my initial testing, they worked just fine. Deployed to environment and they continued to work correctly. Fast forward a couple of months, a few changes made to the app, and now it's a dependency nightmare when I build the new JAR.
TLDR: I'm having trouble managing dependencies in a maven project, integration tests JAR. Is there a better way to deploy automation / integration tests for command line apps where dependency management is easier?
(Note: I'm relatively new to this world, so pardon me if the question seems a bit vague).
I think the error happens when you use the shade plugin to re-package the spring boot jar. The way spring boot works is to add dependencies into the jar as jars itself and configure its own class loader (in the meta config) that is capable of reading classes from jar files inside the jar file. The standard java class loader does not do this - thats probably why the shade plugin misses out some jars (probably the ones embedded in the spring boot uber jar).
what I would try is to create a test-version of the spring boot app that contains the test-classes in the compile scope and a dependency to the original spring boot jar (you don't need the uber jar - therefore you may have to add a classifier to the original (app) spring boot plugin config to have that jar still available as it is replaced by default) and use the spring boot plugin to package the test version of it (using the dependency and its classifier above you used for the original app).
We want to run our own instance of the Spring Initializr and enhance it with own modules. However there is still no stable version available: Spring Inititializr's current version is still 1.0.0.BUILD-SNAPSHOT and it is not available on Maven central. Moreover, there have been some major changes in the module structure some weeks ago, which makes building and maintaining from source difficult...
My questions: is there a roadmap for the Spring Initializr project? When will it be available on Maven central?
Spring Initializr works in a continous deployment mode with no release scheduled at the moment. Every time we push a change on master, the whole tests suite is ran and if it passes we deploy the new version to production.
We did a quiet 0.1.0.RELEASE on repo.spring.io because a project requires it but we have no intention to go 1.0.0.RELEASE on Maven central at the moment. Part of the reasoning is that Spring Initializr is a service and not a library and we want to have the freedom to make breaking changes if necessary.
We do have some plans for an official release but nothing scheduled.