Re: JAVA_HOME policy

[Arnaud Vandyck]

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... Maybe there
are restrictions, it's just an idea...

-- Arnaud Vandyck




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: JAVA_HOME policy

[Ahmed]

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 [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: JBoss debs?

[Greg Wilkins]

Hi,

I'm the main developer of the Jetty HTTPServer and Servlet
container and a core developer on JBoss.

Just a reminder (as I've emailed Joe before) that I'm more than
happy to:

 + lobby the JBoss project to make any changes that may
   assist you with your packaging (not sure of how successful
   that will be).

 + Help with any changes you need to make to support the more
   recent versions of JBoss that are based on the Jetty HTTPServer.

 + Help *anybody* who wants to make a standalone jetty deb.

I use debian, but I don't know anything about creating debians.
So I can't be proactive on this.  But I can offer lots of
help to anybody who takes the lead on this and tells me what is
needed.

cheers


Joe Phillips wrote:

On Fri, 2003-01-10 at 13:37, Darryl L. Pierce wrote:


On 2003.01.10 12:00 Joe Phillips wrote:


how's very soon?


Too slow for me. I need it yesterday. :)



I had it yesterday but you didn't ask.  8)



you can find my packages for 3.0.2 + tomcat at
http://debian.innovationsw.com/

I have plans for 3.2 next.


Will it have any impact on my distribution? I'm currently using sarge 
and am pulling Java from ibilio.org.


I don't know what you mean by that.

I built my packages on stable (woody) with a j2sdk package of  my own
design.  I don't use the ibilio.org packages so I don't know how well
they would play with my packages.  I suspect they'll work fine.

Currently, my packages include the full JBOSS binary release (including
third-party libraries).  Over time, I plan to replace pieces of the
JBOSS binary distro with debian packages.  As this happens, I also
expect the JBOSS packages to grow & change.  

For example, my JBOSS packages include JARs for log4j.  Future packages
will likely make my JBOSS depend on log4j debs and include symlinks to
/usr/share/java/log4j.jar or similar.

I would expect my current packages to work with any java2-compiler on
any Debian release for the following reasons:
1- there are no native dependancies beyond whatever your JVM depends
upon
2- as described above, my packages are self-contained (eg. it has its
own log4j)
3- my packages are essentially a pure repackaging of the JBOSS.org
binary release - if it runs for you, so should my packages

Future revisions, may depend on specific versions of external
libraries.  This is where you may have difficulties down the road.

add our site to your sources.list and  apt-get install
jboss-server-default to get the default server installation.  Then set
your JAVA_HOME in /etc/default/jboss and start it via /etc/init.d/jboss.
If you prefer 'all', install jboss-server-all instead.  Likewise with
'minimal'.

enjoy!

-joe



--
Greg Wilkins<[EMAIL PROTECTED]> Phone/fax: +44 7092063462
Mort Bay Consulting Australia and UK.  http://www.mortbay.com


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: JAVA_HOME policy

[Joe Phillips]

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 has been mentioned to me and Jetty is
another obvious addition to the list).  My point was that there are
systems that depend on this jar file which may be installed in any
number of places - making it tough to maintain packages that need the
tools.jar file.

> 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 software uses jasper2?

> 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.

-joe
-- 
 Innovation Software Group, LLC - http://www.innovationsw.com/
Business Automation Specialists
 UNIX, Linux and Java Training


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: JAVA_HOME policy

[Andrew Pimlott]

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 soon be history.
> Thus anything done to support it in the short term should clearly
> be of a temporary nature.

Huh?  Unless Ant is moving away from using tools.jar, how will the
problem go away?  It will just move to Ant.

I can't imagine that Ant will stop using tools.jar, because even
people who can tolerate waiting for Ant to start can't tolerate
waiting for javac to start.

Andrew


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: JAVA_HOME policy

[Greg Wilkins]

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 software uses jasper2?


