Gunter Rotsaert

interesting approach, thanks

That is possible, but this requires a manual action and this will be forgotten. And will you use for every branch a different version number? Who manages the version numbers when two developers create a branch?

Why not use Apache DevLake for this purpose?

Nice article, but it would be better if you first design your API in an OpenAPI spec and based on that, generate your server side code. In your case, the spec is the code and that's the other way around. I have a working example in one of my blogs: https://mydeveloperplanet.com/2022/02/08/generate-server-code-using-openapi-generator/

Interesting question, I have read about the existence of Ollama, but did not use it.

A quick look at the documentation tells me that Ollama has a limited number of built-in models available, while LocalAI can be extended with a model of your choice (which you can download from HuggingFace). Another difference seems to be the Rest API. LocalAI uses the same Rest API as OpenAI which makes it easier to swap between LocalAI and OpenAI. Ollama seems to have a different API specification.

you are welcome and thank you for the comment

You are welcome :-) Thank you for creating and maintaining this plugin!

Some people nowadays only 'scan' blog posts instead of taking the time to actually 'reading' them. But... they do find the time to express their frustration in a lengthy comment. This is an example of spending time in a negative way and pure a waste of time. So, my advice to you is: if you really want to learn something, you need to invest time. Read the introduction again, click the link to the GitHub repository and find the answers to your frustration.

Thank you and interesting what you mention. Do you have a link to an example for me?

Thanks for the nice comment. According to me, you have two options: graalvm native image or snapstart. This workshop is very insightful: https://catalog.workshops.aws/java-on-aws-lambda/en-US

Thank you very much, very much appreciated

thank you :-)

Thank you for the nice comment, I fully agree with you :-)

SAFe has nothing in common with agile, see also the opinions of leading experts: https://www.smharter.com/blog/safe-a-collection-of-comments-from-leading-experts/

Thank you for the comment, always nice to receive feedback.

Thank you for your comment. I would refer to the official Liquibase documentation for that. If it is not standard available in Liquibase, you still have the opportunity to use the sql changetype where you can execute sql statements: https://docs.liquibase.com/change-types/community/sql.html

The problem with a checklist is that people eventually will only tend to use the checklist and will not think outside the checklist anymore. Therefore, a checklist for code reviews is in my opinion a bad idea. It would have been better if you had called it 'Items you at least need to address during a code review'. It might seem as a mere linguistic thing, but the term checklist often means for people: if I only check these, it will be ok.

thank you for the nice feedback, I really appreciate this.

I do not have a Windows machine available right now, but did you try to use backslashes in the javac command instead of forward slashes?

I do not really understand your question but in both cases the module-info file is at the same level as where the package starts. Part 1 is a simple Java project, Part 2 is a Maven project. Both projects can be opened with IntelliJ IDE. You can also reach out at my mail gunter@mydeveloperplanet.com

Great blog! I would like to add that CIS also provides a tool for checking vulnerabilities in your Docker images. I wrote a blog about it some time ago: https://mydeveloperplanet.com/2019/01/16/secure-docker-in-production/ It can help you identify security issues.

Thank you for your comment. But what is properly in 'After configuring the credStore properly' more specifically?

I can recommend this book, see also my review at https://mydeveloperplanet.com/2020/02/26/book-review-the-unicorn-project/

According to leading agile experts (several which have created the Agile Manifesto), SAFe is anything but agile: https://www.smharter.com/blog/safe-a-collection-of-comments-from-leading-experts/

Sources for this blog have been moved to branch feature/blog: https://github.com/mydeveloperplanet/jiratimereport/tree/feature/blog

Sources for this blog have been moved to branch feature/blog: https://github.com/mydeveloperplanet/jiratimereport/tree/feature/blog

2. Also in paragraph 3: it is not needed to add the following to the unit test:

@Container
static PostgreSQLContainer postgreSQL = new PostgreSQLContainer();

@DynamicPropertySource
static void postgreSQLProperties(DynamicPropertyRegistry registry) {
registry.add(“spring.datasource.url”, postgreSQL::getJdbcUrl);
registry.add(“spring.datasource.username”, postgreSQL::getUsername);
registry.add(“spring.datasource.password”, postgreSQL::getPassword);
}

The errata's above are fixed in the original blog post: https://mydeveloperplanet.com/2020/05/05/easy-integration-testing-with-testcontainers/

There are two errata's in the post:

1. In paragraph 3, the properties file contains a } too much:
${embedded.postgresql.user}}

yes, you are right, it should be 'list of modules'. Thank you for the comment. I cannot change it here at DZone anymore, but will do so at my personal blog.

The dockerfile Maven plugin seems easier to use in this case, in my opinion. An example can be found at: https://mydeveloperplanet.com/2018/05/16/build-and-deploy-a-spring-boot-app-on-minikube-part-1/

Thank you for the feedback. I agree that it would have been better to add jenkins to the docker group.

