[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