Maven은 왜 그렇게 나쁜 담당자를 가지고 있습니까? [닫은]

Maven이 얼마나 나쁜지에 대해 인터넷에서 많은 이야기가 있습니다. 나는 몇 년 동안 Maven의 일부 기능을 사용해 왔으며 내 관점에서 가장 중요한 이점은 종속성 관리입니다.

Maven 문서는 적절하지 않지만 일반적으로 무언가를 수행해야 할 때 한 번 알아 내면 작동합니다 (예 : 항아리 서명을 구현할 때). 나는 Maven이 훌륭하다고 생각하지 않지만 그것이 없으면 진정한 고통이 될 몇 가지 문제를 해결합니다.

그렇다면 Maven은 왜 그렇게 나쁜 담당자를 가지고 있으며 앞으로 Maven에서 어떤 문제를 기대할 수 있습니까? 내가 모르는 훨씬 더 나은 대안이 있을까요? (예를 들어, Ivy를 자세히 살펴본 적이 없습니다.)

참고 : 이것은 인수를 유발하려는 시도가 아닙니다. FUD를 지우려는 시도입니다.

약 6 개월 전에 메이븐을 조사했습니다. 우리는 새로운 프로젝트를 시작하고 있었고 지원할 유산이 없었습니다. 즉,

• Maven은 전부 아니면 전무입니다. 또는 적어도 문서에서 알 수있는 한. maven을 개미의 드롭 인 대체품으로 쉽게 사용할 수 없으며 점차 고급 기능을 채택합니다.
• 문서에 따르면 Maven은 모든 거친 꿈을 실현하는 초월적인 행복입니다. 깨달음을 얻으려면 10 년 동안 교재를 묵상하면됩니다.
• Maven은 네트워크 연결에 따라 빌드 프로세스를 만듭니다.
• Maven에는 쓸모없는 오류 메시지가 있습니다. ant의 "Target x does not exist in the project y"를 mvn의 "Invalid task 'run': 유효한 수명주기 단계 또는 plugin : goal 또는 pluginGroupId : pluginArtifactId : pluginVersion : goal"형식으로 목표를 지정해야합니다. 더 많은 정보를 얻으려면 mvn을 -e와 함께 실행하는 것이 좋습니다. 즉, 동일한 메시지를 인쇄 한 다음 BuildFailureException에 대한 스택 추적을 인쇄합니다.

Maven에 대한 나의 싫어하는 부분의 대부분은 Better Builds with Maven에서 발췌 한 다음 내용으로 설명 할 수 있습니다.

누군가가 Maven이 무엇인지 알고 싶을 때, 그들은 보통“Maven이 정확히 무엇인가?”라고 물을 것이고, 짧은 대답을 기대합니다. “그건 빌드 도구이거나 스크립팅 프레임 워크입니다.”Maven은 지루하고 영감을주지 않는 단어가 세 개 이상입니다. 이것은 아이디어, 표준 및 소프트웨어의 조합이며 Maven의 정의를 단순히 소화 된 사운드 바이트로 추출하는 것은 불가능합니다. 혁명적 인 아이디어는 종종 말로 전달하기가 어렵습니다.

내 제안 : 아이디어를 말로 전달할 수 없다면 주제에 대한 책을 쓰려고하지 말아야합니다. 왜냐하면 나는 아이디어를 텔레파시로 흡수하지 않을 것이기 때문입니다.

• 그것은 처음부터 당신에게 단단한 구조를 부과합니다.
• XML 기반이므로 ANT만큼 읽기가 어렵습니다.
• 오류보고는 모호하며 일이 잘못되면 좌초됩니다.
• 문서가 좋지 않습니다.
• 그것은 어려운 일을 쉽게 만들고 단순한 일을 어렵게 만듭니다.
• Maven 빌드 환경을 유지하는 데 너무 많은 시간이 걸리므로 만능 빌드 시스템이 필요하지 않습니다.
• maven에서 버그를 발견하고 잘못 구성하지 않았 음을 파악하는 데 오랜 시간이 걸립니다. 그리고 버그는 존재하고 놀라운 곳에 있습니다.
• 그것은 많은 것을 약속하지만 아름답고 매혹적이지만 감정적으로 차갑고 교활한 연인처럼 당신을 배신합니다.

나는 과거 에 확실히 maven 에 대해 물고 신음했습니다 . 그러나 지금은 그것 없이는 없을 것입니다. 어떤 문제보다 혜택이 훨씬 더 크다고 생각합니다. 주로:

• 표준화 된 프로젝트 구조.
  • 새 개발자가 프로젝트에 참여하는 경우 :
    • Maven 프로젝트라고 말하면 개발자는 프로젝트 레이아웃과 프로젝트 빌드 및 패키징 방법을 알고 있습니다.
    • Ant 프로젝트라고 말하면 개발자는 자세한 설명을 기다리거나 build.xml을 통해 문제를 해결해야합니다.
  • 물론 Ant로 회사 차원의 표준을 부과하는 것은 항상 가능하지만, 더 자주는 당신이 속담을 재창조 할 것이라고 생각합니다.
• 종속성 관리.
  • 외부 라이브러리뿐만 아니라 내부 라이브러리 / 모듈도 있습니다. Nexus 또는 Artifactory 와 같은 Maven 저장소 프록시 서버를 사용해야합니다 .
  • Ivy 로이 중 일부를 수행 할 수 있습니다 . 실제로 필요한 것이 종속성 관리뿐이라면 Ivy를 사용하는 것이 좋습니다.
