Re: [5.5] Packaging
Costin Manolache wrote: Remy Maucherat wrote: No, you misunderstood. - jakarta-tomcat-5.5.0.zip - for JRE 5.0, no Admin - jakarta-tomcat-5.5.0.tar.gz - for JRE 5.0, no Admin - jakarta-tomcat-5.5.0.exe - for Windows, everything - jakarta-tomcat-5.5.0-compat.zip - for JRE 1.4 (a few additional JARs, not the whole thing) - jakarta-tomcat-5.5.0-compat.tar.gz - for JRE 1.4, no Admin You mean mx4j ? I'm not sure about having the main target be a JRE beta, The said JRE 5 adds a lot of extremely useful features for servers (good Linux 2.6 support, adequate monitoring, easy deadlock debugging), and should be out of beta at about the same time as a 5.5.x stable, right ? For the first time, the improvements are more useful than a performance increase :) This will help a lot for support. but I understand your point, it's cleaner this way. The alternative would be to have a 1.4 distro, with mx4j jars included, and detect at runtime if it's 1.5 and skip them from the loader. I suspect people will keep using 1.4 and 1.5 for a while, as usual there are incompatibilities - so it's better to be able to use the same tomcat with both. Please make sure target=1.3 is present in all javac tasks :-) Shouldn't we support only JRE 1.4 and 5.0 instead ? I would be able to replace jakarta-regexp use with Java regexp. Obviously people who don't want to upgrade (ex: I saw a really funny thread on tomcat-user about a guy who wants JMX runtime stats on 4.1.x, like the ones that were in 5.0.x) aren't going to upgrade to this new branch, because of API breakage. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [5.5] Packaging
Hi, Please make sure target=1.3 is present in all javac tasks :-) Shouldn't we support only JRE 1.4 and 5.0 instead ? I would be able to I'm also not big on JDK 1.3 as the default target. I'm +0 on adding a javaTarget build.properties attribute that users can set to 1.3 but whose default value is 1.4, 1.5, or none, but not 1.3. I haven't seen a question on tomcat-user with someone running JDK 1.3 for a long time now. Yoav This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.5] Packaging
Remy Maucherat wrote: Please make sure target=1.3 is present in all javac tasks :-) Shouldn't we support only JRE 1.4 and 5.0 instead ? I would be able to replace jakarta-regexp use with Java regexp. Obviously people who don't want to upgrade (ex: I saw a really funny thread on tomcat-user about a guy who wants JMX runtime stats on 4.1.x, like the ones that were in 5.0.x) aren't going to upgrade to this new branch, because of API breakage. I'm using 1.3 most of the time, there is a _lot_ of software out there that doesn't work in jdk1.4 and won't work in jdk1.5 either. Not to mention companies having policies and supporting only one VM ( so they don't have to deal with all the incompatibilities between versions ). I'm personally -1 on droping support for 1.3 ( well, I would be +1 on supporting J2ME or 1.1 as a baseline :-). Even compiling software with jdk1.5 or loading it in an IDE is problematic. I think we should value stability more than featurism - and value flexibility and modularity more than bloat. There are people who have problems with the Sun/Microsoft policy of bundling features in order to reduce competition ( logging, mx4j/jbossmx, jakarta-regexp, parser, etc ). Especially when those features are hard to replace with better implementations ( even if they implement an API and have some convoluted endorsed setting to replace ). Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.5] Packaging
Shapira, Yoav wrote: Hi, Please make sure target=1.3 is present in all javac tasks :-) Shouldn't we support only JRE 1.4 and 5.0 instead ? I would be able to I'm also not big on JDK 1.3 as the default target. I'm +0 on adding a javaTarget build.properties attribute that users can set to 1.3 but whose default value is 1.4, 1.5, or none, but not 1.3. I haven't seen a question on tomcat-user with someone running JDK 1.3 for a long time now. Maybe that's because they don't have endorsed problems and things just work and are stable :-) Write once, run anywhere - why would you choose a target that will not run for a (significant) number of people, and try to force them to choose between upgrading tomcat and upgrading other software ? What do we gain ? Few features that are available anyway - with many choices of better implementations. Sun has the bad habit of breaking compatibility and the run anywhere promise on every release. 5.0 is particularly bad. I consider run anywhere one of the essential things in java - including the ability to run with other vendor or open source VMs. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [5.5] Packaging
Hola, I'm personally -1 on droping support for 1.3 ( well, I would be +1 on supporting J2ME or 1.1 as a baseline :-). It depends how you define support, right? Does support mean by default everything is configured for JDK 1.3, and Tomcat is built with target=1.3 ? Or does it means there's an easy way to set this target parameter (e.g. a build.properties setting) and build your own Tomcat for 1.3? I think we should value stability more than featurism - and value flexibility and modularity more than bloat. There are people who have I definitely agree on modularity more than bloat. I wish we had a minimal tomcat distro that comes without admin, without manager, without balancer, without webdav, without docs, without examples, etc. Then we could have individual downloads for these (most would just be a simple zip file you'd extract to $CATALINA_HOME). And maybe one bundle that has everything to save people time. You could work from the minimal distro and add things or from the full distro and remove things. But I've brought this minimal distro idea up in the past already ;) Stability versus featurism is much more of a judgment call IMHO. Does stability mean we stick with an old platform (JDK 1.3) and jump through hoops (e.g. runtime detection) to use newer (JDK 1.4, JDK 1.5) features? If so, then at what point does the cost (e.g. performance) become higher than the benefit (ease of use for old platform users)? It's a subjective call I think. While I don't doubt the legitimacy of your pro-1.3 arguments, you just don't see users on the mailing list with anything other than JDK 1.4. We already get more JDK 1.5 questions than JDK 1.3 it seems, even though 1.5 is still in beta. So I don't know, I'm not 100% convinced we should require JDK 1.5, and I'm not 100% convinced we should drop 1.3, I'm just in the middle ;) I'm comfortable with requiring 1.4 though, as it's been more than 2 years since JDK 1.4 was released. Yoav This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.5] Packaging
Costin Manolache wrote: Remy Maucherat wrote: Please make sure target=1.3 is present in all javac tasks :-) Shouldn't we support only JRE 1.4 and 5.0 instead ? I would be able to replace jakarta-regexp use with Java regexp. Obviously people who don't want to upgrade (ex: I saw a really funny thread on tomcat-user about a guy who wants JMX runtime stats on 4.1.x, like the ones that were in 5.0.x) aren't going to upgrade to this new branch, because of API breakage. I'm using 1.3 most of the time, there is a _lot_ of software out there that doesn't work in jdk1.4 and won't work in jdk1.5 either. Not to mention companies having policies and supporting only one VM ( so they don't have to deal with all the incompatibilities between versions ). I'm personally -1 on droping support for 1.3 ( well, I would be +1 on supporting J2ME or 1.1 as a baseline :-). Well, that's your opinion, and you have one vote (I'll be sure to call a vote on that). This no longer makes any sense to me. Even compiling software with jdk1.5 or loading it in an IDE is problematic. I think we should value stability more than featurism - and value flexibility and modularity more than bloat. I don't see why cleaning up useless depedencies gets labelled as featurism. OTOH, it seems to me it reduces bloat. JRE 1.4.2 is now very stable, so there are no stability concerns. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [5.5] Packaging
Hola, Write once, run anywhere - why would you choose a target that will not run for a (significant) number of people, and try to force them to choose between upgrading tomcat and upgrading other software ? I don't think the number is significant. It's very subjective, and I have no empirical data, just opinion from the tomcat-user list. If someone could show, for example, that more than a tenth of Tomcat users run with JDK 1.3 in production, I'd be convinced me JDK 1.3 is still significant. I completely agree WORA is essential, possibly the biggest advantage of the Java language/platform. But then why aren't we coding/building to JDK 1.1 or J2ME? It's a question of tradeoffs. Maybe we should have a vote on whether Tomcat 5.5 should require JDK 1.5? This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.5] Packaging
I would *guess* that those not bothering to move from 1.3 (for whatever reason) are mostly the same folk who won't upgrade to a more recent Tomcat version anyway. -- Jess Holle Shapira, Yoav wrote: Hola, Write once, run anywhere - why would you choose a target that will not run for a (significant) number of people, and try to force them to choose between upgrading tomcat and upgrading other software ? I don't think the number is significant. It's very subjective, and I have no empirical data, just opinion from the tomcat-user list. If someone could show, for example, that more than a tenth of Tomcat users run with JDK 1.3 in production, I'd be convinced me JDK 1.3 is still significant. I completely agree WORA is essential, possibly the biggest advantage of the Java language/platform. But then why aren't we coding/building to JDK 1.1 or J2ME? It's a question of tradeoffs. Maybe we should have a vote on whether Tomcat 5.5 should require JDK 1.5? This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.5] Packaging
Remy Maucherat wrote: Costin Manolache wrote: Remy Maucherat wrote: Please make sure target=1.3 is present in all javac tasks :-) Shouldn't we support only JRE 1.4 and 5.0 instead ? I would be able to replace jakarta-regexp use with Java regexp. Obviously people who don't want to upgrade (ex: I saw a really funny thread on tomcat-user about a guy who wants JMX runtime stats on 4.1.x, like the ones that were in 5.0.x) aren't going to upgrade to this new branch, because of API breakage. I'm using 1.3 most of the time, there is a _lot_ of software out there that doesn't work in jdk1.4 and won't work in jdk1.5 either. Not to mention companies having policies and supporting only one VM ( so they don't have to deal with all the incompatibilities between versions ). I'm personally -1 on droping support for 1.3 ( well, I would be +1 on supporting J2ME or 1.1 as a baseline :-). Well, that's your opinion, and you have one vote (I'll be sure to call a vote on that). This no longer makes any sense to me. +1 for the vote. :-) I'm in favor of requiring j2se 5.0 (but I work at Sun so I might have a couple of bad habits ;-) ) -- Jeanfrancois Even compiling software with jdk1.5 or loading it in an IDE is problematic. I think we should value stability more than featurism - and value flexibility and modularity more than bloat. I don't see why cleaning up useless depedencies gets labelled as featurism. OTOH, it seems to me it reduces bloat. JRE 1.4.2 is now very stable, so there are no stability concerns. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.5] Packaging
Shapira, Yoav wrote: Hola, Write once, run anywhere - why would you choose a target that will not run for a (significant) number of people, and try to force them to choose between upgrading tomcat and upgrading other software ? I don't think the number is significant. It's very subjective, and I have no empirical data, just opinion from the tomcat-user list. If someone could show, for example, that more than a tenth of Tomcat users run with JDK 1.3 in production, I'd be convinced me JDK 1.3 is still significant. I completely agree WORA is essential, possibly the biggest advantage of the Java language/platform. But then why aren't we coding/building to JDK 1.1 or J2ME? It's a question of tradeoffs. Maybe we should have a vote on whether Tomcat 5.5 should require JDK 1.5? Right now, my position is to use J2SE 1.4 APIs as needed, and to release the default bundle for J2SE 5.0 (with a separate bundle to add the JARs needed to run on J2SE 1.4). All that keeping in mind that Tomcat can now be fully supported on a JRE rather than a JDK. Overall, I'd say few people are going to upgrade to this new branch (but who knows, we don't even have numbers on how many people upgrade), so the J2SE requirement should have little impact. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.5] Packaging
Jeanfrancois Arcand wrote: +1 for the vote. :-) I'm in favor of requiring j2se 5.0 (but I work at Sun so I might have a couple of bad habits ;-) ) There are definitely a lot of places where using the generic collections would make the code a lot cleaner. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.5] Packaging
Jeanfrancois Arcand wrote: +1 for the vote. :-) I'm in favor of requiring j2se 5.0 (but I work at Sun so I might have a couple of bad habits ;-) ) Is the vote to be only on whether to continue to support 1.3? Or the same for 1.4? Also, is it just a commiters vote? Every platform of *any* note has a stable 1.4.2 now and there is precious little excuse to keep using it. On the other hand, if history is any indicator it will be up to 1 full year before 1.5 is available *and* stable on all platforms.(including various versions of UNIX, etc). Perhaps this will somehow only be 6 months, but I'd guess that though 1.5 could be the default, 1.4 support will be needed for up to 12 months after Sun's initial 1.5.0 release. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.5] Packaging
Jess Holle wrote: Jeanfrancois Arcand wrote: +1 for the vote. :-) I'm in favor of requiring j2se 5.0 (but I work at Sun so I might have a couple of bad habits ;-) ) Is the vote to be only on whether to continue to support 1.3? Or the same for 1.4? Also, is it just a commiters vote? Only commiters have votes which do count, but you can participate in any vote if you want to. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.5] Packaging
Shapira, Yoav wrote: It depends how you define support, right? Does support mean by default everything is configured for JDK 1.3, and Tomcat is built with target=1.3 ? Or does it means there's an easy way to set this target parameter (e.g. a build.properties setting) and build your own Tomcat for 1.3? What is the cost of having target=1.3 by default ? It means the class files and the release will work with jdk1.3 - and it will also run on 1.4 or 1.5. What is the benefit of having target=1.4 and forcing people who use 1.3 to recompile the entire tomcat ? Stability versus featurism is much more of a judgment call IMHO. Does stability mean we stick with an old platform (JDK 1.3) and jump through hoops (e.g. runtime detection) to use newer (JDK 1.4, JDK 1.5) features? If so, then at what point does the cost (e.g. performance) become higher than the benefit (ease of use for old platform users)? It's a subjective call I think. That's a question for Sun :-), who is forcing people to jump through the hoops by bundling all features with the VM. Tomcat core already works with 1.3 - and you can have optional connectors/valves/etc that only work with 1.5 or 1.6 - with just a simple conditional compilation. I understand why MSFT is forcing people to upgrade windows - they make a lot of money from that, and don't care how much the users will suffer to upgrade. But we don't gain that much by forcing people to upgrade the VM to use the latest version of tomcat. I wish Sun would sell and make money on the VM - so at least someone would gets some benefit from this forced upgrade cycle :-) While I don't doubt the legitimacy of your pro-1.3 arguments, you just don't see users on the mailing list with anything other than JDK 1.4. We already get more JDK 1.5 questions than JDK 1.3 it seems, even though 1.5 is still in beta. IMO that's because 1.3 is used in production for quite a while - so most problems are solved. If you release the next version with 1.4 target - you may get more 1.3 questions :-) Upgrading the VM is almost the same with upgrading the OS - there are still plenty of packages for RedHat7.3 or NT, and most of the questions are from people trying the latest OS and noticing things are breaking. So I don't know, I'm not 100% convinced we should require JDK 1.5, and I'm not 100% convinced we should drop 1.3, I'm just in the middle ;) I'm comfortable with requiring 1.4 though, as it's been more than 2 years since JDK 1.4 was released. I'm ok with using 1.5 features, or having a default distribution for 1.5 - as long as the code is compiled with target=1.3 ( no major harm ) and it is possible to run the basic tomcat with 1.3 ( with some additional packages - parser, mx4j, etc ). Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.5] Packaging
Costin Manolache wrote: Shapira, Yoav wrote: It depends how you define support, right? Does support mean by default everything is configured for JDK 1.3, and Tomcat is built with target=1.3 ? Or does it means there's an easy way to set this target parameter (e.g. a build.properties setting) and build your own Tomcat for 1.3? What is the cost of having target=1.3 by default ? It means the class files and the release will work with jdk1.3 - and it will also run on 1.4 or 1.5. What is the benefit of having target=1.4 and forcing people who use 1.3 to recompile the entire tomcat ? Despite my own feeling that 1.3 has gone the way of the dodo bird, this is a good question. The only thing I know of offhand is that 1.4 gives you assert(). Stability versus featurism is much more of a judgment call IMHO. Does stability mean we stick with an old platform (JDK 1.3) and jump through hoops (e.g. runtime detection) to use newer (JDK 1.4, JDK 1.5) features? If so, then at what point does the cost (e.g. performance) become higher than the benefit (ease of use for old platform users)? It's a subjective call I think. That's a question for Sun :-), who is forcing people to jump through the hoops by bundling all features with the VM. Most of the features that are interesting in 1.5 have to be to be done right... Tomcat core already works with 1.3 - and you can have optional connectors/valves/etc that only work with 1.5 or 1.6 - with just a simple conditional compilation. I understand why MSFT is forcing people to upgrade windows - they make a lot of money from that, and don't care how much the users will suffer to upgrade. But we don't gain that much by forcing people to upgrade the VM to use the latest version of tomcat. I wish Sun would sell and make money on the VM - so at least someone would gets some benefit from this forced upgrade cycle :-) The reasons to force upgrades are: 1. Ability to fully leverage compelling runtime features for end-user benefit (e.g. in the case of 1.5, better concurrency utilities, built-in JMX, etc; in the case of 1.4 this might possibly include NIO stuff for loading static files or some such) 2. Ability to use compelling development features (e.g. generics in the case of dropping releases prior to 1.5, improved/easier-to-use APIs in cases, etc) 3. Narrower platform mix to mess with supporting / answering questions on, etc. -- Jess Holle
[5.5] Packaging
I'm planning to do the following changes to packaging: - removing commons-launcher from the final distribution (I see little use of it, since we have good scripts and native wrappers available); it will stay as a dependency to launch stuff during the build process - new release archives based on the contents of the compat folder, for JRE 1.4 users (the default distributions will be for JRE 5.0) - new release archives for the admin webapp (= not in the main archive; not everyone uses it, and it's quite large) - the Windows installer will remain the same for now (= an offline installer), as I don't see how to make it an online installer and still respect the mirror scheme we use Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [5.5] Packaging
Hola, I'm planning to do the following changes to packaging: - removing commons-launcher from the final distribution (I see little use of it, since we have good scripts and native wrappers available); it will stay as a dependency to launch stuff during the build process - new release archives based on the contents of the compat folder, for JRE 1.4 users (the default distributions will be for JRE 5.0) - new release archives for the admin webapp (= not in the main archive; not everyone uses it, and it's quite large) - the Windows installer will remain the same for now (= an offline installer), as I don't see how to make it an online installer and still respect the mirror scheme we use What does that leave us with in terms of distros? Let me try: [Source distros, same as today] - jakarta-tomcat-5.5.0-src.zip - jakarta-tomcat-5.5.0-src.tar.gz [Binary distros] - jakarta-tomcat-5.5.0.zip - for JRE 5.0, no Admin - jakarta-tomcat-5.5.0.tar.gz - for JRE 5.0, no Admin - jakarta-tomcat-5.5.0.exe - for Windows, JRE 5.0, no Admin - jakarta-tomcat-5.5.0-jre14.zip - for JRE 1.4, no Admin - jakarta-tomcat-5.5.0-jre14.tar.gz - for JRE 1.4, no Admin - jakarta-tomcat-5.5.0-jre14.exe - for Windows JRE 1.4, no Admin + another one for each of the above with Admin? Maybe we should have admin separately, i.e. jakarta-tomcat-5.5.0-admin.war (complete with META-INF/context.xml), that users can just drop into their webapps directory? I'd rather have that than 6 more binary distributions. What about dropping .tar.gz distros? I realize its files are smaller than zip, but every platform has zip support and I doubt many of our users (who are mostly developers for companies or open-source afficionadoes) are on dialup connections. Alternatively (this is what JonAS has done for example) we could just have .tgz files which the Windows Winzip can handle. This saves the release manager work and reduces user confusion slightly, as they are faced with less download choices. I see the latter (user confusion) increasing when we have JRE1.4 and JRE5.0 distros. Yoav This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.5] Packaging
Shapira, Yoav wrote: Hola, I'm planning to do the following changes to packaging: - removing commons-launcher from the final distribution (I see little use of it, since we have good scripts and native wrappers available); it will stay as a dependency to launch stuff during the build process - new release archives based on the contents of the compat folder, for JRE 1.4 users (the default distributions will be for JRE 5.0) - new release archives for the admin webapp (= not in the main archive; not everyone uses it, and it's quite large) - the Windows installer will remain the same for now (= an offline installer), as I don't see how to make it an online installer and still respect the mirror scheme we use What does that leave us with in terms of distros? Let me try: [Source distros, same as today] - jakarta-tomcat-5.5.0-src.zip - jakarta-tomcat-5.5.0-src.tar.gz [Binary distros] - jakarta-tomcat-5.5.0.zip - for JRE 5.0, no Admin - jakarta-tomcat-5.5.0.tar.gz - for JRE 5.0, no Admin - jakarta-tomcat-5.5.0.exe - for Windows, JRE 5.0, no Admin - jakarta-tomcat-5.5.0-jre14.zip - for JRE 1.4, no Admin - jakarta-tomcat-5.5.0-jre14.tar.gz - for JRE 1.4, no Admin - jakarta-tomcat-5.5.0-jre14.exe - for Windows JRE 1.4, no Admin + another one for each of the above with Admin? No, you misunderstood. - jakarta-tomcat-5.5.0.zip - for JRE 5.0, no Admin - jakarta-tomcat-5.5.0.tar.gz - for JRE 5.0, no Admin - jakarta-tomcat-5.5.0.exe - for Windows, everything - jakarta-tomcat-5.5.0-compat.zip - for JRE 1.4 (a few additional JARs, not the whole thing) - jakarta-tomcat-5.5.0-compat.tar.gz - for JRE 1.4, no Admin - jakarta-tomcat-5.5.0-admin.zip - admin WAR + the XML file - jakarta-tomcat-5.5.0-admin.tar.gz - admin WAR + the XML file Maybe we should have admin separately, i.e. jakarta-tomcat-5.5.0-admin.war (complete with META-INF/context.xml), that users can just drop into their webapps directory? I'd rather have that than 6 more binary distributions. IMO, the admin webapp is better located in the special folder we're using right now. It helps with catalina_base. What about dropping .tar.gz distros? I realize its files are smaller than zip, but every platform has zip support and I doubt many of our users (who are mostly developers for companies or open-source afficionadoes) are on dialup connections. Alternatively (this is what JonAS has done for example) we could just have .tgz files which the Windows Winzip can handle. This saves the release manager work and reduces user confusion slightly, as they are faced with less download choices. I see the latter (user confusion) increasing when we have JRE1.4 and JRE5.0 distros. This is a bad idea. - Windaube XP only supports .zip - tgz allows setting Unix execute flag Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.5] Packaging
Shapira, Yoav wrote: What about dropping .tar.gz distros? I realize its files are smaller than zip, but every platform has zip support and I doubt many of our users (who are mostly developers for companies or open-source afficionadoes) are on dialup connections. Alternatively (this is what JonAS has done for example) we could just have .tgz files which the Windows Winzip can handle. This saves the release manager work and reduces user confusion slightly, as they are faced with less download choices. I see the latter (user confusion) increasing when we have JRE1.4 and JRE5.0 distros. The major difference between the tar.gz and zip distros should be in line endings. Both sources, jsp's, readme's etc... in zip distro should have the CRLF line endings, OTOH the tar.gz needs only LF line endings. Also the tar.gz should have 'rwx' attribs for scripts inside bin. Think that users know that for nixes they should use tar.gz, and for windows .zip. We can also mark what is the actual difference between them (CRLF issue), and for what platforms they are meant to be used. OTOH we can make a agreement what the line endings would be and keep only those. Only then we can drop particular distro. Regards, MT. smime.p7s Description: S/MIME Cryptographic Signature
Re: [5.5] Packaging
Remy Maucherat wrote: I'm planning to do the following changes to packaging: - removing commons-launcher from the final distribution (I see little use of it, since we have good scripts and native wrappers available); it will stay as a dependency to launch stuff during the build process - new release archives based on the contents of the compat folder, for JRE 1.4 users (the default distributions will be for JRE 5.0) Is JRE1.5 final available ? Last I checked it was still beta. I think it's a good idea to keep 1.4 as default target at least until 1.5 is out of beta. Are you going to include xerces or just leave it out and tell 1.3 users to download an xml parser and install it in common/lib ? - new release archives for the admin webapp (= not in the main archive; not everyone uses it, and it's quite large) Not sure what that means :-). - the Windows installer will remain the same for now (= an offline installer), as I don't see how to make it an online installer and still respect the mirror scheme we use Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.5] Packaging
What does that leave us with in terms of distros? Let me try: [Source distros, same as today] - jakarta-tomcat-5.5.0-src.zip - jakarta-tomcat-5.5.0-src.tar.gz [Binary distros] - jakarta-tomcat-5.5.0.zip - for JRE 5.0, no Admin - jakarta-tomcat-5.5.0.tar.gz - for JRE 5.0, no Admin - jakarta-tomcat-5.5.0.exe - for Windows, JRE 5.0, no Admin - jakarta-tomcat-5.5.0-jre14.zip - for JRE 1.4, no Admin - jakarta-tomcat-5.5.0-jre14.tar.gz - for JRE 1.4, no Admin - jakarta-tomcat-5.5.0-jre14.exe - for Windows JRE 1.4, no Admin + another one for each of the above with Admin? Why ? We can distribute admin.war as a separate binary, who needs it can install it separately. What is the difference between JRE1.4 and JRE5.0 distribution ? I'm building with 1.4 and 1.5 and it works fine with 1.5, 1.5 and 1.3, do we need separate builds ? BTW - I don't know how hard it would be to have admin.war also distributed as a .exe with installer ( just need to extract the war in the tomcat dir ). Maybe we should have admin separately, i.e. jakarta-tomcat-5.5.0-admin.war (complete with META-INF/context.xml), that users can just drop into their webapps directory? I'd rather have that than 6 more binary distributions. +1 What about dropping .tar.gz distros? I realize its files are smaller than zip, but every platform has zip support and I doubt many of our users (who are mostly developers for companies or open-source afficionadoes) are on dialup connections. Alternatively (this is what JonAS has done for example) we could just have .tgz files which the Windows Winzip can handle. This saves the release manager work and reduces user confusion slightly, as they are faced with less download choices. I see the latter (user confusion) increasing when we have JRE1.4 and JRE5.0 distros. Do we do any line ending processing for tgz and zip ? The expectation is that .tgz distributions use unix LF, and zip files use CRFL. If tgz and zip are identical ( and I assume it's CRLF since the build is on windows ) - then it's a good idea to have only zip ( tgz with CRLF is confusing ) Costin Yoav This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.5] Packaging
Remy Maucherat wrote: No, you misunderstood. - jakarta-tomcat-5.5.0.zip - for JRE 5.0, no Admin - jakarta-tomcat-5.5.0.tar.gz - for JRE 5.0, no Admin - jakarta-tomcat-5.5.0.exe - for Windows, everything - jakarta-tomcat-5.5.0-compat.zip - for JRE 1.4 (a few additional JARs, not the whole thing) - jakarta-tomcat-5.5.0-compat.tar.gz - for JRE 1.4, no Admin You mean mx4j ? I'm not sure about having the main target be a JRE beta, but I understand your point, it's cleaner this way. The alternative would be to have a 1.4 distro, with mx4j jars included, and detect at runtime if it's 1.5 and skip them from the loader. I suspect people will keep using 1.4 and 1.5 for a while, as usual there are incompatibilities - so it's better to be able to use the same tomcat with both. Please make sure target=1.3 is present in all javac tasks :-) - jakarta-tomcat-5.5.0-admin.zip - admin WAR + the XML file - jakarta-tomcat-5.5.0-admin.tar.gz - admin WAR + the XML file Good. Costin Maybe we should have admin separately, i.e. jakarta-tomcat-5.5.0-admin.war (complete with META-INF/context.xml), that users can just drop into their webapps directory? I'd rather have that than 6 more binary distributions. IMO, the admin webapp is better located in the special folder we're using right now. It helps with catalina_base. What about dropping .tar.gz distros? I realize its files are smaller than zip, but every platform has zip support and I doubt many of our users (who are mostly developers for companies or open-source afficionadoes) are on dialup connections. Alternatively (this is what JonAS has done for example) we could just have .tgz files which the Windows Winzip can handle. This saves the release manager work and reduces user confusion slightly, as they are faced with less download choices. I see the latter (user confusion) increasing when we have JRE1.4 and JRE5.0 distros. This is a bad idea. - Windaube XP only supports .zip - tgz allows setting Unix execute flag Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
