spring-boot-starter randomly stops working - spring

I have a project that is using custom spring-boot-starter. The way I understand is that for every starter we have to create META-INF folder and add spring.factories file to it and then add AutoConfiguration class.
It was working fine. But all of a sudden it stopped working. Then I had to remove the META-INF folder again and add it back and then it started working again. Is there something I am missing here?

My bad but for people who might run into issues. If you are using maven to build your projects do remember to include **/*.factories in the your pom under build

Related

Setup SpringBoot in IDEA from Initializr

I don't understand what happens (before everything worked, feels like I've lost some settings somehow). I download archive from initializer (spring.io; doesn't matter which dependency include, let's say only Spring Web), extract from archive and open project from IDEA. First of all, I'm receiving file ***.iml outside of the container (before it is automatically was created inside)
Also now I have to Assign to "java" folder MarkDirectoryAs - SourceRoot by hand (before this staff applied authomatcally).
And finally looks like IDEA does not see the itself downloaded dependencies. When the project just opened I receive this:
How can I fix it?
UPD:
Errors after reload
And Libraries do not have Maven...
Also what I've found out, I have an error with link to local repository and do not have link to external (like in previous projects)
don't know how to fix it.
Also in my Maven only Lifecycle folder presented now.
Maven Home Path choose as shown on the pic. (Settings->Build,Execution,Deployment->Build Tools->Maven)

Classpath root pointing to grails-app/views - how to amend?

My goal is to add some Json files as project resources accessible from the code. The solution must work in IntelliJ and deployed in a Tomcat. I don't mind if the files are located under grails-app/conf or src.
Getting my classpath root using one of
grailsApplication.parentContext.getResource("classpath:") or
grailsApplication.parentContext.getResource("classpath:.")
resolves in $MY_APP/grails-app/views
However, trying to navigate from this root to grails-app/src using
grailsApplication.parentContext.getResource("classpath:..")
results in: "java.io.FileNotFoundException: class path resource [..] cannot be resolved to URL because it does not exist". This might be acceptable since a root is a root, I guess.
How can I extend my classpath to folders outside of grails-app/views?
How can I make sure that the solution works in both, IntelliJ and Tomcat deployment?
I'm using Gradle 3.5, Grails 3.3.11, Groovy 2.4.10. I'm working in IntelliJ. Rebuilding the project using the Gradle view has not helped so far. The project setup consists of
grails-app/conf/application.yml
grails-app/conf/application.groovy
grails-app/conf/ApplicationResources.groovy (I've tried to add a resource entry here and rebuild the project)
... (Please feel free to have a look in the project in case of further config detail questions.)
I've been exploring endless questions and answers of similar "how can I add my file to the classpath" questions, but nothing has helped so far.
As mentioned earlier in the comment, that you should put the JSON files under /src/main/resources folder. And, you should be able to access the files as:
getClass().getResource("/example.json")
Here is an example application
#PuneetBehl's answer helped me realizing that it isn't about the project code configuration. It is about the configuration of my IDE, which is IntelliJ. You can set Project Structure... --> Project Settings --> Modules. There, "Resource Folders" on the right hand side was listing as: "conf", "i18n" and "views". I dont know why IntelliJ chose "views" for the path "/.".
Anyway, it was enough to:
use Puneet's proposed syntax: getClass().getResource("/myfolder/example.json")
after I had created grails-app/conf/myfolder/example.json

IntelliJ IDEA does not recognize spring boot project

I have a Spring boot project and, until yesteday, IntelliJ IDEA (ultimate version) was recognizing its structure perfectly. I've downloaded the project again from a git repository and now it looks like a bunch of random files...
As example, it does not recognize when a directory tree is a package and I have to pass through all the folders (before it was recognized as a package).
How can I restore the previous setting? I don't think I changed anything... on purpose at least.
Thanks
EDIT:
I'll share a screen of the problem now: the test folder looks like a regular directory and does not recognize the spring code

How to get IntelliJ IDEA run configuration to make use of Maven filtered resources?

I'm having some trouble working out how to run a project in IntelliJ IDEA that makes use of Maven resource filtering.
In my src/main/resources directory I have
spring.xml file that is used to start the application
service.env.properties
I also have the following in src/main/filters
env-uat.properties
env-prd.properties
env-dev.properties
In my pom.xml file I use maven-resources-plugin to create three configuration directories that get included into the final package. Each one is based on one of the filers. This package can then be deployed on any of the three environments without having to be rebuilt.
The issue that I'm having is when I try to run this using IntelliJ IDEA run configs I have to use
-Xbootclasspath/a:target/config/dev;
to force IntelliJ IDEA to pick up the .properties file with the correct filter.
While this works it doesn't seem like it is the right way to go here. Does anyone have any advice on how to handle configuration for multiple environments and how to get IntelliJ IDEA to pick this up through run configurations.

spring-boot-devtools doesn't reload dependent modules in multi-module maven project

Before I start, I'd like to say that I already tried the solution proposed in spring-boot-devtools reload of multi-module maven project changes, which didn't work for me.
Problem:
I have a multi-module Spring Boot project of this sort:
The module launcher has a Maven dependency on module GUI. I launch my Spring Boot application from the main method in launcher.
When I run the application and change any HTML file in GUI module, the spring-boot-devtools dependency doesn't do a live reload of these changes for my running application. Not even manual restart of launcher helps. I need to compile GUI manually and then run launcher again.
What I tried:
I tried defining the spring-boot-devtools dependency first in
parent pom.xml, then in GUI module only and then in both at the same time.
I tried adding spring.devtools.restart.additional-paths=../gui in my application.properties file as suggested in spring-boot-devtools reload of multi-module maven project changes. This does indeed trigger the reload (according to the log), but those changes just don't propagate to the jar file of GUI dependency. Also, before I even made this project into multi-module, there was no need for reloading just because of HTML files (nothing is being compiled) and I could see the changes right away.
I use Netbeans GUI if that's of any help. I also tried running the project from command line, with no success. The Maven packaging on all modules is set to jar.
The fact that this works when you configure absolute paths in devtools tells me that this is mainly a work directory issue.
So this means that:
configured paths should be relative to where you launch the CLI
you should configure the same location as a work directory in the run configuration of your IDE (whatever configuration your IDE is using to launch your application should have such an option)
In your case: everything should be relative to your launcher module; this should be as well your work directory in your IDE.
I have no idea how it happened, but upon one revisit it started working without me knowingly changing anything. It doesn't even require the spring.devtools.restart.additional-path property set.
Could've been a problem of Netbeans IDE perhaps? Then again, it didn't work from command line either. If anyone has any explanation for this, it'd still be grateful as it may prevent this problem from happening in future.

Resources