Documenting project information with Maven

In most projects I’ve worked on, the project information is captured in some sort of file. While this has its strengths, such as ability to write free form text and embed images, it doesn’t quite fit with the project because when the artifact is produced during the build time, the read me is not checked into the artifact repository along with it. So how do I know who the contributors were for that specific artifact version? How do I know where the project was hosted at the time?

Well, today I learned that maven provides ability to capture some of those attributes and some more! I like this because it means that when the artifact gets checked in (along with its pom.xml) the details about the project are captured for that version, frozen in time.

Great thing about these attibutes is that when you run mvn site they are used in the project information html page that maven produces. Technically, then you can upload this to any statically hosted site location, all versioned up and ready to be explored.

Ok so lets begin exploring these attributes. The first three attributes are the basic ones:

For people working in corporations and companies, the following might be useful, especially when open sourcing the project:

Additionally, the licenses tag can be used to describe some licensing information. How many times have you come across a project that has changed the licensing information half way through versions? This is a life saver (at least legally)!

Some source control information is also useful, however, whats more useful is knowing where to go in order to raise issues. In most companies, people use source control to store code but then use an alternative mechanism like Jira or Trello to mange issues. The scm and issueManagement tags are useful here in clarifying such information:

Developer information on projects is very useful. Companies don’t usually like this because, well, developers are supposed to be expendable, however, in my humble opinion, it is useful to list developers who were working on the project at the time. This way the versions can be tracked, at least to the lead working on it at the time. Use it thusly:

For contributors, people who have worked on the project, although not necessarily part of it exclusively, use:

Lastly, it is useful to capture some information about pipeline that was used to create the project. For this, maven has ciManagement tag:

The above is just a small example of what you can do with these attributes, there are many more sub-attributes that you can explore. Hope this is a good introduction and kicks off some ideas of what you can do with this information.

Finding classes in jar/war files

Recently I was out looking for classes that were present in my Web Application Archive (WAR) file. Why? Well, I was out combating Jar Hell. As I am allergic to doing things manually, here’s a small command I constructed to help me find classes within jar files:

The above command prints out class file as well as the name of the jar file that class is present in. If you’re looking just for the path where the classes are present, you can just run:


Download Java Cryptography Extension (JCE) jars using curl

Normally, in order to acquire the JCE jars, you have to:

  1. Go to google
  2. Search JCE Jars
  3. Navigate to oracle website from search results
  4. Accept some agreement agreeing to sell your soul to Oracle
  5. Finally download the jars.

While this is great, it doesn’t work well for when you want JCE jars in your docker container. I mean, yeah you can get it by downloading it into a static directory so that it is available to docker during build time but to be honest, that is a bit lame. Lamer than just fetching it from a URL.

Now, I can’t remember the exact source but after much head banging and googling, I found the following command to download Java Cryptography Extension jars on the fly using curl.

At this point in time, I don’t have links to other versions of this. I needed it for Java 8 and I found it for Java 8. Regardless, I can’t imagine why it wouldn’t work if you’d just change the version from 8 to 7 in the above command.

How to delete all entries from Java JKS Keystore

I had to deal with this recently. After much trial and error, here’s the command that you can use to wipe your Java JKS Keystore of all its entries:

Here, the variable KEYSTOREis the path to your Java keystore and the variable KEYSTORE_PASS is the keystore’s password. If you are not comfortable in using the keystore password plain text in command line, I’d suggest you use an alternative version using a file containing keystore password or name of an environment variable instead. This will hide the password from appearing in shell history. You can do this by suffixing the -storepass argument with :file or :env resulting in it effectively becoming -storepass:file <path/to/file> or -storepass:env <ENV_NAME_WITHOUT_$. Here are some examples:

In the above, notice how the ${KEYSTORE_PASS} environment variable has changed to ${KEYSTORE_PASS_FILE}. Use this to provide a path to the file containing your keystore password.

Similar to previous, this one has been slightly modified to use the -storepass:env flag with ${KEYSTORE_PASS_ENV} environment variable instead.

Generating random bytes in Java

I recently needed to generate a bit of randomness in Java in order to produce a secret. Java comes built in with Random and SecureRandom classes which can help you do this properly but as with all things, there are multiple ways of doing things.

Two of these stood out to me.

Generate a long random number as String, convert to hex and then convert it to bytes.

You could potentially improve this method by not just converting the long number to hex string but also maybe base64 encoding it. You could potentially go further by adding additional entropy to it by filling in random bytes in random indices.

But as it stands above, the benefit of this method is that it is very quick to run. This may vary based on your random seed but I have found the above method to consistently produce byte arrays of size 14-16. This might be good enough in most cases – especially due to the fact that its fast, but in times where you might need very high amounts of entropy, the second approach might suit you.

My personal discontent with this method is that the bytes it produces will be chunked by the length of each individual hex character due to the fact that it is coming from a hex string. This, arguably is not very random. Arguably because although every individual hex characters are themselves in random order, the bytes generated off of those will have identifiable chunks representing each hex character. The second approach resolves this problem in a simpler way.

Another issue I have with this approach is that the total size is limited to the maximum value a Long can support (263-1). The size of Long data structure limits the length of hex string that gets generated which in turn limits total number of bytes produced.

The approach below resolves most of these issues.

Generate a array of random size composed of bytes and then let SecureRandom fill in those bytes.

Here, we’re creating a byte array of random size and then using secure random to fill that byte array in with random bytes. Its simple and elegant. However, as with all things, this has pros and cons of its own.

In my experiments, I have found the range of the byte array to be truly random. In a test that I ran, once it created a byte array of size 8890 while in another time, it created an array so large, I lost my patience and had to quit the process.

This poses a problem where your program could take a long time to generate your secret. Furthermore, it could potentially even go out of stack memory if the array becomes too large.

You can resolve this issue by setting a bound to the random.nextInt which is being used to determine the size of the byte array. I cannot tell you what size here is most optimal because it really depends on the capabilities of the processor you’re running on, your stack size as well as the algorithm you’re using to initialise SecureRandom. An implementation limiting the size of the byte array may look like following:

Here the size of the byte array will be between 0 and 20.

Also, please note that without the Math.abs the value for byteArraySize could be negative. If you initialise your array with a negative number for size, you will get NegativeArraySizeException.