Henri Gomez wrote:
> That's why the idea of using a repository of jars is a good idea :
>
> /usr/share/java/log4j-1.1.3.jar
> /usr/share/java/log4j-1.2.7.jar
> /usr/share/java/log4j-1.2.8.jar
> /usr/share/java/log4j.jar -> log4-1.2.8.jar
>
> /usr/share/java/mx4j-jmx-1.1.1.jar
> /usr/share/java/m
Costin Manolache wrote:
Henri Gomez wrote:
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 compat
Henri Gomez wrote:
> 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).
Yes -
Henri Gomez wrote:
>> - the jar names should be fully versioned ( otherwise we can't keep
>> more than a version in the dist dir ), and a symbolic link will point to
>> the latest release.
>> We would have:
>> catalina.jar -> catalina-4.1.24.jar
>> tomcat-util.jar -> tomcat-util-4.1.24.jar
>>
On Fri, 21 Mar 2003, Costin Manolache wrote:
| It's not about "pick and choose" - we control the list that makes up a
| stable release.
[ ... ]
|
| 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
| "p
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: X
Costin Manolache wrote:
We currently distribute .tar.gz / .zip with the full tomcat as
well as RPM, .so, .exe.
I would like to start adding .jar files as part of the release process
for tomcat - eventually even for 4.1.24 ( we just need to upload the
current jars as a separate download ).
The
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
Costin Manolache wrote:
Remy Maucherat wrote:
If it's just to be used for build tools, then it's ok (and no need for a
proposal, it just needs to get done). The trouble starts if users start
thinking they can use that to upgrade to a newer release, just by
upgrading one or two JARs (or ever worse
Remy Maucherat wrote:
>
> If it's just to be used for build tools, then it's ok (and no need for a
> proposal, it just needs to get done). The trouble starts if users start
> thinking they can use that to upgrade to a newer release, just by
> upgrading one or two JARs (or ever worse, mixing compo
Remy Maucherat wrote:
> No, sorry, I don't like the whole idea. We also have some work left to
> do to split the main Catalina JAR. I'm quite happy with the current
> distributions overall, and users apparently are also.
The current distribution remains - I'm just proposing to also distribute
ind
Mel Martinez wrote:
In general, I like the idea because there are numerous
projects out there that use specific jars from tomcat
and this would greatly ease access. There is some
discussion going on elsewhere in the community for
distributing jars with this kind of model. The idea
is that an appl
In general, I like the idea because there are numerous
projects out there that use specific jars from tomcat
and this would greatly ease access. There is some
discussion going on elsewhere in the community for
distributing jars with this kind of model. The idea
is that an application's expressed
Costin Manolache wrote:
We currently distribute .tar.gz / .zip with the full tomcat as
well as RPM, .so, .exe.
I would like to start adding .jar files as part of the release process
for tomcat - eventually even for 4.1.24 ( we just need to upload the
current jars as a separate download ).
The
We currently distribute .tar.gz / .zip with the full tomcat as
well as RPM, .so, .exe.
I would like to start adding .jar files as part of the release process
for tomcat - eventually even for 4.1.24 ( we just need to upload the
current jars as a separate download ).
The proposal is very simple:
15 matches
Mail list logo