왜 Ant나 Maven 대신 Gradle을 사용하는가?

왜 Ant나 Maven 대신 Gradle을 사용하는가?

현재 이 질문은 Q&A 형식에 적합하지 않습니다.우리는 답변이 사실, 참고 자료 또는 전문지식에 의해 뒷받침되기를 기대하지만, 이 질문은 토론, 논쟁, 여론 조사 또는 연장된 토론을 요구할 것이다.이 질문이 개선되고 다시 열릴 수 있다고 생각되면헬프센터를 방문하여 안내를 받으십시오.

닫힘9년 전.

잠겼습니다. 이 질문과 답변은이 질문은 부적절하지만 역사적 의미가 있기 때문에 잠겨 있습니다.현재 새로운 답변이나 상호작용을 받아들이지 않고 있습니다.

Java를 타깃으로 하는 다른 빌드 툴은 실제로 무엇을 얻을 수 있을까요?

Gradle을 다른 툴에 사용하는 경우, 그 이유는 무엇입니까?

저는 Gradle을 홧김에 사용하지 않습니다(지금까지의 장난감 프로젝트일 뿐이며, Gradle이 장난감 프로젝트라는 것은 아닙니다) (저자는 Gradle을 장난감 프로젝트라는 것이 아니라 코멘트 참조)하지만, 그 사용을 고려하는 이유는 Ant와 Maven의 불만 때문이라고 생각합니다.

제 경험상 앤트는 종종 쓰기 전용입니다(예, 아름다운 모듈러와 우아한 빌드를 쓸 수 있다는 것은 알지만, 대부분의 사람들은 그렇지 않습니다).사소하지 않은 프로젝트에서는 매우 당황하게 되어 복잡한 빌드가 실제로 휴대할 수 있도록 세심한 주의를 기울입니다.이러한 필수 특성은 빌드 간에 구성을 복제하는 결과를 초래할 수 있습니다(단, 매크로가 도움이 됩니다).

Maven은 정반대의 접근방식을 채택하여 Maven 라이프 사이클과 완전히 통합되기를 기대합니다.경험이 많은 개미 사용자들은 Maven이 Ant에서 가지고 있는 많은 자유를 없애기 때문에 이것이 특히 불쾌하다고 생각합니다.예를 들어, Maven의 비판과 그 반응을 열거하는 Sonatype 블로그가 있습니다.

Maven 플러그인 메커니즘에 의해 매우 강력한 빌드 구성이 가능하며 상속 모델에서는 기업 전체의 빌드 구성을 캡슐화하는 소규모 부모 POM 세트를 정의할 수 있습니다.또한 개별 프로젝트에서는 이러한 구성을 상속할 수 있기 때문에 경량 상태로 유지할 수 있습니다.Maven 설정은 매우 상세하고(Maven 3이 이 문제에 대처할 것을 약속하고 있지만), "Maven 방식이 아닌" 작업을 하려면 플러그인을 작성하거나 해킹 앤트 통합을 사용해야 합니다.Maven 플러그인을 쓰는 것을 좋아하지만, 많은 분들이 관련된 노력에 반대해 주셔서 감사합니다.

그래들은 앤트와 메이븐 사이의 달콤한 장소를 가겠다고 약속한다.종속성 해결을 위해 Ivy의 접근 방식을 사용합니다.Configuration에 대한 컨벤션도 가능하지만 퍼스트 클래스 시민으로서의 Ant 태스크도 포함됩니다.또한 기존 Maven/Ivy 저장소를 사용할 수도 있습니다.

따라서 Ant/Maven의 문제점 중 하나라도 부딪쳐 막혔다면 Gradle을 시도해 볼 가치가 있을 것입니다.하지만 제 생각에는 알려진 문제와 알려지지 않은 문제를 교환하지 않는 것이 좋을 것 같습니다.하지만 푸딩의 증거는 먹는 것이기 때문에 저는 제품이 조금 더 숙성되고 다른 사람들이 꼬인 부분을 다림질할 때까지 판단을 유보합니다(이유는 그것을 출혈 가장자리라고 부릅니다).그래도 장난감 프로젝트에서 계속 사용할 거예요. 옵션을 알아두는 것은 언제나 좋아요.

