[Building Sakai] Base64 encoding/decoding and the org.sakaiproject.util.commonscodec package

[Seth Theriault]

Hello,

While taking a look at:

http://jira.sakaiproject.org/browse/KNL-11
http://jira.sakaiproject.org/browse/SAK-14261

I found myself wondering why we are still carrying the old 
Sakai-specific reimplementations of Apache commons-codec Base64 
encoding/decoding code in K1:

kernel-util/src/main/java/org/sakaiproject/util/commonscodec/CommonsCodecBase64.java
kernel-util/src/main/java/org/sakaiproject/util/commonscodec/CommonsDecoderException.java
kernel-util/src/main/java/org/sakaiproject/util/commonscodec/CommonsEncoderException.java

Notes in the first file say:

"This code is included here to avoid having to deploy 
commons-codec to shared. See 
http://jira.sakaiproject.org/jira/browse/SAK-7408"

but the JIRA -- which has to do with breaking our dependence on 
the Tomcat 1.4 JDK compatibility pack -- is a bit hazy on exactly 
why we are doing this.

So, I decided to run some stats.

In kernel, 3 files reference the Sakai-specific 
org.sakaiproject.util.commonscodec.CommonsCodecBase64:

kernel-util/src/main/java/org/sakaiproject/util/BaseResourceProperties.java
kernel-util/src/main/java/org/sakaiproject/util/BasicAuth.java
kernel-util/src/main/java/org/sakaiproject/util/Xml.java

In trunk and 2.6.x, it's 5 files:

assignment/assignment-impl/impl/src/java/org/sakaiproject/assignment/impl/BaseAssignmentService.java
assignment/assignment-impl/impl/src/java/org/sakaiproject/assignment/impl/conversion/impl/CombineDuplicateSubmissionsConversionHandler.java
calendar/calendar-impl/impl/src/java/org/sakaiproject/calendar/impl/BaseExternalCalendarSubscriptionService.java
mailarchive/mailarchive-impl/impl/src/java/org/sakaiproject/mailarchive/impl/conversion/ExtractXMLToColumns.java
mailarchive/mailarchive-impl/impl/src/java/org/sakaiproject/mailarchive/impl/DbMailArchiveService.java

For comparison, 2 files in kernel and 14 files in trunk, and 15 
files in 2.6.x seem to be using 
org.apache.commons.codec.binary.Base64 for encoding/decoding (one 
file, CombineDuplicateSubmissionsConversionHandler.java, imports 
both but only seems to use the Apache one!)

So, since in trunk and 2.6.x, the commons-codec artifact is 
referenced in 46 pom.xml files, is there really a reason this 
shouldn't be in shared as the notes indicate? Wouldn't it be 
better practice to simply use a standard package so we don;t 
have to re-implement fixes like this:

http://issues.apache.org/jira/browse/CODEC-61

that was fixed in the new version (1.4) that was released 3 weeks 
ago?

Seth