Tomcat 4.1.x
Jetty 4.2.x
JBoss 3.0.>=5  3.2.x


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 point is good - I guess the problem has
just moved to ant.  But they appear to have done a better job of
finding tools.jar themselves (Mmmm maybe that is only in their
start script?)

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.

regards

--
Greg Wilkins<[EMAIL PROTECTED]> Phone/fax: +44 7092063462
Mort Bay Consulting Australia and UK.  http://www.mortbay.com


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: JAVA_HOME policy

[Arnaud Vandyck]

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... Maybe there
are restrictions, it's just an idea...

-- Arnaud Vandyck

Re: JAVA_HOME policy

[Ahmed]

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.

Re: JBoss debs?

[Greg Wilkins]

Hi,
I'm the main developer of the Jetty HTTPServer and Servlet
container and a core developer on JBoss.
Just a reminder (as I've emailed Joe before) that I'm more than
happy to:
 + lobby the JBoss project to make any changes that may
   assist you with your packaging (not sure of how successful
   that will be).
 + Help with any changes you need to make to support the more
   recent versions of JBoss that are based on the Jetty HTTPServer.
 + Help *anybody* who wants to make a standalone jetty deb.
I use debian, but I don't know anything about creating debians.
So I can't be proactive on this.  But I can offer lots of
help to anybody who takes the lead on this and tells me what is
needed.
cheers
Joe Phillips wrote:
On Fri, 2003-01-10 at 13:37, Darryl L. Pierce wrote:
On 2003.01.10 12:00 Joe Phillips wrote:
how's very soon?
Too slow for me. I need it yesterday. :)

I had it yesterday but you didn't ask.  8)

you can find my packages for 3.0.2 + tomcat at
http://debian.innovationsw.com/
I have plans for 3.2 next.
Will it have any impact on my distribution? I'm currently using sarge 
and am pulling Java from ibilio.org.

I don't know what you mean by that.
I built my packages on stable (woody) with a j2sdk package of  my own
design.  I don't use the ibilio.org packages so I don't know how well
they would play with my packages.  I suspect they'll work fine.
Currently, my packages include the full JBOSS binary release (including
third-party libraries).  Over time, I plan to replace pieces of the
JBOSS binary distro with debian packages.  As this happens, I also
expect the JBOSS packages to grow & change.  

For example, my JBOSS packages include JARs for log4j.  Future packages
will likely make my JBOSS depend on log4j debs and include symlinks to
/usr/share/java/log4j.jar or similar.
I would expect my current packages to work with any java2-compiler on
any Debian release for the following reasons:
1- there are no native dependancies beyond whatever your JVM depends
upon
2- as described above, my packages are self-contained (eg. it has its
own log4j)
3- my packages are essentially a pure repackaging of the JBOSS.org
binary release - if it runs for you, so should my packages
Future revisions, may depend on specific versions of external
libraries.  This is where you may have difficulties down the road.
add our site to your sources.list and  apt-get install
jboss-server-default to get the default server installation.  Then set
your JAVA_HOME in /etc/default/jboss and start it via /etc/init.d/jboss.
If you prefer 'all', install jboss-server-all instead.  Likewise with
'minimal'.
enjoy!
-joe

--
Greg Wilkins<[EMAIL PROTECTED]> Phone/fax: +44 7092063462
Mort Bay Consulting Australia and UK.  http://www.mortbay.com

Re: JAVA_HOME policy

[Greg Wilkins]

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 hence tomcat needs.
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.
cheers
Joe Phillips wrote:> 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 understanding in a nutshell, I'm happy to be
corrected/educated if I'm mistaken:
The Sun java compiler is written in java.  javac is merely a front-end
to loading and running the correct java code.
Java Server Pages are basically HTML with Java sprinkled within.  JSP
containers convert the JSP source to a servlet (.java file) and then
compile the servlet to a .class file.  The servlet is then executed
within the container.
The compile step requires a java compiler.  Servlet containers I'm
familiar with (Tomcat, jserv, JBOSS+tomcat) require an external
compiler.  

