In my project I'm using the spring-boot-configuration-processor to generate configuration metadata, which can be helpful at setting fields in #ConfigurationProperties marked classes from .properties files.
As build system I use Gradle.
The configuration with JavaDoc in class looks like this:
#Configuration
#ConfigurationProperties(prefix = "user-config")
public class UserSettings {
/**
* User name.
*/
private String name;
// getters & setters
}
And I import spring-boot-configuration-processor dependency in Gradle like this:
annotationProcessor group: 'org.springframework.boot', name: 'spring-boot-configuration-processor'
The problem is that IntelliJ IDEA can't find generated file spring-configuration-metadata.json, which is putted into folder /build/classes/java/main/META-INF when executing build task from Gradle.
I did some research, and found out that IDEA uses out/production/classes path for production output, but Gradle uses build/classes/java/main path.
Then I came to this SO question, where I found a solution: https://stackoverflow.com/a/55516113/8521177. As pointed there, there are two solutions:
Configure the Spring Boot Annotation Processor manually in IDEA (which is unacceptable, because it would force to do so everyone, who works in my project)
Set IDEA output path to the same as Gradle path as pointed in this answer: https://stackoverflow.com/a/46420842/8521177, so IDEA will find the spring-configuration-metadata.json generated metadata file.
And the another is to put generated file in src/main/resources/META-INF manually and deploy the app with the file in this folder.
The second solution is worked out, but then in the same answer in comments I saw the #CrazyCoder's response - Intellij - set default output path to gradle output, which is saying that gradle idea is obsolete and the one should use 'delegate' option in IDEA. I turned on this option, and IDEA now produces output in the same folder as Gradle do, but IDEA again can't find generated metadata file, since output path again is set to out/.
So, what is the right solution to make IDEA recognize this generated file, considering that I don't want to force user do something manually?
P.S. - Also, I have the following automatically added source path: build/sources/annotationProcessor/java/main. I don't know what is it and where it came from, the folder is empty, but can be there solution with it? Maybe if I can make spring boot configuration processor produce generated file in this folder?
UPD: I use IntelliJ IDEA 2019.1.3 (Ultimate Edition), Gradle 5.4.1, Spring Boot 2.1.5.
Related
I guess by asking this I might sound a bit illegible, but I'm still unsure as to how to approach the problem.
In my spring project (not really my, work stuff) I've got some groovy scripts which are initially treated as resources, yet in reality they are rather the "source code" which is compiled not during the gradle assembly of the project but during the runtime by the application itself. And everything's fine with that.
The problem is that the IDE doesn't treat the groovy file properly. Dumb example to somehow describe what I mean:
import myproject.example.blabla
import groovy.transform.CompileStatic
#CompileStatic
class SomeClass1 implements SomeClass2 {
private final SomeClass2 someName1
SomeClass1() {
someName1 = new something
}
#Override
String getSmth() {
return someName1.getSmth()
}
}
The problems:
when I make "command + left_click" on SomeClass2, it says Cannot find declaration to go to, but when I press "command + O" it finds the file because it actually exists
.getSmth() is red, because Cannot resolve symbol
So it seems that I need to somehow show the dependencies via gradle to IDE only. Like, somehow specify the dependencies explicitly for IntelliJ IDEA so that it would understand that it is a source code as well and stop underlining everything with red.
Such files must be located in the module's Source Root directory for the IDE to recognize them as sources and so that navigation would also work.
In a Gradle-based project IDE configures Source Roots automatically based on the Gradle's Source Sets configuration. For each Gradle source set IDE creates a module with one Source Root directory.
So you must configure Gradle to create source set for the directories where these files are located: add them into default sources sets or create a custom source set for them.
We have this project setup for eclipse that I'm now trying to import into IntelliJ.
I've tried using the eclipse import in IntelliJ but that fails, I suspect it's because the person who set up the project decided there shouldn't be a src-folder and instead named it after our course, tddc17...
The structure looks like this:
- project
- lib (contains two jars)
- tddc17
- MyVacuumAgent.java
Now I've set up the jars as modules in IntelliJ and when I configure the run I can find the entry point so that's all good. The project also builds as it should but the problem is when I try to run it.
In one of the jars it tries to find "tddc17.MyVacuumAgent.java" which it then can't find.
I can't edit the jar so I can't change that, so what I need is a way to set it up so that it can be found. When building there's an out directory created with the structure:
- out
- production
- lab1 (name of the project in IntelliJ)
Could that be the issue?
Figured out the problem.
since it looked for tddc17.MyVacuumAgent.java it was expecting that to be part of a package. Which it wasn't. So I added package tddc17 at the top of the file. THis gave me an error but using alt + enter to let IntelliJ fix it created yet another tddc17 folder inside the existing one and now it all works.
I'm writing here because I'm getting headaches trying to find out what is happening.
I'm currently working on a "toolbox" project where the id is to validate a provided string among different kind of rules.
I've stored the different rules on XML files and the project itself works properly.
Its structure is something like :
ValidatorProject :
|___ src/main/java
|____ ValidatorManage.java (this one have a method that is able to load the correct config validator file and validate the provided String)
|___ src/main/resources
|____ *.xml (a lot of xml config files)
Unit testing, direct Manager instanciation inside the project itself works as expected.
Now I'd like to add this project as a maven dependency to other projects that could need to validate some datas.
My problem as creating a new ValidatorManger instance in the second project ValidatorManager.class.getClassLoader().getResourceAsStream is not working because it used the project n°2 classpath and can't find the config files.
I tried to import the resources in the maven build of the validator project (I got it if I unzip the jar file), but I don't know how can I have access to it.
If someone have the solution (and more important the explanations about the way it work) I would be really grateful for it cause I turn around on this.
I'm pretty sure there is something to do during the maven build of the validator project but can't find what.
Thanks in advance for taking time to read me and sorry for my english :/
Have a nice day
Put the xml config files under src/main/resources
I finally find something working;
I'm not sure this is the way to do it (also do not seem to be really practical to do that for every project that need this project);
http://maven.apache.org/plugins/maven-remote-resources-plugin/examples/sharing-resources.html
At least this is working for now, I'm still open for better solution if you have some.
i have a shadowJar compiled with gradle which uses truezip to get some files out of a zip-file.
i get this exception using it:
Exception in thread "main" java.util.ServiceConfigurationError: file (Unknown file system scheme! May be the class path doesn't contain the respective driver module or it isn't set up correctly?)
at de.schlichtherle.truezip.fs.FsAbstractCompositeDriver.newController(FsAbstractCompositeDriver.java:33)
at de.schlichtherle.truezip.fs.FsDefaultManager.getController0(FsDefaultManager.java:95)
at de.schlichtherle.truezip.fs.FsDefaultManager.getController(FsDefaultManager.java:78)
at de.schlichtherle.truezip.file.TBIO.getInputSocket(TBIO.java:280)
at de.schlichtherle.truezip.file.TFileInputStream.newInputStream(TFileInputStream.java:101)
at de.schlichtherle.truezip.file.TFileInputStream.<init>(TFileInputStream.java:95)
i set a archiveDetector like this:
final TArchiveDetector ad = new TArchiveDetector("foo", new ZipDriver(IOPoolLocator.SINGLETON));
TConfig.get().setArchiveDetector(ad);
the exception is thrown when i want to make an input-stream like this:
final TFileInputStream is = new TFileInputStream(thefile);
as far as i can tell the shadowJar contains all necessary classes, but maybe something is missing?
how would i know which class, which package is missing?
what else could cause this?
running it out of eclipse works...
thanks for any help.
That's a common issue when creating an uber-JAR: The individual entries at META-INF/services/* need to get appended. However, by default, many tools simply overwrite them when creating the uber-JAR. As a result, the ServiceLoader class cannot find all necessary plugins (e.g. for file system drivers), which is what this exception is complaining about.
So you need to fix the configuration of the tool which creates your uber-JAR. If you are using Maven with the maven-shade-plugin, then you can simply add the ServicesResourceTransformer - see https://maven.apache.org/plugins/maven-shade-plugin/examples/resource-transformers.html#ServicesResourceTransformer.
Another option is to not use an uber-JAR at all, which is the default when using Maven.
Eclipse can read Maven projects and establish its meta data from it, so maybe you want to consider converting your project to use Maven - if you haven't already.
I had the same problem. After some research i found the following solution:
In your build.gradle add the following:
shadowJar {
mergeServiceFiles()
}
I got a problem with my gradle build. I use the standard proposed by the Spring Website (https://spring.io/guides/gs/rest-service/), but when I try to use gradle build, I got this error :
It doesnt work for this gradle, but when I use another one (that I took when I was at school) it work perfectly.
There are two possibilities
Your source directory is not in the right location (use the sourceSets directive to fix this. your source directory should resemble something like src/main/java/your/package)
Add this to indicate where your main class is
springBoot {
mainClass = "hello.FileUploader"
}
I am pretty sure it is 1.
I also have this problem, Here I solved the problem:
use org.springframework.boot:spring-boot-starter instead of org.springframework.boot:spring-boot-starter-web, if your project is only an module that will be used in other project.
Or Set the main class in gradle:
mainClassName = 'your.package.MainClass'
Or Just disable the bootRepackage
bootRepackage {
enabled = false
}
There is no main method in your project (otherwise the plugin would find one). A main method has a very specific signature, so check that you have public static void main(String[] args).
If the main class is not defined in the current project which the build.gradle file belongs to, but you want to launch it for some purpose, like sprint integration test. Do it like this:
Adding
bootRepackage {
mainClass = 'your.app.package.Application'
}
in build.gradle (after the line apply plugin: 'spring-boot', because the plugin needs to be loaded) fix the problem.
I know this is a very old post. But I came across this issue while trying to build my first spring- boot application (https://spring.io/guides/gs/spring-boot/#scratch).
So the location of the pom.xml, mentioned in the tutorial is incorrect. You need to place it outside your src folder.
So here is the final directory structure -
/workspace/src/main/java/hello/HelloController.java
/workspace/src/main/java/hello/Application.java
/workspace/pom.xml
I solved it by specifying the encoding. Probably it's because I wrote the code in an IDE.
java -Dfile.encoding=UTF-8 -jar build <filename>.jar
This happened to me as well.
I was confused by the location of build.gradle file: I thought it should be located in src/main/java/hello, because it is mentioned right after the instruction to create this sub-directory structure.
It should be placed in the root folder containing src folder. Once I did that and called "gradle build" from the root folder and not "./gradlew build" as the guide instructs, build was successful.
I did not perform the standard installation for gradle, just downloaded the binaries, maybe this is the reason that "./gradlew build" failed for me.