programing

개미와 메이븐의 차이점

newsource 2022. 9. 29. 00:20

개미와 메이븐의 차이점

누가 앤트와 메이븐의 차이점을 말해줄 수 있나요?저도 써본 적이 없어요.Java 프로젝트 구축 자동화에 사용되는 것은 알고 있습니다만, 어디서부터 시작해야 할지 모르겠습니다.

메이븐: 'Definitional Guide'에서는 도입부에서 Maven과 Ant의 차이점에 대해 '개미와 Maven의 차이점'이라는 섹션 제목을 썼습니다.다음은 도입부의 정보와 몇 가지 추가 메모를 조합한 답변입니다.

간단한 비교

가장 기본적인 수준에서 Maven에는 기본 제공 규칙이 있다는 생각을 설명하기 위해 보여드리는 것입니다.다음은 간단한 Ant 빌드 파일입니다.

<project name="my-project" default="dist" basedir=".">
    <description>
        simple example build file
    </description>   
    <!-- set global properties for this build -->   
    <property name="src" location="src/main/java"/>
    <property name="build" location="target/classes"/>
    <property name="dist"  location="target"/>

    <target name="init">
      <!-- Create the time stamp -->
      <tstamp/>
      <!-- Create the build directory structure used by compile -->
      <mkdir dir="${build}"/>   
    </target>

    <target name="compile" depends="init"
        description="compile the source " >
      <!-- Compile the java code from ${src} into ${build} -->
      <javac srcdir="${src}" destdir="${build}"/>  
    </target>

    <target name="dist" depends="compile"
        description="generate the distribution" >
      <!-- Create the distribution directory -->
      <mkdir dir="${dist}/lib"/>

      <!-- Put everything in ${build} into the MyProject-${DSTAMP}.jar file
-->
      <jar jarfile="${dist}/lib/MyProject-${DSTAMP}.jar" basedir="${build}"/>
   </target>

   <target name="clean"
        description="clean up" >
     <!-- Delete the ${build} and ${dist} directory trees -->
     <delete dir="${build}"/>
     <delete dir="${dist}"/>
   </target>
 </project>

이 간단한 개미 예에서는 개미에게 정확히 무엇을 해야 하는지 알려주는 방법을 볼 수 있습니다.src/main/java 디렉토리의 소스를 target/classes 디렉토리로 컴파일하는 javac 태스크를 포함하는 컴파일 목표가 있습니다.Ant에게 소스의 정확한 위치, 결과 바이트 코드를 저장할 위치 및 이 모든 것을 JAR 파일로 패키지하는 방법을 알려야 합니다.Ant가 절차를 덜 밟는 데 도움이 되는 최신 개발도 있지만, 개발자는 XML로 작성된 절차 언어를 코딩하는 데 경험이 있습니다.

이전 개미 예제와 메이븐 예제를 비교합니다.Maven에서 Java 소스에서 JAR 파일을 작성하려면 간단한 pom.xml을 만들고 ${basedir}/src/main/java에 소스 코드를 배치한 후 명령줄에서 mvn install을 실행하면 됩니다.같은 결과를 얻을 수 있는 Maven pom.xml의 예.

<project>
  <modelVersion>4.0.0</modelVersion>
  <groupId>org.sonatype.mavenbook</groupId>
  <artifactId>my-project</artifactId>
  <version>1.0</version>
</project>

pom.xml에 필요한 건 그게 다야명령줄에서 mvn install을 실행하면 리소스 처리, 소스 컴파일, 유닛 테스트 실행, JAR 생성 및 다른 프로젝트에서 재사용하기 위한 로컬저장소에 JAR이 설치됩니다.수정 없이 mvn 사이트를 실행하고 JavaDoc 링크와 소스 코드에 대한 몇 가지 보고서를 포함하는 index.html 파일을 타겟/사이트에서 찾을 수 있습니다.

인정하건대, 이것은 가능한 가장 간단한 예시 프로젝트입니다.소스 코드만 포함하고 JAR을 생성하는 프로젝트입니다.Maven 규약을 따르고 종속성이나 커스터마이즈가 필요 없는 프로젝트입니다.동작을 커스터마이즈 하려면 , pom.xml 의 사이즈가 커집니다.또한 가장 큰 프로젝트에서는, 플러그 인의 커스터마이즈와 의존 선언을 많이 포함한 매우 복잡한 Maven POM 의 컬렉션을 볼 수 있습니다.그러나 프로젝트의 POM 파일이 더 실속 있게 되어도 Ant를 사용한 비슷한 크기의 프로젝트의 빌드 파일과는 전혀 다른 종류의 정보를 가지고 있습니다.Maven POM에는 "이것은 JAR 프로젝트입니다" 및 "소스 코드는 src/main/java에 있습니다"라는 선언이 포함되어 있습니다.개미 빌드 파일에는 "이것은 프로젝트", "소스가 다음 위치에 있습니다.src/main/java "", "실행"javac "를 " "에 저장", ""에 저장""target/classses 「 「 」 「 」 、 「 JAR 」 「 JAR 성."."." 」 에 대해 가 있는 , .Ant는 프로세스에 대해 명확하게 설명해야 했지만, Maven에게는 소스 코드가 어디에 있고 어떻게 처리되어야 하는지를 아는 "빌트인"이 있었습니다.

