Consider a multi-module Spring Boot project where module A depends on module B. What happens when you build module A?
Think about how Maven or Gradle handles project dependencies in multi-module setups.
In a multi-module Spring Boot project, when module A declares a dependency on module B, the build system ensures that module B's classes and resources are available to module A both at compile time and runtime automatically.
Which of the following is the correct way to declare a parent POM for a multi-module Spring Boot project?
The parent POM should represent the overall project, not a child module.
The parent POM declaration must point to the parent project artifact, not a child module. Scope is not valid inside <parent> tag.
You have a multi-module Spring Boot project. Module A defines a service bean, and module B depends on module A. When running module B, you get NoSuchBeanDefinitionException for the service in module A. What is the most likely cause?
Think about how Spring Boot scans for beans in multi-module projects.
Spring Boot scans for beans starting from the package of the class annotated with @SpringBootApplication. If module B's main class is in a package that does not include module A's packages, Spring will not find the beans defined there.
In a multi-module Spring Boot project, module A and module B both define application.properties files with the same property app.name but with different values. When running the project, which value will Spring Boot use?
Consider how Spring Boot loads properties from multiple sources.
Spring Boot loads properties from all application.properties files found in the classpath. When the same property is defined multiple times, the last one loaded (usually the one appearing last in the classpath order) overrides the previous ones.
In a large multi-module Spring Boot project, you want to share common utility classes and configurations across multiple modules. What is the best practice to organize this?
Think about modular design and code reuse principles.
Creating a separate common module for shared code is a standard practice. It allows clean separation, easier maintenance, and clear dependency management. Duplicating code leads to maintenance problems. The parent POM cannot contain Java classes. Auto-configuration helps but does not replace module dependencies.