Ricardo Wurmus writes: > Chris Marusich writes: > >>> Jar files can be told to import classes from another Jar by adding it to >>> the “Class-Path” field of the Jar’s manifest. >>> >>> Here’s an example: >>> https://docs.oracle.com/javase/tutorial/deployment/jar/downman.html >> >> I didn't know this! That's awesome; it might be just what we need. > […] > > Thanks for testing this! > > One limitation appears to be that this only works for applications, not > for libraries. In what way does this not work for libraries? I'm not criticizing you; I'm genuinely curious. To ask this question another way: how would a solution that "works for libraries" behave, exactly? I'm not sure what the phrase "it works for libraries" might mean, since I suspect its meaning varies depending on what one is trying to accomplish. > This could be a problem for us. We don’t really need this urgently > for applications if we automatically generate shell wrappers (as we do > for Python executables). > I agree. > It would be interesting to know if this could be used for libraries as > well, so that the application in the end does not need to know about all > transitive dependencies, but only its first-level dependencies. I think there are at least two concrete goals here. I would phrase them as follows: 1) I can run Java applications (built with Guix). 2) I can use Java libraries (built with Guix) in an IDE to develop Java applications. We can accomplish (1) by using wrapper scripts. I suppose we could also maybe accomplish (1) by using JARs with embedded classpaths, but as long as wrapper scripts are sufficient, it isn't really necessary to do this. As for (2), I think it's probably trickier, since the exact way in which an IDE might want to be informed about the dependencies of a project may vary. I'm still not sure how I would develop Java applications using Java libraries built with Guix, without putting in a lot of manual effort to tell my IDE where the dependencies live. Surely there is a way... -- Chris