메이븐은 왜 그렇게 평판이 나쁜가요?

메이븐은 왜 그렇게 평판이 나쁜가요?

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

닫힘9년 전.

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

인터넷에서는 메이븐이 얼마나 나쁜지에 대해 많은 말이 있다.저는 Maven의 몇 가지 기능을 몇 년째 사용하고 있으며, 가장 중요한 장점은 의존관리다.

메이븐의 문서는 불충분하지만, 일반적으로 어떤 것을 달성해야 할 때는 그것을 한 번 파악한 후 동작합니다(예를 들어, 서명하는 항아리 등).저는 메이븐이 훌륭하다고 생각하지 않지만, 그것 없이는 진정한 고통이 될 수 있는 몇 가지 문제들을 해결해 줍니다.

그렇다면, 왜 메이븐은 그렇게 평판이 나쁜가? 그리고 미래에 메이븐과 어떤 문제를 예상할 수 있을까?내가 모르는 훨씬 더 좋은 대안이 있을까? (예를 들어, 나는 아이비를 자세히 살펴본 적이 없다.)

메모: 이것은 논쟁을 일으키려는 시도가 아닙니다.FUD를 클리어하기 위한 시도입니다.

6개월 전에 메이븐을 조사했어요새로운 프로젝트를 시작하고 있었는데 지원할 만한 유산이 없었습니다.라고 하는 것은, 다음과 같습니다.

• Maven은 전부 아니면 아무것도 아니야.아니면 적어도 내가 서류에서 알 수 있는 한.maven을 개미의 드롭인 대체품으로 쉽게 사용할 수 없고, 점차 고급 기능을 채택할 수 있습니다.
• 문서에 따르면 메이븐은 당신의 가장 황당한 꿈을 모두 실현시켜주는 초월적인 행복이다.10년 동안 매뉴얼을 숙고하면 깨달음을 얻을 수 있다.
• Maven은 네트워크 연결에 따라 빌드 프로세스를 결정합니다.
• Maven에는 쓸모없는 에러 메세지가 있습니다.개미의 "Target x does not exist in the project y"를 mvn의 "Invalid task 'run"과 비교: 올바른 라이프사이클 단계 또는 pluginGroupId:pluginArtifactId:pluginVersion:goal" 형식으로 목표를 지정해야 합니다.이 도움말은 mvn with -e를 실행하여 자세한 정보를 제공합니다.Build Failure의 경우예외.

Maven에 대한 내 혐오의 대부분은 Better Builds with Maven에서 발췌한 것으로 설명할 수 있다.

누군가가 메이븐이 무엇인지 알고 싶을 때, 그들은 보통 "메이븐이 정확히 무엇인가?"라고 묻곤 하며, 그들은 짧고 건전한 대답을 기대한다."글쎄, 그것은 빌드 툴 또는 스크립트 프레임워크입니다." Maven은 지루하고 자극적이지 않은 세 단어 이상입니다.이는 아이디어, 표준 및 소프트웨어의 조합으로, Maven의 정의를 단순히 소화된 사운드 비트로 추출하는 것은 불가능하다.혁명적 사상은 말로 전달하기 어려운 경우가 많다.

제 제안은 아이디어를 말로 전달할 수 없다면 그 주제에 관한 책을 쓰려고 하지 말라는 것입니다. 왜냐하면 저는 아이디어를 텔레파시로 흡수하지 않을 것이기 때문입니다.

• 그것은 처음부터 당신에게 엄격한 구조를 강요한다.
• XML 기반이므로 ANT만큼 읽기 어렵습니다.
• 에러 보고는 불명확하고, 일이 잘못되면 곤란하게 됩니다.
• 서류가 부실하다.
• 어려운 것은 쉽게, 간단한 것은 어렵게 만듭니다.
• Maven 빌드 환경을 유지하는 데 너무 많은 시간이 걸리고, 이는 모두 노래를 부르는 빌드 시스템을 보유해야 할 필요성을 상실합니다.
• 잘못된 설정을 하지 않고 메이븐에서 버그를 발견했다는 것을 알아내는 데 오랜 시간이 걸립니다.그리고 그 벌레들은 놀라운 곳에 존재합니다.
• 그것은 많은 것을 약속하지만 아름답고 유혹적이지만 감정적으로 차갑고 교활한 연인처럼 당신을 배신한다.

나는 분명히 과거에 메이븐에 대해 불평하고 불평한 적이 있다.하지만 지금은 그것 없이는 살 수 없어요.그 어떤 문제보다 이득이 훨씬 더 크다고 생각합니다.주로:

• 표준화된 프로젝트 구조
  • 새로운 개발자가 프로젝트에 참여하는 경우:
    • 메이븐 프로젝트라고 하면 개발자는 프로젝트 레이아웃과 프로젝트 구축 및 패키징 방법을 알 수 있습니다.
    • Ant 프로젝트라고 하면 개발자는 더 많은 설명을 기다리거나 build.xml을 통해 문제를 파악해야 합니다.
  • 물론 앤트와 함께 회사 전체의 기준을 적용하는 것은 항상 가능하지만, 저는 종종 여러분이 이 속담에 나오는 바퀴를 다시 발명하게 될 것이라고 생각합니다.
