On Tue, Sep 18, 2001 at 06:10:43PM -0700, Joe Emenaker wrote:
>
> > My turn to say "tread carefully".
> >
> > Symlinking jars can be dangerous, because jars can contain a Class-path:
> > line in their manifests. These Class-path: lines contain relative
> > references to other jars.
>
> I'm not re
Hi. I checked out the j2se1.3 packages and they look great;
good work on finally getting them in debian proper. :)
I do have one question, and you're going to hate me for it but I'm going
to ask it anyway.
What are we doing about the java2 dependency issue? There was a long
thread about this r
> I'd have thought program-specific jars are by definition, not shared,
> and therefore do not belong on /usr/share?
False. In java there's precious little difference between programs and
binaries; they're often both jar files where the program simply has a
class hiding somewhere with a main() m
On Tue, Sep 18, 2001 at 05:45:14PM -0700, Joe Emenaker wrote:
>
> > I have half a gig of open source Java on my hdd, which amounts to a lot
> > of projects. With this scheme, I'd spend half my life twiddling the
> > JAVA_PROJ_LIB variable to point to whichever project I'm currently
> > interested
Jeff Turner <[EMAIL PROTECTED]> writes:
> On Wed, Sep 19, 2001 at 03:35:20AM +0200, Anders Jackson wrote:
> > Jeff Turner <[EMAIL PROTECTED]> writes:
> >
> > [...]
> >
> > > As long as it's not purely additive. I want to be able to remove stuff
> > > from the classpath, not just add my stuff. Th
On Wed, Sep 19, 2001 at 03:35:20AM +0200, Anders Jackson wrote:
> Jeff Turner <[EMAIL PROTECTED]> writes:
>
> [...]
>
> > As long as it's not purely additive. I want to be able to remove stuff
> > from the classpath, not just add my stuff. There are various subtle
> > problems that can occur othe
On Tue, Sep 18, 2001 at 12:40:01PM -0700, Joe Emenaker wrote:
>
> > > I would argue all classpath manipulation should be done in JVM/compiler
> > > startup scripts and Java application startup scripts.
> >
> > I think you're right.
>
> Me, too. And this has been what I've been pushing for from th
Jeff Turner <[EMAIL PROTECTED]> writes:
[...]
> As long as it's not purely additive. I want to be able to remove stuff
> from the classpath, not just add my stuff. There are various subtle
> problems that can occur otherwise:
Make /usr/bin/java a modified version of your proj.sh, wher you add
th
On Tue, Sep 18, 2001 at 07:13:49PM -0500, Ben Burton wrote:
>
> > Another point about lib/ext. The JVM treats all jars in lib/ext as
> > priveleged, like java.lang.*.
>
> It goes beyond this; policy should not say *anything* about lib/ext at all
> because our system has to support all available J
> My turn to say "tread carefully".
>
> Symlinking jars can be dangerous, because jars can contain a Class-path:
> line in their manifests. These Class-path: lines contain relative
> references to other jars.
I'm not really an advocate of the symlinking idea, but am I the only one
that thinks tha
On Tue, Sep 18, 2001 at 02:44:00PM +0200, Ola Lundqvist wrote:
> Hi
>
> I'll try to summarize what have come up so far during the
> discussion.
[snip good stuff]
> To discuss:
> ---
>
> * Should we allow library packages to provide different versions?
> Like libxalan2 that provides bot
> I have half a gig of open source Java on my hdd, which amounts to a lot
> of projects. With this scheme, I'd spend half my life twiddling the
> JAVA_PROJ_LIB variable to point to whichever project I'm currently
> interested in.
Well, you can mitigate this by making JAVA_PROJ_LIB something like
On Tue, Sep 18, 2001 at 06:10:43PM -0700, Joe Emenaker wrote:
>
> > My turn to say "tread carefully".
> >
> > Symlinking jars can be dangerous, because jars can contain a Class-path:
> > line in their manifests. These Class-path: lines contain relative
> > references to other jars.
>
> I'm not r
> Another point about lib/ext. The JVM treats all jars in lib/ext as
> priveleged, like java.lang.*.
It goes beyond this; policy should not say *anything* about lib/ext at all
because our system has to support all available JVMs, not just sun ports.
Think kaffe, orp, etc.
Ben.
Hi. I checked out the j2se1.3 packages and they look great;
good work on finally getting them in debian proper. :)
I do have one question, and you're going to hate me for it but I'm going
to ask it anyway.
What are we doing about the java2 dependency issue? There was a long
thread about this
> I'd have thought program-specific jars are by definition, not shared,
> and therefore do not belong on /usr/share?
False. In java there's precious little difference between programs and
binaries; they're often both jar files where the program simply has a
class hiding somewhere with a main()
On Tue, Sep 18, 2001 at 05:45:14PM -0700, Joe Emenaker wrote:
>
> > I have half a gig of open source Java on my hdd, which amounts to a lot
> > of projects. With this scheme, I'd spend half my life twiddling the
> > JAVA_PROJ_LIB variable to point to whichever project I'm currently
> > interested
On Tue, Sep 18, 2001 at 02:15:04PM -0700, Bill Wohler wrote:
> Ben Burton <[EMAIL PROTECTED]> writes:
> > /usr/share/java/foo-version.jar
> > /usr/share/java/foo.jar -> foo-version.jar
>
> Tread carefully. This could have unpredictable results.
>
> The extension directory $JAVA_HOME/jre/lib/e
Jeff Turner <[EMAIL PROTECTED]> writes:
> On Wed, Sep 19, 2001 at 03:35:20AM +0200, Anders Jackson wrote:
> > Jeff Turner <[EMAIL PROTECTED]> writes:
> >
> > [...]
> >
> > > As long as it's not purely additive. I want to be able to remove stuff
> > > from the classpath, not just add my stuff. T
On Tue, Sep 18, 2001 at 12:40:01PM -0700, Joe Emenaker wrote:
>
> > > I would argue all classpath manipulation should be done in JVM/compiler
> > > startup scripts and Java application startup scripts.
> >
> > I think you're right.
>
> Me, too. And this has been what I've been pushing for from t
On Wed, Sep 19, 2001 at 03:35:20AM +0200, Anders Jackson wrote:
> Jeff Turner <[EMAIL PROTECTED]> writes:
>
> [...]
>
> > As long as it's not purely additive. I want to be able to remove stuff
> > from the classpath, not just add my stuff. There are various subtle
> > problems that can occur oth
Jeff Turner <[EMAIL PROTECTED]> writes:
[...]
> As long as it's not purely additive. I want to be able to remove stuff
> from the classpath, not just add my stuff. There are various subtle
> problems that can occur otherwise:
Make /usr/bin/java a modified version of your proj.sh, wher you add
t
On Tue, Sep 18, 2001 at 07:13:49PM -0500, Ben Burton wrote:
>
> > Another point about lib/ext. The JVM treats all jars in lib/ext as
> > priveleged, like java.lang.*.
>
> It goes beyond this; policy should not say *anything* about lib/ext at all
> because our system has to support all available
> My turn to say "tread carefully".
>
> Symlinking jars can be dangerous, because jars can contain a Class-path:
> line in their manifests. These Class-path: lines contain relative
> references to other jars.
I'm not really an advocate of the symlinking idea, but am I the only one
that thinks th
On Tue, Sep 18, 2001 at 02:44:00PM +0200, Ola Lundqvist wrote:
> Hi
>
> I'll try to summarize what have come up so far during the
> discussion.
[snip good stuff]
> To discuss:
> ---
>
> * Should we allow library packages to provide different versions?
> Like libxalan2 that provides bo
> I have half a gig of open source Java on my hdd, which amounts to a lot
> of projects. With this scheme, I'd spend half my life twiddling the
> JAVA_PROJ_LIB variable to point to whichever project I'm currently
> interested in.
Well, you can mitigate this by making JAVA_PROJ_LIB something like
The following just entered .../Incoming.
I'd like to thank Matthias Klose for all his work. He is largely
responsible for the existence of these packages.
There will be sparc and ppc packages in .../Incoming shortly.
-BEGIN PGP SIGNED MESSAGE-
Format: 1.7
Date: Thu, 13 Sep 2001 01:13:
> Another point about lib/ext. The JVM treats all jars in lib/ext as
> priveleged, like java.lang.*.
It goes beyond this; policy should not say *anything* about lib/ext at all
because our system has to support all available JVMs, not just sun ports.
Think kaffe, orp, etc.
Ben.
--
To UNSUBSCR
Ben Burton <[EMAIL PROTECTED]> writes:
> /usr/share/java/foo-version.jar
> /usr/share/java/foo.jar -> foo-version.jar
Tread carefully. This could have unpredictable results.
The extension directory $JAVA_HOME/jre/lib/ext currently points to
/usr/share/java, so /usr/share/java is serving as
> > /usr/share/java/foo-version.jar
> > /usr/share/java/foo.jar -> foo-version.jar
>
> Tread carefully. This could have unpredictable results.
>
> The extension directory $JAVA_HOME/jre/lib/ext currently points to
> /usr/share/java, so /usr/share/java is serving as the extension
> director
On Tue, Sep 18, 2001 at 02:15:04PM -0700, Bill Wohler wrote:
> Ben Burton <[EMAIL PROTECTED]> writes:
> > /usr/share/java/foo-version.jar
> > /usr/share/java/foo.jar -> foo-version.jar
>
> Tread carefully. This could have unpredictable results.
>
> The extension directory $JAVA_HOME/jre/lib/
On Tue, Sep 18, 2001 at 02:07:09PM -0500, Adam Heath wrote:
> On Mon, 17 Sep 2001, Per Bothner wrote:
>
> > Stefan Gybas wrote:
> >
> > > Basically yes, but IMHO this should be the decision of the local admin
> > > and not of the package maintainer. How could he know ig his package
> > > contains
> > I would argue all classpath manipulation should be done in JVM/compiler
> > startup scripts and Java application startup scripts.
>
> I think you're right.
Me, too. And this has been what I've been pushing for from the get-go.
> 1) What happens when classpath conflicts arise? Say I've insta
The following just entered .../Incoming.
I'd like to thank Matthias Klose for all his work. He is largely
responsible for the existence of these packages.
There will be sparc and ppc packages in .../Incoming shortly.
-BEGIN PGP SIGNED MESSAGE-
Format: 1.7
Date: Thu, 13 Sep 2001 01:13
> > /usr/share/java/foo-version.jar
> > /usr/share/java/foo.jar -> foo-version.jar
>
> Tread carefully. This could have unpredictable results.
>
> The extension directory $JAVA_HOME/jre/lib/ext currently points to
> /usr/share/java, so /usr/share/java is serving as the extension
> directo
Ben Burton <[EMAIL PROTECTED]> writes:
> /usr/share/java/foo-version.jar
> /usr/share/java/foo.jar -> foo-version.jar
Tread carefully. This could have unpredictable results.
The extension directory $JAVA_HOME/jre/lib/ext currently points to
/usr/share/java, so /usr/share/java is serving as
On Mon, 17 Sep 2001, Per Bothner wrote:
> Stefan Gybas wrote:
>
> > Basically yes, but IMHO this should be the decision of the local admin
> > and not of the package maintainer. How could he know ig his package
> > contains "standard" jars? This means that no package should automatically
> > put j
On Tue, Sep 18, 2001 at 02:07:09PM -0500, Adam Heath wrote:
> On Mon, 17 Sep 2001, Per Bothner wrote:
>
> > Stefan Gybas wrote:
> >
> > > Basically yes, but IMHO this should be the decision of the local admin
> > > and not of the package maintainer. How could he know ig his package
> > > contains
Just to chime in, as an occasional java user (ie. "oh, this program
is in java, what do I have to figure out to run it -- oh, I can just
apt-get install these java libs") I agree - installed java packages
*should* be no less usable than installed C or Perl libraries.
Perhaps that implies that the
> > I would argue all classpath manipulation should be done in JVM/compiler
> > startup scripts and Java application startup scripts.
>
> I think you're right.
Me, too. And this has been what I've been pushing for from the get-go.
> 1) What happens when classpath conflicts arise? Say I've inst
On Mon, 17 Sep 2001, Per Bothner wrote:
> Stefan Gybas wrote:
>
> > Basically yes, but IMHO this should be the decision of the local admin
> > and not of the package maintainer. How could he know ig his package
> > contains "standard" jars? This means that no package should automatically
> > put
Just to chime in, as an occasional java user (ie. "oh, this program
is in java, what do I have to figure out to run it -- oh, I can just
apt-get install these java libs") I agree - installed java packages
*should* be no less usable than installed C or Perl libraries.
Perhaps that implies that th
On Sat, Sep 15, 2001 at 08:54:19PM -0400, Andrew Pimlott wrote:
> On Thu, Sep 13, 2001 at 08:55:04PM +1000, jeff wrote:
> > But I'll spare you that ranting; let's just say I think it's a
> > horrifically bad idea to have a free-for-all in one's classpath.
>
> I tend to agree, though I should point
Joe,
On Mon, Sep 17, 2001 at 07:13:46PM -0700, Joe Emenaker wrote:
>
> > On Mon, Sep 17, 2001 at 01:40:16PM -0700, Joe Emenaker wrote:
> > My solution to the above problem is at:
> >
> > http://newgate.socialchange.net.au/~jeff/jpe/
[snip]
> The lynchpin to what I'm proposing is that narrower-s
On Mon, Sep 17, 2001 at 01:40:16PM -0700, Joe Emenaker wrote:
> > Why not just put the jars in /usr/share/java, keep the system classpath
> > completely clean, and let the startup scripts for individual apps choose
> which
> > to include?
>
> Well, keep in mind that the original e-mail that starte
Hi
I'll try to summarize what have come up so far during the
discussion.
Naming conventions:
===
Package naming:
---
* Java programs should be named as any ordinary debian packages.
* Libraries must (?) have the name
lib[version]-java (where the version part is
On Sat, Sep 15, 2001 at 08:54:19PM -0400, Andrew Pimlott wrote:
> On Thu, Sep 13, 2001 at 08:55:04PM +1000, jeff wrote:
> > But I'll spare you that ranting; let's just say I think it's a
> > horrifically bad idea to have a free-for-all in one's classpath.
>
> I tend to agree, though I should poin
Joe,
On Mon, Sep 17, 2001 at 07:13:46PM -0700, Joe Emenaker wrote:
>
> > On Mon, Sep 17, 2001 at 01:40:16PM -0700, Joe Emenaker wrote:
> > My solution to the above problem is at:
> >
> > http://newgate.socialchange.net.au/~jeff/jpe/
[snip]
> The lynchpin to what I'm proposing is that narrower-
On Mon, Sep 17, 2001 at 01:40:16PM -0700, Joe Emenaker wrote:
> > Why not just put the jars in /usr/share/java, keep the system classpath
> > completely clean, and let the startup scripts for individual apps choose
> which
> > to include?
>
> Well, keep in mind that the original e-mail that start
On Mon, Sep 17, 2001 at 11:51:10PM +0200, Stefan Gybas wrote:
> Ola Lundqvist wrote:
>
> > Yes it bothers me too. What bothers me more is that someone (I
> > do not remember who) told me that I should name my package
> > libxalan2-java instead of lib-xalan2-java.
>
>
> This was probably me. I ha
Hi
I'll try to summarize what have come up so far during the
discussion.
Naming conventions:
===
Package naming:
---
* Java programs should be named as any ordinary debian packages.
* Libraries must (?) have the name
lib[version]-java (where the version part i
On Mon, Sep 17, 2001 at 11:51:10PM +0200, Stefan Gybas wrote:
> Ola Lundqvist wrote:
>
> > Yes it bothers me too. What bothers me more is that someone (I
> > do not remember who) told me that I should name my package
> > libxalan2-java instead of lib-xalan2-java.
>
>
> This was probably me. I h
52 matches
Mail list logo
