Re: Classpath and versioned libraries for Debian-Java
On Sat, Nov 10, 2001 at 01:08:42PM +0100, Max Kellermann wrote:
> On 0, Ola Lundqvist <opal@debian.org> wrote:
> > I have now read this. Not very much of a documentation so I have some
> > questions... :)
> >
> > The Class-Path:-thing. Is it per Name: (class) or per jar-file?
>
>
> What exactly do you mean with "Name: (class)" ?
>
>
> > > This whole thing seems to me very broken, like an idea of sales guys. It's
> >
> > s/me very broken/be an applet thing/;
>
>
> True, for applets this might be a tolerable idea :-)
>
> Sometimes I think Sun forgets about all the people who write Java application, while they are hyping applets, servlets, J2EE etc. Does anyone still remember Jini? What has happened to that "revolution"?
>
>
> > * NO directories in the Class-Path: statement. Just the jar-file.
> > Every jar must be in /usr/share/java so that should not be a problem.
> >
> > The jar name should be the one that it really depends on. We have a
> > problem here that we can not say things like.
> > Class-Path: xerces.jar (>= 1.0.3).
> >
> > So we should do like Class-Path: xerces-1.jar
>
>
> No Class-Path at all whenever possible.. remember the example that Xalan2 provides a Xalan1-compatibility layer - it Xalan2 must be included, we can satisfy all Xalan1-dependencies with that library (with lower precedence). Not possible with Class-Path because the JVM adds the Classpath, not us.
>
Ok, but what will happen to the applet-developers? Will it work anyway?
> > * The deb maintaner have to be the one responsible for the information
> > in the mainfest file. We should of course use information provided
> > by the upstream developer but the maintainer have to make sure that
> > it follows the policy.
>
>
> This only applies if we decide to use the manifest file. If we don't use it, we try not to care about it.
>
>
> > Not too paranoid. But is this solvable at all? To me it seems unsolvable
> > so let us not adress this too much. The alternative is to say:
> > This kind of stuff does not work, so let us not even try (at program start).
>
>
> It is solvable. There may be applications which can't be started because dependencies cannot be met without producing conflicts. Well, nice that Debian tells me before I lose my data. If the dependency checker is wrong, it's either a bug in the dependency checker or the package maintainer filled out wrong infor - both can be fixed. The gray zone where the application runs fine, but the dependency checker forbids, well, maybe the application works, but it is totally undefined. We have to work towards fine grained dependencies where 'generate_classpath' has much power to move stuff around. I believe it will work.
>
>
> > Some debhelper tools should be very nice:
> >
> > * One that reads the manifest (or some other more general database)
> > and give some dependency information.
> > * One that sign jars (and such stuff).
> > * One that fixes the manifest from some more general information.
> > * One that takes the source and generates a dependency line. It should
> > be possible. :) At least suggest some dependencies.
>
>
> I will try to write a small demonstration of my classpath generator script and JAR dependencies. Maybe that's a good point to start.
That is probably a good place to start, yes. :)
Regards,
// Ola
PS. You forgot the list again. :)
DS.
> Regards,
> Max
--
--------------------- Ola Lundqvist ---------------------------
/ opal@debian.org Björnkärrsgatan 5 A.11 \
| opal@lysator.liu.se 584 36 LINKÖPING |
| +46 (0)13-17 69 83 +46 (0)70-332 1551 |
| http://www.opal.dhs.org UIN/icq: 4912500 |
\ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 /
---------------------------------------------------------------
Reply to: