java - 개미와 메이븐 사이의 차이




maven-2 ant build-management (9)

Ant를 본 적이없는 사람을 데리고 갈 수 있습니다. build.xml 은 합리적으로 잘 작성되어 있습니다. 그리고 그들은 무슨 일이 일어나고 있는지 이해할 수 있습니다. 나는 같은 사람을 데려와 Maven POM을 보여줄 수 있으며, 어떤 일이 벌어지고 있는지 전혀 알지 못한다.

엄청난 규모의 엔지니어링 조직에서는 앤트 파일이 커지고 관리하기 어려워지는 것에 대해 사람들이 글을 씁니다. 필자는 이러한 유형을 작성하고 Ant 스크립트를 정리했다. 정말 앞으로해야 할 일을 이해하고 3 년 이상 변화와 규모에 대응할 수있는 템플릿 세트를 설계해야합니다.

간단한 프로젝트가 아니라면, Maven 규칙과 Maven 방식을 익히는 것에 대해 배우는 것은 상당한 작업입니다.

결국 Ant 또는 Maven 프로젝트 시작을 고려할 수 없습니다. 실제로 총 소유 비용입니다. 조직이 수년에 걸쳐 구축 시스템을 유지 관리하고 확장하는 데 필요한 것은 고려해야 할 주요 요소 중 하나입니다.

빌드 시스템의 가장 중요한 측면은 빌드 레서피를 표현할 때 종속성 관리와 유연성입니다. 잘되었을 때 다소 직관적이어야합니다.

누군가가 Ant와 Maven의 차이점을 말해 줄 수 있습니까? 나는 결코 사용하지 않았다. Java 프로젝트를 자동화하는 데 사용된다는 것을 알고 있지만 어디서부터 시작해야할지 모르겠습니다.


Maven은 프레임 워크이며, Ant는 도구 상자입니다.

Maven은 사전 제작 된 도로 차량이며 Ant는 자동차 부품 세트입니다. Ant를 사용하면 자신 만의 자동차를 만들어야하지만, 적어도 오프로드 주행을해야하는 경우 올바른 유형의 자동차를 만들 수 있습니다.

달리 말하면 Maven은 프레임 워크이고 Ant는 도구 상자입니다. 프레임 워크 범위 내에서 작업하는 것에 만족한다면 Maven은 정상적으로 작동합니다. 저를위한 문제는 나가기구의 경계로 부딪 치는 유지하고 저를 밖으로시키지 않을 것입니다이었다.

XML 상세 표시

tobrien은 Maven에 대해 많이 알고있는 사람이며 두 제품에 대해 매우 훌륭하고 정직한 비교를 제공했다고 생각합니다. 그는 단순한 Maven pom.xml과 간단한 Ant 빌드 파일을 비교했으며, Maven 프로젝트가 더욱 복잡해질 수 있음을 언급했습니다. 단순한 실제 프로젝트에서 볼 수있는 파일 몇 개를 비교해 볼 가치가 있다고 생각합니다. 아래의 파일은 다중 모듈 빌드에서 단일 모듈을 나타냅니다.

먼저 메이븐 파일 :

<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-4_0_0.xsd">

    <parent>
        <groupId>com.mycompany</groupId>
        <artifactId>app-parent</artifactId>
        <version>1.0</version>
    </parent>

    <modelVersion>4.0.0</modelVersion>
    <artifactId>persist</artifactId>
    <name>Persistence Layer</name>

    <dependencies>

        <dependency>
            <groupId>com.mycompany</groupId>
            <artifactId>common</artifactId>
            <scope>compile</scope>
            <version>${project.version}</version>
        </dependency>

        <dependency>
            <groupId>com.mycompany</groupId>
            <artifactId>domain</artifactId>
            <scope>provided</scope>
            <version>${project.version}</version>
        </dependency>

        <dependency>
            <groupId>org.hibernate</groupId>
            <artifactId>hibernate</artifactId>
            <version>${hibernate.version}</version>
            <scope>provided</scope>
        </dependency>

        <dependency>
            <groupId>commons-lang</groupId>
            <artifactId>commons-lang</artifactId>
            <version>${commons-lang.version}</version>
            <scope>provided</scope>
        </dependency>

        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring</artifactId>
            <version>${spring.version}</version>
            <scope>provided</scope>
        </dependency>

        <dependency>
            <groupId>org.dbunit</groupId>
            <artifactId>dbunit</artifactId>
            <version>2.2.3</version>
            <scope>test</scope>
        </dependency>

        <dependency>
            <groupId>org.testng</groupId>
            <artifactId>testng</artifactId>
            <version>${testng.version}</version>
            <scope>test</scope>
            <classifier>jdk15</classifier>
        </dependency>

        <dependency>
            <groupId>commons-dbcp</groupId>
            <artifactId>commons-dbcp</artifactId>
            <version>${commons-dbcp.version}</version>
            <scope>test</scope>
        </dependency>

        <dependency>
            <groupId>com.oracle</groupId>
            <artifactId>ojdbc</artifactId>
            <version>${oracle-jdbc.version}</version>
            <scope>test</scope>
        </dependency>

        <dependency>
            <groupId>org.easymock</groupId>
            <artifactId>easymock</artifactId>
            <version>${easymock.version}</version>
            <scope>test</scope>
        </dependency>

    </dependencies>

</project>

그리고 동등한 Ant 파일 :

<project name="persist" >

    <import file="../build/common-build.xml" />


    <path id="compile.classpath.main">
        <pathelement location="${common.jar}" />
        <pathelement location="${domain.jar}" />
        <pathelement location="${hibernate.jar}" />
        <pathelement location="${commons-lang.jar}" />
        <pathelement location="${spring.jar}" />
    </path>


    <path id="compile.classpath.test">
        <pathelement location="${classes.dir.main}" />
        <pathelement location="${testng.jar}" />
        <pathelement location="${dbunit.jar}" />
        <pathelement location="${easymock.jar}" />
        <pathelement location="${commons-dbcp.jar}" />
        <pathelement location="${oracle-jdbc.jar}" />
        <path refid="compile.classpath.main" />
    </path>


    <path id="runtime.classpath.test">
        <pathelement location="${classes.dir.test}" />
        <path refid="compile.classpath.test" />
    </path>


</project>

tobrien은 Maven에 내장 된 규칙이 있음을 보여주기 위해 그의 예를 사용했으나 반드시 XML을 적게 쓰는 것은 아닙니다. 나는 그 반대가 사실임을 발견했다. pom.xml은 build.xml보다 3 배 길고 관례에서 벗어나지 않습니다. 실제로, Maven 예제는 플러그인을 구성하는 데 필요한 추가 54 줄을 사용하지 않고 표시됩니다. 그 pom.xml은 간단한 프로젝트를위한 것입니다. 추가 요구 사항을 추가하기 시작하면 XML이 크게 증가하기 시작합니다. 이는 많은 프로젝트에서 비정상적으로 발생하는 것은 아닙니다.

하지만 Ant에게 무엇을해야하는지 말해야합니다.

위의 Ant 예제는 완전하지 않습니다. 우리는 여전히 정리, 컴파일, 테스트 등에 사용되는 타겟을 정의해야합니다. 이는 다중 모듈 프로젝트의 모든 모듈에서 가져 오는 공통 빌드 파일에 정의됩니다. 이 점은 Maven에서 선언적인데 반해이 모든 것들이 Ant에 명시 적으로 작성되어야한다는 점에 이르게합니다.

사실,이 앤트 타겟을 명시 적으로 작성할 필요가 없다면 시간을 절약 할 수 있습니다. 하지만 얼마나 걸리나요? 내가 지금 사용하고있는 공통 빌드 파일은 5 년 전부터 약간의 개선만으로 작성한 파일입니다. 메이븐 (Maven)과 2 년 동안 실험을 해본 결과 오래된 앤트 (Ant) 파일을 벽장에서 꺼내어 먼지를 털어 내고 다시 작동시켜 보았습니다. 필자에게 Ant에게해야 할 일을 명시 적으로 알리는 데 드는 비용은 5 년 동안 1 주일 미만으로 증가했습니다.

복잡성

다음으로 언급하고자하는 차이점은 복잡성과 실제 효과입니다. Maven은 빌드 프로세스를 생성하고 관리하는 개발자의 작업 부하를 줄이기 위해 개발되었습니다. 이를 위해서는 복잡해야합니다. 불행히도 그 복잡성은 의도 된 목표를 부정하는 경향이 있습니다.