• 의존관계 관리.
  • 외부 라이브러리뿐만 아니라 내부 라이브러리/모듈도 사용할 수 있습니다.Nexus 또는 Artifictory와 같은 Maven 저장소 프록시 서버를 사용해야 합니다.
  • 아이비랑 같이 하는 것도 가능해실제로 의존관리가 필요한 경우 Ivy를 사용하는 것이 좋습니다.
• 특히 프로젝트 내에서는요.작은 서브프로젝트를 전개하는 것이 매우 유용하다는 것을 알게 되었고, 메이븐은 이것을 잘 처리합니다.개미는 훨씬 더 어렵다.
• 표준화된 아티팩트 관리(특히 nexus 또는 아티팩트 저장소와의 연계)
• 릴리스 플러그인은 훌륭합니다.
• Eclipse와 NetBeans의 통합은 매우 양호합니다.
• 허드슨과의 통합은 훌륭합니다.특히 findbugs 등의 트렌드 그래프가 그렇습니다.
• 사소한 점이지만 maven이 기본적으로 jar나 war(파일 이름뿐만 아니라)에 버전 번호와 같은 세부 정보를 포함시켜 주는 것은 큰 도움이 됩니다.

저의 단점은 주로 다음과 같습니다.

• 커맨드 라인은 도움이 되지 않습니다.이것은 처음에 나를 많이 실망시켰다.
• XML 형식은 매우 상세합니다.왜 그렇게 했는지 알 것 같지만, 그래도 읽기가 귀찮다.
  • 즉, IDE에는 XSD가 있어 편집이 용이합니다.
• 처음에는 그것을 이해하기가 어렵다.예를 들어 라이프 사이클 같은 것.
  • 하지만 maven에 대한 명확한 가이드는 좋은 소개입니다.

나는 정말로 시간을 좀 할애해서 메이븐에 대해 알아볼 가치가 있다고 믿는다.

두 개의 큰 프로젝트를 통해 얻은 실제 경험은 메이브 1에서 메이브 2로 이동하는 500시간의 노력을 제외하고 각 프로젝트에 1000~1500시간을 소비했다는 것입니다.

그 이후로, 나는 메이븐이 정말 싫다고 말해야겠다.생각하면 답답해요.

이클립스 통합은 끔찍합니다.(예를 들어 이클립스가 생성된 코드와 동기화되지 않아 완전한 재구축이 자주 필요한 등 코드 생성에 문제가 끊이지 않았습니다.그 책임은 메이븐과 일식 둘 다지만, 일식은 메이븐과 에맥스보다 더 유용하기 때문에 일식은 남아서 없어져야 한다.)

의존관계가 많았습니다.구문 오류는 실제로 퍼블릭 메이븐 저장소에 자주 커밋되어 귀중한 시간을 낭비할 수 있습니다.매주.회피책은 프록시 또는 로컬로 관리되는 저장소를 사용하는 것입니다.이것에 의해서, 올바르게 동작하는 데에도 꽤 시간이 걸립니다.

Mavens 프로젝트 구조는 Eclipse와의 개발에는 그다지 적합하지 않으며, Eclipse의 빌드 시간이 길어집니다.

코드 생성 및 동기화 문제로 인해 스크래치에서 자주 재구축하여 코드/컴파일/테스트 사이클을 무한 컴파일/웹서프/sleep/die/코드 사이클로 줄이고 90년대와 40분의 컴파일 시간으로 바로 되돌려야 했습니다.

maven에 대한 유일한 핑계는 의존관계 해결이지만, 저는 모든 빌드가 아니라 가끔 그것을 하고 싶습니다.

요약하자면, 메이븐은 KISS에서 최대한 멀리 떨어져 있다.그리고 또한, 옹호자들은 그들의 나이가 소수일 때 생일날 추가로 축하하는 타입의 사람들이 되는 경향이 있다.얼마든지 투표해 주세요:-)

메이븐은 대단해.그 명성의 이유는 가파른 학습곡선과 관련이 있다고 생각합니다.(마침내 이제 곧 끝날 것 같아)

이 문서는 이해하기 전에 이해해야 할 텍스트와 새로운 내용이 많다고 느끼기 때문에 설명하기가 좀 어렵습니다.나는 메이븐이 더 널리 칭찬받는데 필요한 것은 시간뿐이라고 말한다.

메이븐은 성인 남성들을 흐느끼는 절대적인 공포의 집단으로 만드는 장치이기 때문이다.

장점:

• 의존관계 관리.이미 몇 년 전부터 동료들과 저는 의존관계를 수동으로 다운로드하고 관리하지 않고 있습니다.이것은 엄청난 시간 절약이다.
• IDE에 의존하지 않습니다.주요 IDE, Eclipse, IDEA 및 NetBeans는 모두 Maven 프로젝트를 적절히 지원하므로 개발자들은 특정 IDE에만 국한되지 않습니다.
• 명령줄Maven을 사용하면 IDE와 명령줄 구성을 동시에 지원할 수 있어 지속적인 통합에 도움이 됩니다.

