<version>0.1</version>
  <packaging>pom</packaging>

  <name>Maven Integration Test :: MNG-3916</name>
  <description>
    Test that plugin executions are properly merged during inheritance, even if the child plugin section has no
    version.
  </description>

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.its.plugins</groupId>
        <artifactId>maven-it-plugin-a</artifactId>

    <version>0.1</version>
  </parent>

  <artifactId>child</artifactId>

  <name>Maven Integration Test :: MNG-3943</name>
  <description>
    Test that plugin executions are properly merged during inheritance, even if the child uses a different
    plugin version than the parent.
  </description>

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.its.plugins</groupId>

    stem from Plexus Classworlds originally.
    <p><i>Notice:</i> this documentation is generated from a Modello model but the code executed is not generated
    from this descriptor. Please report if you find anything wrong.</p>
  ]]></description>
  <defaults>
    <default>
      <key>package</key>
      <value>extension descriptor XML documentation (no java generation)</value><!-- intentionally non-buildable value -->

    <classWorldsVersion>1.3</classWorldsVersion>
    <commonsCliVersion>1.0</commonsCliVersion>
    <!--

    Do not update this, Doxia will be decoupled completely from 3.x and someone can
    create a rendering engine for it if they like when the release stabilizes. JVZ

    -->
    <doxiaVersion>1.0-alpha-9</doxiaVersion>
    <easyMockVersion>1.2_Java1.3</easyMockVersion>
    <junitVersion>4.13.1</junitVersion>

    <classWorldsVersion>1.3</classWorldsVersion>
    <commonsCliVersion>1.0</commonsCliVersion>
    <!--

    Do not update this, Doxia will be decoupled completely from 3.x and someone can
    create a rendering engine for it if they like when the release stabilizes. JVZ

    -->
    <doxiaVersion>1.0-alpha-9</doxiaVersion>
    <easyMockVersion>1.2_Java1.3</easyMockVersion>
    <junitVersion>4.13.1</junitVersion>

    without any of its other classes -- but is also available in a second
    "version" that omits the class to avoid conflicts with the copy in Guava
    itself. The idea is:

    - If users want only ListenableFuture, they depend on listenablefuture-1.0.

    - If users want all of Guava, they depend on guava, which, as of Guava
    27.0, depends on
    listenablefuture-9999.0-empty-to-avoid-conflict-with-guava. The 9999.0-...

   |
   | Default: ${user.home}/.m2/repository
  <localRepository>/path/to/local/repo</localRepository>
  -->

  <!-- interactiveMode
   | This will determine whether maven prompts you when it needs input. If set to false,
   | maven will use a sensible default value, perhaps based on some other setting, for
   | the parameter in question.
   |
   | Default: true
  <interactiveMode>true</interactiveMode>
  -->

            lines could make c.g.c.base.testModule transitively inherit from extra modules. If some
            of those modules are ones that it uses but forgets to list in its own <inherits>, we'd
            like to get an error. Currently we do, but if we add the extra <inherits> lines, we
            won't.

            I have one idea for a better approach, but it's painful, and I haven't tested it: We

    tests, either. This causes it to fail to find AtomicLongMapTest.

    Our workaround is to tell GWT that util.concurrent and all other packages
    have prod supersource, even if they have none. GWT is happy to ignore us
    when we specify a nonexistent path.

    (I hope that this workaround does not cause its own problems in the future.)
-->
<super-source path="super"/>

    tests, either. This causes it to fail to find AtomicLongMapTest.

    Our workaround is to tell GWT that util.concurrent and all other packages
    have prod supersource, even if they have none. GWT is happy to ignore us
    when we specify a nonexistent path.

    (I hope that this workaround does not cause its own problems in the future.)
-->
<super-source path="super"/>