대략적인 비교

이 예에서 Ant와 Maven의 차이점은 무엇입니까?개미...

  • 일반적인 프로젝트 디렉토리 구조처럼 공식적인 규약은 없습니다.원본을 찾을 수 있는 위치와 출력을 어디에 배치해야 하는지 개미에게 정확하게 알려야 합니다.시간이 지남에 따라 비공식적인 관습이 생겨났지만, 그것들은 상품으로 분류되지 않았다.
  • 절차상, 당신은 개미에게 정확히 무엇을 언제 해야 하는지 말해줘야 합니다.컴파일하고, 복사하고, 압축하라고 해야 했어요.
  • 라이프 사이클이 없기 때문에 목표와 의존관계를 정의해야 했습니다.각 목표에 일련의 작업을 수동으로 할당해야 했습니다.

메이븐이...

  • 에는 규칙이 있습니다.규칙을 따랐기 때문에 소스 코드가 어디에 있는지 알고 있습니다.타깃/클래스에 바이트 코드를 배치하고 타깃에 JAR 파일을 생성했습니다.
  • 선언적인 것입니다.pom.xml 파일을 만들고 기본 디렉토리에 소스를 저장하기만 하면 됩니다.메이븐이 나머지를 처리했다.
  • 에는 라이프.라이프 사이클을 하면 이 라이프 이 호출됩니다.mvn install이 명령어는 Maven에게 라이프 사이클에 도달할 때까지 일련의 시퀀스 단계를 실행하도록 지시했습니다.라이프 사이클을 통한 이 여정의 부작용으로 Maven은 컴파일 및 JAR 작성과 같은 많은 기본 플러그인 목표를 실행했습니다.

아이비는 어때?

그래, 스티브 러프란 같은 사람은 그 비교를 읽고 반칙이라고 할 거야그는 아이비라고 불리는 것을 완전히 무시하는 대답과 앤트가 새로운 앤트의 릴리스에서 빌드 로직을 재사용할 수 있다는 사실에 대해 이야기 할 것입니다.이것은 사실입니다.많은 똑똑한 사람들이 Ant+Antlibs+Ivy를 사용한다면, 제대로 작동하도록 설계된 빌드가 완성될 것입니다.Maven이 일리가 있다고 확신하지만, 매우 날카로운 빌드 엔지니어가 있는 프로젝트 팀과 기꺼이 Ant + Ivy를 사용할 것입니다.하지만 Jetty 플러그인과 같은 귀중한 플러그인이 많이 없어지고 시간이 지남에 따라 하지 않아도 되는 많은 작업을 하게 될 것이라고 생각합니다.

Maven vs.개미.

  1. Repository Manager를 사용하여 소프트웨어 아티팩트를 추적합니다.넥서스 다운로드를 추천합니다.Nexus를 사용하여 원격 저장소를 프록시하고 팀이 내부 아티팩트를 배포할 장소를 제공할 수 있습니다.
  2. 소프트웨어 컴포넌트의 적절한 모듈화가 필요합니다.하나의 큰 단일 컴포넌트는 시간이 지남에 따라 거의 확장되지 않습니다.프로젝트가 발전함에 따라 모듈 및 하위 모듈의 개념이 필요하게 될 것입니다.Maven은 이 접근법에 매우 잘 적응한다.
  3. 당신은 당신의 체격을 위해 몇 가지 관습을 채택하고 있다.Ant를 사용하더라도 다른 프로젝트와 일관된 형태의 관습을 채택하도록 노력해야 합니다.프로젝트에서 Maven을 사용하면 Maven을 잘 아는 사람이라면 누구나 빌드를 선택하여 컴파일 방법을 찾기 위해 구성을 조작할 필요 없이 실행할 수 있습니다.

Maven은 프레임워크, 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>

그리고 동등한 개미 파일:

<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은 실제로 많은 프로젝트에서 일반적인 요구 사항을 추가하기 시작하면 크게 증가하기 시작합니다.

하지만 넌 개미에게 이래라 저래라 해야 해

