On 10 Jan 2003, Joe Phillips wrote:
> #2 is a bit trickier. tools.jar is needed in some cases, most notably
> servlet/jsp containers need it in order to compile JSP at runtime. My
> JBOSS packages fall into this category. tools.jar is installed
> somewhere under JAVA_HOME, JBOSS needs tools.jar
On 10 Jan 2003, Joe Phillips wrote:
> #2 is a bit trickier. tools.jar is needed in some cases, most notably
> servlet/jsp containers need it in order to compile JSP at runtime. My
> JBOSS packages fall into this category. tools.jar is installed
> somewhere under JAVA_HOME, JBOSS needs tools.jar
Greg Wilkins wrote:
So hopefully the tools.jar dependancy will soon be history.
Thus anything done to support it in the short term should clearly
be of a temporary nature.
well, if it's only temporary and we know it won't re-surface, there's no
need to add it to policy.
I think Andrew Pimlott's
Greg Wilkins wrote:
So hopefully the tools.jar dependancy will soon be history.
Thus anything done to support it in the short term should clearly
be of a temporary nature.
well, if it's only temporary and we know it won't re-surface, there's no
need to add it to policy.
I think Andrew Pim
--- Patrick Tullmann <[EMAIL PROTECTED]> wrote:
> > Jetty finds tools.jar itself based on the
> java.home property and
> > adds it to its own classloader. All do some
> checking to see if
> > using the ant.jar directly can do the same thing.
>
> It occurred to me that these tools (ant, jetty,
>
On Sat, Jan 11, 2003 at 01:35:53PM -0700, Patrick Tullmann wrote:
> It occurred to me that these tools (ant, jetty, etc.) are only
> dependent upon a specific class name (i.e., com.sun.tools.javac.Main),
> and what they really want is whatever jar file contains that class.
>
> It seems to me that
> Jetty finds tools.jar itself based on the java.home property and
> adds it to its own classloader. All do some checking to see if
> using the ant.jar directly can do the same thing.
It occurred to me that these tools (ant, jetty, etc.) are only
dependent upon a specific class name (i.e., com.s
Joe Phillips wrote:
Note that jasper2 no longer directly uses tools.jar, as it uses
ant to do all it's compiling. Thus whatever ant.jar needs to find
tools.jar is what jasper and hence tomcat needs.
well, that's good to know that we won't be dependant on tools.jar for
jasper2-using systems.
What
Joe Phillips wrote:
Note that jasper2 no longer directly uses tools.jar, as it uses
ant to do all it's compiling. Thus whatever ant.jar needs to find
tools.jar is what jasper and hence tomcat needs.
well, that's good to know that we won't be dependant on tools.jar for
jasper2-using systems.
On Sat, 2003-01-11 at 10:07, Greg Wilkins wrote:
>
> It is really jasper (the JSP engine from jakarta) that needs
> tools.jar. Tomcat is just one of several servlet containers to
> use jasper.
Right, tomcat was my example. I understand there are other systems that
rely on the java compiler (ant
On Sat, Jan 11, 2003 at 03:07:24PM +, Greg Wilkins wrote:
> Note that jasper2 no longer directly uses tools.jar, as it uses
> ant to do all it's compiling. Thus whatever ant.jar needs to find
> tools.jar is what jasper and hence tomcat needs.
>
> So hopefully the tools.jar dependancy will soo
On Sat, Jan 11, 2003 at 03:07:24PM +, Greg Wilkins wrote:
> Note that jasper2 no longer directly uses tools.jar, as it uses
> ant to do all it's compiling. Thus whatever ant.jar needs to find
> tools.jar is what jasper and hence tomcat needs.
>
> So hopefully the tools.jar dependancy will soo
On Sat, 2003-01-11 at 10:07, Greg Wilkins wrote:
>
> It is really jasper (the JSP engine from jakarta) that needs
> tools.jar. Tomcat is just one of several servlet containers to
> use jasper.
Right, tomcat was my example. I understand there are other systems that
rely on the java compiler (ant
It is really jasper (the JSP engine from jakarta) that needs
tools.jar. Tomcat is just one of several servlet containers to
use jasper.
Note that jasper2 no longer directly uses tools.jar, as it uses
ant to do all it's compiling. Thus whatever ant.jar needs to find
tools.jar is what jasper and he
Andrew Pimlott wrote:
But of course people are using it (tools.jar).
That is real life.
But it doesn't solve the problem of whether to use tools.jar
in the first place.
The right question.
Should tools.jar be promoted to a kind of a standard?
Answer: No.
Joe Phillips <[EMAIL PROTECTED]> wrote:
> They should use /etc/alternatives for the name 'tools.jar' if they
> are compatible with Sun's JDK tools.jar.
And make a symlink to $JAVA_HOME/ext ? That way we'll be sure that the
compiler is "automatically" in the [default] classpath... Mayb
Andrew Pimlott wrote:
But of course people are using it (tools.jar).
That is real life.
But it doesn't solve the problem of whether to use tools.jar
in the first place.
The right question.
Should tools.jar be promoted to a kind of a standard?
Answer: No.
--
To UNSUBSCRIBE, email to [E
Joe Phillips <[EMAIL PROTECTED]> wrote:
> They should use /etc/alternatives for the name 'tools.jar' if they
> are compatible with Sun's JDK tools.jar.
And make a symlink to $JAVA_HOME/ext ? That way we'll be sure that the
compiler is "automatically" in the [default] classpath... Mayb
On Fri, Jan 10, 2003 at 07:16:22PM -0500, Joe Phillips wrote:
> On Thu, 2003-01-02 at 18:14, Andrew Pimlott wrote:
> > Any package that depends on JAVA_HOME should be taken out and shot.
> > Or, more politely, when it is packaged for Debian, those portions
> > should be excised.
>
> Is this the co
Joe Phillips wrote:
I haven't delved too deeply into the bowels of JBOSS/Tomcat *yet* but as
I understand it, it contains the java compiler.
Ant is a simpler example.
ant (/usr/share/ant/bin/ant) command is a short shell script worth reading.
The Sun java compiler is written in java. javac is mere
On Fri, Jan 10, 2003 at 07:16:22PM -0500, Joe Phillips wrote:
> On Thu, 2003-01-02 at 18:14, Andrew Pimlott wrote:
> > Any package that depends on JAVA_HOME should be taken out and shot.
> > Or, more politely, when it is packaged for Debian, those portions
> > should be excised.
>
> Is this the co
Joe Phillips wrote:
I haven't delved too deeply into the bowels of JBOSS/Tomcat *yet* but as
I understand it, it contains the java compiler.
Ant is a simpler example.
ant (/usr/share/ant/bin/ant) command is a short shell script worth reading.
The Sun java compiler is written in java. javac is
On Fri, 2003-01-10 at 20:30, Pieter Laeremans wrote:
> so it looks like a rather important file.
>
> Maybe one might place a tools.jar in /usr/share/java
that's basically what I'm proposing we add to the java policy, put an
alternatives-managed tools.jar into /usr/share/java/.
-joe
--
On Fri, 2003-01-10 at 19:36, Ben Burton wrote:
> Can't say much about the tools.jar issue; I don't know what it provides and
> how standardised that is.
I haven't delved too deeply into the bowels of JBOSS/Tomcat *yet* but as
I understand it, it contains the java compiler.
Here's my understandi
> Is this the concensus? You have been my only response so far. Since
> JAVA_HOME is so common, I hope mention of it would be made in the java
> policy documentation.
Well I agree with Andrew. AIUI, JAVA_HOME is not appropriate for java
interpreters such as gij or some of the other free alterna
On Thu, 2003-01-02 at 18:14, Andrew Pimlott wrote:
> Oooh--I'll answer this!
>
> On Thu, Jan 02, 2003 at 05:03:32PM -0500, Joe Phillips wrote:
> > I've seen package after package (mine included) depend on a
> > JAVA_HOME environment variable set somewhere, in some script.
> > Most packages seem to
On Fri, 2003-01-10 at 20:30, Pieter Laeremans wrote:
> so it looks like a rather important file.
>
> Maybe one might place a tools.jar in /usr/share/java
that's basically what I'm proposing we add to the java policy, put an
alternatives-managed tools.jar into /usr/share/java/.
-joe
--
On Fri, 2003-01-10 at 19:36, Ben Burton wrote:
> Can't say much about the tools.jar issue; I don't know what it provides and
> how standardised that is.
I haven't delved too deeply into the bowels of JBOSS/Tomcat *yet* but as
I understand it, it contains the java compiler.
Here's my understandi
> Is this the concensus? You have been my only response so far. Since
> JAVA_HOME is so common, I hope mention of it would be made in the java
> policy documentation.
Well I agree with Andrew. AIUI, JAVA_HOME is not appropriate for java
interpreters such as gij or some of the other free alterna
On Thu, 2003-01-02 at 18:14, Andrew Pimlott wrote:
> Oooh--I'll answer this!
>
> On Thu, Jan 02, 2003 at 05:03:32PM -0500, Joe Phillips wrote:
> > I've seen package after package (mine included) depend on a
> > JAVA_HOME environment variable set somewhere, in some script.
> > Most packages seem to
Oooh--I'll answer this!
On Thu, Jan 02, 2003 at 05:03:32PM -0500, Joe Phillips wrote:
> I've seen package after package (mine included) depend on a
> JAVA_HOME environment variable set somewhere, in some script.
> Most packages seem to use a config file or init-script to define a
> local JAVA_HOME
Recently, I've been building JBOSS/Tomcat packages for internal use and
eventual general release (I'll follow-up with another email for the
location of my working packages).
In doing so, I've had the need to build/back-port various other Java
packages to Debian stable. As I've done this, I've see
Oooh--I'll answer this!
On Thu, Jan 02, 2003 at 05:03:32PM -0500, Joe Phillips wrote:
> I've seen package after package (mine included) depend on a
> JAVA_HOME environment variable set somewhere, in some script.
> Most packages seem to use a config file or init-script to define a
> local JAVA_HOME
Recently, I've been building JBOSS/Tomcat packages for internal use and
eventual general release (I'll follow-up with another email for the
location of my working packages).
In doing so, I've had the need to build/back-port various other Java
packages to Debian stable. As I've done this, I've see
34 matches
Mail list logo
