</association>
        </field>
      </fields>
      <comment>We could probably have a specific element for a dev mailing list for things like CI,
        and maybe even a specific element for the user and scm mailing lists. Then leave the more
        lose structure for any other type of mailing list.</comment>
      <codeSegments>
        <codeSegment>
          <version>4.0.0+</version>

          </description>
        </field>
      </fields>
      <codeSegments>
        <codeSegment>
          <version>1.2.0+</version>
          <comment>Generated hashCode() and equals() based on identifier also calls its super, which breaks comparison
          </comment>
          <code>
            <![CDATA[
    /**
     * Computes a hash value based on {@link #getType()} and {@link #getProvides()} values.
     */

            <type>Repository</type>
            <multiplicity>*</multiplicity>
          </association>
          <comment>
            This may be removed or relocated in the near
            future. It is undecided whether plugins really need a remote
            repository set of their own.
          </comment>
        </field>
        <field xdoc.separator="blank">
          <name>profiles</name>

      <name>Plugin</name>
      <version>1.0.0+</version>
      <description>Mapping information for a single plugin within this group.</description>
      <comment>NOTE: plugin version is _NOT_ included here, since it is resolved using a separate algorithm in plugins' artifact.</comment>
      <fields>
        <field>
          <name>name</name>
          <type>String</type>
          <required>true</required>