Maven POM

카테고리 없음 2011. 1. 19. 14:18 Posted by coodnoob
POM 이란

Project Object Model 로서 메이븐에서 사용하는 프로젝트 관리를 위한 모델이다.
보통 프로젝트의 루트에 pom.xml 파일에서 관리하는데 
여기서 관리하는 내용은 현재 기본적인 프로젝트의 정보, 빌드 세팅, 부가적인 프로젝트 정보, 환경 설정등이 있다.

1. 프로젝트의 기본 정보

<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/xsd/maven-4.0.0.xsd">  <modelVersion>4.0.0</modelVersion>  <groupId>org.codehaus.mojo</groupId>  <artifactId>my-project</artifactId>  <version>1.0</version></project>

여기서는 현재 프로젝트에 대한 기본적인 정보들을 기술한다.

엘리먼트 소개
<groupId> : groupId는 일반적으로 유니크한 값을 사용한다. 이것의 이름은 레포지토리의 폴더에 영향을 미치게된다.
<artifactId> : artifactId는 프로젝트의 잘 알려진 이름을 적는다. groupId와 함께 프로젝트를 유니크하게 할 수 있는 값이다.
<version> : version은 현재 버전을 말하는데 groupId, artifactId와 함께 레포지토리의 디렉토리를 구축하는데 같이 쓰인다.
예를들면 로컬레포지터리에 groupId\artifactId\version 이런식으로 폴더가 구성된다. groupId에 . 가 들어가면 그 해당 앞뒤 단어도 각각 다른 폴더로 지정된다.
<packaging> : packaging은 현재 프로젝트의 배포할 타입 포맷을 지정한다. 디폴트는 jar이다.

2. 디펜던시 관리

<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/xsd/maven-4.0.0.xsd"> ... <dependencies> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>4.0</version> <type>jar</type> <scope>test</scope> <optional>true</optional> </dependency> ... </dependencies> ...</project>