Gradle은 Ant보다 훨씬 뛰어난 스위스 군용 나이프이지만 특히 멀티프로젝트 구축에 중점을 두고 있습니다.

우선 Gradle은 종속 프로그래밍 도구이며 프로그래밍 도구이기도 합니다.Gradle을 사용하면 설정에서 임의의 작업을 실행할 수 있습니다.Gradle은 선언된 모든 의존관계가 적절하고 시기적절하게 실행되도록 합니다.코드는 다양한 종류의 레이아웃(트리, 플랫, 분산 등)으로 여러 디렉토리에 분산될 수 있습니다.

Gradle에는 평가와 실행이라는 두 가지 뚜렷한 단계가 있습니다.기본적으로 평가 중에 Gradle은 검색해야 할 디렉토리에서 빌드 스크립트를 검색하고 평가합니다.실행 중 Gradle은 작업 상호의존성을 고려하여 평가 중에 로드된 작업을 수행합니다.

이러한 의존관계 프로그래밍 기능 외에 Gradle은 Apache Ivy와의 통합을 통해 프로젝트 및 JAR 의존관계 기능을 추가합니다.아시다시피 Ivy는 Maven보다 훨씬 더 강력하고 덜 고집스러운 종속성 관리 도구입니다.

Gradle은 프로젝트 간 및 프로젝트와 JAR 간의 의존성을 검출합니다.Gradle은 iBiblio 저장소 또는 자체 저장소 같은 Maven 저장소(다운로드 및 업로드)와 함께 작동하지만, 보유하고 있을 수 있는 다른 저장소 인프라도 지원합니다.

다중 프로젝트 빌드에서 Gradle은 빌드의 구조 및 아키텍처에 적응할 수 있습니다.Maven에서 요구하는 것처럼 구조나 아키텍처를 빌드 툴에 맞출 필요가 없습니다.

그래들씨는 당신의 길을 막지 않으려고 노력하지만, 메이븐은 거의 노력하지 않습니다.인습은 좋지만 유연성도 좋다.Gradle은 Maven보다 더 많은 기능을 제공하지만, 가장 중요한 것은 Gradle이 Maven에서 멀리 떨어진 곳에서 쉽게 이행할 수 있는 경로를 제공한다는 것입니다.

이것은 다소 논란이 될 수 있지만, Gradle은 그것이 완전한 프로그래밍 언어라는 사실을 숨기지 않는다.

개미 + 개미-contrib은 본질적으로 아무도 프로그래밍하고 싶어하지 않는 튜링 완전 프로그래밍 언어입니다.

Maven은 완전히 선언적인 접근을 시도하고 논리가 필요한 경우 플러그인을 작성하고 컴파일하도록 강요하는 정반대의 접근법을 취하려고 합니다.또한 완전히 융통성 없는 프로젝트 모델을 강요합니다.Gradle은 다음과 같은 모든 툴의 장점을 겸비하고 있습니다.

• 컨벤션 오버 컨피규레이션(일명 메이븐)에 준거하고 있습니다만, 필요한 범위내에서만 가능합니다.
• Ant와 같은 유연한 커스텀 태스크를 작성할 수 있습니다.
• Ant와 Maven보다 뛰어난 멀티 모듈 프로젝트 지원을 제공합니다.
• DSL을 탑재하여 80%가 쉽고 20%가 가능합니다(80%가 쉽고 10%가 가능하며 10%가 사실상 불가능합니다).

Gradle은 아직 사용하지 않은 가장 구성이 쉽고 유연한 빌드 도구입니다.DSL과 구성 등의 개념을 익히기 위해서는 사전에 약간의 투자가 필요하지만, 의미 없는 완전한 구성이 가능한 JVM 빌드 툴이 필요한 경우 타의 추종을 불허합니다.

