Posts about technology and arts.
Some time ago while working in one of the many projects in the Apache Software Foundation (Apache Commons FileUpload if I remember well), I noticed that it had a Base64 implementation. What called my attention was that the project not using the Apache Commons Codec Base64 implementation.
While Apache Commons’ mission is to create components that can be re-used across ASF projects, and also by other projects not necessarily under the ASF, it is understandable that some projects prefer to keep its dependencies to a minimum. It is normally a good software engineering practice to carefully manage your dependencies.
But would Apache Commons FileUpload be the only project in the ASF with its own Base64 implementation?
Simply put, Base64 is a way to encode bytes to strings. It utilises a table, to convert parts of the binary input to certain numbers. These numbers match an entry in the table used by the Base64 implementation. There are several Base64 implementations, though some are obsolete now.
The input text “this is base64!” results in “dGhpcyBpcyBiYXNlNjQh”. It can be decoded and will result in the same input text. An image can also be encoded. Or a ZIP file. This is helpful for data transfer and storage.
Apache Commons Codec is well known to provide a Bse64 implementation, and used in several projects, both Open Source and in the industry. Its implementation is based on the RFC-2045.
Java 8 contains a Base64 implementation, so that may very well replace Apache Commons Coded use in some projects, though that may take some time. The Java 8 implementation supports the RFC-2045, RFC-4648, and has also support to the URL and MIME formats.
Using GitHub search, I looked for other Base64 implementations in the ASF projects. Here’s the result table with only the custom implementations found after going through some 15 pages in more than 100 pages with hits for “base64”.
|Project & link to implementation||JVM||Base64 implementation|
|Apache ActiveMQ Artemis||8||RFC-3548, based on http://iharder.net/base64|
|Apache AsterixDB Hyracks (Incubator)||8||?|
|Apache Calcite Avatica||7||RFC-3548, based on http://iharder.net/base64|
|Apache Cayenne||8||RFC-2045 (based on codec)|
|Apache Chemistry||7||RFC-3548, based on http://iharder.net/base64|
|Apache Commons FileUpload||6||?|
|Apache Commons Net||6||RFC-2045 (copy of codec?)|
|Apache Directory Kerby||7||RFC-2045 (copy of codec?)|
|Apache Felix||5 (?)||RFC-2045 (copy of codec?)|
|Apache HBase||8||RFC-3548, based on http://iharder.net/base64|
|Apache Jackrabbit||8 (?)||?|
|Apache James||6||RFC-2045 via javax.mail.internet.MimeUtility|
|Apache James Mime4J||5||RFC-2045 (based on codec)|
|Apache Qpid||8||? uses javax.xml.bind.DatatypeConverter#parseBase64Binary()|
|Apache Shiro||6||RFC-2045 (based on commons)|
|Apache Tomcat||8||RFC-2045 (copy of codec?)|
|Apache TomEE (Site-NG)||6||RFC-2045|
|Apache Trafodion (Incubator)||7||RFC-3548, based on http://iharder.net/base64|
|Apache Wave (Incubator)||7||RFC-3548 (?), based on http://iharder.net/base64|
♥ Open Source
Last week I wrote about the ImmobilienScout24/illegal-transitive-dependency-check rule for Maven Enforcer Plug-in. There are two other Maven Plug-ins that can be useful.
The mbknor/deptools is another rule for the Maven Enforcer Plug-in. It will scan your project dependency tree, looking for transitive dependencies. Whenever it finds a transitive dependency, it will keep track of the versions. And if, because of the way your dependencies and transitive dependencies are organised, you end up with a version that is not the newest, the build will fail.
So, for example, if you have
commons-lang3 as transitive dependency of two other dependencies, but one is using 3.4 and the other 3.5. If for any reason you are using 3.4 instead of 3.5, you will have a build error.
Here’s an example of the plug-in configuration.
<project> ... <build> <plugins> <plugin> <groupId>deptools.plugin</groupId> <artifactId>maven-deptools-plugin</artifactId> <version>1.3</version> <executions> <execution> <phase>compile</phase> <goals> <goal>version-checker</goal> </goals> </execution> </executions> </plugin> </plugins> </build> <pluginRepositories> <pluginRepository> <id>mbk_mvn_repo</id> <name>mbk_mvn_repo</name> <url>https://raw.githubusercontent.com/mbknor/mbknor.github.com/master/m2repo/releases</url> </pluginRepository> </pluginRepositories> ... </project>
mvn clean verify will execute the Maven Enforcer Plug-in
enforce goal, which will call the deptools check. As you may have noticed, you also need to download the plug-in from GitHub, as it is not released to Maven Central.
I do not use it for this reason, and also because I normally spend some time looking at the dependency tree anyway, but every now and then when I work on a new project I like quickly running it just to see what are the dependencies that are being shadowed by older versions.
<project> ... <build> <plugins> <plugin> <groupId>net.revelc.code</groupId> <artifactId>impsort-maven-plugin</artifactId> <version>1.0.0</version> <configuration> <groups>java.,javax.,org.,com.</groups> <staticGroups>java,*</staticGroups> <excludes> <exclude>**/thrift/*.java</exclude> </excludes> </configuration> <executions> <execution> <id>sort-imports</id> <goals> <goal>sort</goal><!-- runs at process-sources phase by default --> </goals> </execution> </executions> </plugin> </plugins> </build> ... </project>
I am neutral on imports order, though in cases where you have several contributors submitting pull requests, it can probably be useful to reduce the number of interactions. In other words, if a user submits a pull request and you have an automated check, then the user would be automatically notified about changes that s/he needs to do in order for his pull request to be accepted.
I am not using any of these two plug-ins, but wanted to save it somewhere in case I needed to use them in the future, and also to share with others. Besides most common plug-ins (PMD, CheckStyle, FindBugs), I normally use at least some Maven Enforcer Plug-in rules, and the OWASP plug-in.
While most of the time we spend writing code, preparing the infrastructure, and deploying and testing, I got bitten by some maven build bugs a few times, and had to spend days/weeks debugging some of these. So hope some of these posts save some hours of someone out there in a similar situation.
♥ Open Source
Maven Enforcer Plug-in “provides goals to control certain environmental constraints such as Maven version, JDK version and OS family along with many more built-in rules and user created rules”. There are several libraries that provide custom rules, or you can write your own.
One of these libraries is ImmobilienScout24/illegal-transitive-dependency-check, “an additional rule for the maven-enforcer-plugin that checks for classes referenced via transitive Maven dependencies”.
With the following example:
<project> ... <build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-enforcer-plugin</artifactId> <version>1.3.1</version> <dependencies> <dependency> <groupId>de.is24.maven.enforcer.rules</groupId> <artifactId>illegal-transitive-dependency-check</artifactId> <version>1.7.4</version> </dependency> </dependencies> <executions> <execution> <id>enforce</id> <phase>verify</phase> <goals> <goal>enforce</goal> </goals> <configuration> <rules> <illegalTransitiveDependencyCheck implementation="de.is24.maven.enforcer.rules.IllegalTransitiveDependencyCheck"> <reportOnly>false</reportOnly> <useClassesFromLastBuild>true</useClassesFromLastBuild> <suppressTypesFromJavaRuntime>true</suppressTypesFromJavaRuntime> <listMissingArtifacts>false</listMissingArtifacts> </illegalTransitiveDependencyCheck> </rules> </configuration> </execution> </executions> </plugin> </plugins> </build> ... </project>
mvn clean verify will execute the Maven Enforcer Plug-in
enforce goal, which will call the illegal transitive dependency check.
And the build will fail if your code is using (i.e. importing) any class that is not available in your first-level dependencies. For example, if in your pom.xml you added
commons-configuration, the latter which includes
commons-lang 2.x, and you used
org.apache.commons.lang.StringUtils instead of
org.apache.commons.lang3.StringUtils, the build would fail.
In order to fix the build, you have to either add the transitive dependency to your pom.xml file, or correct your import statements. This is specially useful to prevent future issues due to other dependencies being added or updated, and changing the version of the transitive dependency.
Bonus points if you combine that with continuous integration and some service like Travis-CI.
♥ Open Source
My favourite Star Trek captain: Jean-Luc Picard.
“Space, the final frontier. These are the voyages of the starship Enterprise. Its continuing mission: to explore strange new worlds, to seek out new life and new civilizations, to boldly go where no one has gone before!”
2B pencil, rubber eraser, blending stump, and HB 0.3 mechanical pencil. Yellow-ish layer added adjusting LAB colour space in GIMP.
An Introduction to the International Image Interoperability Framework (IIIF)