<!--

    Copyright (c) 2010, 2020 Oracle and/or its affiliates. All rights reserved.

    This program and the accompanying materials are made available under the
    terms of the Eclipse Public License v. 2.0, which is available at
    http://www.eclipse.org/legal/epl-2.0.

    This Source Code may also be made available under the following Secondary
    Licenses when the conditions for such availability set forth in the
    Eclipse Public License v. 2.0 are satisfied: GNU General Public License,
    version 2 with the GNU Classpath Exception, which is available at
    https://www.gnu.org/software/classpath/license.html.

    SPDX-License-Identifier: EPL-2.0 OR GPL-2.0 WITH Classpath-exception-2.0

-->

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">

    <modelVersion>4.0.0</modelVersion>
    <parent>
        <groupId>org.glassfish.main.persistence.cmp</groupId>
        <artifactId>cmp</artifactId>
        <version>6.0.0-SNAPSHOT</version>
    </parent>

    <artifactId>cmp-scripts</artifactId>
    <name>GlassFish cmp scripts</name>

    <!--
        The comments below were copied from the ejb-timer-databases module.  
        They are very helpful so it seemed like a good idea to leave them here also.
    -->
    <!--
      This packaging specifies that it's a package that contains files to be added to
      the distribution.

      In this packaging mode, the build will produce a jar, like it normally does for
      the <packaging>jar</packaging>, but the contents of this jar is then extracted
      when the final GlassFish distribution is assembled. (But when this happens,
      META-INF/** in the jar will be ignored.)

      For a fragment to be added to the distribution, the distribution POM needs
      to directly or indirectly depend on the fragment module. This is normally
      done by creating a feature-level grouping POM (which allows you to bundle multiple
      modules and treat it as a single dependency - see the webtier-all module for example),
      and have that declare a dependency on the fragment, instead of directly
      modifying the distribution POM.

      So the idea here is that individual technology area will create their own
      fragments that contain pieces that they need, and when the said technology
      is bundled in GF, the corresponding fragment will be also added, thanks to
      the transitive dependency handling in Maven.
    -->

    <packaging>distribution-fragment</packaging>

        <!--
         In this module, all the files are statically stored as-is in the Subversion repository,
         so the simple copying from src/main/resources to target/classes that Maven does by default
         is suffice.
   -->

</project>