Re: [PROPOSAL] Distributing the .jar files as binaries in release

2003-03-24 Thread Henri Gomez
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

Re: [PROPOSAL] Distributing the .jar files as binaries in release

2003-03-24 Thread Henri Gomez
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:

Re: [PROPOSAL] Distributing the .jar files as binaries in release

2003-03-24 Thread Endre Stølsvik
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 |

Re: [PROPOSAL] Distributing the .jar files as binaries in release

2003-03-24 Thread Costin Manolache
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 etc. A big

Re: [PROPOSAL] Distributing the .jar files as binaries in release

2003-03-24 Thread Costin Manolache
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 - but

Re: [PROPOSAL] Distributing the .jar files as binaries in release

2003-03-24 Thread Henri Gomez
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

Re: [PROPOSAL] Distributing the .jar files as binaries in release

2003-03-24 Thread Costin Manolache
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

[PROPOSAL] Distributing the .jar files as binaries in release

2003-03-21 Thread Costin Manolache
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

Re: [PROPOSAL] Distributing the .jar files as binaries in release

2003-03-21 Thread Remy Maucherat
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

Re: [PROPOSAL] Distributing the .jar files as binaries in release

2003-03-21 Thread Mel Martinez
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

Re: [PROPOSAL] Distributing the .jar files as binaries in release

2003-03-21 Thread Remy Maucherat
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

Re: [PROPOSAL] Distributing the .jar files as binaries in release

2003-03-21 Thread Costin Manolache
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

Re: [PROPOSAL] Distributing the .jar files as binaries in release

2003-03-21 Thread Costin Manolache
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

Re: [PROPOSAL] Distributing the .jar files as binaries in release

2003-03-21 Thread Remy Maucherat
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

Re: [PROPOSAL] Distributing the .jar files as binaries in release

2003-03-21 Thread Costin Manolache
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