Search code examples
spring-bootdependenciesexternalfreemarkerapplication.properties

How do I point spring.freemarker.template-loader-path to the templates within a dependency jar?


I have 2 projects. One project (A) contains all my core functionality such as my entities/services/daos etc. It also contains many .ftl templates I wish to take advantage of and reuse in my other project (B). I have successfully gotten (B) to utilise the classes from (A) but I'm having no luck in reusing the freemarker templates.

Project (B) is a Spring Boot application (v2.1.3) and so I think I'm right in using the application.property: spring.freemarker.template-loader-path as opposed to defining a new @Bean.

Due to being a spring-boot application, by default and without this property the project will look in the projects own src/main/resources/templates location but my aim is for Project (A) to have none of its own templates and for my controller to return the templates found within Project (B).

Within my Maven Dependencies the hierachy is as thus:

projectA-0.0.1.jar
    templates
        folder1
            exampleA.ftl
        folder2
            exampleB.ftl

Currently my controllers are set to return things like return new ModelAndView("folder1/exampleA") where the context prefix is src/main/resources/templates/

Does anyone know the correct format of the value I need to give to the spring.freemarker.template-loader-path property in order to point to the templates in my dependency jar instead of the local src/main/resources/templates?


Solution

  • So spring.freemarker.template-loader-path=classpath:/templates/ was the answer to my original question, however it didn't solve my problem.

    Adding the following @Bean to my config class did, credit to @ddekany

    @Bean
    public FreeMarkerConfigurationFactoryBean getFreeMarkerConfiguration() {
        FreeMarkerConfigurationFactoryBean bean = new FreeMarkerConfigurationFactoryBean();
        bean.setTemplateLoaderPath("classpath:/templates/");
        return bean;
    }
    

    Would appear that although I could use a property, due to other factors a @Bean was required in my scenario.