@justintoo I noticed you listed yourself as an author of this package above. Spack now has the ability to list maintainers of a package. Would you like to be added so that you are pinged whenever a major change to the package is made?

None of these older versions are downloadable, so I removed the url_for_version function. Do we even want to keep these versions?

I'm no longer at that particular consulting gig, but I used to have the tarballs for a couple of those versions (b14 and b17, perhaps) in mirrors that were used for repeatable deployments.

I'm generally not in favor of cleaning them up (this came up in the Perl package too), it breaks things for people using mirrors and then we need to re-instate them.

Technically, this isn't perfect. If someone has multiple versions of JDK 10.0 installed, it will return the newest version.

I'm not sure if libjvm is the prototypical Java library. There is also a libjava. But I needed libjvm for another package (#8614).

I could have used conflicts for this, but if I did, you would not be able to install the package, even if it is already available as an external package.

Unfortunately, this message does not print to the terminal unless you are installing with --verbose. It will end up in your build log. See #2566.

Most of the logic in these last couple functions is stolen from the python package.

This variable should already be set by setup_dependent_environment in the jdk and icedtea packages.

If I understand, only one of (1) or (2) needs to happen to support this.

Regarding (3), is that strictly required? Do all packages which depend on java want to add their jars to spec['java'].prefix.lib.ext? This isn't how Java projects are typically exposed to the user (generally they would all be added to the classpath, which could be managed by adding a JavaPackage build system). In other words, I'm not sure if packages using Java would typically want to extend Java.

If that is still desirable, then while the lack of virtual extensions would make it hard to activate the package (by modifying the Spack Java package prefix), you could achieve this relocation for views: PackageViewMixin.view_destination/view_source may be useful here. Once those are implemented and working for views, activations should automatically work too once (1) or (2) is resolved.

I'll be looking through this more tomorrow.

(1) and (2) have nothing in common. (1) is "you can't extend virtual packages" and (2) is "you can't extend multiple packages". Although, maybe (1) is another symptom of (2)? Anyway, (2) will be really important if we ever make python a virtual package.

(3) is not strictly required. You're right, Java developers rarely suggest installing .jar files directly to lib/ext. But it does work, so if it isn't too much work, I might as well support it. I'm sure there's an easy way to do this, I just don't know how.

The main reason why packages would want to extend Java is so that they are automatically added to the CLASSPATH. I implemented things just like python did, but I guess I could add them to CLASSPATH if they have a run-time dep on Java, not only if they are extensions.

(1) and (2) have nothing in common. (1) is "you can't extend virtual packages" and (2) is "you can't extend multiple packages"

What I mean is: if you could extend multiple packages, my understanding is you would say

extends('jdk')
extends('icedtea')

And you wouldn't need to add extends('java').

That being said, the primary benefits of marking a package as an extension of some other package is:

• The dependent can be activated in the prefix of the extendee
• You can manage centralized state (e.g. a merged .pth file for Python)

Since Java doesn't need to manage centralized state for dependents, only the first benefit would apply. As mentioned in #8613 (comment), you can implement whatever customized merging logic you want without waiting for the extension issues to be resolved.

if you could extend multiple packages, my understanding is you would say

extends('jdk')
extends('icedtea')

And you wouldn't need to add extends('java').

That won't work, as the package would now depend on both jdk and icedtea. Virtual packages exist for a reason 😆

I'm doing a bad job of inferring why you want this so I'll be direct: why is the ability to extend multiple packages important here? Could you give me an example of what you would write if this were possible?

See #987. There are already multiple packages in Spack that extend multiple languages. For example, some packages have both Python and Perl libraries.

@adamjstewart could you rewrite (3) according to #8613 (comment) (or use the wording suggested there)? The way it's worded now, it looks like something a package author could manage, but I think it will actually take some work on the core (e.g. updating PackageViewMixin to add a symlink to the jar files in lib/ext).

Other than that this looks good.

My guess is that you'd want to preserve the original install structure but to potentially add ext/lib/

I'm not sure if this is the case here. Honestly, we both agree that symlinking .jar files to ext/lib probably isn't a good idea, but if we were to support it, I would expect spack activate to only symlink .jar files to ext/lib, not anywhere else. Some PRs install them in prefix.bin, others in prefix.lib or prefix. It wouldn't make sense in my mind to symlink to the Java prefix.bin or prefix.lib directories when prefix.ext.lib is designed for this purpose.

I would expect spack activate to only symlink .jar files to ext/lib, not anywhere else.

OK fair enough. My main point though is that Package.activate wouldn't be the natural place to handle that anymore: it should be handled by adding a method to PackageViewMixin and to have YamlFilesystemView.merge check for customized Package merging behavior and use it if present, for example if a java package wants to add .jar files to ext/lib/ and also add a script to prefix.bin. Another possible way to word it:

# TODO: update YamlFilesystemView.merge to allow a Package to
# completely override how it is symlinked into a view prefix