We developed a new CoreFramework with Spring Boot (CoreFramework-1.0.0.jar) and pushed it to JFROG-Artifactory. The CoreFramework performs all the common functionalities required for all Microservices that we are developing. All these Microservices having dependency on it through maven POM.xml. I've a query here, in future if there is any change in our CoreFramework will force all Microservices to redeploy (new PODS need to be created as we deployed these Microservices to Openshift). Can someone suggest how to handle this situation?
Thanks in advance.
Having dependencies that happen to be common is not a problem - you already have a dependency on spring which you think is fine :)
The key point is "will force all Microservices to redeploy" - that's what you want to avoid. It is easier said than done but you need to make sure future changes are backward compatible so that services will be able to opt-in to upgrade and in their own timelines
As Arnon already mentioned, the best case would be that your microservices do not need to be deployed all together. So your services should be decoupled to the point where the exact version of a library does not matter and there is some backward compatibility.
That being said, one possibility to do such a redeployment is via a pipeline or build triggers. That means that the library build will trigger a rebuild of your microservices, which will then automatically lead to a new deployment:
+-----------+ +------------+
+--->| Service A +---->| Service A |
| | Build | | Deployment |
+-----------+ | +-----------+ +------------+
| Library +----+
| Build +----+
+-----------+ | +-----------+ +------------+
| | Service B | | Service B |
+--->| Build +---->| Deployment |
+-----------+ +------------+
In OpenShift, you can use Build Triggers to implement something like this or use a pipeline (Jenkins, Tekton, ...).
Related
We have git repository with a set of sample applications. Each sample app has its own subdirectory and its own pom.xml, but no common parent pom. The root level has an aggregator pom that should list all the sample apps.
+- sample-apps
| +- sample-app-A
| +- sample-app-B
| +- etc...
Because each sample app has a dependency to our core product, and we want the sample apps to use our latest version, we run the maven-versions-plugin from the root level to keep all apps up-to-date. However, developers that add new sample apps (subfolders) forget to add them to the aggregator pom. Hence, those sample apps will become stale over time.
Is there a way for maven to enforce that all subdirectories are listed as modules in the aggregator pom? We could write a custom enforcer rule for the maven-enforcer-plugin, but want to check for better alternatives first.
We do not want the sample apps to have a parent pom from our side, as the customer should be able to modify the sample app and inherit from his own parent.
I think I've a fairly generic problem that I expecting Maven to solve, but I can't find the appropriate plug-in...
Background
Like most reasonably sized projects I've got a requirement to deploy my application in several different environments. Let's say they are called "development", "qa" and "production". In each of these environments my application will talk to a different back end server and save it's data to a different data base. Rather then hard code all the setting in my application I'm going to create a Java properties file for each environment and just deploy the right one with the application. In my source code will look something like:
<root>
|-- conf
| |--develop
| | \-- application.properties
| |--qa
| | \-- application.properties
| \--production
| \-- application.properties
\-- pom.xml
The problem
If the developer is adding a new setting to the project it's too easy to update conf\development\application.properties file but forget to update the other files. If the setting is missing this typically causes errors a run time, which on a production server could be disastrous.
The Question
Is there a Maven plug-in that could be used to ensure that all three versions of application.properties contain the exactly same set of keys. If one (or more) key is missing from any of the files the build should be failed.
I'd develop a Maven plugin:
with an appropriate parameter, e.g. files.
See this answer for examples how to implement multiple values parameters.
that reads the three .properties files and fills a Map<String, Integer> (where: String key, Integer count).
If any of the Integer is not equal to the number of files given in the end throw an org.apache.maven.plugin.MojoFailureException. The same applies if one of the values is invalid, e.g. empty or otherwise syntactically wrong.
I'd bind the plugin's goal to the generate-resources phase.
Found that Camel EventNotifierSupport is not triggered with camel-spring-boot.
When working without camel-spring-boot, I am able to see this log. Should I use another lifecycle supporting class instead? Thanks in advance
2016-02-12 11:05:59,191 | main | INFO | com.ch.integration.camel.notifier.CamelEventNotifier | Started CamelContext: camel
2016-02-12 11:06:12,709 | Thread-0 | INFO | com.ch.integration.camel.notifier.CamelEventNotifier | Stopped CamelContext: camel
Looks like your application is stopping soon after it starts, which means the app is not a webapp, since there is no embedded servlet container it is stopping. There are two ways to keep it running
Using Main class from Camel as mentioned in http://camel.apache.org/running-camel-standalone-and-have-it-keep-running.html
Adding spring-boot-starter-web dependency Why does my Spring Boot App always shutdown immediately after starting?
Hope it helps, if the above assumption is not correct please provide some more console output, of DEBUG level.
I'm creating a new java web project. This web application will have many modules such as core/commons, business service, repository, security, integration, ldap, user management,.... I wonder if I should separate each module into each maven project (jar file) or create project that include all java packages of all modules into single one maven project.
Structure of Multi modules maven project
mycompany-core
mycompany-repository
mycompany-api
mycompany-usermanagement
mycompany-business
mycompany-web
Structure of Single module project:
mycompany-web
|___ src
|____ main
|____ java
|____ com.mycompany.core
|____ com.mycompany.repository
|____ com.mycompany.business
|____ com.mycompany.controller
When should we apply multi-modules or single-module project> Please give me some advice.
All products I've worked on in Maven were multi-module. This is because they tended to be big. However, when I create my own pet projects, they are normally single-module ones.
As a rule, as products grow, they will need to be organized into multi-modules. Some projects start as a single module and are split as they grow. Others, created by developers with more experience, are already divided up, because the developers already know how the code will grow and how it needs to be organized.
Specifically, from your list, "core/commons, business service, repository, security, integration, ldap, user management", I would separate "commons" into its own module, because it smells like it could be reused on other projects. The other parts could all fit into one module, but I'd need more insight into the project.
It is depend on your requirement. If you want to run this using .sh or .bat you should have single target(single jar with other libraries).
If your project build as an API it is better to have your build as multi module one.
I have a Maven based J2EE project structure
Customer (root pom)
|
|------ WebTier (JSF 2/Primefaces)
|
|------ BusinessTier (EJB 3.*, interfaces, interface impl)
|
|------ PersistenceTier (JPA 2)
|
|------ CustomerEar
Now I have found that I'd need a new Java class or classes for handling basic routines
I guess its not good idea to place this Utility class under WebTier, because Utilities might be used also from BusinessTier.
Is it the "best practise" to create an independent Java Project, implement necessary classes and include this jar to the ear??
based on my experience , i recommend to have separate project folder for utility and include this as jar where ever is required
advantages are
easy maintenance, since you need to change code once .
plugin & unplug when ever you need.
you can have this as common and utilize for
other projects.
for instance
apache string util
http://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/StringUtils.html
bean util
http://commons.apache.org/proper/commons-beanutils/
It would be hard to try and justify a "best practice" in this kind of situation as it is a very project-specific question.
There would be nothing inherently wrong with adding a "CommonLibrary" project or such-like that is a dependency of both the WebTier and BusinessTier. In fact the project I am working on now is almost exactly that structure (with a common library).
As this is a maven project, just make sure the "CommonLibrary" project dependecy scope is set to "provided" in the Business/Web/Persistence tiers, and "compile" in the ear project.
e.g. In WebTier, the dependency would be:
<dependency>
<groupID>group.name</groupID>
<artifactID>common-library</artifactID>
<scope>provided</scope>
</dependency>
EDIT: The scope would be 'provided' in the Web Tier as it would be a .war. The other tiers would be jars so the scope can be 'compile' for the persistence and business tiers.