Blogroll

Tech Travels

maven

So it looks like I’ve not been posting here for quite some time. Last post was in 2017…

The maven enforcer on the binary size can be a very useful tool as well as disruptive and close to useless. I think, in this world of cloud deployment and containers it’s getting again useful as you want a microservice to be as little as possible and be aware if it breaks a certain limit.

I said it: a microservice. What if you are working on a HUGE monolith comprised by 185 different OSGi bundles and God only knows how many other form of binary content are distributed in there?

In this last case, you may have a limit, with some margin and then the size is creeping closer and closer to the limit. Then you send your PR, which increase the size by just 2KB and BANG! Fails the check. WTF! You sure think… not my fault. Why on earth… regardless.

The point now is to find if there has been any commit which pushed the size considerably in the “recent past”. A task that done by hand can be tedious and error prone. So here’s another script. With a very imaginative name: artifact-size.sh.

What it does is fairly simple. it takes 3 mandatory parameters: repo, name and numer of commits. Repo is the path to a local git clone of the project, name is the relative path to the generated artifact (the jar) and number of commits is, well…, the number of commits you want to go back in time.

Don’t worry, if just invoke it without any parameter it will give you a help.

It will then take that number of commits, go back in time and start working forwards one commit a time packaging your project and collecting in target/ a CSV with the meaningful info like: commit hash, size and something more. You can then open this CSV file in open office (for example) and start playing with filters, putting it through a complex pipe of bash command or, why not, read it as it is.

If you’re lucky like me, you can find a single commit pushing considerably the size (20MB+) and therefore can work with the developer on what can be done (reverting?).

Potential future improvements? Here are some ideas and PR are always welcome

get a % of increase as argument and flag already any commit that goes beyond such threshold.

take the above % and work with bisect pinning down the first commit that bumped the size beyond such threshold.

Sure. release-plugin is giving you an extra check about any local changes that may not end in the release. However you don’t want to commit those changes to the SCM just yet; you want first to see if they works.

Personally I don’t like a package name like “sampleapp-content-x.y.z”
as I’m actually deploying a codebase and not content. So I find it a
bit misleading. In order to have the package named as
“sampleapp-codebase-x.y.z” in the sampleapp/content/pom.xml in the
build->plugin->configuration for the content-package-maven-pluing add
the name and finalName definition as following

In eclipse then by converting the project to a faceted, dynamic web project and with the proper context root path you’ll have the proper JSP support. Don’t forget to delete the rubbish that eclipse puts in when converting to a dynamic web project.

REST Web Services can be particularly difficult to test, with the need for networking, a web container, multiple threads and transaction management creating extra complexity beyond your standard unit test. In this article I demonstrate patterns designed to address this complexity while enabling complete testing of your REST web service stack.