tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Gomez <>
Subject Re: [PROPOSAL] Distributing the .jar files as binaries in release
Date Mon, 24 Mar 2003 12:06:48 GMT
Costin Manolache wrote:
> Remy Maucherat wrote:
>>>For example if we fix something in jk - should we have to make a full
>>>new release of tomcat ? Same for jasper, catalina, etc.
>>Yes, we do. We release stable builds based on multiple components. We
>>can't support pick and choosing (latest big example: Xerces, which you
>>couldn't upgrade to the latest release). That's a guarantee to users
>>that we have tested that particular combination. How we handle the thing
>>internally is irrelevant, we have to present users with a single archive
>>containing everything needed.
> It's not about "pick and choose" - we control the list that makes up a
> stable release. 
> I think we're looking at this problem from very different angles. 
> I won't use xerces as an example ( it's a trap :-), but commons-logging
> If some bugs are fixed (that affect tomcat) - we can recommend people to
> update commons-logging to the specific version that we tested and includes
> the fixes.
> If we find a bug in jasper - we can test the fix against the "stable"
> release and make a mini-release with only jasper. 
> At any givent time, "Tomcat stable" will be the latest major release (
> 4.1.24 ) plus any additional patches that we test. All OS vendors have
> "patches" that include updates to individual components ( well, Microsoft
> has the huge service packs, but most other just update very specific
> components ).  
> Most of our components are relatively independent of each other and we 
> have reasonably stable APIs, so "pick and choose on your own" could work,
> but we can't support it.

To follow a Packaged approach, ie using rpm/deb, tc5/tc4.1 should
have its own jars and dependencies on externals jar (logging, mx4j.).

With this way it's easy to maintain a tomcat version with up to date
externals jars (assuming they are backward compatible).

But that's just my 'packager' vision...

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message