물론 위의 나의 개미 예는 완전하지 않다.청소, 컴파일, 테스트 등에 사용되는 대상을 정의해야 합니다.이러한 파일은 다중 모듈 프로젝트의 모든 모듈에서 가져오는 공통 빌드 파일에 정의됩니다.메이븐에서는 선언적인 반면, 이 모든 것들이 어떻게 앤트로 명시적으로 쓰여져야 하는지에 대한 요점으로 이어집니다.

맞아요, 개미 표적을 명시적으로 쓰지 않아도 된다면 시간을 절약할 수 있을 거예요.하지만 얼마나 걸릴까요?현재 사용하고 있는 일반적인 빌드 파일은 5년 전에 작성한 것으로, 그 이후 약간의 개량만 하고 있습니다.Maven과 2년 동안 실험을 한 후, 나는 옷장에서 오래된 개미 빌드 파일을 꺼내서 먼지를 털어내고 다시 작동시켰다.저는 앤트에게 명시적으로 지시해야 하는 비용이 5년 동안 1주일도 채 되지 않았습니다.

복잡성

다음으로 언급하고 싶은 중요한 차이점은 복잡성과 실제 효과입니다.Maven은 빌드 프로세스 생성 및 관리를 담당하는 개발자의 작업 부하를 줄이려는 목적으로 구축되었습니다.그러기 위해서는 복잡해야 합니다.불행하게도 그 복잡성은 그들의 의도한 목표를 부정하는 경향이 있다.

Ant와 비교하면 메이븐 프로젝트의 빌드맨이 더 많은 시간을 할애할 수 있습니다.

  • 문서 읽기:Maven에는 더 많은 문서가 있습니다. 왜냐하면 당신이 배워야 할 것이 너무 많기 때문입니다.
  • 팀원 교육:그들은 스스로 답을 찾으려고 하는 것보다 아는 사람에게 물어보는 것이 더 쉽다고 생각한다.
  • 빌드 문제 슈팅: Maven은 Ant보다 신뢰성이 떨어집니다.특히 코어 이외의 플러그인은 신뢰성이 떨어집니다.또한 Maven 빌드는 반복할 수 없습니다.플러그인의 스냅샷 버전을 사용하는 경우(아마도), 아무것도 변경하지 않으면 빌드가 중단될 수 있습니다.
  • Maven 플러그인 쓰기: 플러그인은 보통 웹스타트 번들을 작성하는 등 특정 작업을 염두에 두고 작성됩니다.이 경우 플러그인은 다른 작업에 재사용하거나 목표를 달성하기 위해 결합하는 것이 더욱 어려워집니다.따라서 기존 플러그인 세트의 차이를 해결하려면 사용자 자신의 문서를 작성해야 할 수 있습니다.

대조적으로:

  • 개미의 문서는 간결하고 포괄적이며 모두 한 곳에 정리되어 있습니다.
  • 개미는 간단하다.Ant를 배우려는 새로운 개발자는 알아야 할 나머지 사항을 파악하기 위해 몇 가지 간단한 개념(목표, 태스크, 의존관계, 속성)만 이해하면 됩니다.
  • 개미는 믿음직스럽다.지난 몇 년 동안 개미의 출시는 많지 않았다. 왜냐하면 개미는 이미 효과가 있기 때문이다.
  • 개미 빌드는 일반적으로 온라인 저장소, 실험적인 서드파티 플러그인 등 외부 종속 없이 생성되므로 반복 가능합니다.
  • 개미는 포괄적이다.도구 상자이므로 도구를 결합하여 원하는 거의 모든 태스크를 수행할 수 있습니다.커스텀 태스크를 작성할 필요가 있는 경우는, 간단하게 작성할 수 있습니다.

익숙함

또 다른 차이점은 친숙하다는 것이다.신규 개발자는 항상 최신 정보를 얻기 위해 시간이 필요합니다.그런 점에서 기존 제품에 익숙하다는 것은 도움이 되며, Maven 지지자들은 이것이 Maven의 장점이라고 올바르게 주장한다.물론 앤트의 유연성은 원하는 규칙을 만들 수 있다는 것을 의미합니다.그래서 제가 사용하는 규칙은 소스 파일을 디렉토리 이름 src/main/java에 넣는 것입니다.컴파일된 클래스는 target/classes라는 디렉토리에 들어갑니다.어디서 많이 들어본 것 같지 않아?

나는 Maven이 사용하는 디렉토리 구조가 마음에 든다.말이 되는 것 같아요.또, 빌드 라이프 사이클도 있습니다.그래서 저는 개미 건물에서도 같은 관습을 사용합니다.Maven을 사용해 본 적이 있는 사람에게 익숙할 것이기 때문입니다.

개미는 주로 제작 도구입니다.

