You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by Edouard De Oliveira <do...@yahoo.fr> on 2008/08/14 00:48:35 UTC
Re : Commons Codec Base64 Was : Re: Re : svn commit: r685401 - /mina/trunk/core/pom.xml
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 <jv...@archean.fr>
À : 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 <do...@yahoo.fr> 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 <el...@gmail.com>
> À : 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
Re: Re : Commons Codec Base64 Was : Re: Re : svn commit: r685401 - /mina/trunk/core/pom.xml
Posted by Niall Pemberton <ni...@gmail.com>.
On Thu, Aug 14, 2008 at 12:04 AM, Emmanuel Lecharny <el...@gmail.com> wrote:
> Edouard De Oliveira wrote:
>>
>> <snip/>
>> 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
>
> Well, we have to balance advantage of keeping the framework as small as
> possible, compared to having to check out commons-codec modifications
> regularely...
How about using the shade plugin:
http://maven.apache.org/plugins/maven-shade-plugin
Niall
> The origin of the problem is that the Java JDK does not exhibit a Base64
> coder/decoder (it's not visible, but it exists), so there was a need for
> something available on ASL license.
>
> FYI, we at directory have forked the code too, and never touched it back.
> It's around 200 lines of code.
>
> Anyway, we can discuss it and make a decision.
>
> --
> --
> cordialement, regards,
> Emmanuel Lécharny
> www.iktek.com
> directory.apache.org
>
>
>
Re: Re : Commons Codec Base64 Was : Re: Re : svn commit: r685401
- /mina/trunk/core/pom.xml
Posted by Emmanuel Lecharny <el...@gmail.com>.
Julien Vermillard wrote:
<snip/>
> More seriously, minimising core dependencies is important, I know you
> all use maven and don't care, but a full lib for a 200 LoC class it's a
> bit ridiculous for me, but if it's used in critical code, and we deeply
> need update and fixes, why not.
>
I would also favor a core with the lowest possible number of
dependencies. Log libs and that's it...
> For my personal usage, I will probably never use proxy support, but I
> will need to carry another dep, and bloat a little more my embedded
> server ;)
>
Just because MINA is a framework, this approach looks like the good one.
> I really would like to have feedback on this issue from regular users.
>
announce@apache.org is the list to watch !
> Julien
>
> PS : I think we should write some this kind of propaganda about NIO
> frameworks at ASF ;)
>
Not only at the ASF... I wish I have more time !
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: Re : Commons Codec Base64 Was : Re: Re : svn commit: r685401 -
/mina/trunk/core/pom.xml
Posted by Julien Vermillard <jv...@archean.fr>.
On Thu, 14 Aug 2008 01:04:02 +0200
Emmanuel Lecharny <el...@gmail.com> wrote:
> Edouard De Oliveira wrote:
> > <snip/>
> > 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 ...
> Well, we have to balance advantage of keeping the framework as small
> as possible, compared to having to check out commons-codec
> modifications regularely...
>
> The origin of the problem is that the Java JDK does not exhibit a
> Base64 coder/decoder (it's not visible, but it exists), so there was
> a need for something available on ASL license.
>
> FYI, we at directory have forked the code too, and never touched it
> back. It's around 200 lines of code.
>
> Anyway, we can discuss it and make a decision.
>
Just for one class, if a bloated software like directory fork it, I
think we need to do it too ;)
More seriously, minimising core dependencies is important, I know you
all use maven and don't care, but a full lib for a 200 LoC class it's a
bit ridiculous for me, but if it's used in critical code, and we deeply
need update and fixes, why not.
For my personal usage, I will probably never use proxy support, but I
will need to carry another dep, and bloat a little more my embedded
server ;)
I really would like to have feedback on this issue from regular users.
Julien
PS : I think we should write some this kind of propaganda about NIO
frameworks at ASF ;)
Re: Re : Commons Codec Base64 Was : Re: Re : svn commit: r685401
- /mina/trunk/core/pom.xml
Posted by Emmanuel Lecharny <el...@gmail.com>.
Edouard De Oliveira wrote:
> <snip/>
> 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 ...
>
Well, we have to balance advantage of keeping the framework as small as
possible, compared to having to check out commons-codec modifications
regularely...
The origin of the problem is that the Java JDK does not exhibit a Base64
coder/decoder (it's not visible, but it exists), so there was a need for
something available on ASL license.
FYI, we at directory have forked the code too, and never touched it
back. It's around 200 lines of code.
Anyway, we can discuss it and make a decision.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org