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) a
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
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 commit
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 h
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
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 s
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 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
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 empiri
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 t
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'
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
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 abo
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 de
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
JA
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)
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
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 rele
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
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 proc
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 archive
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
22 matches
Mail list logo
