```yaml
    usability:
      observability:
        status:
      analyzers:
        virtualservice:
```

will allow you to label a test with:

```go
    "usability.observability.status.exist-by-default"
    "usability.analyzers.virtualservice"
```

 * under the License.
 */
package org.apache.maven.usability.plugin;

import java.io.File;
import java.io.IOException;
import java.io.InputStream;
import java.net.MalformedURLException;
import java.net.URL;
import java.net.URLClassLoader;
import java.util.HashMap;
import java.util.List;
import java.util.Map;

import org.apache.maven.usability.plugin.io.xpp3.ParamdocXpp3Reader;

 * KIND, either express or implied.  See the License for the
 * specific language governing permissions and limitations
 * under the License.
 */
package org.apache.maven.usability.plugin;

/**
 * ExpressionDocumentationException
 */
@Deprecated
public class ExpressionDocumentationException extends Exception {
    static final long serialVersionUID = 1;

For Java, Groovy, Kotlin, and Android compatibility, see the [full compatibility notes](userguide/compatibility.html).   

## New features and usability improvements

<!-- Do not add breaking changes or deprecations here! Add them to the upgrade guide instead. -->

<!--

================== TEMPLATE ==============================

<a name="FILL-IN-KEY-AREA"></a>

For Java, Groovy, Kotlin, and Android compatibility, see the [full compatibility notes](userguide/compatibility.html).   

## New features and usability improvements

<!-- Do not add breaking changes or deprecations here! Add them to the upgrade guide instead. -->

<!--

================== TEMPLATE ==============================

<a name="FILL-IN-KEY-AREA"></a>

// internally and are not intended to be used outside the standard libraries,
// Therefore, we make those APIs use internal types like poll.FD or poll.String
// in their function signatures to disable the usability of these APIs from
// external codebase.

         * file dependency, with the file path pointing to the attempted component selector.
         * This shows up in the IDE as a red flag in the dependencies view. That's not the best
         * usability and it also muddies the API contract, because we disguise an unresolved
         * dependency as a file dependency, even though that file really doesn't exist.
         *

    <exportedPackage>org.apache.maven.settings</exportedPackage>
    <exportedPackage>org.apache.maven.toolchain</exportedPackage>
    <exportedPackage>org.apache.maven.usability</exportedPackage>


    <!-- wagon-api -->
    <exportedPackage>org.apache.maven.wagon.*</exportedPackage>
    <exportedPackage>org.apache.maven.wagon.authentication</exportedPackage>

              <include>org.apache.maven.rtinfo.internal</include>
              <include>org.apache.maven.settings</include>
              <include>org.apache.maven.toolchain</include>
              <include>org.apache.maven.usability</include>
            </includes>
            <!-- allowed non-binary backwards compatible changes -->
            <excludes>
              <!-- START default constructor on Plexus/JSR 330 components -->

### Picking a collection type

There are a variety of collection types available.
Picking these is about simplicity, usability, and performance.

The `NewSingleton` form (`func() *O`), in theory, could be used universally.
Consider a transformation from `Pod` to `SimplePod`:

```go