I have two maven projects: project (A) and another project (B) that is a dependency of A. B contains a properties file that I wish to access in one of A's controllers. Is there a way to add B's properties file to A's classpath so that I can inject it into A's controller?
There is a similar question but I'm not sure if the scope of my question is covered by it.
UPDATE:
Using the #Value annotation in A's controller, the project returns a 500 error code and a FileNotFoundException.
Related
Let's say I have a repository named A.
I have a dependency that also has a repository with the same name A.
Now, I have used #EnableJPARepositories() to mark the base package of my repositories (which contains repository A).
At the same time, I have imported (#Import) the configuration of the dependency that has again used #EnableJPARepositories() to mark the repositories in the dependency (which contains repository A).
So basically, I have two #EnableJPARepositories() annotations in my application that mark separate repository packages. But these packages have repositories with the same name.
When I run and use my application, I don't get any conflict error.
So I just want to know, when I want to fetch the repository A in my applicaton, which one will be returned?
I have a project named A， and there is a spring-config.xml and a config.properties in A. Project A dependency project B, and project B also have a resource file spring-datasource.xml.I want to filter resource during package project A ,so I use maven-resource-filter.But it can only filter the resource file in Project A, doesn't work for project B. How can i filter project B's resource file during package project A?
You cannot (and should not) filter an already packaged dependency.
Filtering is enabled only during the build of the project.
More precisely, during the process-resources phase.
To achieve what you want, you have two ways :
moving spring-datasource.xml in the A project
OR
filtering spring-datasource.xml directly in the B project build.
I understand that the way these projects have been structured isn't necessarily good design, but i have found myself working on a project which has the following format and have a dependency and spring bean configuration issue:
Project A :
Is a Spring Project. Spring configuration is in an XML file. The project consists of many different beans and classes. Some of these classes are Services which make calls to a database(JPA/Hibernate is used). So in the Spring configuration file there is an entityManagerFactory defined, a Datasource etc and all the beans needed to perform database operations.
Project B:
Is also a Spring project, and also contains various beans and classes. This project also contains classes which make calls to a database(using JPA/Hibernate). So the Spring configuration also defined an entityManagerFactory/datasource etc. The project contains a series of Entity Classes which are scanned by the entityManagerFactory using the property 'packagesToScan'. The configuration is using Java Config.
The problem:
A bean in Project A needs to use a bean from Project B. The bean from project B is a Service class which reads data from the database. I want to be able to inject the bean from Project B into the class from Project A. I am using gradle in both projects, so have added Project B into Project A as a gradle dependency.
I tried adding a to the configuration from Project A to scan the package in Project B which contains the Java Config. I thought this would enable me to autowire the class from Project B into Project A. However, i am getting an exception that the entities in Project A are not managed entities and that autowiring is failing. Does this mean i need to scan the entities in Project B with the entityManager in Project A? Does this mean i cannot autowire a bean which has already been configured in the configuration of another project? Do i need to add this bean to Project A xml configuration and do all the property setting there, copied from Project B?
I'm having a problem properly setting up spring boot for my multi-module maven project.
There is a module "api" that uses another module "core". Api has an application.properties file that contains spring.mail.host=xxx. According to the spring boot documentation this provides you with a default implementation of the JavaMailSender interface, ready to be autowired.
However the class that is responsible for sending out the e-mails resides in the "core" package. When I try to build that module the build fails because no implementation of JavaMailSender can be found.
My guess then was that the mailing config should reside in "core" in a separate application.properties. I created that and moved the spring.mail.host property from the "api" to the "core" property file.
This time the core module builds successfully, but "api" fails to build because of the same exception, so I think I just moved the problem.
I don't understand the required structure for handling this type of situations well enough so I was wondering what the correct way is for having a "core" module containing all the correct configuration for sending mails and having other modules use the mailing code and config that resides in it.
I found the answer in another stack overflow question: How to add multiple application.properties files in spring-boot?
It turns out there can only be 1 application.properties file in the final jar that spring boot creates. To have multiple files you have to rename one of the files to something custom. I named the properties of the core module "core-application.properties".
Then in the API module I added this to the spring boot application class:
#SpringBootApplication
#PropertySource(value = {"core-application.properties", "application.properties"})
Doing this I can correctly use the base properties file and overwrite them in the more specific modules. Also you can still create profile-specific properties file (core-application-production.properties) with this setup, no need to add those to the propertysource manually). Note that #PropertySource does not work for yaml configuration files at this moment.
there is one effective application.properties per project. you just keep 2 properties file for a success build.
when api module use core module, the application.properties in core module is overwrite by api.
Your API's pom.xml must has dependency of CORE module.
the solution is to define properties files as a value of #PropertiesSource in Starter class.
but it is beter to put "classpath:" behind the properties files.
for example in Intellij idea after adding the "classpatch:" word berhind the files name, values become to link. like this:
#SpringBootApplication
#PropertySource(value = {"classpath:core-application.properties", "classpath:application.properties"})
I hope to helped you.
I am using mvn archetype:create-from-project within a manually created project
This project has both inherited and aggregated modules.
However when creating a new project based on this fresh archetype, the aggregated module pom file always finds itself injected with <parent>..</parent> attribute thus inheriting rather than being aggregated, which screws up the build order.
How can I prevent this aggregated module to be injected with <parent> tag?
It's actually not possible.
There's an open request for it on their JIRA from November 2011:
As mentioned in ARCHETYPE-110, the current implementation overwrites parent information if there are no existing parent definition inside the body of the pom.xml. So if we don't want such declaration we haven't no alternatives.
Source: https://jira.codehaus.org/browse/ARCHETYPE-393