Apache commons inter-dependencies

[Brett Hitzel]

Hello,

 

On our Tomcat installation we are utilizing the following jar files
(among others):

 

commons-httpclient-2.0.2.jar

commons-beanutils-1.6.jar

commons-codec-1.3.jar

commons-collections-2.1.1.jar

commons-dbcp-1.2.1.jar

commons-discovery-0.2.jar

commons-el.jar

commons-lang-1.0-b1.jar

commons-logging-1.0.1.jar

commons-pool-1.2.jar

 

These are mostly all some degree of outdated I know, unfortunately that
is out of necessity right now, due to some legacy applications.

 

We have identified the need to upgrade commons-httpclient to version
3.1. Due to the rather precarious nature of our system, we prefer to NOT
upgrade the remaining common libs if we do not have to. I have read all
through the documentation and I wasn't able to find much information on
the inter-dependencies of the commons files, but based on what I've read
it seems that the individual components are built in such a way that
their respective versions shouldn't matter much. Is there a matrix out
there that details what versions of what components will work together
and which ones won't? Is this even something I should be worried about?

 

I am new to these forums and fairly green with Java as well, so please
talk plainly :-).

 

Thanks,

Brett

Brett Hitzel schrieb:

> Hello,
>
>  
>
> On our Tomcat installation we are utilizing the following jar files
> (among others):
>
>  
>
> commons-httpclient-2.0.2.jar
>
> commons-beanutils-1.6.jar
>
> commons-codec-1.3.jar
>
> commons-collections-2.1.1.jar
>
> commons-dbcp-1.2.1.jar
>
> commons-discovery-0.2.jar
>
> commons-el.jar
>
> commons-lang-1.0-b1.jar
>
> commons-logging-1.0.1.jar
>
> commons-pool-1.2.jar
>
>  
>
> These are mostly all some degree of outdated I know, unfortunately that
> is out of necessity right now, due to some legacy applications.
>
>  
>
> We have identified the need to upgrade commons-httpclient to version
> 3.1. Due to the rather precarious nature of our system, we prefer to NOT
> upgrade the remaining common libs if we do not have to. I have read all
> through the documentation and I wasn't able to find much information on
> the inter-dependencies of the commons files, but based on what I've read
> it seems that the individual components are built in such a way that
> their respective versions shouldn't matter much. Is there a matrix out
> there that details what versions of what components will work together
> and which ones won't? Is this even something I should be worried about?
>  

No, there is no matrix of that sort. It would be useful, but the vast
amount of work that would be required to test all possible combinations
and document the results is just too much (and too boring).

If I understand right, you just want to upgrate httpclient. None of the
other libs depend on httpclient, so all you need to worry about is
whether httpclient will work with the older libs you have.

It is *possible* that commons-httpclient still works with those older
libs, but you'll need to do the work to figure out if that is true or
not. The maven2 pom.xml declares what dependencies are needed; the
version numbers in there are the "recommended" versions (and these are
the ones that are tested via the unit tests before release).

I see here:
  http://hc.apache.org/httpclient-3.x/dependencies.html
that codec and logging are the only runtime dependencies (this is the
same info that is in the pom file).

I would suggest checking out the httpclient source, editing the pom.xml
file to specify the codec and logging versions you want to use, then
running the unit tests. If they pass then that's a pretty good
indication that httpclient will work with your older lib versions.
Logging certainly will not be a problem (the API is very stable), but I
don't know about codec.

Note that the httpclient project recently moved from being part of the
commons project to being part of the "http components" project. So
questions about httpclient should probably be sent to the httpclient
email list rather than here..

The source for the 3.1 release of httpclient can be downloaded via svn
from here:
 
http://svn.apache.org/repos/asf/httpcomponents/oac.hc3x/tags/HTTPCLIENT_3_1/

Regards,
Simon


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

[juliusdavies]

Httpclient-3.x is fine with those versions of commons-codec and commons-logging.

Httpclient-3.x does not use any of the other jars, so you'll be fine
if you don't upgrade them.

In other words:  Yes, you can upload your httpclient jar, and leave
the rest alone.


yours,

Julius




On Mon, Jun 2, 2008 at 8:35 AM, simon.kitching@...
<simon.kitching@...> wrote:

> Brett Hitzel schrieb:
>> Hello,
>>
>>
>>
>> On our Tomcat installation we are utilizing the following jar files
>> (among others):
>>
>>
>>
>> commons-httpclient-2.0.2.jar
>>
>> commons-beanutils-1.6.jar
>>
>> commons-codec-1.3.jar
>>
>> commons-collections-2.1.1.jar
>>
>> commons-dbcp-1.2.1.jar
>>
>> commons-discovery-0.2.jar
>>
>> commons-el.jar
>>
>> commons-lang-1.0-b1.jar
>>
>> commons-logging-1.0.1.jar
>>
>> commons-pool-1.2.jar
>>
>>
>>
>> These are mostly all some degree of outdated I know, unfortunately that
>> is out of necessity right now, due to some legacy applications.
>>
>>
>>
>> We have identified the need to upgrade commons-httpclient to version
>> 3.1. Due to the rather precarious nature of our system, we prefer to NOT
>> upgrade the remaining common libs if we do not have to. I have read all
>> through the documentation and I wasn't able to find much information on
>> the inter-dependencies of the commons files, but based on what I've read
>> it seems that the individual components are built in such a way that
>> their respective versions shouldn't matter much. Is there a matrix out
>> there that details what versions of what components will work together
>> and which ones won't? Is this even something I should be worried about?
>>
> No, there is no matrix of that sort. It would be useful, but the vast
> amount of work that would be required to test all possible combinations
> and document the results is just too much (and too boring).
>
> If I understand right, you just want to upgrate httpclient. None of the
> other libs depend on httpclient, so all you need to worry about is
> whether httpclient will work with the older libs you have.
>
> It is *possible* that commons-httpclient still works with those older
> libs, but you'll need to do the work to figure out if that is true or
> not. The maven2 pom.xml declares what dependencies are needed; the
> version numbers in there are the "recommended" versions (and these are
> the ones that are tested via the unit tests before release).
>
> I see here:
>  http://hc.apache.org/httpclient-3.x/dependencies.html
> that codec and logging are the only runtime dependencies (this is the
> same info that is in the pom file).
>
> I would suggest checking out the httpclient source, editing the pom.xml
> file to specify the codec and logging versions you want to use, then
> running the unit tests. If they pass then that's a pretty good
> indication that httpclient will work with your older lib versions.
> Logging certainly will not be a problem (the API is very stable), but I
> don't know about codec.
>
> Note that the httpclient project recently moved from being part of the
> commons project to being part of the "http components" project. So
> questions about httpclient should probably be sent to the httpclient
> email list rather than here..
>
> The source for the 3.1 release of httpclient can be downloaded via svn
> from here:
>
> http://svn.apache.org/repos/asf/httpcomponents/oac.hc3x/tags/HTTPCLIENT_3_1/
>
> Regards,
> Simon
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@...
> For additional commands, e-mail: user-help@...
>
>

--
yours,

Julius Davies
250-592-2284 (Home)
250-893-4579 (Mobile)
http://juliusdavies.ca/

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...