Gradle은 Ant와 Maven을 잘 조합하여 두 프레임워크의 장점을 최대한 활용합니다.Ant의 유연성 및 Maven의 구성, 의존관계 관리 및 플러그인에 대한 관례.

따라서 maven과 같은 표준 Java 빌드를 사용하고 싶지만 테스트 태스크에서 다음과 같은 몇 가지 사용자 지정 단계를 수행해야 합니다.

build.gradle:

apply plugin:'java'
task test{
  doFirst{
    ant.copy(toDir:'build/test-classes'){fileset dir:'src/test/extra-resources'}
  }
  doLast{
    ...
  }
}

게다가 groovy 구문을 사용하고 있기 때문에 ant/maven의 xml보다 훨씬 표현력이 뛰어납니다.

이것은 Ant의 슈퍼셋입니다.모든 Ant 태스크를 gradle로 사용할 수 있습니다.즉, groovy와 같은 구문입니다.

ant.copy(file:'a.txt', toDir:"xyz")

또는

ant.with{
  delete "x.txt"
  mkdir "abc"
  copy file:"a.txt", toDir: "abc"
}

우리는 Gradle을 사용하고 Maven과 Ant보다 그것을 선택했습니다.Ant는 우리에게 완전한 유연성을 주었고, Ivy는 Maven보다 더 나은 의존관계 관리를 제공했지만, 멀티 프로젝트 빌드에 대한 지원은 많지 않았습니다.결과적으로 멀티프로젝트 빌드를 지원하기 위해 많은 코딩 작업을 하게 됩니다.또한 규칙에 따라 빌드하는 것이 좋으며 빌드 스크립트를 보다 간결하게 만들 수 있습니다.Maven에서는 관례에 따라 빌드해야 하며 빌드 프로세스를 커스터마이즈하는 것은 해킹이 됩니다.또한 Maven은 아티팩트를 게시하는 모든 프로젝트를 홍보합니다.프로젝트를 하위 프로젝트로 분할하는 경우도 있지만 모든 하위 프로젝트를 함께 빌드 및 버전 관리해야 합니다.메이븐이 의도한 것은 아니다.

Gradle과 함께 당신은 Ant의 유연성을 가질 수 있고 Maven의 컨벤션으로 건설할 수 있습니다.예를 들어, 자신의 작업으로 기존의 빌드 라이프 사이클을 연장하는 것은 간단한 일입니다.그리고 당신이 원하지 않는다면 당신은 관습을 사용하도록 강요받지 않는다.Groovy는 XML보다 코드화하는 것이 훨씬 더 좋습니다. Gradle에서는 로컬 파일 시스템의 프로젝트 간에 의존 관계를 정의할 수 있습니다. 각 프로젝트의 아티팩트를 저장소에 게시할 필요가 없습니다.마지막으로 Gradle은 Ivy를 사용하기 때문에 의존관리가 우수합니다.지금까지의 나의 유일한 진정한 단점은 성숙한 이클립스 통합이 없다는 것이지만, Maven의 옵션은 그다지 좋지 않다.

이건 제 대답은 아니지만, 확실히 제 마음을 울립니다.ThinkWorks의 테크놀로지 레이더에서 2012년 10월부터 입수했습니다.

Ant 및 Maven과 같은 XML 기반 빌드 툴에는 두 가지 문제가 있습니다. 즉, 너무 많은 분노의 뾰족한 괄호와 플러그인 아키텍처의 조잡함입니다.구문 문제는 세대를 통해 해결할 수 있지만 플러그인 아키텍처는 프로젝트가 복잡해짐에 따라 빌드 도구를 원활하게 확장할 수 있는 능력을 크게 제한합니다.플러그인은 추상화의 잘못된 수준이라는 것을 알게 되었습니다.그래들이나 레이크 같은 언어 기반의 툴을 선호하게 되었습니다.이는 플러그인이 보다 세밀한 추상화와 장기적인 유연성을 제공하기 때문입니다.