• 특히 프로젝트 내에서. 나는 작은 하위 프로젝트를 나누는 것이 매우 유용하다는 것을 알았고 maven은 이것을 잘 처리합니다. 개미에게는 훨씬 더 어렵습니다.
• 표준화 된 아티팩트 관리 (특히 nexus 또는 아티팩트 )
• 릴리스 플러그인은 훌륭합니다.
• Eclipse 및 NetBeans 통합은 매우 훌륭합니다.
• 허드슨 과의 통합 은 훌륭합니다. 특히 findbugs와 같은 것에 대한 경향 그래프.
• 사소한 점이지만 maven 이 기본적으로 jar 또는 war (파일 이름뿐만 아니라) 내부에 버전 번호와 같은 세부 정보를 포함한다는 사실 은 매우 유용합니다.

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

• 명령 줄은 도움이되지 않습니다. 이로 인해 시작해야 할 일이 많았습니다.
• XML 형식은 매우 장황합니다. 왜 그렇게되었는지 알 수 있지만 여전히 읽는 것은 고통 스럽습니다.
  • 즉, IDE에서 쉽게 편집 할 수있는 XSD가 있습니다.
• 처음에는 머리를 돌리기가 어렵습니다. 예를 들어 수명주기와 같은 것.
  • 그러나 maven에 대한 확실한 가이드 는 좋은 소개입니다.

저는 전문가를 알아가는 데 약간의 시간을 할애 할 가치가 있다고 믿습니다.

두 개의 대규모 프로젝트에서 얻은 실제 경험은 maven 1에서 maven 2로 이동하는 500 시간의 노력을 제외하고 각 프로젝트에 대해 maven 관련 문제에 대해 1000 ~ 1500 시간을 소비 한 것입니다.

그 이후로 나는 절대적으로 메이븐을 싫어한다고 말해야한다. 생각하면 답답해집니다.

Eclipse 통합은 끔찍합니다. (예를 들어, eclipse가 생성 된 코드와 동기화되어 완전한 재 빌드가 필요한 코드 생성에 끝없는 문제가있었습니다. 비난은 maven과 eclipse 둘 다이지만 eclipse는 maven보다 유용하며 emacs라고 말합니다. 일식이 머무르고 메이븐은 가야합니다.)

우리는 많은 의존성을 가지고 있었고 우리가 발견했듯이 구문 오류는 실제로 공용 Maven 저장소에 커밋되어 귀중한 시간의 시간을 망칠 수 있습니다. 매주. 해결 방법은 프록시 또는 로컬에서 관리되는 저장소를 사용하는 것입니다.이 작업도 제대로 수행하는 데 시간이 많이 걸립니다.

Mavens 프로젝트 구조는 Eclipse를 사용한 개발에는 적합하지 않으며 Eclipse의 빌드 시간이 늘어납니다.

코드 생성 및 동기화 문제의 영향으로, 우리는 코드 / 컴파일 / 테스트주기를 끝없는 컴파일 / 웹 서핑 / 슬립 / 다이 / 코드-주기로 줄여서 90 년대로 바로 돌아가도록 scrach에서 다시 빌드해야했습니다. 40 분 컴파일 시간.

maven의 유일한 변명은 종속성 해결이지만 모든 빌드가 아닌 가끔씩 그렇게하고 싶습니다.

요약하면, maven은 가능한 한 KISS에서 멀리 떨어져 있습니다. 또한 옹호자는 나이가 소수 일 때 생일을 추가로 축하하는 유형의 사람들 인 경향이 있습니다. 저에게 투표 해주세요 :-)

Maven은 훌륭합니다. 그 명성에 대한 이유는 가파른 학습 곡선과 관련이 있다고 생각합니다. (드디어 넘어 가기 직전)

문서가 이해하기 시작하기 전에 이해해야 할 많은 텍스트와 새로운 사항이있는 것처럼 느껴지기 때문에 문서를 살펴보기가 약간 어렵습니다. 나는 Maven이 더 널리 칭찬받는 데 필요한 모든 것입니다.

Maven은 성인 남성을 절대적인 공포의 집단으로 만드는 장치이기 때문입니다.

장점 :

• 종속성 관리. 이미 몇 년 동안 동료와 저는 종속성을 수동으로 다운로드하고 관리하지 않습니다. 이것은 엄청난 시간 절약입니다.
• IDE 독립성. 모든 주요 IDE, Eclipse, IDEA 및 NetBeans가 Maven 프로젝트를 제대로 지원하므로 개발자가 하나의 특정 IDE에 얽매이지 않습니다.
• 명령 줄. Maven을 사용하면 동시 IDE 및 명령 줄 구성을 지원하는 것이 간단하여 지속적인 통합에 적합합니다.

단점 :

