Working on a Spring Boot 1.3.3 / Spring Framework 4.2.5 project, I faced a circular dependency (ServiceA autowired in ServiceB, and ServiceB autowired in ServiceA - injection is done via constructors). I solved this problem with some refactoring to delete this circular dependency.
Meanwhile, I noticed that the code (TestNG unit tests) worked on Windows (Windows 7, Java 8), and failed on our Jenkins CI (Linux).
-> Is there any reason to explain why it worked on Windows ? I'm trying to make my Windows local builds to reflect CI builds as much as possible.
//edit -> it may be an important information: I can't give an accurate number, but ~75% of Linux builds fail and ~25% don't fail (still on Linux). There is no random condition in pom.xml, but I probably miss something...
Related
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).
I am using Java 8, ActiveJDBC 1.4.13 and Spring Boot 2.0.0.RC1 with Spring 5.
On application startup I am getting this error:
org.springframework.beans.factory.BeanDefinitionStoreException: Failed to read candidate component class: FooActiveModel.class;
This problem appeared when I upgraded from Spring Boot 2.0.0.M7 to 2.0.0.RC1.
I have found a few references to this error but no mention of ActiveJDBC. In my case classes extended from the activejdbc.Model class (instrumented classes) are causing the problem.
As per answers and suggestions in these...
SPRING4: Failed to read candidate component class CouchbaseConfig.class
Server fails to start, Spring throws BeanDefinitionParsingException
BeanDefinitionStoreException Failed to read candidate component class
ArrayOutOfBoundsException on Bean creation while using Java 8 constructs
I have...
made sure I'm using Java 8
searched for conflicting dependencies
cleaned and rebuilt my project
deleted local maven repo that "might" have been corrupted
re-imported all the dependencies
upgraded all dependencies to their latest version
These options did not help.
Finally managed to solve this problem by excluding the problematic classes(the ones extended from activejdbc.Model that were being instrumented) from the spring component scan.
To make sure that this was actually the reason for the error, I even reverted to my original pom.xml with all my previous dependency versions, re-imported everything, cleaned, rebuilt and sure enough I'm no longer having this issue.
This was an extremely frustrating and time consuming problem, hope it helps somebody.
I am new to Karaf IT testing within the karaf container. I created a small practice project
Practice OSGI project. All the bundles are running fine as I am able to run them in karaf container(3.0.8) and able to make a rest hit to manually test it out. But Now I am trying to test it via integration tests. I wrote a testcase as well, but when I try to execute it, the maven says, no tests to build. Here my objective is to run a simple command like mvn clean install or mvn clean test so that it builds the complete project and in end test it using integration test(deploy karaf container, deploy bundles and execute the test cases, and bring the container down).
I hope I am able to explain my objective and question well.
Any help will be greatly appreciated.
Your test code is in the wrong directory. It is in src/test/main/java while it should be in src/test/java.
After this change the test runs but produces an exception. So there is more to fix but I guess this already helps you a bit.
Btw. I saw that your maven projects all have version 0.1 this is not a good idea in maven. You should always use a SNAPSHOT version. Release version should only be built and deployed once as they can not be overwritten in a remote maven repo.
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.
Is there any workable alternative to jetty-maven-plugin? This particular plugin is not supported properly. I even failed to find its source code repository.
What I need is an embedded container for integration testing.
There is a very similar Tomcat Maven Plugin. Works exactly the same, except... it uses Tomcat. You might also try Maven Cargo plugin that uniforms deploy process to several different containers/servers.
There's an embedded-glassfish plugin that can be used for this.
I often use an embedded jetty server that is started in the #beforeClass part of an junit test. That embedded jetty along with openejb provides most things you need without having to deploy your application anywhere