On Thursday 9 November 2000, at 22 h 37,
the keyboard of =?iso-8859-1?Q?Nicol=E1s_Lichtmaier?= [EMAIL PROTECTED] wrote:
This proposed java-policy is broken... It doesn't allow for diferent
versions of the same classes.
Proposals and patches are welcome (bugs against java-common, for
On Wednesday 8 November 2000, at 12 h 3,
the keyboard of Aaron Brashears [EMAIL PROTECTED] wrote:
Joe Emenaker sent a nice idea to me which the list didn't get to
see. He suggested making a script which does autodetection of jar
files in your /usr/share/java and sets the classpath
On Thu, Nov 09, 2000 at 10:59:25AM +, Nic Ferrier wrote:
The point I was trying to make is that Debian may want to provide a
standard webapp directory or path (the place where WAR files are put
so that the servlet engine can find them).
Though not yet in main, Stefan Gybas packaged Tomcat
Aaron Brashears [EMAIL PROTECTED] 09-Nov-00 6:17:55 PM
Though not yet in main, Stefan Gybas packaged
Tomcat 3.2b6 recently for Debian. I've given it some simple
tests, and it seems to work. He decided to make
/usr/share/java/webapps the place to dump war
files. The war files are then
On Tuesday 7 November 2000, at 21 h 55,
the keyboard of Aaron Brashears [EMAIL PROTECTED] wrote:
After some reflection it seems that it would make more sense to just
copy the class files in /usr/share/java so setting the classpath for
standard packages would be handled once by setting
On Wed, Nov 08, 2000 at 04:05:04AM -0300, Nicolás Lichtmaier wrote:
The truth is that there isn't a Java policy.
True, but there is a proposed java policy, which seems like a good
starting point. AFAIK, most java packages for debian are conforming to
the java policy.
apt-get install
Aaron Brashears [EMAIL PROTECTED] writes:
Joe Emenaker sent a nice idea to me which the list didn't get to
see. He suggested making a script which does autodetection of jar
files in your /usr/share/java and sets the classpath
appropriately.
Which is what you have to do anyway if you want to
"Per" == per [EMAIL PROTECTED] writes:
Per Juergen Kreileder [EMAIL PROTECTED] writes:
Our Java 2 packages use a extension directory /usr/lib/j2re1.3/ext (and
/usr/lib/j2re1.3/$(ARCH)/lib). The packages for Java3D, JAI and JMF
install into those directories.
I've been thinking about the way debian java packages are built. For
example, libxerces-java and ant are both distributed as jar files
which wind up in /usr/share/java and some documentation which goes in
/usr/share/doc/package-name. According to the java policy, debian
java packages can be
On Tuesday 7 November 2000, at 21 h 55,
the keyboard of Aaron Brashears [EMAIL PROTECTED] wrote:
After some reflection it seems that it would make more sense to just
copy the class files in /usr/share/java so setting the classpath for
standard packages would be handled once by setting
Aaron Brashears [EMAIL PROTECTED] writes:
After some reflection it seems that it would make more sense to just
copy the class files in /usr/share/java so setting the classpath for
standard packages would be handled once by setting
CLASSPATH=/usr/share/java once instead of having to tack on
On Wed, Nov 08, 2000 at 04:05:04AM -0300, Nicolás Lichtmaier wrote:
The truth is that there isn't a Java policy.
True, but there is a proposed java policy, which seems like a good
starting point. AFAIK, most java packages for debian are conforming to
the java policy.
apt-get install
On Wed, Nov 08, 2000 at 09:49:47AM -0500, [EMAIL PROTECTED] wrote:
Aaron Brashears [EMAIL PROTECTED] writes:
After some reflection it seems that it would make more sense to just
copy the class files in /usr/share/java so setting the classpath for
standard packages would be handled once by
On Wed, Nov 08, 2000 at 12:22:39PM -0800, [EMAIL PROTECTED] wrote:
Aaron Brashears [EMAIL PROTECTED] writes:
Joe Emenaker sent a nice idea to me which the list didn't get to
see. He suggested making a script which does autodetection of jar
files in your /usr/share/java and sets the
Juergen Kreileder [EMAIL PROTECTED] writes:
Our Java 2 packages use a extension directory /usr/lib/j2re1.3/ext (and
/usr/lib/j2re1.3/$(ARCH)/lib). The packages for Java3D, JAI and JMF
install into those directories.
Additionally we add /usr/share/java/repository to CLASSPATH but in
Per == per [EMAIL PROTECTED] writes:
Per Aaron Brashears [EMAIL PROTECTED] writes:
Joe Emenaker sent a nice idea to me which the list didn't get to
see. He suggested making a script which does autodetection of jar
files in your /usr/share/java and sets the classpath
Per == per [EMAIL PROTECTED] writes:
Per Juergen Kreileder [EMAIL PROTECTED] writes:
Our Java 2 packages use a extension directory /usr/lib/j2re1.3/ext (and
/usr/lib/j2re1.3/$(ARCH)/lib). The packages for Java3D, JAI and JMF
install into those directories.
After some reflection it seems that it would make more sense to just
copy the class files in /usr/share/java so setting the classpath for
standard packages would be handled once by setting
CLASSPATH=/usr/share/java once instead of having to tack on new jar
file to the classpath every time a
On Wed, Nov 08, 2000 at 12:03:40PM -0800, Aaron Brashears wrote:
Joe Emenaker sent a nice idea to me which the list didn't get to
see. He suggested making a script which does autodetection of jar
files in your /usr/share/java and sets the classpath
appropriately. Though I don't think that
On Wed, Nov 08, 2000 at 12:03:40PM -0800, Aaron Brashears wrote:
Good point. The current method of debanizing jars is going to fail
soon, since most I've run into don't version stamp the filename.
Not really. If a given debianized jar needed to support multiple versions, it
could be modified
Our Java 2 packages use a extension directory /usr/lib/j2re1.3/ext (and
/usr/lib/j2re1.3/$(ARCH)/lib). The packages for Java3D, JAI and JMF
install into those directories.
Additionally we add /usr/share/java/repository to CLASSPATH but in
general I would prefer a strictly extension
Ah, wouldn't that be nice. If every package maintained compatibility
release to release, we could do that. But that doesn't always happen.
For example, Kawa's package hierarchy is going through some
reorganization, such that if I compile BRL against Kawa 1.6.67 won't
work with Kawa 1.6.70
* Joe Emenaker [EMAIL PROTECTED] [001108 14:04]:
Ah, wouldn't that be nice. If every package maintained compatibility
release to release, we could do that. But that doesn't always happen.
For example, Kawa's package hierarchy is going through some
reorganization, such that if I compile
* Joe Emenaker [EMAIL PROTECTED] [001108 14:04]:
Isn't that what the Debian package conflicts and requires settings
are
for? If I compile Apache against libc5 and then replace libc5 with
libc6,
Apache's going to break until I recompile, right? However, the Debian
packaging system safely
*And now some stuff about servlet engines
This gets more complicated when you consider servlet engines. Servlet
engines should have their code (jars or classes) specified on the
classpath (ie: 3).
The classes and jar files that define applications (eg: servlets and
so forth) go in an
I've been thinking about the way debian java packages are built. For
example, libxerces-java and ant are both distributed as jar files
which wind up in /usr/share/java and some documentation which goes in
/usr/share/doc/package-name. According to the java policy, debian
java packages can be
26 matches
Mail list logo