Maven은 프로젝트 및 종속성 관리 도구입니다(물론 프로젝트도 구축합니다).

만약 당신이 Maven을 피하고 싶다면 Ant+Ivy는 꽤 좋은 조합이다.

몇 가지 차이점을 더 나열해 보겠습니다.

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

업데이트:

이것은 Maven에서 온 것입니다. 최종 가이드미안해요, 인용하는 걸 완전히 잊어버렸어요.

Maven 또는 Ant?는 이 질문과 매우 유사한 질문으로, 질문에 대답하는 데 도움이 될 것입니다.

메이븐이 뭐죠?공식 사이트에서

편집: 신규/그린필드 프로젝트에서는 Maven을 사용하는 것을 추천합니다.「컨벤션 오버 컨피규레이션」을 사용하면, 빌드 및 전개 스크립트의 기입과 셋업에 걸리는 시간을 꽤 절약할 수 있습니다.개미를 사용하면 빌드 스크립트의 길이와 복잡성이 시간이 지남에 따라 증가하는 경향이 있습니다.기존 프로젝트의 경우 구성/배치를 Maven 시스템에 주입하는 것이 어려울 수 있습니다.

Maven은 중앙 저장소 또는 사용자가 설정한 저장소에서 jar를 검색하는 데 사용할 수 있는 종속성 관리 도구와 선언적 빌드 도구 역할을 모두 수행합니다."명언적" 빌드 툴과 개미나 메이커와 같은 기존 빌드 툴의 차이점은 수행 방법을 구성하는 것이 아니라 수행해야 할 작업을 구성하는 것입니다.예를 들어 maven 스크립트에서 프로젝트를 WAR 파일로 패키지해야 하며 maven은 이를 처리하는 방법을 알고 있습니다.

Maven은 프로젝트 디렉토리의 「명언성」을 달성하기 위해서, 프로젝트 디렉토리의 배치 방법에 관한 관례에 의존하고 있습니다.예를 들어 기본 코드 배치 위치, web.xml 배치 위치, 장치 테스트 등에 대한 규칙이 있지만 필요에 따라 변경할 수도 있습니다.

또한 maven 내에서 ant 명령을 실행하기 위한 플러그인이 있다는 점도 유의해야 합니다.

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

또한 maven의 원형은 프로젝트를 매우 빠르게 시작할 수 있도록 합니다.예를 들어, Wicket archype은 실행 가능한 hello 월드형 프로젝트 전체를 얻기 위해 실행하는 maven 명령어를 제공합니다.

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

개미를 본 적이 갈 수 . - 개미는 본 이 없다. - 개미는 본 적이 없다. - 개미는 본 적이 없다.build.xml는 꽤 잘 쓰여져 있습니다.또, 무슨 일이 일어나고 있는지를 이해할 수 있습니다.내가 그 사람을 데려가서 Maven POM을 보여주면 그들은 무슨 일이 일어나고 있는지 전혀 모를 거야.

거대한 엔지니어링 조직에서 사람들은 개미 파일이 크고 관리하기 어려워진다는 이야기를 씁니다.그런 타입과 깨끗한 개미 스크립트를 작성했습니다.앞으로 해야 할 일을 미리 이해하고 3년 이상에 걸쳐 변화에 대응하고 확장할 수 있는 템플릿 세트를 설계하는 것입니다.

간단한 프로젝트가 없는 한 메이븐 규약과 메이븐 방식을 배우는 것은 꽤 힘든 일입니다.

결국 Ant 또는 Maven을 사용한 프로젝트 시작은 사실상 총소유비용입니다.조직이 빌드 시스템을 몇 년 동안 유지 및 확장하는 데 필요한 것은 고려해야 할 주요 요소 중 하나입니다.

빌드 시스템의 가장 중요한 측면은 의존관계 관리와 빌드 레시피를 표현할 때의 유연성입니다.잘하면 어느 정도 직관적일 거예요.

프로젝트의 규모에 따라 다르다고 생각합니다만...개인적으로는 간단한 컴파일, 패키징, 도입이 필요한 간단한 프로젝트에는 Maven을 사용하고 싶습니다.좀 더 복잡한 작업(많은 의존관계, 매핑 파일 작성 등)이 필요하시면 Ant로 전환하겠습니다.

또한 Maven은 일반적으로 사용되는 오픈 소스 프로젝트의 대규모 저장소를 보유하고 있습니다.빌드 중에 Maven은 이러한 의존관계(및 의존관계 :)를 다운로드하여 프로젝트 구축의 이 부분을 좀 더 관리하기 쉽게 만들 수 있습니다.

언급URL : https://stackoverflow.com/questions/603189/differences-between-ant-and-maven