I have a project that follows the standard Maven structure:
project
src
main
java
test
java
In some classes, assertTrue is able to be resolved, and in others it cannot be resolved.
I took the static import from the class (in the src/java/test directory) that is resolving and pasted it into the class that can't resolve assertTrue (in the src/java/main directory) and that didn't resolve it.
So using import static org.junit.Assert.assertTrue; doesn't work.
Using Assert.assertTrue doesn't work either.
Edit:
One thing that I didn't make clear in the initial post is that this isn't a standard Java project with unit tests. The project is the integration test framework for another Java program. So all the code within this project exists to test the functionality of another program using the external REST API. Hence why I had a Junit assertion outside the test folder. Granted there may still be an opportunity to clean that up.
So the issue was in my build.gradle file that I had specified the junit dependency as a testCompile dependency. Meaning that it would only be apply to classes within the src/test directory. So to resolve my issue, I changed the build.gradle to use compile('junit:junit:4.12').
I could have also moved the file that wasn't resolving into the src/test directory, but the file didn't logically belong there.
Related
I have a multi module gradle project. The project contains two subproject, i.e. a spring-boot application server and an npm front-end ui (which is just static javascript).
I can build both sub-projects. I can define:
implementation(project(':ui'))
in the dependencies section of the spring application and I get a running jar in the server projects build folder successfully serving the frontend.
However, I want to be able not to combine the two not within the server sub-project, but rather in the enclosing project.
I thought of something like:
build.gradle:
allprojects {
group = 'com.example.webapp'
version = '0.0.1-SNAPSHOT'
}
dependencies {
implementation(project(':server'))
implementation(project(':ui'))
}
settings.gradle:
rootProject.name = 'webapp'
include 'server', 'ui'
I think, I am completely wrong. Everything I find about gradle is either completely basic, or assumes way more than what I understood about it so far.
EDIT:
With my solution approach I am getting the following error:
A problem occurred evaluating root project 'webapp'.
Could not find method implementation() for arguments [project ':server'] on object of type org.gradle.api.internal.artifacts.dsl.dependencies.DefaultDependencyHandler.
EDIT 2:
The basic idea is from https://ordina-jworks.github.io/architecture/2018/10/12/spring-boot-angular-gradle.html
The implementation not found is caused by the lack of plugins applied to your root project. The implementation configuration is created by the java plugins in Gradle.
What you are trying to achieve requires a good understanding of Gradle and all the magic provided by the Spring Boot plugin.
You are effectively trying to reproduce some of that integration in your root project, without the help of the plugins.
An approach that might be easier would be to migrate your application project to be the root project and then have the ui as a subproject.
Kotlin internal visibility is scoped to the "module" including the helpful statement that it may be:
a Gradle source set (with the exception that the test source set can access the internal declarations of main)
... so you can unit-test internal methods.
My Gradle build holds performance tests in a sub-project. How can I make those also "see" internal items of the parent?
The standard import doesn't do this
dependencies {
compile project(':myParentName')`
}
If it's impossible from a sub-project, how can a custom source-set (i.e. not test) in the main project have the same exception?
PS. It is quite common to see JMH performance tests put into a sub-project to keep configuration from polluting from the main build.gradle. This doesnt mean they are only tests of public interfaces (see the M in JMH).
I have a Maven project and defined a module + component in src/main/java, which Dagger 2 is handling as expected.
Now I want to mock some dependencies for my unit tests. However the dagger-compiler seems to ignore components inside src/test/java.
Is there a way of telling Dagger 2 to also look inside my test source set?
(Not an Android project)
Ok found my mistake. For others having the same problem: This question gave me the correct hint.
Components declared in src/test/java are generated to target/generated-test-sources/. This is an annotation processing default, not Dagger's fault. I just didn't have the idea to look for directories other than target/generated-sources...
I'm using IntelliJ IDEA and my project has a default Maven structure.
I often run into the scenario where I need to create a new class or resource in the same package, but in different folder (one of src/main/java, src/main/resources, src/test/java, src/test/directory). The case where I'm editing a class in src/main/java and I need to create a test in src/test/java is covered by the Create Test command.
What about the other scenarios?
Often I find myself writing a unit test and I'd like to create a test resource in the same package in test resources folder. Is there a quick way how to achieve that?
What you can do at least is to copy the path of your package, and then (in the test resources dir) say new directory, and paste the path there. You then need to delete the absolute prefix, but can keep the package definition. With deep package structures, this at least helps a bit.
To the best of my knowledge (via 10 years of use) there is not a built in way to do this. It is something I've recently been desiring for creating default Spring Test Context files. Your post has promoted me to open a Feature Request for auto-generating the spring text context. I'd recommend you either add a comment to that request, or open a separate feature request.
I have a couple of java modules set up in IDEA and I am wanting to mavenize them. These java modules use classes from one another.
I was not quite sure how I should take up this and I decide to add modules on a maven project using IDEA. Hence first I created a maven project, let's name it pm1 which has a class let's name it TempClass1. Now this class can be used in other maven project. Hence I added another maven module - pm11 and tried to use TempClass1 with in pm11. It worked and I notices that IDEA had added module dependency of pm1 in pm11. So whole structure looks as -
But now when I do mvn test from pm11 then it fails with error message package package1 does not exist and it looks to me that it is because package1 is in a different maven project. And I am not sure how I could use classes which reside in a different maven project. I hope I am clear in my question.
You can use classes of other maven projects, as long as there's a proper maven dependency defined in pom.xml. Ensure that the dependency is defined and its' scope is either undefined or relevant (You may have problems if the scope is provided for example).