Gradle은 빌드/어셈블리 소프트웨어에 재미를 되돌렸습니다.저는 지금까지 개미를 사용하여 소프트웨어를 구축했습니다.개발 작업의 실제 "빌드" 부분은 항상 필요악이라고 생각해 왔습니다.몇 달 전, 우리 회사는 바이너리 리포트(일명 vcs에 항아리 체크인)를 사용하지 않는 것에 싫증이 나기 시작했고, 나는 이것을 조사하라는 임무를 부여받았다.처음에는 담쟁이덩굴로 시작했는데, 개미 위에 빗장을 걸 수 있어서 내가 원하는 대로 내 인공물을 출판할 수 없었어.maven을 찾아서 xml을 해킹하고 간단한 도우미 lib를 위해 훌륭하게 일했지만, 애플리케이션을 번들하여 도입할 수 있도록 하는 과정에서 심각한 문제에 부딪혔습니다.플러그인과 독서 포럼을 검색하면서 꽤 많은 시간을 보냈고, 결국 여러 플러그인에 사용할 수 있는 수조 개의 지원 항아리를 다운로드하게 되었습니다.결국 저는 그라들(이 시점에서 상당히 화가 나 "이렇게 힘들지 않아!"라고 짜증을 내면서)을 선택했어요.

하지만 첫날부터 내 기분이 좋아지기 시작했다.난 좀 나아지고 있었어.첫 개미 모듈을 옮기는 데 2시간 정도 걸렸는데 빌드 파일은 아무 것도 아니었어요1개의 스크린을 간단하게 장착할 수 있습니다.가장 큰 "와우"는: xml로 스크립트를 빌드하는 것입니다.그것은 얼마나 어리석은 일입니까?1개의 종속성을 선언하는 데 1개의 행이 소요된다는 사실은 매우 매력적입니다.-> 특정 프로젝트의 모든 종속성을 한 페이지에서 쉽게 확인할 수 있습니다.그 후, 저는 계속 승승장구해 왔습니다.지금까지 직면한 문제마다 심플하고 우아한 해결책이 있습니다.그 이유는 다음과 같습니다.

• groovy는 자바 개발자에게 매우 직관적이다.
• 문서화는 훌륭하고 훌륭하다
• 유연성이 무한하다

지금은 빌드 프로세스에 추가할 새로운 기능을 찾는 데 시간을 보내고 있습니다.얼마나 역겨워?

또한 기본 빌드를 훨씬 쉽게 관리할 수 있습니다.Ant와 Maven은 사실상 Java 전용입니다.일부 플러그인은 Maven을 위해 존재하며 일부 네이티브 프로젝트를 처리하려고 하지만 효과적인 작업을 수행하지 못합니다.개미 태스크는 네이티브 프로젝트를 컴파일하기 위해 작성될 수 있지만 너무 복잡하고 어색합니다.

JNI 및 기타 많은 네이티브 비트를 사용하여 Java를 실행합니다.그래들 덕분에 개미들이 어지럽혀졌어우리가 네이티브 프로젝트에 의존 관리를 도입하기 시작했을 때는 혼란스러웠습니다.메이븐에게 부탁했지만그래들 코드는 메이븐에 필요한 것의 극히 일부여서 사람들은 메이븐의 전문가가 되지 않고도 그것을 읽고 이해할 수 있었습니다.

나는 Ed Staub의 말에 부분적으로 동의한다.Gradle은 메이브에 비해 확실히 파워풀하고 장기적으로 유연성이 높아집니다.

maven에서 gradle로 이행하기 위한 평가를 실시한 후 gradle에서 발생한 두 가지 문제(속도는 maven보다 느리고 프록시는 작동하지 않음)에 대해 maven 자체를 고수하기로 결정했습니다.

언급URL : https://stackoverflow.com/questions/1163173/why-use-gradle-instead-of-ant-or-maven