On Tue, 2003-04-22 at 00:17, Ola Lundqvist wrote: > Hello > > 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 Nicos