This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
There is a method in the Library class, getVolumeTypes(String volumeType). But there is no way for the client to find out what are the valid volume types provided by that library. That seems to be incomplete. How the client code is supposed to find out the volume types? I suggest to add a new method: String[] getVolumeTypes() to that class, providing the missing info.
I guess you mean that getContent(String volumeType) exists. But its Javadoc already states: "Your module must have contract with a particular provider's module to be able to query it effectively." If you do not have knowledge of this specific type of library, then it is true that you cannot find the possible volume types - but getting a list of volume types would probably not help you anyway, since you would not know what any of them were. So I would close this as WONTFIX unless a compelling use case is given.
There might be a special contract, which would declare meaning of the names of the volume types? That is OK, but why are the other modules prohibited to call that method? I don't understand that. The could be a lot of use caseS for the other modules to use the content (without knowing the specific contracts). 1) lookup for certain content instances in the libraries, 2) providing some info about the lib content, 3) debugging purposes, 4) testing purposes, I think those should be enouhg of use cases. On the other hand, it should be suspicios the API itself. Why is there a method in the API, which is not possible to use? Let have a look at it. The other modules can find out what is the type of the library (getType), they can find out the name, display name, description, all that works for them. But they are not allowed to get the content of the library, why? That is supposed the main purpose of it, doesn't it?
All of the existing client use cases for libraries involve specifically one type of library, e.g. "j2se", for which the volume types are known by the caller, so getContent(type) can work. I still don't see any concrete use cases where you would need to list volume types of a library of unrecognized type. Getting the name etc. of a library can be useful to a client which wishes to present a list of choices, but still the libraries which would be displayed would be restricted to those of a certain type. The Library Manager dialog lists all libraries of all types, but it does not care about the meaning of different volumes - that is left to the library customizer panel for each type.
It's already a part of patch for the project libraries. But I am not sure if it will go to the NB 4.2 since there is no consensus about UI Spec.
But as Jesse pointed out such an API will not help you much, you will get the names of volumes but you need a contract with the provider to understand their role. For "j2se" lib you will get {"classpath","src","javadoc"} but it's up to you to give them semantics.
To the first Tomas comment: That is OK for me, unless some other issues, related to this, show up. To the second: Yes, that is fine with me, how to interpret the "classpath", "src" or "javadoc" etc. Or, to have the API more complete, you could also define constants for the standard volume types like those mentioned above, for the cases when the contract is needed.
This old bug may not be relevant anymore. If you can still reproduce it in 8.2 development builds please reopen this issue. Thanks for your cooperation, NetBeans IDE 8.2 Release Boss