단점:

• 메이븐 학습에 투자해야 한다.글쎄, 해야겠다.좋은 소식이야, 팀원 모두가 배울 필요는 없어.
• 문서.예전에는 문제가 되곤 했는데, 지금은 Sonatype과 그들의 책(http://www.sonatype.com/products/maven/documentation/book-defguide), 덕분에 상황이 훨씬 나아졌습니다.
• 경직성당신이 원하는 방식으로 일을 하는 것은 때때로 도전적이고 좌절감을 줍니다.저는 메이븐이 최선을 다하거나, 간단한 빌드나, 안정적인 모조를 사용할 수 있을 때 싸우거나, 메이븐에게 일을 시키지 말 것을 조언합니다.다른 경우, 우리는 자퇴하고 Ant 태스크(http://maven.apache.org/plugins/maven-antrun-plugin/) orxternal 프로그램)로 일을 합니다.개인적으로 좋아하는 것은 그루비 플러그군(http://groovy.codehaus.org/GMaven))입니다.

경쟁 제품:

• Ant: 의존관리가 없습니다.마침표
• 아이비: 아직 메이븐보다 덜 성숙합니다.기능 세트가 거의 같기 때문에 이동할 필요가 없습니다.나는 그것을 시도하려고 여러 번 시도했지만 모두 실패했다.

결론: 우리의 모든 프로젝트는 이미 몇 년 전부터 Maven과 함께 진행되었습니다.

가장 단순하고 복잡한 프로젝트를 하는 사람들에게 나쁜 평판을 받는 것 같아요.

단일 코드베이스에서 단일 WAR을 구축하는 경우 프로젝트 구조를 이리저리 이동하고 3개의 jar 중 2개를 수동으로 POM 파일에 나열해야 합니다.

5개의 WAR 파일, 3개의 EJB 및 17개의 기타 도구, 종속성 항아리 및 구성을 조합하여 9개의 EAR 파일 프로토타입에서 하나의 EAR를 구축하는 경우 MANIFIST를 조정해야 합니다.최종 빌드 중에 기존 리소스에 있는 MF 및 XML 파일을 사용하면 Maven이 너무 제한될 수 있습니다.이러한 프로젝트는 복잡한 중첩 프로파일, 속성 파일 및 메이븐 빌드 목표와 분류자 지정의 오남용으로 혼란스러워집니다.

따라서 복잡도 곡선의 하위 10%에 속한다면 과잉 살상입니다.상위 10%의 커브에서는 구속복을 입게 됩니다.

Maven의 성장은 80% 중반에서 잘 작동하기 때문입니다.

제 경험상 많은 투고들이 좌절감을 느낍니다.Maven의 문제는 궁극의 자동적인 장점을 추구할 때 빌드 관리의 세부 사항을 숨기고 포장한다는 것입니다.이게 깨지면 거의 속수무책이에요.

제 경험으로는 maven에 문제가 생기면 루트 캐널과 비슷한 경험으로 네스트된 xml 파일의 웹을 통해 몇 시간 동안 스니프 헌트로 빠르게 변질되었습니다.

메이븐에 크게 의존하고 있는 가게에서도 일했습니다만, 그것을 좋아하는 사람들( 「버튼을 눌러, 모든 것을 완성한다」라고 하는 면에서 그것을 좋아하는 사람들)은 그것을 이해하지 못했습니다.메이븐 빌딩에는 100만 개의 자동 타겟이 있습니다. 몇 시간 동안 그들이 한 일을 읽고 싶다면 도움이 될 것입니다.충분히 이해할 수 있는 2가지 목표.

주의: 2년 전 Maven과 마지막으로 작업한 경우, 지금은 더 나을 수 있습니다.

글렌처럼 메이븐도 나쁜 평판이 아니라 엇갈린 평판을 가지고 있는 것 같아요.저는 6개월 동안 큰 프로젝트를 메이븐으로 이행하기 위해 독점적으로 일해 왔습니다.그것은 툴의 한계를 명확하게 나타내고 있습니다.

제 경험상 Maven은 다음과 같은 장점이 있습니다.

• 외부 의존 관리
• 빌드의 일원 관리(상속)
• 많은 것을 위한 많은 플러그인
• 지속적인 통합 도구와의 뛰어난 통합
• 매우 뛰어난 보고서 기능(FindBugs, PMD, Checkstyle, Javadoc 등)

또한 다음과 같은 문제가 있습니다.

• 모두 또는 전혀 접근하지 않음(Maven으로 천천히 이동하기 어려움)
• 복합 종속성, 모듈 간 종속성
• 주기적 의존관계(예: 설계가 나쁘지만 5년간의 개발은 수정할 수 없습니다...)
• 일관성(버전 범위는 모든 곳에서 동일하지 않음)
• bugs(버전 범위 포함)
• 재현 가능한 빌드(모든 플러그인의 버전 번호를 수정하지 않으면 6개월 내에 동일한 빌드를 얻을 수 없습니다)
• 문서화의 결여(기본적으로는 매우 적합하지만 대규모 프로젝트를 처리하는 방법의 예는 많지 않음)

이 프로젝트에는 약 30명의 개발자가 종사하고 있습니다.프로젝트는 5년 이상 되었습니다.그 때문에, 많은 레거시, 많은 프로세스, 커스텀 독자적인 툴이 이미 준비되어 있습니다.자체 툴 유지 보수 비용이 너무 많이 들기 때문에 Maven으로의 이행을 시도하기로 했습니다.

저는 이 포럼에서 제기된 몇 가지 불만 사항에 대해 반박하고 싶습니다.

Maven은 전부 아니면 아무것도 아니야.아니면 적어도 내가 서류에서 알 수 있는 한.maven을 개미의 드롭인 대체품으로 쉽게 사용할 수 없고, 점차 고급 기능을 채택할 수 있습니다.

그건 사실이 아니야.Maven의 큰 장점은 의존관계를 합리적으로 관리하는 것입니다.Maven에서 그것을 하고 싶다면 다른 모든 것을 개미에서 할 수 있습니다.방법은 다음과 같습니다.

<?xml version="1.0" encoding="UTF-8"?>
<project name="foo" basedir="." xmlns:maven="antlib:org.apache.maven.artifact.ant" >
  <maven:dependencies verbose="true" pathId="maven.classpath">
    <maven:pom id="maven.pom" file="pom.xml" />
  </maven:dependencies>
</project>

이제 pom 파일에 정의된 모든 maven 종속성을 포함하는 'maven.classpath'라는 이름의 클래스 경로 개체가 있습니다.maven ants tasks jar를 ant's lib 디렉토리에 저장하기만 하면 됩니다.

Maven은 네트워크 연결에 따라 빌드 프로세스를 결정합니다.

기본 종속성 및 플러그인 가져오기 프로세스는 네트워크 연결에 따라 달라지지만 초기 빌드(또는 사용 중인 종속성 또는 플러그인을 변경하는 경우)에만 적용됩니다.그 후 모든 항아리는 로컬로 캐시됩니다.네트워크 접속을 강제하고 싶은 경우는, 오프라인 모드를 사용하도록 maven에게 지시할 수 있습니다.

그것은 처음부터 당신에게 엄격한 구조를 강요한다.

이것이 파일 형식과 관련된 것인지, '컨벤션 대 구성'의 문제인지는 명확하지 않습니다.후자의 경우 Java 소스 파일 및 리소스의 예상 위치나 소스의 호환성과 같은 보이지 않는 많은 기본값이 있습니다.그러나 이는 경직성이 아니라 합리적인 디폴트로 설정되기 때문에 명시적으로 정의할 필요가 없습니다.모든 설정은 매우 쉽게 덮어쓸 수 있습니다(초보자용 문서에서는 특정 사항을 변경하는 방법을 찾기 어려울 수 있습니다).

파일 형식을 말하는 거라면 다음 부분에 대한 응답에서 다루겠지만...

XML 기반이므로 ANT만큼 읽기 어렵습니다.

우선, 나는 어떻게 어떤 것의 어떤 측면이 나쁜 평판을 가진 것에 대한 정당화로서 '개미보다 낫지 않다'고 불평할 수긍정할 수 있는지 모르겠다.둘째, 여전히 XML이지만 XML 형식은 훨씬 더 정의되어 있습니다.게다가 정의되어 있기 때문에, POM용의 센스 있는 씩 클라이언트 에디터를 만드는 것이 훨씬 쉬워집니다.여기저기 뛰어다니는 개미 제작 스크립트를 몇 페이지나 봤거든요어떤 개미 빌드 스크립트 에디터라도 이 기능을 더 이상 즐길 수 있는 것은 아닙니다.조금 다른 방식으로 상호 연결된 태스크의 또 다른 긴 목록일 뿐입니다.

내가 여기서 봤던 몇 가지 불만들이 있는데, 그 중 가장 큰 것은 약간의 중독이 있었다.

• 매뉴얼이 불충분/누락
• 재현 가능한 빌드
• Eclipse 통합이 잘못됨
• 버그

이에 대한 나의 반응은 이중적이다.첫째, Maven은 Ant나 Make보다 훨씬 새로운 도구이기 때문에 이러한 애플리케이션의 성숙도 수준에 도달하는 데 시간이 걸릴 것으로 예상해야 합니다.둘째, 마음에 안 들면 고치세요.오픈 소스 프로젝트입니다.그리고 그것을 사용하고 나서, 누구라도 해결에 관여할 수 있는 것에 대해 불평하는 것은, 나에게는 지극히 타당하다고 생각됩니다.서류가 마음에 안 드시나요?초보자도 보다 명확하고 완전하며 쉽게 접근할 수 있도록 기여합니다.

재현 가능한 빌드 문제는 버전 범위와 자동 메이븐 플러그인 업데이트의 두 가지 문제로 나뉩니다.플러그인 업데이트의 경우 1년 후 프로젝트를 재구축할 때 동일한 JDK와 동일한 Ant 버전을 사용하고 있는지 확인하지 않는 한 이는 다른 이름으로 동일한 문제입니다.버전 범위에 대해서는 모든 직접 및 전이 종속성에 대해 잠긴 버전이 포함된 임시 POM을 생성하여 maven 릴리스 라이프사이클의 일부로 만드는 플러그인 작업을 권장합니다.이렇게 하면 릴리스 빌드 폼은 항상 모든 종속성을 정확하게 설명합니다.

그것은 평판을 받을 자격이 있다.Maven의 개발자가 모든 프로젝트에 적합하다고 생각한 견고한 구조가 모든 사람에게 필요한 것은 아닙니다.너무 융통성이 없어요.그리고 많은 사람들에게 '프로'인 의존관리는 IMHO의 가장 큰 '콘'입니다.네트워크에서 jar를 다운로드하는 것이 전혀 불편하고 비호환성에 대한 불안감이 있습니다(예, 오프라인 모드는 존재하지만 수백 개의 xml 파일과 체크섬을 모두 가지고 있어야 하는 이유는 무엇입니까?사용할 라이브러리를 결정하고 많은 프로젝트에서 네트워크 연결에 따라 빌드에 심각한 문제가 있습니다.

더 나쁜 것은, 일이 잘 풀리지 않을 때, 당신은 완전히 길을 잃게 된다는 것이다.서류는 형편없고, 지역사회는 아무것도 몰라.

1년 후, 이것을 갱신하고 싶다고 생각했습니다.나는 메이븐 공동체에 대해 더 이상 이 의견을 가지고 있지 않다.오늘 질문을 받았다면 이 답변을 쓰지 않았을 것이다.저는 현재 제 의견을 별도의 답변으로 추가하려고 합니다.

---

이것은 매우 주관적인 대답이지만, 문제는 의견의 문제이기 때문에…

저는 메이븐을 좋아하고, 알게 될수록 더 좋아지고 있습니다.그러나 이에 대한 제 감정에 영향을 미치는 한 가지는 Maven 커뮤니티가 주로 Sonatype(Maven Honcho의 많은 회사가 일하고 있는 곳)에 집중되어 있고, Sonatype은 회사 제품을 커뮤니티에 상당히 적극적으로 홍보하고 있다는 것입니다.

예:"Maven Book" 트위터 스트림은 저장소 관리에 대한 소개로 연결됩니다.

죄송합니다만, 그 「인트로」는, Nexus에 있어서, 반은 정보, 반은 세일즈 피치입니다.즉석 퀴즈: 넥서스나 넥서스 프로 외에 레포 매니저가 있습니까?그리고 그게 오픈소스 메이븐 북이랑 무슨 상관이죠?저장소 관리에 관한 장에서 Nexus에 관한 별도의 책으로 분리되었습니다.허허, 메이븐북에 기고하면 넥서스 매출이 늘어나면 소개비를 받을 수 있나요?

Java 개발 포럼에 참가하고 있으며, Java에 대해 논의하는 Sun의 직원들이 NetBeans와 "NetBeans Pro"에 대해 이야기할 수 있는 모든 기회를 잡을 것이 분명하다고 상상해 보십시오.잠시 후, 그것은 공동체 의식을 잃는다.나는 개미와 그런 경험을 한 적이 없다.

Maven은 소프트웨어 개발 구성 및 빌드 관리에 매우 흥미롭고 유용한 시스템이라고 생각합니다(Ant와 같이 Maven은 그보다 더 광범위합니다).의존관리는 때로는 축복이기도 하고 때로는 저주이기도 하지만, 신선하기도 합니다. 물론 메이븐이 제공하는 유일한 이점은 아닙니다.음파탐지기 실링에 대해 너무 강하게 반응하고 있는 것 같은데, 내 생각에 그건 연관성에 의해 메이븐에게 상처를 주는 것 같아요.나는 이 의견이 다른 사람과 공유되는지 모르겠다.

저는 Maven이 프로젝트에 구조를 강요하기 때문에 나쁜 평가를 받는다고 생각합니다만, Ant와 같은 다른 툴에서는 원하는 대로 구조를 완전히 정의할 수 있습니다.서류도 나쁘다는 것에 동의하지만, 메이븐이 받는 나쁜 비난은 사람들이 앤트에 너무 익숙하기 때문이라고 생각해요.

마법이 너무 많아.

만족하지 못하는 사람들은 불평을 하지만 만족하는 사람들은 만족한다고 말하지 않기 때문이다.내 요점은 만족하는 사용자가 불만족하는 사용자보다 훨씬 더 많지만, 나중에는 더 시끄럽다는 것이다.이것은 실제로도 일반적인 패턴입니다(ISP, 전화 통신 사업자, 트랜스포트 등).

가장 중요한 문제는 Maven이 적절하게 구성되지 않으면 다음과 같은 이유로 반복 가능한 빌드를 생성하지 못할 수 있다는 것입니다.

• 신뢰할 수 없는 리모트 저장소
• 스냅샷 버전이 있거나 버전이 없는 플러그인과 라이브러리에 종속됩니다.

모든 항아리가 로컬로 체크인되기 때문에 장황하고 귀찮은 IMO가 기능하는 개미 빌드와 비교해 보십시오.

좋은 점은 다음과 같은 문제에 대처할 수 있다는 것입니다.

• 당신의 maven 저장소를 사용합니다.이것은 매우 심플해졌습니다.아치바에서는 좋은 결과를 얻을 수 있는 결과가 있습니다.
• 항상 종속성을 적절하게 버전화합니다.Maven은 2.0.8 또는 2.0.9부터 슈퍼 POM의 플러그인 버전을 잠그기 시작했습니다.모든 의존관계는 출시된 버전에 있어야 합니다.

뛰어난 아이디어 - 구현 불량

최근에 앤트에서 메이븐으로 프로젝트를 옮겼어요.마지막에는 잘 작동했지만, 한 버전에서 작동하던 것이 다른 버전에서 고장났기 때문에 같은 폼에서 maven-assembly-plugin과 maven-jar-plugin의 두 가지 다른 버전을 사용해야 했습니다.

그래서 그것은 꽤 골칫거리였다.문서가 항상 좋은 것은 아니지만 답을 검색하기가 비교적 쉬웠다는 것을 인정해야겠다.

사용하는 플러그의 버전을 항상 지정해야 합니다.새로운 버전이 하위 호환성이 있을 것으로 기대하지 마십시오.

논란은 여전히 진화하고 그 과정이 때때로 고통스럽다는 사실에서 비롯된다고 생각한다.

안부 전해요

v.

나는 메이븐을 좋아한다.1.0 이전부터 사용했어요.이 툴은 강력한 툴로, 시간을 대폭 절약하고 개발 인프라스트럭처를 개선했습니다.하지만 어떤 사람들이 느끼는 좌절감은 이해할 수 있어요.3가지 유형의 좌절이 보입니다.

1. 원인이 실제 우려 사항인 경우(예: 상세 POM, 문서 부족),
2. 일부는 잘못된 정보입니다(예: "구축하려면 인터넷에 연결되어 있어야 합니다"). 사실이 아닙니다. 이는 피할 수 있습니다.
3. 그 중 일부는 메이븐에서 분출되지만 실제로는 다른 누군가가 책임을 져야 한다("메신저를 쏘지 마세요")

첫 번째 경우, 실제 문제 - 물론 문제가 있습니다. POM은 장황하고 문서화는 더 나을 수 있습니다.그럼에도 불구하고, 메이븐과 함께 빠른 시간에 좋은 결과를 얻을 수 있다.저는 개미로 만든 프로젝트를 받을 때마다 움츠러들고, 이것을 IDE에 Import하려고 합니다.디렉토리 구조를 설정하는 데 오랜 시간이 걸릴 수 있습니다.maven은 IDE에서 POM 파일을 여는 경우입니다.

두 번째 경우, Maven은 복잡하고 오해가 흔한 경우입니다.maven 3이 이 복잡성(또는 인식된 복잡성)에 대처할 수 있는 방법을 찾을 수 있다면 좋을 것입니다.maven은 상당한 투자를 필요로 하지만, 제 경험상 투자 수익은 빠르게 회수됩니다.

마지막으로 maven의 과도적 의존성에 대한 불만이 가장 잘 알려진 예라고 생각합니다.

전이 의존성은 재사용을 사용하는 실제 소프트웨어의 특성입니다.Windows DLL, Debian 패키지, Java 패키지, OSGi 번들, 심지어 C++ 헤더 파일도 모두 종속성을 가지며 종속성 문제를 겪습니다.두 개의 의존관계가 있고, 각각 다른 버전의 같은 것을 사용하고 있다면, 당신은 그것을 어떻게든 해결하려고 노력해야 합니다.Maven은 의존성 문제를 해결하려고 하는 것이 아니라, 그것을 전면에 내세우고, 경합을 보고하거나 프로젝트의 계층에 일관된 의존성을 제공하는 등 문제를 관리하는 데 도움이 되는 툴을 제공하고, 실제로 프로젝트의 의존성에 대한 절대적인 제어를 제공합니다.

각 프로젝트에 의존관계를 수동으로 포함시키는 접근법(포스터 하나에 소스 제어에 대한 모든 의존관계를 확인한다고 기재되어 있습니다)은 의존관계에 대한 업데이트를 확인하지 않고 라이브러리가 갱신되었을 때 간과되는 업데이트 등 잘못된 의존관계를 사용할 위험이 있습니다.모든 규모의 프로젝트에서 의존관계를 수동으로 관리하면 오류가 발생할 수 있습니다.maven을 사용하면 사용하는 라이브러리 버전을 업데이트할 수 있으며 올바른 종속성이 포함되어 있습니다.변경 관리의 경우 이전 종속성 세트(프로젝트 전체)를 새로운 세트와 비교할 수 있습니다.또, 변경에 대해서는, 주의 깊게 조사, 테스트등을 실시할 수 있습니다.

Maven은 의존성 문제의 원인이 아니라 더 잘 보이게 합니다.의존성 문제에 대처하는 데 있어서 maven은 의존성 "tweaks"를 명시합니다(의존성을 재정의하는 POM의 변경). 수동 관리된 jars가 단순히 존재하는 경우처럼, jars가 올바른 의존성인지 아닌지를 나타냅니다.

대부분의 비방자들은 Maven + Hudson + Sonar의 조합을 관찰하지 못했기 때문에 Maven은 평판이 좋지 않다고 생각합니다.그렇다면 "어떻게 시작할까요?"라고 묻겠죠?

메이븐에 대한 나의 불만들 중 몇 가지는:

• XML의 정의는 매우 어설프고 상세하다.그들은 속성에 대해 들어본 적이 없나요?

• 디폴트 설정에서는, 항상 모든 조작에 대해서 「net」을 스캔 합니다.이것이 어떤 것에 도움이 되는지에 관계없이, "깨끗한" 인터넷 접속을 필요로 하는 것은 매우 어리석어 보입니다.

• 디폴트에서는, 정확한 버전 번호를 지정하지 않으면, 이러한 최신 버전에 의존 에러가 발생하고 있는지에 관계없이, 최신 업데이트가 「넷」에서 풀 됩니다.다른 말로 하면, 당신은 다른 사람들의 의존관리의 지배를 받게 됩니다.

• 이 모든 네트워크접근에 대한 해결책은 네트워크 접속을-o선택.그러나 종속성 업데이트를 수행하려면 이 기능을 해제해야 합니다.

• 또 다른 해결책은 종속성을 위해 자체 "소스 제어" 서버를 설치하는 것입니다.서프라이즈:대부분의 프로젝트에는 이미 소스 제어 기능이 있지만 추가 설정 없이 작동합니다.

• 메이븐 빌드는 믿을 수 없을 정도로 느리다.네트워크 업데이트를 조작하면 이 문제는 완화되지만 Maven 빌드는 여전히 느립니다.그리고 끔찍하게 장황하다.

• Mven 플러그인(M2Eclipse)은 이클립스와 가장 잘 통합되지 않습니다.Eclipse는 버전 관리 소프트웨어 및 Ant와 상당히 원활하게 통합됩니다.Maven 통합은 그에 비해 매우 투박하고 추악하다.내가 느리다고 말했나요?

• 메이븐은 계속 버그가 있다.오류 메시지는 도움이 되지 않습니다.너무 많은 개발자들이 이로 인해 고통 받고 있다.

좋은 질문입니다.저는 막 직장에서 큰 프로젝트를 시작했는데, 이전 프로젝트 중 일부는 코드 베이스에 모듈화를 도입하는 것이었습니다.

I've heard bad things about maven. In fact, it's all I've ever heard about it. I looked at introducing it to solve the dependency nightmare we're currently experiencing. The problem I've seen with Maven is that it is quite rigid in its structure, i.e. you need to conform to its project layout for it to work for you.

I know what most people will say - you don't have to conform to the structure. Indeed that's true but you won't know this until you're over the initial learning curve at which point you've invested too much time to go and throw it all away.

Ant is used a lot these days, and I love it. Taking that into account I stumbled across a little known dependency manager called Apache Ivy. Ivy integrates into Ant very well and it's quick and easy to get basic JAR retrieval setup and working. Another benefit of Ivy is that it's very powerful yet quite transparent; you can transfer builds using mechanisms such as scp or ssh quite easily; 'chain' dependency retrieval over filesystems or remote repositories (Maven repo compatibility is one of its popular features).

That all said, I found it very frustrating to use in the end - the documentation is aplenty, but it's written in bad English which can add to frustration when debugging or attempting to work out what's gone wrong.

I'm going to revisit Apache Ivy at some point during this project and I hope to get it working properly. One thing it did do was allow us as a team to work out what libraries we're dependent on and get a documented list.

Ultimately I think it all comes down to how you work as an individual/team and what you need to resolve your dependency issues.

You might find the following resources relating to Ivy useful:

• Apache Ivy vs Maven 2 comparison
• Apache Ivy FAQ
• Apache Ivy feature list

I love Maven - it boosts productivity, and I am very happy that I am no longer using Ant (phew!)

But if I could change things it would be:

1. Make pom.xml file less verbose
2. Make it easier to include .jars not from the repository.

There are lot of reasons why people don't like Maven, but let face it they are very subjective. Maven today with some good (and free) books, better documentation, biger set of plugins and lot of referential succesful project builds isn't the same Maven as it was one or two years ago.

Using Maven in simple projects is very easy, with bigger/complicated ones there is need for more knowledge and deeper understanding of Maven philosophy - maybe in company level a position for Maven guru like network admin. Main source of Maven hates statments are often ignorance.

Another niggle for Maven is lack of flexibility like e.g. in Ant. But remeber Maven has set of conventions - sticking to them seems to be hard in the begining, but in the end often save as from problems.

Current success of Maven proves its value. Of course nobody is perfect and Maven has some cons and its quirks but in my opinion Maven slowly sways his opponents.

I wouldn't say it has a bad rep so much as it has a mixed rep. If your project follows the "convention over configuration" paradigm advocated by Maven then you can get a lot leverage out of it. If your project doesn't fit well into Maven's world view then it can become a burden.

To that end, if you have control over the project, then Maven may be the way to go. But if you don't and the layout is determined by someone not a fan of Maven, it may be more trouble than it's worth. The happiest Maven projects are probably the ones that started as Maven projects.

To me, there are as many pros as there are cons to using maven vs ant for in-house projects. For open source projects however, I think Maven has had a great impact in making many projects much easier to build. It wasn't too long ago that it took hours get the average OSS Java (ant based) project to compile, having to set a ton of variables, downloading dependent projects, etc.

You can do anything with Maven you can do with Ant, but where Ant doesn't encourage any standards, Maven strongly suggests you to follow it's structure, or it'll be more work. True, some things are a pain to set up with Maven that would be easy to do with Ant, but the end result is almost always something that is easier to build from the perspective of people who just want to check out a project and go.

If you're going to bet your business or job on a development project, you want to be in control of the foundations - i.e. the build system. With Maven, you are not in control. It is declarative and opaque. The maven-framework developers have no idea how to build a transparent or intuitive system and this is clear from the log output and the documentation.

The dependency management is very tempting since it could same you some time at project inception but be warned, it is fundamentally broken and will eventually cause you a lot of headaches. When two dependencies have incompatible transient dependencies you will be blocked by a rat's nest of complexity that will break the build for your entire team and block development for days. The build process with Maven is also notoriously inconsistent for different developers in your team due to inconsistent states of their local repositories. Depending on when a developer created their environment, or what other projects they're working on, they will have different results. You'll find that you're deleting your entire local repository and having Maven re-download jars far more often than the first time setup for a dev branch. I believe OSGI is an initiative that is attempting to fix this fundamental problem. I would say that perhaps if something needs to be so complex, the fundamental premise is wrong.

I've been a maven user/victim for over 5 years now and I have to say that it will save you far more time to just check your dependencies into your source repository and write nice and simple ant tasks. With ant, you know EXACTLY what your build system is doing.

I've experienced many, many lost man weeks of time at several different companies due to Maven problems.

I've recently tried to bring an old GWT/Maven/Eclipse project back to life and 2 weeks of all my spare time later, I still can't get it to build consistently. It's time to cut my losses and develop using ant / eclipse me thinks...

The short answer: I've found it very difficult to maintain a Maven build system, and I would like to switch to Gradle as soon as I can.

I've been working with Maven for over four years. I would call myself an expert on build systems because in the last (at least) five companies I've been in, I've done major renovations on the build/deploy infrastructure.

Some of the lessons I've learned:

• Most developers tend not to spend a lot of time thinking about build systems; as a result, the build turns into a spaghetti mess of hacks, but they do appreciate it when that mess is cleaned up and rationalized.
• In dealing with complexity, I would rather have a transparent system that exposes the complexity (like Ant) than one that tries to make complex things simple by imposing rigid restrictions, like Maven. Think of Linux vs. Windows.
• Maven has a lot of holes in functionality which require byzantine workarounds. This leads to POM files that are incomprehensible and unmaintainable.
• Ant is super-flexible and understandable, but Ant files can get pretty big too, because it's so low-level.
• For any significant project, developers have to create their own build/deploy structure beyond what the tool provides; the suitability of the structure to the project has a lot to do with how easy it is to maintain. The best tools will support you in creating a structure and not fight you.

I've looked into Gradle a bit and it looks like it has the potential to be the best of both worlds, allowing a mix of declarative and procedural build description.

It's more complicated than the language you used to write your project. Getting it configured right is harder than actual programming.

I've struggled my way through most/all the negatives mentioned here, and similar objections from teammates, and agree with them all. But I've stuck it out and will continue to do so by holding firm to the one objective that only maven (or gradle perhaps) really delivers on.

If you're optimizing for peers (open source developers), ant/make/whatever will do. If you're delivering functionality to non-peers (users), only maven/gradle/etc will do.

Only maven lets you release a small bundle of source code + poms (no embedded lib/binary dependency jars with cryptic names and no dependency info) with a well documented standard project layout that can be loaded by any IDE by someone that hasn't absorbed the developers' idiosyncratic layout conventions. And there's a one-button install procedure (mvn install) that builds everything while acquiring any missing dependencies.

The result is an easy on-ramp those users can follow to find their way into the code, where the poms can point them to relevant documentation.

Apart from that (indispensible) requirement, I dislike maven as much as anyone.

ReferenceURL : https://stackoverflow.com/questions/861382/why-does-maven-have-such-a-bad-rep