Re: Solution for CLASSPATH revisited
On Tue, 2003-04-22 at 00:17, Ola Lundqvist wrote:
> On Mon, Apr 21, 2003 at 07:25:30PM -0700, Nicos Panayides wrote:
> > After suggestions from Ola I extended the classloaded and it now works with
> > package dependencies.
> > How it works:
> > Every package has a file in /etc/debian-classloader/ with the following format:
> > classpath = /usr/share/java/xxxxx.jar ...
> > depends = package1 package2 ....
> Hmm do it resolve the jars that theese packages provide?
I believe that the build scripts should take care of that. It is fairly
trivial to write a script to fill the classpath line with all jars in
the package directory.
> It might be better to depend on jars instead of debian packages. Just a thought
The classloader doesn't know anything about packages so we could depend
on anything just as long a file exists with the name of the dependency.
> I also do not really think that this should be configuration files, or?
You are right. The files would be better under /usr/share
> If it should resolve the jars in the packages we have to change policy
> so a package only provide one variant of a jar (non conflicting with each other).
> I can think of a few such cases.
The package can have multiple files like: package-variant1
package-variant2 etc and the other packages can depend on those.
> > A class is started with: deb-java <package> <classname>
> > The classpath is the minimum needed, which avoids class and resource conflicts
> > between unrelated packages.
> > Limitations:
> > no recommends, suggests etc only depends.
> > Because of that it only emmits a warning if a package is not found.
> It would be really nice if it first resolves all the dependencies, then
> the recommendations, and then finally suggestions.
Great idea, I'll work on that during the weekend. How about this:
depends missing -> fail
recommends missing -> warning
suggests missing -> proceed as if nothing happend