Maven은 프레임 워크이고 Ant는 Toolbox입니다.
Maven은 사전 제작 된로드 카인 반면 Ant는 자동차 부품 세트입니다. Ant를 사용하면 자신의 자동차를 만들어야하지만 적어도 오프로드 주행을해야하는 경우 올바른 유형의 자동차를 만들 수 있습니다.
달리 말하면 Maven은 프레임 워크 인 반면 Ant는 도구 상자입니다. 프레임 워크의 범위 내에서 작업하는 것에 만족한다면 Maven은 잘 작동합니다. 나를위한 문제는 내가 프레임 워크의 경계에 부딪 혔고 나를 풀어 줄 수 없다는 것입니다.
XML 상세
tobrien은 Maven에 대해 많은 것을 알고있는 사람이며 두 제품에 대해 매우 훌륭하고 정직한 비교를 제공했다고 생각합니다. 그는 간단한 Maven pom.xml을 간단한 Ant 빌드 파일과 비교하여 Maven 프로젝트가 어떻게 복잡해질 수 있는지 언급했습니다. 간단한 실제 프로젝트에서 볼 수있는 몇 가지 파일을 비교해 볼 가치가 있다고 생각합니다. 아래 파일은 다중 모듈 빌드에서 단일 모듈을 나타냅니다.
먼저 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 예제는 아직 완료되지 않았습니다. 우리는 여전히 청소, 컴파일, 테스트 등에 사용되는 대상을 정의해야합니다. 이들은 다중 모듈 프로젝트의 모든 모듈이 가져 오는 공통 빌드 파일에 정의되어 있습니다. 이 모든 것들이 Ant로 명시 적으로 작성되어야하는 반면 Maven에서는 선언적이라는 점을 알려줍니다.
사실, 이러한 Ant 대상을 명시 적으로 작성할 필요가 없으면 시간을 절약 할 수 있습니다. 그러나 얼마나 많은 시간? 내가 지금 사용하는 일반적인 빌드 파일은 5 년 전에 그 이후로 약간만 수정하여 작성한 파일입니다. Maven으로 2 년 동안 실험 한 후, 오래된 Ant 빌드 파일을 옷장에서 꺼내어 먼지를 털어 다시 작동시켰다. 저에게, Ant에게해야 할 일을 명시 적으로 알려주는 데 드는 비용은 5 년 동안 일주일 이내에 추가되었습니다.
복잡성
다음으로 언급하고자하는 주요 차이점은 복잡성과 실제 효과의 차이점입니다. Maven은 빌드 프로세스 작성 및 관리 작업을 수행하는 개발자의 워크로드를 줄이기 위해 작성되었습니다. 이렇게하려면 복잡해야합니다. 불행히도 그 복잡성은 의도 된 목표를 부정하는 경향이 있습니다.
Ant와 비교할 때 Maven 프로젝트의 빌드 담당자는 더 많은 시간을 소비합니다.
- 문서 읽기 : Maven에 대해 더 많은 문서가 있습니다. 배울 것이 훨씬 더 많기 때문입니다.
- 팀원 교육 : 그들은 스스로 답을 찾으려고하지 않고 아는 사람에게 물어 보는 것이 더 쉽다는 것을 알게됩니다.
- 빌드 문제 해결 : Maven은 Ant, 특히 비 핵심 플러그인보다 안정성이 떨어집니다. 또한 Maven 빌드는 반복 할 수 없습니다. SNAPSHOT 버전의 플러그인에 의존하는 경우, 변경하지 않으면 빌드가 중단 될 수 있습니다.
- Maven 플러그인 작성 : 플러그인은 일반적으로 특정 작업을 염두에두고 작성합니다 (예 : 웹 스타트 번들 작성). 다른 작업에 재사용하거나 조합하여 목표를 달성하기가 더 어렵습니다. 따라서 기존 플러그인 세트의 임시 해결책으로 공백을 작성해야 할 수도 있습니다.
대조적으로 :
- Ant 문서는 간결하고 포괄적이며 모두 한 곳에 있습니다.
- 개미는 간단하다. Ant를 배우려는 새로운 개발자는 알아야 할 나머지 부분을 파악할 수 있도록 몇 가지 간단한 개념 (대상, 작업, 종속성, 속성) 만 이해하면됩니다.
- 개미는 믿을만하다. 지난 몇 년 동안 Ant가 이미 출시 되었기 때문에 많은 릴리스가 없었습니다.
- Ant 빌드는 일반적으로 온라인 저장소, 실험용 타사 플러그인 등과 같은 외부 종속성없이 작성되므로 반복 가능합니다.
- 개미는 포괄적입니다. 도구 상자이므로 도구를 결합하여 원하는 거의 모든 작업을 수행 할 수 있습니다. 사용자 정의 작업을 작성해야하는 경우 매우 간단합니다.
정통
또 다른 차이점은 친숙 함입니다. 새로운 개발자는 항상 속도를 내기 위해 시간이 필요합니다. 기존 제품에 익숙하면 이러한 점에서 도움이되며 Maven 지지자는 이것이 Maven의 이점이라고 올바르게 주장합니다. 물론 Ant의 유연성으로 원하는 규칙을 만들 수 있습니다. 그래서 내가 사용하는 규칙은 소스 파일을 src / main / java 디렉토리 이름에 넣는 것입니다. 컴파일 된 클래스는 target / classes라는 디렉토리로 이동합니다. 익숙하지 않은 것 같습니다.
Maven에서 사용하는 디렉토리 구조가 마음에 듭니다. 나는 그것이 의미가 있다고 생각합니다. 또한 빌드 수명주기. 따라서 Ant 빌드에서 동일한 규칙을 사용합니다. 의미가있을뿐 아니라 이전에 Maven을 사용해 본 사람에게도 친숙 할 것입니다.