groupId와 artifactId와 version은 위에서 설명한 내용과 같다.
<type> artifact의 패키지된 타입을 기술한다.
<scope> scope는 작업상태(compiling and runtime, testing, etc)의 클래스패스와 관련되어 있을 뿐만 아니라 디펜던시의 이행성을 얼마만큼 허용할 것인가를 관리한다.
  • compile - this is the default scope, used if none is specified. Compile dependencies are available in all classpaths. Furthermore, those dependencies are propagated to dependent projects.
  • provided - this is much like compile, but indicates you expect the JDK or a container to provide it at runtime. It is only available on the compilation and test classpath, and is not transitive.
  • runtime - this scope indicates that the dependency is not required for compilation, but is for execution. It is in the runtime and test classpaths, but not the compile classpath.
  • test - this scope indicates that the dependency is not required for normal use of the application, and is only available for the test compilation and execution phases.
  • system - this scope is similar to provided except that you have to provide the JAR which contains it explicitly. The artifact is always available and is not looked up in a repository.

  • <exclusions> exclusions 엘리먼트는 해당 모듈을 제외할 때 사용된다.

    <dependencies>
        <dependency>      <groupId>org.apache.maven</groupId>      <artifactId>maven-embedder</artifactId>      <version>2.0</version>      <exclusions>
            <exclusion>          <groupId>org.apache.maven</groupId>          <artifactId>maven-core</artifactId>        </exclusion>
    </exclusions> </dependency>
    <Parent pom.xml>

    Inheritance
    메이븐은 상속기능을 제공한다.
    상속을 사용하기 위해서는 부모프로젝트의 packaging type은 pom이여야 한다.
    이 패키징 타입들은 라이프사이클의 한부분인 goals을 지정할 때 쓰인다. 예를 들어 패키징 타입이 jar면 패키징 단계의 goals은 jar:jar가 된다.
    패키징이 pom 이라면 site:attach-descriptor 가 된다.
    부모의 엘리먼트들은 자식 엘리먼트들이 상속한다.

    <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/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <parent> <groupId>org.codehaus.mojo</groupId> <artifactId>my-parent</artifactId> <version>2.0</version> <relativePath>../my-parent</relativePath> </parent> <artifactId>my-project</artifactId></project>
    <child pom.xml>

    위와 같이 <parent> 엘리먼트를 이용하여 상속 할 대상을 정의할 수 있다.
    <relativePath> 엘리먼트는 필요하지는 않지만 현재 프로젝트의 부모 프로젝트의 경로를 처음으로 검색 할 때 이용된다. 그 다음에 로컬레포지토리와 원격 레포지토리를 
    검색한다.

    The Super POM

    OOP의 객체상속과 비슷하게, POM들은 parent의 값들을 상속을 이용하여 확장할 수 있다. 게다가 자바의 모든 오브젝트가 java.lang.Object 를 상속 하듯이, 모든 POM은
    Super POM을 기본적으로 상속한다.

    mvn help:effective-pom

    이렇게 타이핑 하면 SuperPom이 당신이 만든 프로젝트에서 암묵적으로 쓰인 부분을 확인 할 수 있다.
    프로젝트의 pom.xml파일이 있는 곳에서 해야한다.

    Aggregation(or Multi-Module)
    위와 같이 inherit을 이용하는 다른 모듈과의 관계를 aggregation으로 나타 낼 수 도 있다.
    <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/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>org.codehaus.mojo</groupId> <artifactId>my-parent</artifactId> <version>2.0</version> <packaging>pom</packaging> <modules> <module>my-project</module> <module>another-project</module> </modules></project>
    <최상위 pom.xml>
    이 때 패키징 엘리먼트 역시 pom이고
    <modules> 에서 관련된 하위 모듈을 기술한다.
    하위 모듈들에서는 상속에서와 마찬가지로 <parent> 엘리먼트를 이용하여 최상위 모듈을 지정 할 수 있다.

    3. Build Settings
    위에서 주어진 폼의 기본 뿐만 아니라 알 필요가 있는 엘리먼트 들이 더 있다.
    프로젝트의 디렉토리 구조를 선언하고 플러그인을 관리할 수 있는 build 엘리먼트와 reporting을 하기위한 reporting 엘리먼트이다.

    Build
    POM4.0.0 XSD에 의하면 <build> 엘리먼트는 개념적으로 두가지로 나뉜다. 하나는 <project> 밑에서 사용되는 거고 또 다른 하나는 <profiles> 밑에서 사용 하는 것이다.

    <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/xsd/maven-4.0.0.xsd"> ... <!-- "Project Build" contains more elements than just the BaseBuild set --> <build>...</build> <profiles> <profile> <!-- "Profile Build" contains a subset of "Project Build"s elements --> <build>...</build> </profile> </profiles></project>

    BaseBuild Element Set
    BaseBuild 는 그 단어 뜻 그대로 <build> 엘리먼트 안에서 사용되는 기본적인 elements들이다.
    <build>  <defaultGoal>install</defaultGoal>  <directory>${basedir}/target</directory>  <finalName>${artifactId}-${version}</finalName>  <filters>    <filter>filters/filter1.properties</filter>  </filters>  ...</build>
    • defaultGoal: the default goal or phase to execute if none is given. If a goal is given, it should be defined as it is in the command line (such as jar:jar). The same goes for if a phase is defined (such as install).
    • directory: This is the directory where the build will dump its files or, in Maven parlance, the build's target. It aptly defaults to ${basedir}/target.
    • finalName: This is the name of the bundled project when it is finally built (sans the file extension, for example: my-project-1.0.jar). It defaults to ${artifactId}-${version}. The term "finalName" is kind of a misnomer, however, as plugins that build the bundled project have every right to ignore/modify this name (but they usually do not). For example, if the maven-jar-plugin is configured to give a jar a classifier of test, then the actual jar defined above will be built as my-project-1.0-test.jar.
    • filter: Defines *.properties files that contain a list of properties that apply to resources which accept their settings (covered below). In other words, the "name=value" pairs defined within the filter files replace ${name}strings within resources on build. The example above defines the filter1.properties file under the filter/ directory. Maven's default filter directory is ${basedir}/src/main/filters/.
    Resources
    build 엘리먼트의 다륵 특징은 프로젝트 내에 존재하는 리소스들을 명시 할 수 있다. 리소스는 소스코드가 아니라 컴파일 되지 않으면 다양한 이유로 프로젝트 내에 추가 되는
    그런 것들을 말한다.

    예를 들면 Plexus 프로젝트는 configuration.xml 파일을 필요로 하는데 META-INF/plexus 디렉토리의

    <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/xsd/maven-4.0.0.xsd">
     
    <build> ... <resources> <resource> <targetPath>META-INF/plexus</targetPath> <filtering>false</filtering> <directory>${basedir}/src/main/plexus</directory> <includes> <include>configuration.xml</include> </includes> <excludes> <exclude>**/*.properties</exclude> </excludes> </resource> </resources> <testResources> ... </testResources> ... </build> </project>
    • resources: is a list of resource elements that each describe what and where to include files associated with this project.
    • targetPath: Specifies the directory structure to place the set of resources from a build. Target path defaults to the base directory. A commonly specified target path for resources that will be packaged in a JAR is META-INF.
    • filtering: is true or false, denoting if filtering is to be enabled for this resource. Note, that filter *.properties files do not have to be defined for filtering to occur - resources can also use properties that are by default defined in the POM (such as ${project.version}), passed into the command line using the "-D" flag (for example, "-Dname=value") or are explicitly defined by the properties element. Filter files were covered above.
    • directory: This element's value defines where the resources are to be found. The default directory for a build is ${basedir}/src/main/resources.
    • includes: A set of files patterns which specify the files to include as resources under that specified directory, using * as a wildcard.
    • excludes: The same structure as includes, but specifies which files to ignore. In conflicts between include and excludeexclude wins.
    • testResources: The testResources element block contains testResource elements. Their definitions are similar to resource elements, but are naturally used during test phases. The one difference is that the default (Super POM defined) test resource directory for a project is ${basedir}/src/test/resources. Test resources are not deployed.
    Plugins
    <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/xsd/maven-4.0.0.xsd"> <build> ... <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-jar-plugin</artifactId> <version>2.0</version> <extensions>false</extensions> <inherited>true</inherited> <configuration> <classifier>test</classifier> </configuration> <dependencies>...</dependencies> <executions>...</executions> </plugin> </plugins> </build> </project>

    Beyond the standard coordinate of groupId:artifactId:version, there are elements which configure the plugin or this builds interaction with it.

    • extensionstrue or false, whether or not to load extensions of this plugin. It is by default false. Extensions are covered later in this document.
    • inheritedtrue or false, whether or not this plugin configuration should apply to POMs which inherit from this one.
    • configuration: This is specific to the individual plugin. Without going too in depth into the mechanics of how plugins work, suffice it to say that whatever properties that the plugin Mojo may expect (these are getters and setters in the Java Mojo bean) can be specified here. In the above example, we are setting the classifier property to test in the maven-jar-plugin's Mojo. It may be good to note that all configuration elements, wherever they are within the POM, are intended to pass values to another underlying system, such as a plugin. In other words: values within a configuration element are never explicitly required by the POM schema, but a plugin goal has every right to require configuration values.
    • dependencies: Dependencies are seen a lot within the POM, and are an element under all plugins element blocks. The dependencies have the same structure and function as under that base build. The major difference in this case is that instead of applying as dependencies of the project, they now apply as dependencies of the plugin that they are under. The power of this is to alter the dependency list of a plugin, perhaps by removing an unused runtime dependency via exclusions, or by altering the version of a required dpendency. See above under Dependencies for more information.
    • executions: It is important to keep in mind that a plugin may have multiple goals. Each goal may have a separate configuration, possibly even binding a plugin's goal to a different phase altogether. executionsconfigure the execution of a plugin's goals.
    For example, suppose you wanted to bind the antrun:run goal to the verify phase. We want the task to echo the build directory, as well as avoid passing on this configuration to its children (assuming it is a parent) by setting inherited to false. You would get an execution like this:


    <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/xsd/maven-4.0.0.xsd"> ... <build> <plugins> <plugin> <artifactId>maven-antrun-plugin</artifactId> <version>1.1</version> <executions> <execution> <id>echodir</id> <goals> <goal>run</goal> </goals> <phase>verify</phase> <inherited>false</inherited> <configuration> <tasks> <echo>Build Dir: ${project.build.directory}</echo> </tasks> </configuration> </execution> </executions> </plugin> </plugins> </build> </project>

    • id: Self explanatory. It specifies this execution block between all of the others. When the phase is run, it will be shown in the form: [plugin:goal execution: id]. In the case of this example: [antrun:run execution: echodir]
    • goals: Like all pluralized POM elements, this contains a list of singular elements. In this case, a list of plugin goals which are being specified by this execution block.
    • phase: This is the phase that the list of goals will execute in. This is a very powerful option, allowing one to bind any goal to any phase in the build lifecycle, altering the default behavior of Maven.
    • inherited: Like the inherited element above, setting this false will supress Maven from passing this execution onto its children. This element is only meaningful to parent POMs.
    • configuration: Same as above, but confines the configuration to this specific list of goals, rather than all goals under the plugin.

    4. Environment Settings

    결론 : The POM is the large, but bright, center.


    참고 한 사이트