Quote from commons-codec web site : "Codec was formed as an attempt to focus development effort on one definitive implementation of the Base64 encoder. At the time of Codec's proposal, there were approximately 34 different Java classes that dealt with Base64 encoding spread over the Foundation's CVS repository. Developers in the Jakarta Tomcat project had implemented an original version of the Base64 codec which had been copied by the Commons HttpClient and Apache XML project's XML-RPC subproject. After almost one year, the two forked versions of Base64 had significantly diverged from one another. XML-RPC had applied numerous fixes and patches which were not applied to the Commons HttpClient Base64. Different subprojects had differing implementations at various levels of compliance with the RFC 2045 . Out of that confusing duplication of effort sprang this simple attempt to encourage code reuse among various projects. While this package contains a abstract framework for the creation of encoders and decoders, Codec itself is primarily focused on providing functional utilities for working with common encodings. " I know that having a core that do not rely on some other lib is a good feature. But is code dup worth it ? I personnaly hate it but i'm not saying we absolutely should avoid it specially when we're talking about only one class ... I'm just emphasing that point and the fact that we would have to carefully watch the updates on this class to keep up with them my 2 cents :) Cordialement, Regards, -Edouard De Oliveira- http://tedorg.free.fr/en/main.php
----- Message d'origine ---- De : Julien Vermillard <[EMAIL PROTECTED]> À : dev@mina.apache.org Envoyé le : Mercredi, 13 Août 2008, 12h26mn 16s Objet : Commons Codec Base64 Was : Re: Re : svn commit: r685401 - /mina/trunk/core/pom.xml On Wed, 13 Aug 2008 06:54:29 +0000 (GMT) Edouard De Oliveira <[EMAIL PROTECTED]> wrote: > Hi guys, > +1 to dependency discussion. I didn't know we could just add some > apache class in in order to avoid adding dependencies to the core. In > fact, the code used the class and i thought it was preferable to > import the dependency to avoid code dup so i modified it just before > committing. Talking abouts this, i'm relatively new to maven but > parent pom already enlists commons-codec as a dependency why do > the core child pom can't beneficiate from this dependency ? I'll > correct the headers tonight : as the svn tag says, its only the > initial commit and it was done on 2:00 AM There are other points to > discuss about the code but i wanted to commit it to trunk to give all > the opportunity to start test driving it. Cordialement, Regards, > -Edouard De Oliveira- http://tedorg.free.fr/en/main.php > > > > ----- Message d'origine ---- > De : Emmanuel Lecharny <[EMAIL PROTECTED]> > À : dev@mina.apache.org > Envoyé le : Mercredi, 13 Août 2008, 8h36mn 09s > Objet : Re: svn commit: r685401 - /mina/trunk/core/pom.xml > > Julien Vermillard wrote: > > Hi, > > > > I think we need to discuss this extra core dependency, perhaps we > > need to move proxy support as a module ? > > > Is this used to do base64 decoding/encoding ? > > If so, it might be enough to import the class we need, as Julien > suggested. > I finally copied base64.java (and removed some references to other classes) to o.a.mina.util and remvoed all trace of commons codec from the poms. I think it was here when the asyncweb http codec was assimilated as a mina module. Julien _____________________________________________________________________________ Envoyez avec Yahoo! Mail. Une boite mail plus intelligente http://mail.yahoo.fr
