lately, I have spent a lot of time setting up GitLab pipelines. A lot of those time spent, now looking back, are actually wasted in the end, because turned out they’re bugs with gitlab itself. somehow, even with gitlab 14.8, this issue still exists. to make things even bizarre…

for some old version of git-commit-id-plugin, for example, ` 4.9.10 there is a Auth Fail error, when the plugin is in execution. Turns out there was a bug (should be fixed in latest version), which uses JGitDataProvider, and requesting for ` LOCAL_BRANCH_AHEAD and LOCAL_BRANCH_BEHIND mark the plugin as office sorted out the issue <plugin> <groupId>pl.project13.maven</groupId> <artifactId>git-commit-id-plugin</artifactId> <version>4.9.10</version> <configuration> <verbose>false</verbose> <useNativeGit>true</useNativeGit> <offline>true</offline> </configuration>

Turns out when spring boot construct the configuration bean, it’s using the setter method to map the values. So for IgniteConfiguration, for example, even though the variable for peer ClassLoading is private boolean p2pEnabled =DFLT_P2P_ENABLED; however, the values below won’t work instead, it should be peerClassLoadingEnabled: true as the setter to set the p2pEnabled is actually called public IgniteConfiguration setPeerClassLoadingEnabled(boolean p2pEnabled) { this.p2pEnabled = p2pEnabled; return this; }

I have several applications that were running with 450GB memory before. It did seem like it’s a valid memory consumption, after manually calculating the memory footprint, specifically the sum up of all primitive types and object sizes. however, the same applications are now able to run with ~ 50GB from…

there are many options for continuous deployment. one possible approach is to leverage on ansible and couple it with gitlab. so in .gitlab-ci.yml add a deploy stage ansible will try to remove the old container and start the newly built docker image from previous steps. Published Originally published at https://lwpro2.wordpress.com on January 25, 2022.

I was not able to generate the git.properties at the beginning. somehow turns out it was due to a missing version for the plugin. <plugin> <groupId>pl.project13.maven</groupId> <artifactId>git-commit-id-plugin</artifactId> <version>4.0.5</version> <!--need to add the specific version--> <executions> <execution> <goals> <goal>revision</goal> </goals> </execution> </executions> </plugin> with that, at packaging, it could generate the package with the SHA.

following up with https://lwpro2.dev/2021/12/28/maven-nested-modules/ and https://lwpro2.dev/2021/12/14/microservies-in-monorepo/, there are times where a class defined upstream (either third party or shared library internally) should be overriden. The trick is to keep the class name exact with the same package name. when maven shaded the class, it would pick up the class from the closest level. For example, if module ACore has a class names org.wordpress.util.DomainMapper, a class with the exact same name org.wordpress.util.DomainMapper could be created in A1 module to override the provided functionality.

following up with https://lwpro2.dev/2021/12/14/microservies-in-monorepo/, there are times it needs a set up of nested modules. where for example, module A could contain module A1, module A2 for example. the needed changes/set up for nested maven module is similar to the multi module set up. …

recently i have spent some time to break a monolith project into multiple modules within a single monorepo. it was a huge codebase with several different projects commingled together into a same git repo. after the change, it now break into different modules, literally several microservies in a monorepo. there…