Re: [PROPOSAL] Distributing the .jar files as binaries in release
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 proposal is very simple:
- jars will be placed in /dist/jakarta/tomcat-x/binaries/
( the standard location in the current mirroring scheme )
- we include only the .jars that are part of tomcat. In time
we should make sure that the projects we depend on ( logging,
digester, etc ) start doing the same, and we can adjust the
build process to get only the jars and support the mirrors.
For example:
commons-logging.jar=${mirror}/jakarta/commons/binaries/commons-logging.jar
- 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 +1, it the way we choose in jPackage project but symlink didn't
works on Windows boxes
- in tomcat5 we should start including the _major_ version number in the
jar name: catalina5.jar. A version number should be used whenever we have
a break in backward compatibility.
May I suggest :
catalina5-5.0.1.jar ?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Distributing the .jar files as binaries in release
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Distributing the .jar files as binaries in release
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 | patches that include updates to individual components ( well, Microsoft | has the huge service packs, but most other just update very specific | components ). What about having the Tomcat version number, e.g. Tomcat 4.1.40, being the entire _set of jars_? So that, if you upgrade one of the jars in the package, you'd have to make a new Tomcat 4.1.41, with maybe a little human readable diff textfile for each minor-release: Jasper 1.2.3.4, because of a security hole (http://buglink) in 1.2.3.3. This means that a Tomcat version is simply a tag on the slice of its components. -- Mvh, Endre Stølsvik M[+47 93054050] F[+47 51625182] Developer @ CoreTrek AS - http://www.coretrek.com/ CoreTrek corporate portal / EIP - http://www.corelets.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Distributing the .jar files as binaries in release
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 +1, it the way we choose in jPackage project but symlink didn't works on Windows boxes AFAIK all apache mirrors are on Unix machines, and symlinks are already used in the dist/ ( for -latest.tar.gz ). The links are only used to allow people who want a latest stable. They can also be augmented with a descriptor ( similar with Apt, etc ) or even multiple descriptors to support a variety of tools. My goal with this proposal was to make it as simple as possible, with the minimum amount of change - just a small incremental addition to the current dist structure. - in tomcat5 we should start including the _major_ version number in the jar name: catalina5.jar. A version number should be used whenever we have a break in backward compatibility. May I suggest : catalina5-5.0.1.jar ? Duplicated the 5 doesn't look very good, I don't know any project doing that. The goal is to make it clear that it is a different product, that is not completely backward compatible ( even if we try our best ). There are few linux products that do that ( embed a number in the main name ). An alternative is to have: catalina-5.jar - catalina-5.0.1.jar and use catalina-5.jar as the name in the distribution. BTW, I am _not_ proposing the use of catalina.5.0.1.jar ( full versioned names ) in the runtime, this is only about distributing .jars as part of the binary release, and if this works we can extend to .war. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Distributing the .jar files as binaries in release
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 we'll have to take it with their projects ( jakarta-commons mostly, also struts, etc ). For mx4j it's a bit more complicated - IMHO all external .jars should be in an apache-wide repository and approved by somone who can check all details. I don't think it's a good idea for every project to distribute jars for all other projects. We'll still have to publish a list with the dep. version numbers of the stable release. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Distributing the .jar files as binaries in release
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 compatible). Yes - but we'll have to take it with their projects ( jakarta-commons mostly, also struts, etc ). For mx4j it's a bit more complicated - IMHO all external .jars should be in an apache-wide repository and approved by somone who can check all details. I don't think it's a good idea for every project to distribute jars for all other projects. We'll still have to publish a list with the dep. version numbers of the stable release. 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/mx4j-tools-1.1.1.jar /usr/share/java/mx4j-jmx.jar - mx4j-jmx-1.1.1.jar /usr/share/java/mx4j-tools.jar - mx4j-tools-1.1.1.jar Each Apache application/tool which require a jar could get, the latest released which is symlinked to the latest released or could use a 'named' version since you know that your application still need an outdated lib. A common repository is allways simpler to manage - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Distributing the .jar files as binaries in release
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/mx4j-tools-1.1.1.jar /usr/share/java/mx4j-jmx.jar - mx4j-jmx-1.1.1.jar /usr/share/java/mx4j-tools.jar - mx4j-tools-1.1.1.jar Each Apache application/tool which require a jar could get, the latest released which is symlinked to the latest released or could use a 'named' version since you know that your application still need an outdated lib. A common repository is allways simpler to manage Henri, we are discussing different things here. My proposal is only about distributing things at http://www.apache.org/dist/jakarta/tomcat/ What is in /usr/share/jave or C:\Java is a completely different problem. Tomcat distribution ( as well as commons, etc ) should provide the latest stable jar in each major supported branch - i.e. what we support and recommend people to use. Tomcat runtime is still using the common/lib, server/lib hierarchy - or in embeded a single flat loader ( that will likely be the case in most applications that embed tomcat ). We should support an update mechansim where people can upgrade each jar to the latest supported version - i.e. if a bug is found in jk2, we fix it and release a new tomcat-jk2.jar ( tested against the other stable jars ) and we recommend people to update only tomcat-jk2.jar. Same for every other component and libraries. That will reduce the complexity of updating tomcat - right now we have to deal with changes in all components of tomcat, and an incremental release will deal with components one-by-one. Again - I'm only discussing what we distribute, not how people can or should use it. We clearly need the version in the filename ( and it really doesn't matter where - directory or file - however given the current dist/ layout we have to put it in file ). And we clearly need a very simple way to get the latest stable. There are dozens of complex descriptor-based solutions, and they can be used in addition to support various tools. However it would be crazy to not use the symlink to allow the simple get to work. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Distributing the .jar files as binaries in release
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 proposal is very simple:
- jars will be placed in /dist/jakarta/tomcat-x/binaries/
( the standard location in the current mirroring scheme )
- we include only the .jars that are part of tomcat. In time
we should make sure that the projects we depend on ( logging,
digester, etc ) start doing the same, and we can adjust the
build process to get only the jars and support the mirrors.
For example:
commons-logging.jar=${mirror}/jakarta/commons/binaries/commons-logging.jar
- 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.
- in tomcat5 we should start including the _major_ version number in the
jar name: catalina5.jar. A version number should be used whenever we have
a break in backward compatibility.
Opinions ?
Remy - could we do that for 4.1.24 ? Should we start asking on commons
to get the .jars distributed separately so we can use them in the download
target ?
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.
I would also like the version number to be in the directory (ie, not all
releases coexist in the same dir).
Remy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Distributing the .jar files as binaries in release
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 dependencies on 3rd
party packages can include a URL to the specific jar
(including version specification). Thus deployment
host platforms can automatically retrieve and resolve
dependencies without the application developer having
to be responsible for unpacking, repackaging a subset
of tomcat (or whatever) and then possibly having to
provide the subset on his/her own server.
The caveats are that I don't know if there is
consensus yet on versioning format, there definitely
are too many competing package dependency schemes and
I'm not sure what the impact of jar refactoring will
be.
Overall, though, I like the idea.
My $.02
Mel
--- Costin Manolache [EMAIL PROTECTED] wrote:
[deleted]
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:
- jars will be placed in
/dist/jakarta/tomcat-x/binaries/
( the standard location in the current mirroring
scheme )
- we include only the .jars that are part of tomcat.
In time
we should make sure that the projects we depend on (
logging,
digester, etc ) start doing the same, and we can
adjust the
build process to get only the jars and support the
mirrors.
For example:
commons-logging.jar=${mirror}/jakarta/commons/binaries/commons-logging.jar
- 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.
- in tomcat5 we should start including the _major_
version number in the
jar name: catalina5.jar. A version number should be
used whenever we have
a break in backward compatibility.
[deleted]
__
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Distributing the .jar files as binaries in release
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 application's expressed dependencies on 3rd party packages can include a URL to the specific jar (including version specification). Thus deployment host platforms can automatically retrieve and resolve dependencies without the application developer having to be responsible for unpacking, repackaging a subset of tomcat (or whatever) and then possibly having to provide the subset on his/her own server. The caveats are that I don't know if there is consensus yet on versioning format, there definitely are too many competing package dependency schemes and I'm not sure what the impact of jar refactoring will be. Overall, though, I like the idea. 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 components). Then there's trouble. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Distributing the .jar files as binaries in release
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 individual .jars. We could also start distributing the individual .wars. Tomcat source are already very componentized - utils, coyote, jasper, catalina, jk, http, webapps. Each of those can be used in other containers, and we have relatively stable APIs. I think this is very good - and we should plan on switching to micro-releases of individual components. The current release cycle and complexity is too big IMHO. I would also like the version number to be in the directory (ie, not all releases coexist in the same dir). I would like version number in the directory - but that's what we have in the current dist/ layout. It's much easier to just use what we have and build from it. I don't like version number in jar - at least not for runtime. Having the version in dir and the simple .jar name is clearly better for this use case. But my proposal is in the middle - the distributed jars can be downloaded with both version number or without. If you want a specific version and you want to use the non-versioned name at runtime - just rename or specifiy an unversioned name as target. In the end it really doesn't matter where the version number sits - it has to be somewhere, and we can control the name of the downloaded jar. BTW, the goals of this are: 1. Increase the componentization of tomcat. In future we may be able to get to more incremental and simpler releases of individual components. 2. Simpler downloads for people who use only parts of tomcat, and simpler downloads for us if commons components we use are available as .jars. 3. Maybe we'll be able to support an upgrade feature, or patch releases For example, if a bug is found in jasper we can buildtest against the latest stable release and distribute only the fixed jasper, without having to do a full release of tomcat. ( that would be more important for 5.0, since 4.1.x is mostly stable and less likely to change ). Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Distributing the .jar files as binaries in release
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 components). Then there's trouble. Mixing components may be bad - since it is not tested or supported. However upgrading only and individual component may be very good in the future. Why do you think that patch releases ( where only few individual .jars are updated ) are bad ? For example if we fix something in jk - should we have to make a full new release of tomcat ? Same for jasper, catalina, etc. As long as we test the new jar against the stable version - and _we_ recommend the components that should be mixed - I think it is far better way to upgrade. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Distributing the .jar files as binaries in release
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, mixing components). Then there's trouble. Mixing components may be bad - since it is not tested or supported. However upgrading only and individual component may be very good in the future. Why do you think that patch releases ( where only few individual .jars are updated ) are bad ? 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. As long as we test the new jar against the stable version - and _we_ recommend the components that should be mixed - I think it is far better way to upgrade. This is too complex, and not practical. We already have problems with regressions in stable releases, people not testing anything, etc, even with the current system. What you propose would just make things worse. I don't like your ideas today ;-) Wait until tomorrow to submit them :) Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Distributing the .jar files as binaries in release
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. As long as we test the new jar against the stable version - and _we_ recommend the components that should be mixed - I think it is far better way to upgrade. This is too complex, and not practical. We already have problems with regressions in stable releases, people not testing anything, etc, even with the current system. What you propose would just make things worse. I don't like your ideas today ;-) Wait until tomorrow to submit them :) :-) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
