proxool-developer

[Proxool-developer] Proxool IRC

[Christian N. <chr...@em...>]

We have set up an IRC channel for Proxool.

Server: oslo.no.eu.undernet.org
Port: 6660
Channel: Proxool

Everybody is weclome to join.

CHR

-- 
_______________________________________________
Sign-up for your own FREE Personalized E-mail at Mail.com
http://www.mail.com/?sr=signup

Meet Singles
http://corp.mail.com/lavalife

[Proxool-developer] Logging class refactoring?

[Martin C. <mus...@us...>]

All.

So I've been porting documentation over and reading it as I go...

Question:

I understand that we wanted to remove the dependency of the 
commons-logging package. Mainly I guess because JDBC drivers standardly 
are one package. Additionally, because it would be good to keep the 
dependencies down.

I guess the question is why refactor over redistribute? To make a single 
JAR the Ant script could unjar the commons-logging JAR and then jar it 
back in the Proxool JAR.

True, we could potentially run into version issues in the future. Our 
trade off as I see it though is that we loose the reusability using 
existing implementations of Log (without refactoring them too). Plus we 
have a bit of a maintenance head ache on our hands.

I am sure there are some good arguements to refactor over redistribute? 
I'd be interested in hearing these arguments. Mainly because I've been 
considering this issue often in other projects and usually just rebunlde 
the JARs.

Cheers.
Martin

Re: [Proxool-developer] Logging class refactoring?

[Bill H. <bi...@lo...>]

Martin,

On Fri, 2003-02-28 at 06:11, Martin Crawford wrote:

> I guess the question is why refactor over redistribute? To make a single 
> JAR the Ant script could unjar the commons-logging JAR and then jar it 
> back in the Proxool JAR.

Yes, that is tempting. The trouble is that because the package names
would remain the same it would conflict with the *real* commons-logging
if that too was on the classpath. 

Most of the time, that would be just fine, but if the user upgrades to a
new version yet proxool.jar is first on the classpath then the user
won't get the upgrade! Or worse still, get compile time errors because
of conflicts between the classes of the same name. 

The refactoring is pretty simple so we shouldn't have a problem with
keeping up with the latest versions.

This sounds wise to me. Anyone?

Cheers,
-- 
  Bill Horsman
  Proxool
  http://proxool.sourceforge.net
  ICQ: 119577180