Ant와 비교할 때, Maven 프로젝트의 빌드 녀석은 더 많은 시간을 보낼 것입니다 :

  • 문서 읽기 : Maven에는 훨씬 더 많은 것을 배울 필요가 있기 때문에 훨씬 더 많은 문서가 있습니다.
  • 팀원 교육 : 그들은 대답을 스스로 찾으려고하기보다는 아는 사람에게 쉽게 물어볼 수 있습니다.
  • 빌드 문제 해결 : Maven은 Ant, 특히 비 핵심 플러그인보다 안정성이 낮습니다. 또한 Maven 빌드는 반복 할 수 없습니다. 플러그인의 SNAPSHOT 버전을 사용하는 경우 가능성이 있습니다. 변경 사항이 없으면 빌드가 중단 될 수 있습니다.
  • Maven 플러그인 작성 : 플러그인은 일반적으로 특정 작업을 염두에두고 작성됩니다. 예를 들어 Webstart 번들을 작성하면 다른 작업에 재사용하거나 목표를 달성하는 데 더 어려워집니다. 따라서 기존 플러그인 세트에서 해결 방법 격차를 줄이기 위해 직접 작성해야 할 수도 있습니다.

대조적으로 :

  • 개미 문서는 간결하고 포괄적이며 한 곳에서 모두 제공됩니다.
  • 개미는 간단합니다. Ant를 배우려고하는 새로운 개발자는 알아야 할 나머지 부분을 파악할 수 있도록 몇 가지 간단한 개념 (대상, 작업, 종속성, 속성)을 이해해야합니다.
  • 개미는 믿을만합니다. 이미 작동하기 때문에 지난 몇 년 동안 개미가 많이 출시되지 않았습니다.
  • Ant 저장소는 일반적으로 온라인 저장소, 실험용 타사 플러그인 등의 외부 종속성없이 만들어지기 때문에 반복 가능합니다.
  • 개미는 포괄적입니다. 도구 상자이기 때문에 도구를 결합하여 원하는 거의 모든 작업을 수행 할 수 있습니다. 자신 만의 맞춤 작업을 작성해야하는 경우 매우 간단합니다.

정통

또 다른 차이점은 친숙 함의 차이입니다. 새로운 개발자는 항상 속도를 낼 시간이 필요합니다. 기존 제품에 익숙해지면 Maven의 지지자는 Maven의 이점이라고 주장합니다. 물론 Ant의 유연성은 원하는 컨벤션을 만들 수 있음을 의미합니다. 그래서 내가 사용하는 규칙은 내 소스 파일을 src / main / java 디렉토리 이름에 넣는 것이다. 컴파일 된 클래스는 target / classes 디렉토리에 저장됩니다. 익숙한 소리가 아닙니다.

나는 Maven에서 사용하는 디렉토리 구조를 좋아한다. 나는 그것이 합리적이라고 생각한다. 또한 빌드 수명주기. 그래서 저는 Ant 빌드에서 동일한 규칙을 사용합니다. 그것은 단지 의미가 있기 때문에가 아니라 Maven을 사용 해본 사람이라면 익숙 할 것이기 때문입니다.


단지 몇 가지 차이점을 나열하기 만하면됩니다.

  • 개미에는 공식적인 규칙이 없습니다. 앤트에게 어디서 소스를 찾을 것인지, 출력을 넣을 곳 등을 정확히 알려줘야한다.
  • 개미는 절차 적입니다. Ant에게 정확히 무엇을해야하는지 알려줘야합니다. 컴파일, 복사, 압축 등을 지시하십시오.
  • 개미에는 라이프 사이클이 없습니다.
  • Maven은 규칙을 사용합니다. 이 규약을 따르면 소스 코드가 자동으로 어디 있는지 알 수 있습니다. Maven이 어디에 있는지 말할 필요가 없습니다.
  • Maven은 선언적입니다. pom.xml 파일을 만들고 소스를 기본 디렉토리에 저장하기 만하면됩니다. Maven이 나머지를 처리합니다.
  • Maven에는 수명주기가 있습니다. mvn install을 호출하면 일련의 시퀀스 단계가 실행됩니다.
  • Maven은 일반적인 프로젝트 작업에 대한 정보를 가지고 있습니다. 테스트를 실행하려면 파일이 기본 위치에 있으면 mvn test를 실행하십시오. Ant에서는 먼저 JUnit JAR 파일을 가지고 다음 JUnit JAR을 포함하는 클래스 경로를 만든 다음 Ant에 테스트 소스 코드를 찾아야하는지 알려주고 테스트 소스를 컴파일하는 목표를 작성한 다음 마지막으로 유닛 테스트를 실행합니다 JUnit과

