Re: Solution for CLASSPATH

[Nicos Panayides <anarxia@gmx.net>]

On Sun, 2003-04-20 at 09:37, Ola Lundqvist wrote:
> > It is arbitrary (the ordering depends on the order java.Files.getFiles()
> > returns filenames. That is why classes should have a unique name (this
> > is the case for most packages, if not all) and it has the same effect as
> > adding everything in the classpath.
> 
> That will be a problem. I have been hit by it several times when
> packaging bigger applications. The idea is good though. I just want
> it extended with the possibility of it using the package
> dependencies or a similar dep-tree. See one of the wishlist bugs against
> java-common.
> 
The current implementation hardcodes a property filename and it was just
a draft to get feedback. A possible solution would be to have a
directory with a properties file for each package. Example:

package.properties:
main = org.someorg.application.Main
classpath = /usr/share/java/package.jar or
/usr/share/package/dir_with_many_jars/
depends = package2 package3 ...

package2.properties:
main = package.Main
classpath = /usr/share/java/package2.jar
depends = .....

The classloader can take as an argument the name of the package that will be "run"
and recursively add the dependencies. This is only done once during the classloader initialization 
(so there is no significant performance penalty), and IMHO it is as close to package dependencies 
as it can get. What do you think?

Nicos