i usually stick to the saying "it it aint broke dont fix it .." apparently i am
the only person that thinks time is better spent working on new features
instead of changing old code..
developers who force refactoring of implementation code because someone decided
to demote a String param or return value to Object (for no reason then excess
time on their hands) produces an end result of endless iterations of
re-factoring code (that should NEVER have to be refactored in the first place)
is not my favourite past-time..
that said there are a few immutable exceptions to that rule :
Log4j has pretty much replaced functionality from commons-logging. e.g.
defining Levels of output severe (nothing but worst) vs info (everything and
the kitchen sink) and Appenders (SMTP and FTP as well as File and HTTP
Appenders)..ceki thought of everything when he designed this library
i use log4j almost exclusively ..having come off a situation which used
commons-logging i groaned thru CL which did'nt have the functionality i needed
if any developer here wants to go and replace (the largely untouched
commons-logging codebase) with log4j functionality i say go for it!!!
http-commons is about to get a new facelift when IPV4 addresses run out..which
is from my recollection immediately..we all need to bury the legacy IPv4
addressing schema (it has served us well for almost 30 years) and go full speed
ahead for accommodating IPv6 addresses into http-commons-(IPv6) library
any thoughts ???
Martin
______________________________________________
Jogi és Bizalmassági kinyilatkoztatás/Verzicht und
Vertraulichkeitanmerkung/Note de déni et de confidentialité
Ez az
üzenet bizalmas. Ha nem ön az akinek szánva volt, akkor kérjük, hogy
jelentse azt nekünk vissza. Semmiféle továbbítása vagy másolatának
készítése nem megengedett. Ez az üzenet csak ismeret cserét szolgál és
semmiféle jogi alkalmazhatósága sincs. Mivel az electronikus üzenetek
könnyen megváltoztathatóak, ezért minket semmi felelöség nem terhelhet
ezen üzenet tartalma miatt.
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger
sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung
oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem
Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung.
Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung
fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le
destinataire prévu, nous te demandons avec bonté que pour satisfaire informez
l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est
interdite. Ce message sert à l'information seulement et n'aura pas n'importe
quel effet légalement obligatoire. Étant donné que les email peuvent facilement
être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité
pour le contenu fourni.
> Subject: Question.
> Date: Fri, 11 Feb 2011 15:09:54 -0500
> From: nadia.a...@cgi.com
> To: user@commons.apache.org
>
> Hello Common Developers,
>
>
>
> In my department, we have java modules on Unix, some of them uses third
> party tools like: jasper, some uses hibernate, .... . Some modules
> uses more than one java third party tool.
>
> Most of these third party tools uses commons in their code. Now we
> install all of these products in order Unix box and change the class
> path in order to use the third party tool in our modules.
>
>
>
> The question is how to control different releases of commons within the
> same program? How compatible are your new releases with the older ones.?
> Is it safe to substitute always with the latest for all these third
> party tools?
>
>
>
> Please advise.
>
>
>
>
>
>
>
>
>
> Nadia Ayar
>
> Brokerage Services, Banking and Investment CGI Information Systems &
> Management Consultants Inc. Office Phone Number - (905) 762 2800 X4502.
> 125 Commerce Valley Drive West - 6th Floor Markham, ON L3T 7W4
>
> CONFIDENTIALITY NOTICE: Proprietary/Confidential Information belonging
> to CGI Group Inc. and its affiliates may be contained in this message.
> If you are not a recipient indicated or intended in this message (or
> responsible for delivery of this message to such person), or you think
> for any reason that this message may have been addressed to you in
> error, you may not use or copy or deliver this message to anyone else.
> In such case, you should destroy this message and are asked to notify
> the sender by reply email.
>
>
>