최신 정보:

이것은 Maven : The Definitive Guide 에서 나왔습니다. 미안, 나는 그것을 인용하는 것을 완전히 잊었다.


나는 그것이 프로젝트의 크기에 달려 있다고 말할 것입니다. 개인적으로, 나는 간단한 컴파일, 패키징 및 배포가 필요한 간단한 프로젝트에 Maven을 사용할 것입니다. 마자 당신이 더 복잡한 것들 (많은 의존성, 매핑 파일 만들기 ...)을 할 필요가있을 때, 나는 개미로 전환 할 것입니다 ...


개미는 주로 빌드 도구입니다.

메이븐 (Maven)은 프로젝트 및 의존성 관리 도구입니다 (물론 프로젝트를 빌드합니다).

Ant + Ivy 는 Maven을 피하고 싶다면 꽤 좋은 조합입니다.


메이븐 (Maven)은 또한 일반적으로 사용되는 오픈 소스 프로젝트의 대규모 저장소를 제공합니다. 빌드하는 동안 Maven은 의존성을 다운로드 할 수 있습니다. (의존성 의존성은 물론 :))이 프로젝트를 좀 더 쉽게 관리 할 수 ​​있도록합니다.


Maven은 의존성 관리 도구로 작동합니다. 중앙 저장소 또는 설정 한 저장소에서 jar를 검색하고 선언적 빌드 도구로 jar를 검색하는 데 사용할 수 있습니다. "선언적"빌드 도구와 ant 또는 make와 같은보다 전통적인 도구의 차이점은 수행 방법이 아니라 수행해야 할 것을 구성하는 것입니다. 예를 들어, 프로젝트를 WAR 파일로 패키지화해야한다는 maven 스크립트에서 maven이이를 처리하는 방법을 알고 있다고 말할 수 있습니다.

Maven은 "declarativeness"를 달성하기 위해 프로젝트 디렉토리가 어떻게 배치되는지에 대한 관습에 의존합니다. 예를 들어, 주 코드를 넣을 곳, web.xml을 넣을 위치, 단위 테스트 등을 규정하고 있지만 필요할 경우 변경할 수있는 기능을 제공합니다.

또한 maven 내에서 ant 명령을 실행하기위한 플러그인이 있음을 명심해야합니다.

http://maven.apache.org/plugins/maven-ant-plugin/

또한, Maven의 아키 타입은 프로젝트를 매우 빠르게 시작합니다. 예를 들어 Wicket archetype이 있습니다.이 명령은 실행 준비가 된 전체 hello world-type 프로젝트를 실행하기 위해 실행하는 maven 명령을 제공합니다.

https://wicket.apache.org/start/quickstart.html


메이븐이나 개미? 이 질문과 매우 비슷한 질문입니다. 귀하의 질문에 대답하는 데 도움이됩니다.

메이븐 무엇입니까? 공식 사이트에서.

편집 : 새로운 / greenfield 프로젝트의 경우 Maven을 사용하는 것이 좋습니다. "컨벤션 오버 컨벤션"은 작성 및 배포 스크립트 설정에 상당한 시간을 절약 해줍니다. 개미를 사용하면 빌드 스크립트는 시간이지나면서 길고 복잡 해지는 경향이 있습니다. 기존 프로젝트의 경우 Maven 시스템에 구성 / 레이아웃을 구형 화하는 것이 어려울 수 있습니다.


명령 줄 자체에서 원하는 경우. 프로젝트 경로에서 아래 명령을 실행하기 만하면됩니다.

mvn 어셈블리 : 어셈블리





java maven-2 ant build-management