The pro's and con's of this setup are clearly described in the first part of paragraph 4.3. It is clearly stated that this setup should only be used in a playground setup. Your comment however implies that you did not read the article thoroughly.

It would have been better if you provided a link to an article how you think it should have been done. This would have been positive feedback instead of just criticizing and giving a vague advice.

Did you execute the command?

docker inspect myjenkins

It should show you the IP Address to use. What URL are you using?

Of course, see the last line of the introduction, a link to the Java and Python repository are available there.

First of all, you will have to look at the adoption of JDK 11. A prediction of InfoQ shows that they expect 10% of adoption of JDK 11 at the end of 2019 (https://www.infoq.com/news/2018/12/java-2019-predictions/). I don't think that everyone that adopts JDK 11 will start immediately with modules, so I assume that will lag even behind.

Hi Thiago, I am not completely sure, but according to me, you can use properties you define in your pom file and use them in the appengine-web.xml. If you can do that, then you can use maven profiles in order to set the correct property. You define a dev profile and a prod profile. Hope this guides you in the right direction.

You can enable it in any Spring Boot app. Spring Actuator will create the endpoints for you. It is up to you to to enable the different endpoints in the application.properties.

Is it working fine on Windows? According to the installation instructions of Minikube, Windows support is still experimental: https://github.com/kubernetes/minikube/releases

I had several problems in the past installing Minikube on Hyper-V, then turned to VirtualBox, but also this gave problems. Eventually, I turned to using an Ubuntu VM and installed Minikube but without using a vm-driver.

I have no experience with an Image Based RESTful service, therefore I cannot answer your question.

The Spring example has a GreetingRouter with a method route which is annotated as a Bean. I first created an own example ExampleRouter also with a method route and annotated as a Bean. The problem here is that two beans with the same name exist which causes the error. When you give the bean a unique name (exampleRouter in this case), the problem is solved. Hope this explains it enough.

Common libraries are placed in the parent pom. The modules poms will inherit the libraries of the parent pom. If for some reason you need another version of a library in your module pom, then you can override it in your module pom. It is a similar approach as inheritance in Java. Hope this helps.

Hello José,

you will use Spring Webflux whenever you need asynchronuous processing and with microservices. Take a look at the following article: https://dzone.com/articles/patterns-for-microservices-sync-vs-async It is quite good explained.

I don't really understand why you should do something like this. It is far more easy (and cheap if you run Nexus OSS) to run a docker instance of Nexus and don't abuse a VCS for this. Besides that, a repository manager is far more than only storing your own artifacts. It also serves as a proxy for your maven libraries and provides tooling for managing your artifacts.

Maybe your solution is cheap because you don't have to run Nexus yourself, but you will spend extra effort (and therefore extra costs) in managing your artifacts manually with the GitHub solution and abusing a VCS.

Thank you for the feedback. I just tried the command again and it works for me with the semicolon. I guess you mean the semicolon in the module-path, right? I also checked the Oracle documentation and it says to use a semicolon: https://docs.oracle.com/javase/9/tools/java.htm#JSWOR624

First of all, I did not create the plugin, I am a user of the plugin. No credits for me for creating it ;-)

I have read the post you mentioned, which is also interesting. It seems to me, but correct me if I am wrong, that it takes more effort to use the approach described and is less flexible in the information you want to put into a version properties (or class) file.

The git commit id plugin is limited to git, that is correct. The approach with the buildnumber maven plugin is less SCM dependent. So, if you are using another SCM than git, you will need to fall back to the buildnumber maven plugin.

I think a properties file is more convenient than a Version.java class:

* the properties file can be read by anyone without having to run the application. E.g. if someone quickly wants to see the versioning information, the data can be read with a text editor

* a properties file does not prevent you from having a Version.java class. You can still make your Version.java class and read the properties file and then have the possibility to retrieve the versioning information within you Java application. I think this would be the most flexible approach.

To summarize, the approach in the link you provided is also a valid way. It depends on your application, tooling, needs which solution you choose. In any way, make sure that the versioning information is generated and not manually maintained.

You state that 'In addition, if the service is not in the application module, then the module declaration must have a requires directive that specifies the module which exports the service.' is not true. But, the application module is the Consumer module. The Consumer module must have a requires directive for the ServiceInterface module (which exports the service). This is according to the example you gave correct. So, the statement in the JDK documentation is correct, right?

That is an interesting question. A drawback would be that there is extra configuration to make (certainly if you are planning to do this manually). However, I believe that the stronger encapsulation and the possibility to use a ‘small’ JVM will be the advantages developers will deal with the most. The cost of extra configuration is small, as long as the IDE offers enough support on this. In my next post, I will show how modules can be used with Maven and IntelliJ. IntelliJ makes it quite easy to manage the module-info in such a way that it almost costs no extra effort. Besides that, I did not yet migrate a legacy system to Java 9 Modules, there might be issues with that. Currently, I see no reasons for not using Java Modules. Any other opinions are welcome of course.