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

Noah Botimer botimer at umich.edu
Tue Sep 1 12:09:38 PDT 2009


I agree, commons-codec should be promoted to shared and upgraded. I  
looked some time back and the 1.2->1.3 upgrade was pure fixes. I  
didn't see any potential for expected function to change.

I also think our com.sun (Xerces) Base64 references are gone now, but  
that's worth a check.

+1

Thanks,
-Noah

On Sep 1, 2009, at 1:03 PM, Seth Theriault wrote:

> 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
>
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to sakai-dev- 
> unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>
>



More information about the sakai-dev mailing list