AFAIK, they depend on the Sun implementation.  I do not know about the
standardization.  My guess is there is no standardization between JDK
vendors.  It *seems* for Sun JDKs, at least the jarfile and class names
seem consistant.  I've never had compiler-related problems running
Tomcat across J2SDKs.
-joe

--
Greg Wilkins<[EMAIL PROTECTED]> Phone/fax: +44 7092063462
Mort Bay Consulting Australia and UK.  http://www.mortbay.com

Re: JAVA_HOME policy

[Andrew Pimlott]

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 soon be history.
> Thus anything done to support it in the short term should clearly
> be of a temporary nature.

Huh?  Unless Ant is moving away from using tools.jar, how will the
problem go away?  It will just move to Ant.

I can't imagine that Ant will stop using tools.jar, because even
people who can tolerate waiting for Ant to start can't tolerate
waiting for javac to start.

Andrew

Re: JAVA_HOME policy

[Joe Phillips]

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 has been mentioned to me and Jetty is
another obvious addition to the list).  My point was that there are
systems that depend on this jar file which may be installed in any
number of places - making it tough to maintain packages that need the
tools.jar file.

> 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 software uses jasper2?

> 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.

-joe
-- 
 Innovation Software Group, LLC - http://www.innovationsw.com/
Business Automation Specialists
 UNIX, Linux and Java Training

Re: JAVA_HOME policy

[Greg Wilkins]

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 software uses jasper2?
Tomcat 4.1.x
Jetty 4.2.x
JBoss 3.0.>=5  3.2.x
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 point is good - I guess the problem has
just moved to ant.  But they appear to have done a better job of
finding tools.jar themselves (Mmmm maybe that is only in their
start script?)
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.
regards
--
Greg Wilkins<[EMAIL PROTECTED]> Phone/fax: +44 7092063462
Mort Bay Consulting Australia and UK.  http://www.mortbay.com

Re: JAVA_HOME policy

[Patrick Tullmann]

> 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.sun.tools.javac.Main),
and what they really want is whatever jar file contains that class.

It seems to me that the right way to get away from making 'tools.jar'
a standard name is to provide a way for packages to depend upon "the
jar that contains foo.bar.baz" (perhaps more generally "the classpath
element that contains foo.bar.baz".

So, for example, a Kaffe package would return a different set of
classpath elements than a j2sdk one.

Not sure if this is feasible or what, but thought I'd make the
observation.

-Pat

- -  ---  ---  --   --  - -   -
Pat Tullmann   [EMAIL PROTECTED]
   A closed mouth gathers no foot.

Re: JAVA_HOME policy

[Andrew Pimlott]

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 the right way to get away from making 'tools.jar'
> a standard name is to provide a way for packages to depend upon "the
> jar that contains foo.bar.baz" (perhaps more generally "the classpath
> element that contains foo.bar.baz".

But is anyone else reimplimenting any parts of tools.jar?  I doubt
it, in which case this is pointless.  (Not that it isn't a good idea
in principle.)

Maybe someone just needs to wrap this up in a (dead simple) compiler
API, and provide an implementation that uses tools.jar, and an
implementation that uses the preferred command-line compiler.

Andrew

Re: JAVA_HOME policy

[Dalibor Topic]

--- 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,
> 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.

Programs that use any com.sun.tools.* class are broken
by default anyway. They work by sheer luck and
coincidence.

If you write a program that needs to use a java
compiler, provide a way to specify it. Ant does that
via -Dbuild.compiler=something.

A trivial compiler lookup implementation in my eyes
would be to check a myapp.java.compiler property, and
try to load the class. If that fails, then call it as
a process. That would handle all java based compilers
*and* non-java based ones.

best regards,
dalibor topic

__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com