Re: svn commit: r581797 - in /turbine/fulcrum/trunk/crypto: ./ src/java/org/apache/fulcrum/crypto/ src/java/org/apache/fulcrum/crypto/impl/ src/java/org/apache/fulcrum/crypto/provider/ xdocs/

[Scott Eade <se...@backstagetech.com.au>]

commons-codec was in fact a pre-existing dependency so it was hardly 
likely to cause problems for anyone.

While my personal preference would be to retain the pre-existing 
dependency, Siegfried does at least have a rational for the way he 
implemented it and a counter-argument to the maintenance point (key 
phrase: "in this case").

Let's try and not discourage any efforts that go into moving us forward.

Scott

Dipl. Ing. Siegfried Göschl wrote:
> Hi Thomas,
>
> in this case the big question is - how stable is the Base64 
> implementation versus adding a dependency? IMO Base64 implementation 
> is stable and therefore safe to be "copy and wasted" versus having an 
> additional dependency.
>
> Any other opinions out there ... :-)
>
> Cheers,
>
> Siegfried Goeschl
>
>
>
> On Thu Oct 4 17:34 , Thomas Vandahl sent:
>
>     Dipl. Ing. Siegfried Göschl wrote:
>     > Hi Scott,
>     >
>     > +) I spend a big junk of my time managing projects and fighting
>     > dependency hell
>     > +) fulcrum-crypto was depending on three external libraries
>     whereas two
>     > of them are troublesome (cryptix, mail)
>     > +) since fulcrum is a component repository any additional
>     dependency is
>     > a problem because it is required if you would like to use a component
>     > +) if you depend on a single self-contained class of an external
>     library
>     > I tend to move the code to my own project to get rid of the
>     dependency
>     > +) looking at fulcrum-yaafi as an example I could depend on
>     > commons-lang, commons-codec, commons-proxy and commons-cli
>     > +) from a technical point of view those dependencies are correct but
>     > makes reuse a lot harder
>
>     I understand your point but I beg to differ (as you know). IMO, if you
>     flee the dependency hell this way, you will rot in maintenance hell
>     sooner or later. We call that "den Teufel mit dem Beelzebub
>     austreiben"
>     in German.
>
>     Bye, Thomas.
>
>     ---------------------------------------------------------------------
>     To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
>     <javascript:top.opencompose('dev-unsubscribe@turbine.apache.org','','','')>
>     For additional commands, e-mail: dev-help@turbine.apache.org
>     <javascript:top.opencompose('dev-help@turbine.apache.org','','','')>
>
>
> --------------------------------------------------------------------- 
> To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org For 
> additional commands, e-mail: dev-help@turbine.apache.org 



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org