Re: [JBoss-dev] RH: tools.jar (javac)...
Maybe I am missing something, but isn't this whole issue about distributing a compiler with JBoss so the user doesn't have to download the JDK and edit a configuration file to point to it? If that is the case, can't we distribute jikes? -Phil Scott M Stark [EMAIL PROTECTED]To: JBossDev \(E-mail\) Sent by: [EMAIL PROTECTED] [EMAIL PROTECTED]cc: eforge.net Subject: Re: [JBoss-dev] RH: tools.jar (javac)... 11/13/2001 05:37 PM Please respond to Scott M Stark That is how both the bundled tomcat and standalone tomcat handles this. You have to have the JDK tools.jar, or jikes, or some other compiler configured as part of the installation. Since we can't bundle tools.jar and javac.jar is just a black box we don't want to include since it source for it can't be obtained, there is nothing we can do to make this a platform independent zero configuration issue as far as I know. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: David Maplesden [EMAIL PROTECTED] To: JBossDev (E-mail) [EMAIL PROTECTED] Sent: Tuesday, November 13, 2001 4:14 PM Subject: RE: [JBoss-dev] RH: tools.jar (javac)... No I haven't and I see now what you mean, I didn't read what you put carefully enough. Still you might be able to do it this way, IIRC we used to distribute javac in a javac.jar that was distributed with JBoss to different platforms and it seemed to work OK. I thought the only reason we weren't distributing tools.jar in the same way is because of licensing issues with Sun. That of course brings up a problem with 1) you can't distribute any package you create that contains tools.jar (I think). Perhaps the easiest thing to do for the Jetty dist is to reference tools.jar as if it exists in the lib/ext dir and simply include a README telling people what is going on, then they can supply their own (platform specific if neccessary) jar. David -Original Message- From: Julian Gosnell [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 14, 2001 1:02 PM To: David Maplesden; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [JBoss-dev] RH: tools.jar (javac)... David Maplesden wrote: 1) worked fine for me... Have you tried it on different architectures? My concern is that if I do the build on Linux, the tools.jar from my 1.3.1 distrib may not work on e.g. a Mac etc... Jules ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] RH: tools.jar (javac)...
Yes, you are missing the fact that tools.jar is plattform/vendor dependant. Therefore you would have to distribute one for each plattform. Andy - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, November 14, 2001 8:14 AM Subject: Re: [JBoss-dev] RH: tools.jar (javac)... Maybe I am missing something, but isn't this whole issue about distributing a compiler with JBoss so the user doesn't have to download the JDK and edit a configuration file to point to it? If that is the case, can't we distribute jikes? -Phil Scott M Stark [EMAIL PROTECTED]To: JBossDev \(E-mail\) Sent by: [EMAIL PROTECTED] [EMAIL PROTECTED]cc: eforge.net Subject: Re: [JBoss-dev] RH: tools.jar (javac)... 11/13/2001 05:37 PM Please respond to Scott M Stark That is how both the bundled tomcat and standalone tomcat handles this. You have to have the JDK tools.jar, or jikes, or some other compiler configured as part of the installation. Since we can't bundle tools.jar and javac.jar is just a black box we don't want to include since it source for it can't be obtained, there is nothing we can do to make this a platform independent zero configuration issue as far as I know. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: David Maplesden [EMAIL PROTECTED] To: JBossDev (E-mail) [EMAIL PROTECTED] Sent: Tuesday, November 13, 2001 4:14 PM Subject: RE: [JBoss-dev] RH: tools.jar (javac)... No I haven't and I see now what you mean, I didn't read what you put carefully enough. Still you might be able to do it this way, IIRC we used to distribute javac in a javac.jar that was distributed with JBoss to different platforms and it seemed to work OK. I thought the only reason we weren't distributing tools.jar in the same way is because of licensing issues with Sun. That of course brings up a problem with 1) you can't distribute any package you create that contains tools.jar (I think). Perhaps the easiest thing to do for the Jetty dist is to reference tools.jar as if it exists in the lib/ext dir and simply include a README telling people what is going on, then they can supply their own (platform specific if neccessary) jar. David -Original Message- From: Julian Gosnell [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 14, 2001 1:02 PM To: David Maplesden; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [JBoss-dev] RH: tools.jar (javac)... David Maplesden wrote: 1) worked fine for me... Have you tried it on different architectures? My concern is that if I do the build on Linux, the tools.jar from my 1.3.1 distrib may not work on e.g. a Mac etc... Jules ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] RH: tools.jar (javac)...
Jikes is not a Java program and you have to use a binary suitable for the target platform. I'm not interested in getting into supporting mutiple platform binaries. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, November 14, 2001 8:14 AM Subject: Re: [JBoss-dev] RH: tools.jar (javac)... Maybe I am missing something, but isn't this whole issue about distributing a compiler with JBoss so the user doesn't have to download the JDK and edit a configuration file to point to it? If that is the case, can't we distribute jikes? -Phil ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] RH: tools.jar (javac)...
amen marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Scott |M Stark |Sent: Wednesday, November 14, 2001 11:51 AM |To: [EMAIL PROTECTED] |Subject: Re: [JBoss-dev] RH: tools.jar (javac)... | | |Jikes is not a Java program and you have to use a binary suitable for |the target platform. I'm not interested in getting into supporting mutiple |platform binaries. | | |Scott Stark |Chief Technology Officer |JBoss Group, LLC | |- Original Message - |From: [EMAIL PROTECTED] |To: [EMAIL PROTECTED] |Sent: Wednesday, November 14, 2001 8:14 AM |Subject: Re: [JBoss-dev] RH: tools.jar (javac)... | | | | Maybe I am missing something, but isn't this whole issue about |distributing | a compiler with JBoss so the user doesn't have to download the JDK and |edit | a configuration file to point to it? | | If that is the case, can't we distribute jikes? | | -Phil | | | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] RH: tools.jar (javac)...
On Wed, 14 Nov 2001, Scott M Stark wrote: Jikes is not a Java program and you have to use a binary suitable for the target platform. I'm not interested in getting into supporting mutiple platform binaries. Well, I guess now is as good a time as any to bring up a problem I have with the current source tarball for 2.4.3. The 2.4.3 tarball contains precompiled jars. Some of these jars are precompiled jboss jars(ick, but forgivable, see below(1)). Some of these jars are non-free, and should NOT be redistributed. I understand the desire to provide a one-stop-shop for getting jboss to work. But then there should be a pristince source package, that does not have all this bundled code inside it. What I am requesting is such a pristine source package. Otherwise, I have to go to great lengths when making a Debian(www.debian.org) package of this software. There is also the point that I can not upload this package to the Debian archive, because it includes non-free code into its source package. I would greatly like to be able to upload this to Debian. list of packages included with jboss, followed by their homepage, then license type: castor: http://castor.exolab.org/ (BSD-like) hsql: http://hsqldb.sf.net/ (BSD) jetty-server: http://jetty.mortbay.org (artistic-like) oswego: http://g.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html (public domain) tyrex: http://tyrex.exolab.org/ (BSD-like) activation: http://java.sun.com/products/javabeans/glasgow/jaf.html (sun) jaxp: http://java.sun.com/xml/jaxp/ (sun) jcert: http://java.sun.com/products/jsse/(or j2se/1.4) (sun/export restrictions) jpl-util: http://www.gjt.org/ (unspecified) mail: http://java.sun.com/products/javamail/ (sun) ots-jts:http://java.sun.com/j2se/1.3/ (sun) 1: Additionally, the precompiled jboss jars that are in the source tarball get rebuilt during a build. This means a diff generation sees them as changed, and dpkg-source complains. Would it not be proper, to have proper compile ordering, and have each sub-package use what was just previously built? ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] RH: tools.jar (javac)...
2.4.x is based on the archaic and fragmented build policy from the early days of JBoss and its not likely to change(at least by me). The build process has been totally reorganized in the main branch for the 3.0 release so focus on getting a source ball that suits your purpose using it. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Adam Heath [EMAIL PROTECTED] To: Scott M Stark [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, November 14, 2001 9:48 AM Subject: Re: [JBoss-dev] RH: tools.jar (javac)... On Wed, 14 Nov 2001, Scott M Stark wrote: Jikes is not a Java program and you have to use a binary suitable for the target platform. I'm not interested in getting into supporting mutiple platform binaries. Well, I guess now is as good a time as any to bring up a problem I have with the current source tarball for 2.4.3. The 2.4.3 tarball contains precompiled jars. Some of these jars are precompiled jboss jars(ick, but forgivable, see below(1)). Some of these jars are non-free, and should NOT be redistributed. I understand the desire to provide a one-stop-shop for getting jboss to work. But then there should be a pristince source package, that does not have all this bundled code inside it. What I am requesting is such a pristine source package. Otherwise, I have to go to great lengths when making a Debian(www.debian.org) package of this software. There is also the point that I can not upload this package to the Debian archive, because it includes non-free code into its source package. I would greatly like to be able to upload this to Debian. list of packages included with jboss, followed by their homepage, then license type: castor: http://castor.exolab.org/ (BSD-like) hsql: http://hsqldb.sf.net/ (BSD) jetty-server: http://jetty.mortbay.org (artistic-like) oswego: http://g.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html (public domain) tyrex: http://tyrex.exolab.org/ (BSD-like) activation: http://java.sun.com/products/javabeans/glasgow/jaf.html (sun) jaxp: http://java.sun.com/xml/jaxp/ (sun) jcert: http://java.sun.com/products/jsse/(or j2se/1.4) (sun/export restrictions) jpl-util: http://www.gjt.org/ (unspecified) mail: http://java.sun.com/products/javamail/ (sun) ots-jts:http://java.sun.com/j2se/1.3/ (sun) 1: Additionally, the precompiled jboss jars that are in the source tarball get rebuilt during a build. This means a diff generation sees them as changed, and dpkg-source complains. Would it not be proper, to have proper compile ordering, and have each sub-package use what was just previously built? ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] RH: tools.jar (javac)...
I'm preparing a patch (my humble contribution, snif!) for run.bat/run.jar. It includes: 1.- Support for tools.jar 'a la' Tomcat: you should define a JAVA_HOME environment variable that points to your java instalation directory. It checks if tools.jar is where it should. If not, it doesn't let you start JBoss. 2.- Moves all the JAXP env variables into run.jar, cleaning the bat file. 3.- Document into run.bat a bit what's happening. 4.- Include commented lines to start jboss in debug mode (JPDA), both by socket and by shared memory. There are docs out there about how to connect to an already started app. I use this one a lot. Ignacio. -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En nombre de Andreas Schaefer Enviado el: miércoles, 14 de noviembre de 2001 16:46 Para: [EMAIL PROTECTED]; [EMAIL PROTECTED] Asunto: Re: [JBoss-dev] RH: tools.jar (javac)... Yes, you are missing the fact that tools.jar is plattform/vendor dependant. Therefore you would have to distribute one for each plattform. Andy - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, November 14, 2001 8:14 AM Subject: Re: [JBoss-dev] RH: tools.jar (javac)... Maybe I am missing something, but isn't this whole issue about distributing a compiler with JBoss so the user doesn't have to download the JDK and edit a configuration file to point to it? If that is the case, can't we distribute jikes? -Phil Scott M Stark [EMAIL PROTECTED]To: JBossDev \(E-mail\) Sent by: [EMAIL PROTECTED] [EMAIL PROTECTED]cc: eforge.net Subject: Re: [JBoss-dev] RH: tools.jar (javac)... 11/13/2001 05:37 PM Please respond to Scott M Stark That is how both the bundled tomcat and standalone tomcat handles this. You have to have the JDK tools.jar, or jikes, or some other compiler configured as part of the installation. Since we can't bundle tools.jar and javac.jar is just a black box we don't want to include since it source for it can't be obtained, there is nothing we can do to make this a platform independent zero configuration issue as far as I know. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: David Maplesden [EMAIL PROTECTED] To: JBossDev (E-mail) [EMAIL PROTECTED] Sent: Tuesday, November 13, 2001 4:14 PM Subject: RE: [JBoss-dev] RH: tools.jar (javac)... No I haven't and I see now what you mean, I didn't read what you put carefully enough. Still you might be able to do it this way, IIRC we used to distribute javac in a javac.jar that was distributed with JBoss to different platforms and it seemed to work OK. I thought the only reason we weren't distributing tools.jar in the same way is because of licensing issues with Sun. That of course brings up a problem with 1) you can't distribute any package you create that contains tools.jar (I think). Perhaps the easiest thing to do for the Jetty dist is to reference tools.jar as if it exists in the lib/ext dir and simply include a README telling people what is going on, then they can supply their own (platform specific if neccessary) jar. David -Original Message- From: Julian Gosnell [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 14, 2001 1:02 PM To: David Maplesden; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [JBoss-dev] RH: tools.jar (javac)... David Maplesden wrote: 1) worked fine for me... Have you tried it on different architectures? My concern is that if I do the build on Linux, the tools.jar from my 1.3.1 distrib may not work on e.g. a Mac etc... Jules ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] RH: tools.jar (javac)...
How about removing the code and leaving a comment in the run.bat file? It's easy to modify the required of JAVA_HOME to add tools.jar if JAVA_HOME is available -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En nombre de David Maplesden Enviado el: miércoles, 14 de noviembre de 2001 19:38 Para: [EMAIL PROTECTED] Asunto: RE: [JBoss-dev] RH: tools.jar (javac)... You might be jumping the gun a bit with this one. tools.jar is only needed afaik for Jasper i.e. when Jetty (or Tomcat) needs to serve jsp pages. Not everyone will want this, indeed many people will probably run JBoss without a servlet engine, and so they won't need tools.jar. David -Original Message- From: Ignacio Coloma [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 15, 2001 7:57 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] RH: tools.jar (javac)... I'm preparing a patch (my humble contribution, snif!) for run.bat/run.jar. It includes: 1.- Support for tools.jar 'a la' Tomcat: you should define a JAVA_HOME environment variable that points to your java instalation directory. It checks if tools.jar is where it should. If not, it doesn't let you start JBoss. 2.- Moves all the JAXP env variables into run.jar, cleaning the bat file. 3.- Document into run.bat a bit what's happening. 4.- Include commented lines to start jboss in debug mode (JPDA), both by socket and by shared memory. There are docs out there about how to connect to an already started app. I use this one a lot. Ignacio. -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En nombre de Andreas Schaefer Enviado el: miércoles, 14 de noviembre de 2001 16:46 Para: [EMAIL PROTECTED]; [EMAIL PROTECTED] Asunto: Re: [JBoss-dev] RH: tools.jar (javac)... Yes, you are missing the fact that tools.jar is plattform/vendor dependant. Therefore you would have to distribute one for each plattform. Andy - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, November 14, 2001 8:14 AM Subject: Re: [JBoss-dev] RH: tools.jar (javac)... Maybe I am missing something, but isn't this whole issue about distributing a compiler with JBoss so the user doesn't have to download the JDK and edit a configuration file to point to it? If that is the case, can't we distribute jikes? -Phil Scott M Stark [EMAIL PROTECTED]To: JBossDev \(E-mail\) Sent by: [EMAIL PROTECTED] [EMAIL PROTECTED]cc: eforge.net Subject: Re: [JBoss-dev] RH: tools.jar (javac)... 11/13/2001 05:37 PM Please respond to Scott M Stark That is how both the bundled tomcat and standalone tomcat handles this. You have to have the JDK tools.jar, or jikes, or some other compiler configured as part of the installation. Since we can't bundle tools.jar and javac.jar is just a black box we don't want to include since it source for it can't be obtained, there is nothing we can do to make this a platform independent zero configuration issue as far as I know. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: David Maplesden [EMAIL PROTECTED] To: JBossDev (E-mail) [EMAIL PROTECTED] Sent: Tuesday, November 13, 2001 4:14 PM Subject: RE: [JBoss-dev] RH: tools.jar (javac)... No I haven't and I see now what you mean, I didn't read what you put carefully enough. Still you might be able to do it this way, IIRC we used to distribute javac in a javac.jar that was distributed with JBoss to different platforms and it seemed to work OK. I thought the only reason we weren't distributing tools.jar in the same way is because of licensing issues with Sun. That of course brings up a problem with 1) you can't distribute any package you create that contains tools.jar (I think). Perhaps the easiest thing to do for the Jetty dist is to reference tools.jar as if it exists in the lib/ext dir and simply include a README telling people what is going on, then they can supply their own (platform specific if neccessary) jar. David -Original Message- From: Julian Gosnell [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 14, 2001 1:02 PM To: David Maplesden; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [JBoss-dev] RH: tools.jar (javac)... David Maplesden wrote: 1
RE: [JBoss-dev] RH: tools.jar (javac)...
yeah sounds good, add it if you can find it, if you can't print a warning and carry on -Original Message- From: Ignacio Coloma [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 15, 2001 8:48 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] RH: tools.jar (javac)... How about removing the code and leaving a comment in the run.bat file? It's easy to modify the required of JAVA_HOME to add tools.jar if JAVA_HOME is available -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En nombre de David Maplesden Enviado el: miércoles, 14 de noviembre de 2001 19:38 Para: [EMAIL PROTECTED] Asunto: RE: [JBoss-dev] RH: tools.jar (javac)... You might be jumping the gun a bit with this one. tools.jar is only needed afaik for Jasper i.e. when Jetty (or Tomcat) needs to serve jsp pages. Not everyone will want this, indeed many people will probably run JBoss without a servlet engine, and so they won't need tools.jar. David -Original Message- From: Ignacio Coloma [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 15, 2001 7:57 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] RH: tools.jar (javac)... I'm preparing a patch (my humble contribution, snif!) for run.bat/run.jar. It includes: 1.- Support for tools.jar 'a la' Tomcat: you should define a JAVA_HOME environment variable that points to your java instalation directory. It checks if tools.jar is where it should. If not, it doesn't let you start JBoss. 2.- Moves all the JAXP env variables into run.jar, cleaning the bat file. 3.- Document into run.bat a bit what's happening. 4.- Include commented lines to start jboss in debug mode (JPDA), both by socket and by shared memory. There are docs out there about how to connect to an already started app. I use this one a lot. Ignacio. -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En nombre de Andreas Schaefer Enviado el: miércoles, 14 de noviembre de 2001 16:46 Para: [EMAIL PROTECTED]; [EMAIL PROTECTED] Asunto: Re: [JBoss-dev] RH: tools.jar (javac)... Yes, you are missing the fact that tools.jar is plattform/vendor dependant. Therefore you would have to distribute one for each plattform. Andy - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, November 14, 2001 8:14 AM Subject: Re: [JBoss-dev] RH: tools.jar (javac)... Maybe I am missing something, but isn't this whole issue about distributing a compiler with JBoss so the user doesn't have to download the JDK and edit a configuration file to point to it? If that is the case, can't we distribute jikes? -Phil Scott M Stark [EMAIL PROTECTED] To: JBossDev \(E-mail\) Sent by: [EMAIL PROTECTED] [EMAIL PROTECTED]cc: eforge.net Subject: Re: [JBoss-dev] RH: tools.jar (javac)... 11/13/2001 05:37 PM Please respond to Scott M Stark That is how both the bundled tomcat and standalone tomcat handles this. You have to have the JDK tools.jar, or jikes, or some other compiler configured as part of the installation. Since we can't bundle tools.jar and javac.jar is just a black box we don't want to include since it source for it can't be obtained, there is nothing we can do to make this a platform independent zero configuration issue as far as I know. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: David Maplesden [EMAIL PROTECTED] To: JBossDev (E-mail) [EMAIL PROTECTED] Sent: Tuesday, November 13, 2001 4:14 PM Subject: RE: [JBoss-dev] RH: tools.jar (javac)... No I haven't and I see now what you mean, I didn't read what you put carefully enough. Still you might be able to do it this way, IIRC we used to distribute javac in a javac.jar that was distributed with JBoss to different platforms and it seemed to work OK. I thought the only reason we weren't distributing tools.jar in the same way is because of licensing issues with Sun. That of course brings up a problem with 1) you can't distribute any package you create that contains tools.jar (I think). Perhaps the easiest thing to do for the Jetty dist is to reference tools.jar as if it exists in the lib/ext dir and simply include a README
RE: [JBoss-dev] RH: tools.jar (javac)...
On Thu, 15 Nov 2001, David Maplesden wrote: You might be jumping the gun a bit with this one. tools.jar is only needed afaik for Jasper i.e. when Jetty (or Tomcat) needs to serve jsp pages. Not everyone will want this, indeed many people will probably run JBoss without a servlet engine, and so they won't need tools.jar. The way I did the packaging for debian, is I made a separate jboss-tomcat-service.deb, which doesn't always have to be installed, and have this do the nescessary setup in the init script(/etc/init.d/jboss-server). Of course, I'm not quite ready to make these available yet(they are still only alpha quality, and have debian packaging issues that may only be fixable by someone who knows the internals of debian). ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] RH: tools.jar (javac)...
On Wed, 14 Nov 2001, Scott M Stark wrote: 2.4.x is based on the archaic and fragmented build policy from the early days of JBoss and its not likely to change(at least by me). The build process has been totally reorganized in the main branch for the 3.0 release so focus on getting a source ball that suits your purpose using it. Ok, I can understand that. I am reluctant to make debs from something that only exists in cvs(it has been done before, I just don't want to do it in this case). Is there an estimate to when even an alpha might be made available? ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] RH: tools.jar (javac)...
Next week. - Original Message - From: Adam Heath [EMAIL PROTECTED] To: Scott M Stark [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, November 14, 2001 12:55 PM Subject: Re: [JBoss-dev] RH: tools.jar (javac)... On Wed, 14 Nov 2001, Scott M Stark wrote: 2.4.x is based on the archaic and fragmented build policy from the early days of JBoss and its not likely to change(at least by me). The build process has been totally reorganized in the main branch for the 3.0 release so focus on getting a source ball that suits your purpose using it. Ok, I can understand that. I am reluctant to make debs from something that only exists in cvs(it has been done before, I just don't want to do it in this case). Is there an estimate to when even an alpha might be made available? ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] RH: tools.jar (javac)...
On Wed, 14 Nov 2001, Scott M Stark wrote: Next week. Ooh! I can't wait. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] RH: tools.jar (javac)...
Can we automate .deb building with the new build system? --jason On Wed, 14 Nov 2001, Adam Heath wrote: On Wed, 14 Nov 2001, Scott M Stark wrote: 2.4.x is based on the archaic and fragmented build policy from the early days of JBoss and its not likely to change(at least by me). The build process has been totally reorganized in the main branch for the 3.0 release so focus on getting a source ball that suits your purpose using it. Ok, I can understand that. I am reluctant to make debs from something that only exists in cvs(it has been done before, I just don't want to do it in this case). Is there an estimate to when even an alpha might be made available? ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] RH: tools.jar (javac)...
yOn Wed, 14 Nov 2001, Jason Dillon wrote: Can we automate .deb building with the new build system? Possibly. The whole point of debian is automation. We have lots of build daemons setup(for all the architectures we support), that demand this sort of feature. I have just checked out the cvs stuff, and perusing it now. I'm thinking of redoing how I did the debification. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] RH: tools.jar (javac)...
We are not planning on re-adding tools.jar to the package are we? Perhaps we could setup an InstallAnywhere installer which could have some custom tasks to install a tools.jar from the target JDK for those users who might have trouble doing this by hand. --jason On Wed, 14 Nov 2001, Adam Heath wrote: On Wed, 14 Nov 2001, Scott M Stark wrote: Next week. Ooh! I can't wait. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] RH: tools.jar (javac)...
No were not. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Jason Dillon [EMAIL PROTECTED] To: Adam Heath [EMAIL PROTECTED] Cc: Scott M Stark [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, November 14, 2001 5:57 PM Subject: Re: [JBoss-dev] RH: tools.jar (javac)... We are not planning on re-adding tools.jar to the package are we? Perhaps we could setup an InstallAnywhere installer which could have some custom tasks to install a tools.jar from the target JDK for those users who might have trouble doing this by hand. --jason On Wed, 14 Nov 2001, Adam Heath wrote: On Wed, 14 Nov 2001, Scott M Stark wrote: Next week. Ooh! I can't wait. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] RH: tools.jar (javac)...
1) worked fine for me... -Original Message- From: Julian Gosnell [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 14, 2001 10:05 AM To: [EMAIL PROTECTED] Subject: [JBoss-dev] RH: tools.jar (javac)... Jasper requires tools.jar to be available to it. Should I: 1. copy it from my java distrib into lib/ext with the Jetty jars at build time (is the jar arch independent) 2. try to get it on the JBOSS_CLASSPATH and hope Jetty/Jasper can see it... 3. find another way - suggestions ? In short, given the ClassLoader architecture of RH - how should I get hold of tools.jar Thanks for your time, Jules _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] RH: tools.jar (javac)...
No I haven't and I see now what you mean, I didn't read what you put carefully enough. Still you might be able to do it this way, IIRC we used to distribute javac in a javac.jar that was distributed with JBoss to different platforms and it seemed to work OK. I thought the only reason we weren't distributing tools.jar in the same way is because of licensing issues with Sun. That of course brings up a problem with 1) you can't distribute any package you create that contains tools.jar (I think). Perhaps the easiest thing to do for the Jetty dist is to reference tools.jar as if it exists in the lib/ext dir and simply include a README telling people what is going on, then they can supply their own (platform specific if neccessary) jar. David -Original Message- From: Julian Gosnell [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 14, 2001 1:02 PM To: David Maplesden; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [JBoss-dev] RH: tools.jar (javac)... David Maplesden wrote: 1) worked fine for me... Have you tried it on different architectures? My concern is that if I do the build on Linux, the tools.jar from my 1.3.1 distrib may not work on e.g. a Mac etc... Jules -Original Message- From: Julian Gosnell [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 14, 2001 10:05 AM To: [EMAIL PROTECTED] Subject: [JBoss-dev] RH: tools.jar (javac)... Jasper requires tools.jar to be available to it. Should I: 1. copy it from my java distrib into lib/ext with the Jetty jars at build time (is the jar arch independent) 2. try to get it on the JBOSS_CLASSPATH and hope Jetty/Jasper can see it... 3. find another way - suggestions ? In short, given the ClassLoader architecture of RH - how should I get hold of tools.jar Thanks for your time, Jules _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] RH: tools.jar (javac)...
That is how both the bundled tomcat and standalone tomcat handles this. You have to have the JDK tools.jar, or jikes, or some other compiler configured as part of the installation. Since we can't bundle tools.jar and javac.jar is just a black box we don't want to include since it source for it can't be obtained, there is nothing we can do to make this a platform independent zero configuration issue as far as I know. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: David Maplesden [EMAIL PROTECTED] To: JBossDev (E-mail) [EMAIL PROTECTED] Sent: Tuesday, November 13, 2001 4:14 PM Subject: RE: [JBoss-dev] RH: tools.jar (javac)... No I haven't and I see now what you mean, I didn't read what you put carefully enough. Still you might be able to do it this way, IIRC we used to distribute javac in a javac.jar that was distributed with JBoss to different platforms and it seemed to work OK. I thought the only reason we weren't distributing tools.jar in the same way is because of licensing issues with Sun. That of course brings up a problem with 1) you can't distribute any package you create that contains tools.jar (I think). Perhaps the easiest thing to do for the Jetty dist is to reference tools.jar as if it exists in the lib/ext dir and simply include a README telling people what is going on, then they can supply their own (platform specific if neccessary) jar. David -Original Message- From: Julian Gosnell [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 14, 2001 1:02 PM To: David Maplesden; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [JBoss-dev] RH: tools.jar (javac)... David Maplesden wrote: 1) worked fine for me... Have you tried it on different architectures? My concern is that if I do the build on Linux, the tools.jar from my 1.3.1 distrib may not work on e.g. a Mac etc... Jules ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
