/src/main/resources is a Maven project structure convention. It's a path inside your project where you place resources. During the build step, Maven will take files in there and place them in the appropriate place for you to use them in your runtime classpath, eg in an executable .jar, some physical file system location used in the classpath (with java's -cp option), etc.
I could choose to build my application myself or with a different build tool. In such a case, /src/main/resources would not exist. However, the intention is for the classpath to be the same, ie. to contain the same resources and .class files.
The Spring boot documentation talks about the classpath because it shouldn't make assumptions about how your project is set up.
Answer from Sotirios Delimanolis on Stack Overflow/src/main/resources is a Maven project structure convention. It's a path inside your project where you place resources. During the build step, Maven will take files in there and place them in the appropriate place for you to use them in your runtime classpath, eg in an executable .jar, some physical file system location used in the classpath (with java's -cp option), etc.
I could choose to build my application myself or with a different build tool. In such a case, /src/main/resources would not exist. However, the intention is for the classpath to be the same, ie. to contain the same resources and .class files.
The Spring boot documentation talks about the classpath because it shouldn't make assumptions about how your project is set up.
The classpath also contains additional libraries (JARs), which also can have a static folder, which would then be included for serving static resources. So if the documentation would only state the folder src/main/resources/static, it would be incomplete.
Ad 2: As long as you don't mess with the default Maven configuration, then it's safe to assume this.
Ad 3: Maybe start with the official Oracle documentation: https://docs.oracle.com/javase/8/docs/technotes/tools/windows/classpath.html. Hint: Of course, it's not only the contents of the resources folder, which are in the classpath, but also of course all compiled classes, hence its name.
Videos
You can use the loader.path parameter to define a location for an external lib folder. All jars under this folder will be added to the classpath. For example, if you'd like to define C:\extLib as your external lib folder, you can do the following:
java -Dloader.path=/C:/extLib/ -jar aapName.jar
For this to work, you need to use the PropertiesLauncher. There are two ways to do that:
Option 1
Update the project pom.xml and add the following tag:
<configuration> <!-- added -->
<layout>ZIP</layout> <!-- to use PropertiesLauncher -->
</configuration>
Effective build tag, the post-update looks like below:
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<configuration> <!-- added -->
<layout>ZIP</layout> <!-- to use PropertiesLauncher -->
</configuration>
</plugin>
</plugins>
</build>
Option 2
Use the PropertiesLauncher when launching the application from the commandline:
java -cp aapName.jar -Dloader.path=/C:/extLib/ org.springframework.boot.loader.PropertiesLauncher
References:
How to add jars to SpringBoot classpath with jarlauncher
You may refer this below link from spring boot:
https://docs.spring.io/spring-boot/docs/current/reference/html/executable-jar.html#executable-jar-property-launcher-features
You can use the loader.path property to define a lib folder location
On Linux:
java -cp MyApp.jar:/home/sleeper/thirdparty/lib -Dloader.main=myMainApplicationClass org.springframework.boot.loader.PropertiesLauncher
On Windows:
java -cp MyApp.jar;/home/sleeper/thirdparty/lib -Dloader.main=myMainApplicationClass org.springframework.boot.loader.PropertiesLauncher
This will avoid messing with the manifest or the Spring Boot Maven plugin configuration as in the other answers. It will launch your app with the PropertiesLauncher, which allows you to specify the main class in loader.main. As mentioned earlier, for some reason if you use PropertiesLauncher with loader.path, it will not add resource files to the classpath. This works around the issue by using -cp instead of -jar.
EDIT As mentioned by Pianosaurus in the comment, use ":" instead of ";" as separator in the classpath on Linux
If you just want add external libraries you can use the loader.path property.
java -Dloader.path="your-lib/" -jar your-app.jar
UPDATE
If you also need to read additional files from the classpath you have to create/change the manifest file of your application.
Lets assume that your are initializing your Spring Boot context from the class de.app.Application. Your MANIFEST.MF should looks as follows:
Manifest-Version: 1.0
Main-Class: de.app.Application
Class-Path: your-lib/
And the you can simply start your app with java -Dloader.path="your-lib/" -jar MyApp.jar.
For more information about the MANIFEST.MF please see Working with Manifest Files: The Basics.
I just check that no matter if you use .properties or .yaml file you will have always classpath:app\mock-templates as an injected property value. And that's ok. Spring does not complete classpath: prefix to the real path in a time of reading from properties. That will be done next by ClassPathResource.
P.S. I think quotest also don't make any sense here.
I faced the exact same issue and there is a way to solve this. I tried using classpath but it does not work. Then I used this way
app:
templates: "${PWD}/your/resources/dir/location"
In your application.yml file. It works for me just make sure your PWD will come from the path where your test are running. If you are using git hooks for running tests then mostly it's run from project root dir.
Updated answer:
You can follow the practice in my original answer, but we recently dropped this for a simpler and cleaner option that is more standard (the "Java" way). We made the change because we needed to dynamically load dependent libraries at runtime that were not available at compile time (in their exact version). In our case we wanted to load dependent jars only from separate folder(s) and not from an executable jar. We ended up having duplicate dependencies in the executable jars and in separate folder(s), so we decided to drop the executable jar Properties Launcher and instead only load dependencies from separate folders. This is often NOT the best option and should be evaluated for your use case. I prefer reading the standard Java classpath.
To run a Spring Boot app without an executable jar, we used Maven Assembly to put the dependent jars in a /libs directory and dropped the spring-boot-maven-plugin. The steps and some code for this are below:
- Remove the spring-boot-maven-plugin that creates the executable jar in ZIP format
Add the following to your assembly XML
<dependencySets> <dependencySet> <outputDirectory>where you want the libs to go</outputDirectory> <useProjectArtifact>whether you want to include the project artifact here</useProjectArtifact> </dependencySet> </dependencySets>Run your code from the main class and include the dependent jar folder(s) on the classpath. Use the standard classpath notation on your OS and not the custom, awkward PropertiesLauncher loader path syntax
java -cp <standard-classpath> <main-class>
An example of an actual call:
java -cp $CLASSPATH:./lib/*:./cfg/*:my-app.jar Application.class
In this way you execute the Spring Boot app via standard java execution call, no custom Spring loading syntax. You just need to ensure that all of your dependencies are available on the classpath at runtime. We found this much easier to maintain and made this the standard for all of our apps.
Original answer:
After some researching, and thanks to @TuyenNguyen's helpful answer I was able to get the following working:
I added the following to my spring-boot-maven-plugin so that when I run from the command line it uses the PropertiesLauncher instead of the JarLauncher:
<configuration>
<mainClass>${mainClass}</mainClass>
<layout>ZIP</layout> //THIS IS THE IMPORTANT PART
</configuration>
See here and here for more about the PropertiesLauncher options. It allows you to set the classpath, among other things.
See here, here, and here for where I found the answer to this problem. Using format ZIP makes the PropertiesLauncher be used.
From there, I was able to use this command to launch the application as I intended:
java -Dloader.path=../config,../ -Dloader.config.location=classpath:application.properties -jar ../app-exec.jar
Another important note: when specifying the -Dloader.path make sure to use comma-separated values and only directories and files, as described here. Also, be sure to put the -D args before you specify -jar jar or they will not be set.
If anyone has any suggestions or edits to further improve this answer or the original question in order to help additional users, please let me know or make the edits yourself!
If you don't put your files in src/main/resources then you can put it inside any folder that you want, BUT you must set your folder as a resources folder. Because classpath is always point to resources folder. Once you make your folder as a resource folder, it will be packaged into the jar. If you want to edit your resource file, just using 7 zip tool to open your jar -> edit files -> save -> it will update your change in the jar.
Another solution is create a folder, put all files you want to edit and not packaged in that, then set classpath manually to that folder every time you run, but the way you set above is not correct, try this solution for set classpath correct way.