How to reuse mule code (flows, exception strategies, database connectors, validators) across several projects. It's a application specific reusable artifacts, not an enterprise wide reuse.
For ex: I have some master code( validators, flows, and exception stratagies) which should be reused in a 15 different flows. (i.e 15 different mule projects). We are not using maven at the moment. One way I explored is, we could jar it and publish to local nexus repo, and re-use it via pom. Is there any other way ?
If possible, I also would like to make it dynamic, such that if I change the master code and deploy, it should be in effect without having to redeploy the ones that are using it.
You can reuse flows etc. (everything which is in Mule xml files) and Java classes by placing them in a plain Java project, building a jar from it and placing the jar on the classpaths of the importing Mule projects.
To use the stuff in the xml files, import them with .
Your question sounds like you already know this part.
I recommend building all Mule projects and the so called master project with Maven, Mule projects with packaging Mule, the master project with packaging jar.
Maven will pack the master part inside the using projects, so there is no dynamic update.
When you want this dynamic update, don't build with Maven or set the scope to "provided". In this case the master is not packaged in the other Mule projects. You have to make sure it is on the server classpath, e.g. in lib/user. Then you can change it there, restart the Mule server and all projects get the update.
Same with another level of indirection/possibility for grouping can be done with Mule domains.
All the dynamic stuff described so far does only for on premise Mule servers, not for CloudHub.
Related
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'm using Intellij IDE Ultimate and I create a Project with spring inicializer. The problem is... now I need create more microservices (Spring Boot) but idk how to do this in IDE. I the end I need 3 microservices. Have a terminal command to create a new microservice inside my project? Or a way in the IDE to do this.
What you need to do is creating several modules (normally Maven modules), each of them is a SpringBoot application with its own application context and its own configuration, directories structure, etc.
IntelliJ has a concept of Module which matches very well the Maven module concept.
If you go to File, Project Structure, Project Settings, Modules you can see a very nice view of the current modules (in your case it should be only one). You can add or remove modules there. (Also by just clicking File-New Module, but the Project Structure View is more useful).
If you decide going the Maven way, you can also create your structure in disk and its POMs and import maven project in IntelliJ.
In any case, keep in mind that you will like to deploy every microservice as a separate and autonomous deployable unit.
I want to be sure what is the best practice for project structure while using microservice architecture.
All microservices can be created as a new maven/gradle project or as a subproject/module.
I think dependency inheritance, project repository should be taken into account.
Due to the nature of the microservices, any service can has a different technology but still most of the services can have same dependencies(e.g. spring-boot)).
Another issue is that should team fetch all services or just a service which will be worked on? so repository structure also will be affected by the structure.
The main reasons to have a multi-module project is to manage dependencies (in the maven sense) between the different modules (and build them together in the right order). Your microservices may call each other, but are not dependent on each other in the Maven sense. So I would not use multi-module projects for them.
Nevertheless, you can define a parent pom for your microservices that defines common configuration and dependencies.
I don't recommend you to have a single project with multiple microservices of different technologies.
If you use Java as a programming language you can have a master project and use it as a parent in your microservices projects. Also, you can have common libraries as dependencies of your microservices projects.
If you want to do a microservices with different technology I recommend you to have a repository for each microservice.
Choosing this option you can deploy and versioning each microservice when you do changes in its code and not when you have changes in another microservice.
How to combine 3 standalone applications on java and run parallely with maven in spring.
The three othe standalone applications run on different Db's and I want to make use of these three in my main Standalone app.
What are the required maven settings i need to follow and what are the best spring components i used.
Any kind of answer is appresiable.
Thanks in Advance.
About Maven.
I recomend you to use a Repository Manager (Nexus, Artifactory...). In that repository, you can upload manually your aplications as a jar (I assumed that these three app are not build with Maven, but it could be interesant to migrate them, you should evaluate that).
You have to configure your new app pom.xml and settings.xml to get access to this repository. And then, you can add these dependencies in your new app pom.xml. After that, you can use your applications classes in your new app.
About Spring
Spring Framework, has a lot of things that could help you in your development (like dependency injection, jdbcTemplate and a large etc)
I really recommend you to read the documentation (with the index you can get an idea), and evaluate what things could help you.
I'd like to keep Mule Projects small for the sake of simplicity. This means that I'd only like a single Mule project to hold flows which are related.
However, when deploying I'd like to bundle all projects and deploy them together as one. Is there a good way to do this using Maven which will result in a single Mule deployable file which to Mule looks like a single project?
As far as I understand, your mule-deploy.properties file is the one responsible for holding the list of flows which should be executed or deployed.
It is generated automatically, when you first create a project. It automatically gets populated as flows are added.
It is located at src->main->app.
Try to deploy the project on mule-standalone and it will deploy all the flows as one.