I am using DirectoryModuleCalatog to load the modules.
What I am trying to implement is all the modules needs to be dependent on some specific module. For example, I have one MainModule and several orher modules, what I want is all my modules are dependent on MainModule.
We can do this by specifying ModuleDependency attribute, but my requirement is even if module don't have this attribute, the dependency can be set through code.
I have checked various forims and found that this can be achieved if I am populate ModuleCatalog direct from code. I can Implement this by directly traversing the modules location but not sure how it could impact on performance if number of modules are more (say 50+ or 100+).
Is it possible to set the module dependency if catalog is populated using DirectoryModuleCatalog?
Related
I have a doubt about which solution is better to share utilities between maven modules.
The problem is that we have 2 maven modules for 2 api type modules and another "shared" module with logic used by those two modules.
In this "shared" module there are also utility classes for tests, for example, an abstract class "MockMvcTest.java" that are used in the other modules to not repeat code. All classes are shared directly, are not declared within test packages, and are not shared as tests. That is, in this "shared" module test dependencies, such as "junit-vintage-engine", cannot have "test" scope.
This "shared" module ends up containing packages with test utilities, security, mappers, etc.
I have doubts about whether it is okay to mix "normal" and "test" logic in this "shared" module and share it with the other modules or would be better to create another module?
Thank you very much in advance
Experts,
I need some expert advice on how to approach the below use case in spring boot.
I need to have a maven multi-module approach to my project.
I need to have a single jar as output of the final build process.
There are to be common modules for controllers, data access and other functionality
Other modules are to be created based on functionality domain for eg a module for Payroll, a module for Admin etc etc.
Each domain functional module will then have their own controllers extending the common controller, exception handler and so on.
Each module will also have its own set of thyme leaf pages.
The reason for following such an approach is we have development in phases and we will be rolling out based on functional modules.
Here are the issues that I can sense using this approach.
Where do I add the spring web dependency? If I add to the parent pom - it gets replicated across the children and there will be port conflict issues as each module loads. the same issue will also be there the moment I add it to two child modules.
How do I build the fat jar which has all the jars from all modules and works as the final deployment?
All the text that I read i can't see anything even close to what I am trying to achieve.
AD1. They will not unless you are trying to setup independent application context in each module. Of course you can do that(it might be complicated but I believe it's achievable), but for me it's an overkill. Personally I think it's better to have one application context and rely on scanning components that are present in classpath.
AD2. The structure in maven might be a little bit complicated and overwhelming at first glance but it makes sense. Here's how I see it:
Create a parent module that will aggregate each module in project and will declare library/plugin dependencies for submodules.
Create 1-N shared submodules that will be used in other modules. With come common logic, utils, etc.
Create 1-N submodules that will be handling your business logic
Create an application submodule that creates application context and loads configuration and components from classpath
Create a submodule that will be responsible for packaging process, either to war, jar, uber-jar or whatever else you desire. Maven jar plugin should do that for you. For executable uber-jar, you have dedicated tool from spring.
Now you can choose three ways(these ways I know) of loading your modules.
1. Include some modules in maven build based on the build configuration via maven profiles and let spring IoC container load all the components he finds in the classpath
2. Include all of the modules in maven build and load them depending on spring active profiles - you can think about it as of feature flag. You annotate your components or configuration class with #Profile("XYZ") telling spring IoC container whether to instantiate component or not. You will need (most flexible solution) to provide a property file which tells spring which profiles are active and thus which modules should be loaded
3. Mix of these two above.
Solution 1 pros:
build is faster (modules that are not included will be skipped during build)
final build file is light (modules that are not included are... not included ;))
nobody can run module that is not present
Solution 1 contras:
project descriptor in maven may explode as you might have many different profiles
Solution 2 pros:
it's fairly easy and fun to maintain modules from code
less mess in project descriptor
Solution 2 contras:
somebody can run module that is not intended to be run as it's present in classpath, but just excluded during runtime via spring active profiles
final build file might be overweight - unused code is still present in code
build might take longer - unused code will be compiled
Summary:
It's not easy to build well structured project from scratch. It's much more easier to create a monolith and then split it into modules. It's because if you already created a project, you've probably already identified all the domains and relations between them.
Over past 8 years of using maven, I honestly and strongly recommend using gradle as it's far more flexible than maven. Maven is really great tool, but when it comes to weird customization it often fails as it's build capabilities rely on plugins. You can't write a piece of code on the fly to perform some custom build behaviour while buidling your project, you must have a dedicated plugin for doing that. If such plugin exists it's fine, if it's not you will probably end up writing your own and handling its shipment, so anyone in your company can easily perform project build.
I hope it helps. Have fun ;)
I have separated my project in multiple modules using Maven. On of the modules is used as a 'common' module which shares entities and other code between modules. I have imported this module within the other modules. A problem arises when launching a module which uses the 'common' module. The module seems to scan for all entities in the common package and tries to validate the schema. This module does not have the SQL permission to access some tables, which results in a validation error.
Is there a way to disable this feature and only validate the schema based on the actually used entities in the code (based on imports)?
A somewhat vague explanation, I would like to see an immediate problem.
But the first thing that comes to mind: exclude auto jpa support. For your application class:
#SpringBootApplication(exclude = {JpaRepositoriesAutoConfiguration.class})
Possible, you can exclude also class DataSourceAutoConfiguration.
I have a project which was designed using a custom archetype to build modules under parent project as follows -
Details - The archetype implements a <configuration> in the <build> phase with a <mainClass> let's say Generator that builds the classes under the pojos and service packages into a single target folder and hence enabling to create the final JAR for the user module as user-1.0.0.jar
There's some requirement in terms of separately exposing the pojos without the intervention of service code that has left me brainstorming -
Is there a way to modify the existing archetype or module structure to get two separate JARs for the packages pojos and service as user-pojos-1.0.0.jar and user-service-1.0.0.jar?
One way I possibly know is to move the code in two different module and building their jars but then for multiple existing modules under the parent and a thought over the same name modules under the parent, wouldn't be preferable.
Is there a way to modify the currently obtained user-1.0.0.jar created and separate out it into the two JARs required same as above?
I was going to couple of blogs to get the basics of maven, in the mean time I was confused when I can use the multi module project. It will be great if the answer includes example.
The main idea is that you have small modules that are dependent on each other and can be grouped together. Its not necessary that all sub-modules in a multi-module project be dependent on every other sub-module.
Lets consider you have multiple modules for an application (e.g a social networking application) that belong together. These modules can range from smaller modules like a client consumer module or a server module that will serve requests initiated by the client module, an ejb module that will hold your beans that are used by both the server and the client module and a deploy-able web module that would comprise of your front-end application etc.
This is usually handled via a multi-module build which means all modules have the same version number, are bound together under a similar platform (a social networking application in our example) but can be accessed and used by other separately.
Please check How to assemble multimodule maven project into one WAR? to know how to package a multi module project in a war file. also, you can check maven official site on Introduction to pom file