• Maven 학습에 투자해야합니다. 글쎄요. 좋은 소식입니다. 팀원 모두가 배워야하는 것은 아닙니다.
• 선적 서류 비치. 예전 에는 문제 였지만 이제는 Sonatype과 그들의 책 ( http://www.sonatype.com/products/maven/documentation/book-defguide ) 덕분에 상황이 훨씬 나아졌습니다.
• 강성. 원하는 방식으로 일을하는 것은 때때로 도전적이고 좌절감이 있습니다. 내 조언은 Maven이 최선을 다하고, 간단한 빌드를하거나, 안정적인 모조를 사용할 수있을 때 싸우고 메이븐이하도록 만드는 것이 아닙니다. 다른 경우에는 Ant 작업 ( http://maven.apache.org/plugins/maven-antrun-plugin/ ) 또는 외부 프로그램을 중단하고 작업을 수행 합니다. 개인적으로 가장 좋아하는 것은 Groovy plugun ( http://groovy.codehaus.org/GMaven )입니다.

경쟁:

• Ant : 종속성 관리가 없습니다. 기간.
• Ivy : Maven보다 아직 성숙하지 않습니다 (후자에도 별다른 문제가 없습니다). 거의 동일한 기능 세트이므로 이동할 이유가 없습니다. 나는 그것을 시도하기 위해 여러 번 시도했다. 모두 실패했습니다.

결론 : 우리의 모든 프로젝트는 이미 몇 년 동안 Maven으로 완료되었습니다.

가장 단순하고 복잡한 프로젝트를 맡은 사람들에게 나쁜 평판을 받고 있다고 생각합니다.

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

5 개의 WAR 파일, 3 개의 EJB 및 17 개의 기타 도구, 종속성 jar 및 최종 빌드 중에 기존 리소스의 MANIFEST.MF 및 XML 파일을 조정해야하는 구성을 사용하여 9 개의 EAR 파일 프로토 타입 세트에서 하나의 EAR을 빌드하는 경우 Maven은 너무 제한적일 수 있습니다. 이러한 프로젝트는 복잡한 중첩 프로필, 속성 파일 및 Maven 빌드 목표 및 분류 자 ​​지정의 오용으로 인해 엉망이됩니다.

따라서 복잡성 곡선의 하위 10 %에 있으면 과잉입니다. 그 곡선의 상위 10 %에서는 구속복을 입은 상태입니다.

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

내 경험은 여기에있는 많은 게시물의 좌절감을 반영합니다. Maven의 문제는 궁극적 인 자동 마법의 장점을 추구하면서 빌드 관리의 세부 사항을 감추고 숨긴다는 것입니다. 이것은 깨지면 거의 무력하게 만듭니다.

내 경험에 따르면 maven의 모든 문제는 근관과 유사한 경험에서 중첩 된 xml 파일의 웹을 통해 여러 시간 동안의 도적 사냥으로 빠르게 퇴화되었습니다.

또한 Maven에 크게 의존하는 상점에서 일한 적이 있습니다. Maven을 좋아하는 사람들 ( "버튼 누르기, 모두 완료"측면에서 좋아함)은 이해하지 못했습니다. 메이븐 빌드에는 백만 개의 자동 타겟이 있었는데, 그들이 한 일을 읽는 데 몇 시간을 투자하고 싶다면 유용 할 것이라고 확신합니다. 당신이 완전히 이해하는 더 나은 2 개의 목표.

주의 사항 : 2 년 전에 Maven과 마지막으로 작업했지만 지금은 더 좋을 수 있습니다.

Glenn과 마찬가지로 Maven이 나쁜 담당자가 아니라 혼합 담당자라고 생각합니다. 저는 6 개월 동안 독점적으로 큰 프로젝트 프로젝트를 Maven으로 마이그레이션하려고 노력해 왔으며 도구의 한계를 분명히 보여줍니다.

내 경험상 Maven은 다음에 적합합니다.

• 외부 의존성 관리
• 빌드의 중앙 집중식 관리 (pom 상속)
• 많은 것을위한 많은 플러그인
• 지속적인 통합 도구와 매우 잘 통합
• 매우 우수한보고 기능 (FindBugs, PMD, Checkstyle, Javadoc, ...)

그리고 다음과 같은 몇 가지 문제가 있습니다.

• 모두 또는 전혀 접근하지 않음 (Maven으로 천천히 마이그레이션하기 어려움)
• 컴플렉스 종속성, 모듈 간 종속성
• 주기적 의존성
• 일관성 (버전 범위가 모든 곳에서 동일하게 작동하지 않음)
• 버그 (버전 범위와 함께)
• 재현 가능한 빌드 (모든 플러그인의 버전 번호를 수정하지 않는 한 6 개월 내에 동일한 빌드를 얻을 수 있을지 확신 할 수 없음)
• 문서 부족 (문서는 기본에 상당히 적합하지만 대규모 프로젝트를 처리하는 방법에 대한 예제는 많지 않습니다)

컨텍스트를 제공하기 위해 약 30 명의 개발자가이 프로젝트에 참여하고 있으며이 프로젝트는 5 년 이상 진행되었습니다. 따라서 많은 레거시, 많은 프로세스가 이미 준비되어 있고, 많은 사용자 지정 독점 도구가 이미 준비되어 있습니다. 독점 도구를 유지하는 데 드는 비용이 너무 높아서 Maven으로 마이그레이션하기로 결정했습니다.

이 포럼에서 제기 된 몇 가지 불만 사항에 대응하고 싶습니다.

Maven은 전부 아니면 전무입니다. 또는 적어도 문서에서 알 수있는 한. maven을 개미의 드롭 인 대체품으로 쉽게 사용할 수 없으며 점차 고급 기능을 채택합니다.

이것은 사실이 아닙니다. Maven의 큰 승리는이를 사용하여 합리적인 방식으로 종속성을 관리하는 것입니다. Maven에서이를 수행하고 ant에서 다른 모든 작업을 수행하려면 가능합니다. 방법은 다음과 같습니다.

<?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 ant tasks jar를 ant의 lib 디렉토리에 넣는 것입니다.

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

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

그것은 처음부터 당신에게 단단한 구조를 부과합니다.

이것이 파일 형식 또는 '컨벤션 대 구성'문제를 참조하는지 명확하지 않습니다. 후자의 경우 Java 소스 파일 및 리소스의 예상 위치 또는 소스의 호환성과 같은 보이지 않는 기본값 이 많이 있습니다. 그러나 이것은 강성이 아닙니다. 그것은 당신을 위해 합리적인 기본값을 제공하므로 명시 적으로 정의 할 필요가 없습니다. 모든 설정은 매우 쉽게 재정의 할 수 있습니다 (초보자는 문서에서 특정 사항을 변경하는 방법을 찾기가 어려울 수 있음).

파일 형식에 대해 이야기하고 있다면 다음 부분의 응답에서 다룹니다.

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

우선, '개미보다 낫지 않다'는 것의 일부 측면이 나쁜 rep을 갖는 이유에 대해 어떻게 불평 할 수 있는지 모르겠습니다. 둘째, 여전히 XML이지만 XML의 형식은 훨씬 더 정의되어 있습니다. 더욱이, 그렇게 정의 되었기 때문에 POM을위한 합리적인 두꺼운 클라이언트 편집기를 만드는 것이 훨씬 쉽습니다. 나는 여기 저기 뛰어 다니는 페이지 긴 개미 빌드 스크립트를 보았습니다. 개미 빌드 스크립트 편집기는 더 이상 맛있게 만들지 않을 것이며 약간 다른 방식으로 제시된 상호 연결된 작업의 또 다른 긴 목록 일뿐입니다.

여기에서 제가 본 적이있는 몇 가지 불만이 있으며, 그 중 가장 큰 것은

• 문서가 불량 / 누락 됨
• 재현 가능한 빌드
• Eclipse 통합이 나쁘다
• 버그

내 대답은 두 가지입니다. 첫째, Maven은 Ant 또는 Make보다 훨씬 젊은 도구이므로 이러한 애플리케이션의 성숙도 수준에 도달하는 데 시간이 걸릴 것으로 예상해야합니다. 둘째, 마음에 들지 않으면 수정하십시오 . 그것은 오픈 소스 프로젝트이고 그것을 사용하고 누군가가 해결할 수있는 것에 대해 불평하는 것은 나에게 상당히 어리석은 것처럼 보입니다. 문서가 마음에 들지 않습니까? 초보자가 더 명확하고 완벽하거나 더 쉽게 접근 할 수 있도록 기여하세요.

재현 가능한 빌드 문제는 버전 범위와 자동 Maven 플러그인 업데이트의 두 가지 문제로 나뉩니다. 플러그인 업데이트의 경우 1 년 후 프로젝트를 다시 빌드 할 때 똑같은 JDK와 똑같은 Ant 버전을 사용하고 있는지 확인하지 않는 한 이것은 다른 이름을 가진 동일한 문제입니다. 버전 범위의 경우 모든 직접 및 전이 종속성에 대해 잠긴 버전으로 임시 pom을 생성하고 메이븐 릴리스 수명주기의 일부로 만드는 플러그인 작업을 권장합니다. 그러면 릴리스 빌드 형식이 항상 모든 종속성에 대한 정확한 설명이됩니다.

그것은 그 명성을받을 자격이 있습니다. 모든 사람이 Maven의 개발자가 모든 단일 프로젝트에 적합하다고 생각한 견고한 구조가 필요한 것은 아닙니다. 너무 유연하지 않습니다. 그리고 많은 사람들에게 'Pro'인 의존성 관리는 IMHO의 가장 큰 '단점'입니다. 나는 maven이 네트워크에서 jar를 다운로드하는 것을 절대적으로 편하지 않고 비 호환성으로 인해 잠을 잃습니다 (예, 오프라인 모드가 있지만 왜 수백 개의 xml 파일과 체크섬이 있어야합니까?). 내가 사용하는 라이브러리를 결정하고 많은 프로젝트가 네트워크 연결에 의존하는 빌드에 대해 심각한 우려를 가지고 있습니다.

더 나쁜 것은 일이 작동하지 않으면 절대적으로 길을 잃는 것입니다. 문서가 형편없고 커뮤니티는 단서가 없습니다.

1 년 후 나는 이것을 업데이트하고 싶었다. 나는 더 이상 Maven 커뮤니티에 대한이 의견을 가지고 있지 않다. 오늘 질문이 있다면이 답변을 쓰지 않을 것입니다. 현재 의견을 별도의 답변으로 추가하겠습니다.

이것은 매우 주관적인 대답이지만 질문은 의견에 관한 것이므로 ...

나는 Maven을 좋아하고, 내가 알게 될수록 더 좋아한다. 그러나 그것에 대한 내 감정에 영향을 미치는 한 가지는 : maven 커뮤니티는 주로 Sonatype ( "the maven company", 많은 Maven honchos가 일하고있는 곳입니다)을 중심으로하고 있고 Sonatype은 회사 제품을 커뮤니티에 꽤 공격적으로 추진하고 있습니다.

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

죄송합니다. 그 "소개"는 절반은 정보이고 절반은 Nexus에 대한 판매 프레젠테이션입니다. 팝 퀴즈 : Nexus 및 Nexus Pro 외에 다른 리포지토리 관리자가 있습니까? 또한 이것이 오픈 소스 Maven Book과 어떤 관련이 있습니까? 아, 맞습니다. 저장소 관리에 관한 장은 Nexus에 대한 별도의 책으로 분리되었습니다. 허. Maven 책에 기여하면 Nexus 판매를 늘리면 추천 수수료를 받게 되나요?

Java 개발 포럼에 참여하고 있고 Java를 논의하는 Sun 직원이 NetBeans 및 "NetBeans Pro"에 대해 이야기 할 수있는 모든 기회를 잡을 것이라는 것이 분명하다고 상상해보십시오. 잠시 후 커뮤니티 느낌을 잃습니다. 나는 Ant와 같은 경험을 한 적이 없습니다.

모든 것을 말했듯이 Maven은 소프트웨어 개발 구성 및 빌드 관리를위한 매우 흥미롭고 유용한 시스템이라고 생각합니다 (나는 Ant와 같은 도구라고 부르지 않습니다. 의존성 관리는 때때로 축복이자 저주이지만 신선하고 Maven이 제공하는 유일한 이점은 아닙니다. 나는 아마도 Sonatype 실링에 대해 너무 강하게 반응하고 있지만, 내 생각으로는 Maven을 연상시키기 때문에 아프다. 이 의견이 다른 사람과 공유되는지는 모르겠습니다.

Maven은 프로젝트에 구조를 부과하기 때문에 나쁜 평가를받는다고 생각하지만 Ant와 같은 다른 도구를 사용하면 원하는 방식으로 구조를 완전히 정의 할 수 있습니다. 문서가 나쁘다는 것도 동의했지만 Maven이 얻는 나쁜 랩은 사람들이 Ant에 너무 익숙하기 때문이라고 생각합니다.

너무 많은 마법.

불만족 한 사람들은 불만을 품고 만족하는 사람들은 만족한다고 말하지 않기 때문입니다. 내 요점은 만족스럽지 않은 것보다 훨씬 더 만족스러운 maven 사용자가 있지만 나중에 더 많은 소음을 낸다는 것입니다. 이것은 실제 생활에서도 흔히 볼 수있는 패턴입니다 (ISP, 전화 통신사, 교통 수단 등).

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

• 신뢰할 수없는 원격 저장소;
• SNAPSHOT 버전 또는 버전이없는 플러그인 및 라이브러리에 대한 종속성.

이것을 장황하고 귀찮은 IMO에도 불구하고 모든 병이 로컬로 체크인되기 때문에 작동하는 개미 빌드와 대조하십시오.

좋은 부분은 문제를 해결할 수 있다는 것입니다.

• 자신의 Maven 저장소를 사용하십시오. 이것은 매우 간단 해졌습니다. 저는 Archiva 를 좋은 결과로 사용하고 있습니다.
• 항상 종속성을 적절하게 버전 화하십시오. Maven은 2.0.8 또는 2.0.9로 시작하는 super-POM에서 플러그인 버전을 잠그기 시작했으며 모든 종속성은 릴리스 된 버전에 있어야합니다.

좋은 생각-잘못된 구현.

최근에 Ant에서 Maven으로 프로젝트를 옮겼습니다. 결국 잘 작동했지만 한 버전에서 작동하는 것이 다른 버전에서 손상 되었기 때문에 동일한 pom (두 개의 프로필이 있음)에서 두 가지 버전의 maven-assembly-plugin 및 maven-jar-plugin을 사용해야했습니다.

그래서 그것은 꽤 두통이었습니다. 문서가 항상 좋은 것은 아니지만 Google 답변이 비교적 쉬웠다는 것을 인정해야합니다.

사용하는 플러그 버전을 항상 지정해야합니다. 새 버전이 이전 버전과 호환 될 것이라고 기대하지 마십시오.

메이븐이 아직 진화하고 있고 그 과정이 때때로 고통 스럽다는 사실에서 논란이 있다고 생각합니다.

문안 인사

V.

나는 메이븐을 좋아한다. 1.0 이전부터 사용했습니다. 균형 잡힌 상태에서 상당한 시간을 절약하고 개발 인프라를 개선 한 강력한 도구입니다. 그러나 나는 어떤 사람들이 가진 좌절감을 이해할 수 있습니다. 나는 3 가지 유형의 좌절감을 본다.

1. 원인이 실제 문제인 경우 (예 : 자세한 POM, 문서 부족)
2. 일부는 잘못된 정보입니다 (예 : "구축하려면 인터넷 연결이 필요합니다"-사실이 아님-피할 수 있습니다).
3. 일부는 maven에서 배출되지만 실제로 다른 사람은 과실이 있습니다 ( "메신저를 쏘지 마십시오").

첫 번째 경우 실제 문제-물론 문제가 있고 POM이 장황하고 문서가 더 좋을 수 있습니다. 그럼에도 불구하고 maven으로 빠른 시간에 좋은 결과를 얻을 수 있습니다. 나는 ant로 빌드 된 프로젝트를 얻을 때마다 움찔하고 이것을 내 IDE로 가져 오려고합니다. 디렉토리 구조를 설정하는 데 시간이 오래 걸릴 수 있습니다. Maven에서는 IDE에서 POM 파일을 여는 경우 일뿐입니다.

두 번째 경우, Maven은 복잡하고 오해가 흔합니다. Maven 3이 이러한 복잡성 (또는인지 된 복잡성)을 해결할 방법을 찾을 수 있다면 좋을 것입니다. maven은 상당한 투자를하지만, 제 경험상 투자는 그 자체로 빠르게 보상을받습니다.

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

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

각 프로젝트에 대한 종속성을 수동으로 포함하는 접근 방식 (한 포스터에서는 모든 종속성을 소스 제어에 확인한다고합니다)은 라이브러리가 종속성에 대한 업데이트를 확인하지 않고 업데이트 될 때 간과되는 업데이트와 같이 잘못된 종속성을 사용할 위험이 있습니다. 모든 규모의 프로젝트에서 종속성을 수동으로 관리하면 오류가 발생할 수 있습니다. Maven을 사용하면 사용하는 라이브러리 버전을 업데이트 할 수 있으며 올바른 종속성이 포함됩니다. 변경 관리를 위해 이전 종속성 집합 (프로젝트 전체에 대한)을 새 집합과 비교할 수 있으며 모든 변경 사항을 면밀히 조사하고 테스트 할 수 있습니다.

Maven은 종속성 문제의 원인이 아니지만 더 잘 보입니다. 종속성 문제를 해결할 때 maven은 버전 제어에서 수동으로 관리되는 jar의 경우처럼 암시 적이 아닌 명시 적으로 종속성을 "조정"(종속성을 재정의하는 POM 변경)합니다. 날씨가 올바른지 여부를 지원하십시오.

나는 대부분의 비방 자들이 Maven + Hudson + Sonar 의 조합을 관찰하지 않았기 때문에 Maven이 나쁜 rep을 가지고 있다고 생각합니다 . 그렇다면 "어떻게 시작해야하나요?"라고 물을 것입니다.

Maven에 대한 내 애완 동물의 일부 :

• XML 정의는 매우 서투르고 장황합니다. 속성에 대해 들어 본 적이 없습니까?

• 기본 구성에서는 항상 모든 작업에서 '넷'을 샅샅이 뒤집니다. 이것이 유용한 지 여부에 관계없이 "깨끗한"인터넷 액세스가 필요한 것은 매우 어리석은 것처럼 보입니다.

• 다시 기본적으로 정확한 버전 번호를 지정하지 않으면 최신 버전이 종속성 오류를 유발하는지 여부에 관계없이 최신 업데이트를 '넷에서 가져옵니다. 즉, 다른 사람들의 의존성 관리의 자비에 놓여 있습니다.

• 이 모든 네트워크 액세스에 대한 해결책은 -o옵션 을 추가하여 끄는 것 입니다. 하지만 정말로 의존성 업데이트를하고 싶다면 그것을 끄는 것을 기억해야합니다!

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

• Maven 빌드는 엄청나게 느립니다. 네트워크 업데이트를 조작하면이 문제가 완화되지만 Maven 빌드는 여전히 느립니다. 그리고 끔찍하게 장황합니다.

• Maven 플러그인 (M2Eclipse)은 Eclipse와 가장 잘 통합되지 않습니다. Eclipse는 버전 제어 소프트웨어 및 Ant와 합리적으로 원활하게 통합됩니다. Maven 통합은 비교해 볼 때 매우 투박하고 추합니다. 천천히 언급 했나요?

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

좋은 질문. 저는 방금 직장에서 대규모 프로젝트를 시작했으며 이전 프로젝트의 일부는 코드 기반에 모듈성을 도입하는 것이 었습니다.

메이븐에 대해 나쁜 얘기를 들었습니다. 사실, 내가 들어 본 전부입니다. 나는 우리가 현재 겪고있는 의존성 악몽을 해결하기 위해 그것을 도입하는 것을 검토했습니다. 내가 Maven에서 본 문제는 구조가 매우 엄격하다는 것입니다. 즉, 작업을 수행하려면 프로젝트 레이아웃을 준수해야합니다.

나는 대부분의 사람들이 무엇을 말할지 압니다. 구조를 따를 필요는 없습니다. 사실 그것은 사실이지만, 당신은 너무 많은 시간을 투자하여 모든 것을 버리는 초기 학습 곡선을 넘어 설 때까지 이것을 알지 못할 것입니다.

개미는 요즘 많이 사용되며 나는 그것을 좋아합니다. 이를 고려하여 아파치 아이비 ( Apache Ivy) 라고 불리는 약간 알려진 의존성 관리자를 우연히 발견했습니다 . Ivy는 Ant에 매우 잘 통합되며 기본 JAR 검색 설정 및 작업을 빠르고 쉽게 수행 할 수 있습니다. Ivy의 또 다른 이점은 매우 강력하면서도 투명하다는 것입니다. scp 또는 ssh와 같은 메커니즘을 사용하여 빌드를 매우 쉽게 전송할 수 있습니다. 파일 시스템 또는 원격 저장소에 대한 '체인'종속성 검색 (Maven 저장소 호환성은 인기있는 기능 중 하나입니다).

즉, 결국 사용하는 것이 매우 답답하다는 것을 알았습니다. 문서는 많지만 잘못된 영어로 작성되어 디버깅이나 잘못된 문제를 해결하려고 할 때 좌절감을 더할 수 있습니다.

이 프로젝트의 어느 시점에서 Apache Ivy를 다시 방문 할 예정이며 제대로 작동하기를 바랍니다. 한 가지는 팀으로서 우리가 의존하는 라이브러리를 파악하고 문서화 된 목록을 얻을 수 있도록 허용하는 것입니다.

궁극적으로 나는 모든 방법에 내려 오는 생각 은 개인 / 팀과 무슨 일을 당신이 당신의 의존성 문제를 해결해야합니다.

Ivy와 관련된 다음 리소스가 유용 할 수 있습니다.

• Apache Ivy와 Maven 2 비교
• Apache Ivy FAQ
• Apache Ivy 기능 목록

저는 Maven을 좋아합니다-생산성을 높이고 더 이상 Ant를 사용하지 않는다는 것이 매우 기쁩니다 (phew!)

그러나 내가 일을 바꿀 수 있다면 그것은 다음과 같을 것입니다.

1. 하다 pom.xml파일을 덜 장황하게
2. 저장소가 아닌 .jars를 쉽게 포함 할 수 있습니다.

사람들이 Maven을 좋아하지 않는 데는 많은 이유가 있지만, 그들은 매우 주관적 입니다. 좋은 (그리고 무료) 책, 더 나은 문서, 더 큰 플러그인 세트 및 많은 참조 성공 프로젝트 빌드가있는 Maven은 1 년 또는 2 년 전과 같은 Maven이 아닙니다.

단순한 프로젝트에서 Maven을 사용하는 것은 매우 쉽습니다. 더 크고 복잡한 프로젝트에서는 Maven 철학에 대한 더 많은 지식과 심층적 인 이해가 필요합니다. 회사 수준에서는 네트워크 관리자와 같은 Maven 전문가의 입장 일 수 있습니다. Maven 혐오 문구의 주요 출처는 종종 무지 입니다.

Maven의 또 다른 문제는 Ant와 같은 유연성 부족입니다. 그러나 기억하는 Maven에는 일련의 관습이 있습니다. 처음에는 그것들을 고수하는 것이 어려운 것처럼 보이지만 결국에는 종종 문제에서 벗어나는 경우가 많습니다.

Maven의 현재 성공은 그 가치를 증명합니다. 물론 아무도 완벽하지 않으며 Maven에는 단점과 단점이 있지만 내 생각에는 Maven이 천천히 상대를 흔들고 있습니다.

나는 그것이 혼합 된 rep을 가지고있는만큼 나쁜 rep을 가지고 있다고 말하지 않을 것이다. 프로젝트가 Maven이 옹호하는 "컨벤션에 대한 관례"패러다임을 따르는 경우 많은 이점을 얻을 수 있습니다. 프로젝트가 Maven의 세계관에 잘 맞지 않으면 부담이 될 수 있습니다.

이를 위해 프로젝트를 제어 할 수 있다면 Maven이 갈 길일 수 있습니다. 그러나 그렇지 않고 레이아웃이 Maven의 팬이 아닌 사람에 의해 결정되면 가치보다 더 문제가 될 수 있습니다. 가장 행복한 Maven 프로젝트는 아마도 Maven 프로젝트로 시작된 프로젝트 일 것입니다.

나에게는 사내 프로젝트에 maven 대 ant를 사용하는 것에 대한 단점만큼 많은 장점이 있습니다. 그러나 오픈 소스 프로젝트의 경우 Maven이 많은 프로젝트를 훨씬 쉽게 빌드하는 데 큰 영향을 미쳤다고 생각합니다. 평균적인 OSS Java (ant 기반) 프로젝트를 컴파일하고 수많은 변수를 설정하고 종속 프로젝트를 다운로드하는 데 몇 시간이 걸렸습니다.

Ant로 할 수있는 모든 것을 Maven으로 할 수 있지만 Ant가 표준을 권장하지 않는 경우 Maven은 구조를 따르도록 강력히 제안합니다. 그렇지 않으면 더 많은 작업이 수행됩니다. 사실, 어떤 것들은 Ant로 쉽게 할 수있는 Maven으로 설정하는 데 고통 스럽지만 최종 결과는 거의 항상 프로젝트를 확인하고 가고 싶어하는 사람들의 관점에서 빌드하기 더 쉬운 것입니다.

개발 프로젝트에 사업이나 직업을 걸고 자한다면, 기초, 즉 빌드 시스템을 관리하고 싶을 것입니다. Maven을 사용하면 제어 할 수 없습니다. 선언적이고 불투명합니다. 메이븐 프레임 워크 개발자는 투명하거나 직관적 인 시스템을 구축하는 방법을 알지 못하며 이는 로그 출력과 문서에서 분명합니다.

의존성 관리는 프로젝트 초기에 당신과 같은 시간을 가질 수 있지만 경고를받을 수 있기 때문에 매우 유혹적입니다. 근본적으로 깨져 결국 많은 골칫거리가 될 것입니다. 두 종속성에 호환되지 않는 일시적 종속성이 있으면 전체 팀의 빌드를 무너 뜨리고 며칠 동안 개발을 차단하는 복잡한 복잡성에 의해 차단됩니다. Maven을 사용한 빌드 프로세스는 로컬 리포지토리의 일관성없는 상태로 인해 팀의 여러 개발자에게 일관성이없는 것으로 악명이 높습니다. 개발자가 환경을 만든시기 또는 작업중인 다른 프로젝트에 따라 결과가 달라집니다. 전체 로컬 저장소를 삭제하고 Maven이 dev 브랜치를 처음 설정할 때보 다 훨씬 더 자주 jar를 다시 다운로드하도록하는 것을 알 수 있습니다. 저는 OSGI가이 근본적인 문제를 해결하려는 시도라고 생각합니다. 뭔가 너무 복잡해야한다면 근본적인 전제가 잘못된 것 같습니다.

저는 5 년 넘게 maven 사용자 / 피해자였으며 소스 저장소에 대한 종속성을 확인하고 멋지고 간단한 개미 작업을 작성하는 데 훨씬 더 많은 시간을 절약 할 수 있다고 말해야합니다. ant를 사용하면 빌드 시스템이 수행하는 작업을 정확히 알 수 있습니다.

저는 Maven 문제로 인해 여러 회사에서 몇 주 동안 많은 시간을 잃었습니다.

나는 최근에 오래된 GWT / Maven / Eclipse 프로젝트를 되살리려 고 시도했고 2 주 후에 모든 여가 시간을 가져 왔지만 여전히 일관되게 빌드 할 수 없습니다. 내 손실을 줄이고 개미 / 일식을 사용하여 개발할 시간입니다.

짧은 대답 : Maven 빌드 시스템을 유지하는 것이 매우 어렵다는 것을 알았으며 가능한 한 빨리 Gradle로 전환하고 싶습니다.

저는 Maven과 4 년 넘게 일했습니다. 내가 근무했던 마지막 (적어도) 5 개 회사에서 인프라 구축 / 배포에 대한 대대적 인 개조 작업을 수행했기 때문에 스스로를 구축 시스템 전문가라고 부를 것입니다.

내가 배운 몇 가지 교훈 :

• 대부분의 개발자는 빌드 시스템에 대해 생각하는 데 많은 시간을 소비하지 않는 경향이 있습니다. 결과적으로 빌드는 스파게티 엉망진창으로 변하지 만, 그 엉망이 정리되고 합리화되면 감사합니다.
• 복잡성을 다룰 때 나는 Maven과 같은 엄격한 제한을 적용하여 복잡한 것을 단순하게 만드는 것보다 복잡성을 노출하는 투명한 시스템 (예 : Ant)을 선호합니다. Linux 대 Windows를 생각해보십시오.
• Maven에는 비잔틴 해결 방법이 필요한 기능에 많은 구멍이 있습니다. 이로 인해 이해할 수없고 유지 관리 할 수없는 POM 파일이 생성됩니다.
• Ant는 매우 유연하고 이해하기 쉽지만 Ant 파일도 매우 낮기 때문에 상당히 커질 수 있습니다.
• 중요한 프로젝트의 경우 개발자는 도구가 제공하는 것 이상으로 자체 빌드 / 배포 구조를 만들어야합니다. 프로젝트에 대한 구조의 적합성은 유지 관리가 얼마나 쉬운 지와 많은 관련이 있습니다. 최고의 도구는 구조를 만드는 데 도움이되고 싸우지 않습니다.

저는 Gradle을 조금 살펴 보았고 선언적 및 절차 적 빌드 설명의 혼합을 허용하여 두 세계 모두에서 최고가 될 가능성이있는 것처럼 보입니다.

프로젝트 작성에 사용한 언어보다 더 복잡합니다. 올바르게 구성하는 것은 실제 프로그래밍보다 어렵습니다.

여기에 언급 된 대부분의 / 모든 부정적인 점과 팀원의 유사한 이의 제기를 통해 어려움을 겪었으며 모두 동의합니다. 그러나 나는 그것을 내 놓았고 maven (또는 아마도 gradle)만이 실제로 제공하는 하나의 목표를 확고하게 유지함으로써 계속 그렇게 할 것입니다.

동료 (오픈 소스 개발자 ) 를 위해 최적화하는 경우 ant / make / whatever가 수행합니다. 비 동료 ( users ) 에게 기능을 제공하는 경우 maven / gradle / etc 만 수행합니다.

Maven만이 흡수하지 않은 사람이 IDE에서로드 할 수있는 잘 문서화 된 표준 프로젝트 레이아웃을 사용하여 소스 코드 + poms의 작은 번들 (암호화 된 이름이있는 임베디드 라이브러리 / 바이너리 종속성 jar 없음)을 릴리스 할 수 있습니다. 개발자의 특이한 레이아웃 규칙. 그리고 누락 된 종속성을 획득하면서 모든 것을 빌드하는 원 버튼 설치 절차 (mvn install)가 있습니다.

그 결과 사용자가 코드에 대한 길을 찾기 위해 따라갈 수있는 쉬운 진입로가 있으며, 여기서 poms는 관련 문서를 가리킬 수 있습니다.

그 (필수적 인) 요구 사항을 제외하고는 누구보다 maven을 싫어합니다.