Projects should only list the license(s) that applies to the project
            and not the licenses that apply to dependencies.
            If multiple licenses are listed, it is assumed that the user can select
            any of them, not that they must accept all.
            ]]>
          </description>
          <association>
            <type>License</type>
            <multiplicity>*</multiplicity>

  <artifactId>parent</artifactId>
  <version>0.1</version>
  <packaging>pom</packaging>

  <name>Maven Integration Test :: MNG-4102</name>
  <description>
    Verify that the effective value of an inherited property reflects the values of any nested property
    as defined by the child. This boils down to the order of inheritance and (parent) interpolation.
  </description>

  <properties>
    <overridden>PARENT</overridden>

  <version>0.1</version>
  <packaging>jar</packaging>

  <name>Maven Integration Test :: MNG-4102 :: Child</name>
  <description>
    Verify that the effective value of an inherited property reflects the values of any nested property
    as defined by the child. This boils down to the order of inheritance and (parent) interpolation.
  </description>

  <properties>
    <overridden>CHILD</overridden>
  </properties>

    27.0, depends on
    listenablefuture-9999.0-empty-to-avoid-conflict-with-guava. The 9999.0-...
    version number is enough for some build systems (notably, Gradle) to select
    that empty artifact over the "real" listenablefuture-1.0 -- avoiding a
    conflict with the copy of ListenableFuture in guava itself. If users are
    using an older version of Guava or a build system other than Gradle, they

          <sourcepath>doesnotexist</sourcepath>
          <!-- Note that we do need to build Javadoc for *some* class. Otherwise, we get an empty Javadoc jar, which the Sonatype repository manager rejects. To avoid that, we've introduced a dummy class. But we made it package-private so that no one can depend on it. That in turn forced us to configure Javadoc to show package-private APIs. -->
          <show>package</show>

    27.0, depends on
    listenablefuture-9999.0-empty-to-avoid-conflict-with-guava. The 9999.0-...
    version number is enough for some build systems (notably, Gradle) to select
    that empty artifact over the "real" listenablefuture-1.0 -- avoiding a
    conflict with the copy of ListenableFuture in guava itself. If users are
    using an older version of Guava or a build system other than Gradle, they

  <artifactId>parent</artifactId>
  <version>0.1</version>
  <packaging>pom</packaging>

  <name>Maven Integration Test :: MNG-4102</name>
  <description>
    Verify that the effective value of an inherited property reflects the values of any nested property
    as defined by the child. This boils down to the order of inheritance and (parent) interpolation.
  </description>

  <properties>
    <overridden>PARENT</overridden>

  <version>0.1</version>
  <packaging>jar</packaging>

  <name>Maven Integration Test :: MNG-4102 :: Child</name>
  <description>
    Verify that the effective value of an inherited property reflects the values of any nested property
    as defined by the child. This boils down to the order of inheritance and (parent) interpolation.
  </description>

  <properties>
    <overridden>CHILD</overridden>
  </properties>