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은 이것을 잘 처리합니다. 개미에게는 훨씬 더 어렵습니다.
- 표준화 된 아티팩트 관리 (특히 넥서스 또는 아티팩트 와 함께 )
- 릴리스 플러그인은 훌륭합니다.
- 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 파일에 수동으로 나열해야합니다.
최종 빌드 중에 기존 리소스의 MANIFEST.MF 및 XML 파일을 조정해야하는 5 개의 WAR 파일, 3 개의 EJB 및 17 개의 기타 도구, 종속성 jar 및 구성의 일부 조합을 사용하여 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으로 천천히 마이그레이션하기 어려움)
- 컴플렉스 종속성, 모듈 간 종속성
- 순환 의존성 (나도 안다, 나쁜 디자인,하지만 우리는 5 년의 개발을 고칠 수 없다 ...)
- 일관성 (버전 범위가 모든 곳에서 동일하게 작동하지 않음)
- 버그 (버전 범위와 함께)
- 재현 가능한 빌드 (모든 플러그인의 버전 번호를 수정하지 않는 한 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은 그보다 더 광범위합니다). 의존성 관리는 때때로 축복이자 저주이지만 신선하고 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 가지 유형의 좌절감을 본다.
- 원인이 실제 문제인 경우 (예 : 자세한 POM, 문서 부족)
- 일부는 잘못된 정보입니다 (예 : "구축하려면 인터넷 연결이 필요합니다"-사실이 아님-피할 수 있습니다).
- 일부는 maven에서 배출되지만 실제로 다른 사람은 과실이 있습니다 ( "메신저를 쏘지 마십시오").
첫 번째 경우 실제 문제-물론 문제가 있고 POM이 장황하고 문서가 더 좋을 수 있습니다. 그럼에도 불구하고 maven으로 빠른 시간에 좋은 결과를 얻을 수 있습니다. 나는 ant로 빌드 된 프로젝트를 얻을 때마다 움찔하고 이것을 내 IDE로 가져 오려고합니다. 디렉토리 구조를 설정하는 데 시간이 오래 걸릴 수 있습니다. Maven에서는 IDE에서 POM 파일을 여는 경우 일뿐입니다.
두 번째 경우, Maven은 복잡하고 오해가 흔합니다. Maven 3이 이러한 복잡성 (또는인지 된 복잡성)을 해결할 방법을 찾을 수 있다면 좋을 것입니다. maven은 상당한 투자를하지만, 제 경험상 투자는 그 자체로 빠르게 보상을받습니다.
마지막으로, maven의 전 이적 의존성에 대한 불만이 아마도 가장 잘 알려진 예라고 생각합니다.
Transitive dependencies are the nature of real software employing reuse. Windows DLLs, Debian packages, java packages, OSGi bundles, even C++ header file includes all have dependencies and suffer the dependency problem. If you have two dependences, and each uses a different version of the same thing, then you have to try to resolve that somehow. Maven doesn't try to solve the dependency problem, but rather brings it to the forefront, and provides tools to help manage the problem, such as by reporting conflicts and providing consistent dependencies for a hierarchy of projects, and in fact provides absolute control over a project's dependencies.
The approach of manually including dependencies with each project (one poster says he checks all dependencies into source control) is runing the risk of using the wrong dependency, such as overlooked updates when a library is updated without checking in updates for it's dependencies. For a project of any size, managing dependencies manually is surely going to lead to errors. With maven, you can update the library version you use and the correct dependencies are included. For change management, you can compare the old set of dependencies (for your project as a whole) with the new set, and any changes can be carefully scrutinized, tested etc.
Maven isn't the cause of the dependency problem, but makes it more visible. In tackling dependency issues, maven makes any dependency "tweaks" explicit (a change to your POM overriding the dependency), rather than implicit, as is the case with manually managed jars in version control, where the jars are simply present, with nothing to support weather they are the correct dependency or not.
I believe that Maven has a bad rep because most detractors have not observed the combination of Maven + Hudson + Sonar. If they had, they would be asking "how do I get started"?
Some of my pet peeves with Maven:
The XML definition is super clumsy and verbose. Have they never heard of attributes?
In its default configuration, it always scours the 'net on every operation. Regardless of whether this is useful for anything, it looks extremely silly to need Internet access for "clean".
Again in the default, if I'm not careful to specify exact version numbers, it will pull the very latest updates off the 'net, regardless of whether these newest versions introduce dependency errors. In other words, you're placed at the mercy of other peoples' dependency management.
The solution to all this network access is to turn it off by adding the
-ooption. But you have to remember to turn it off if you really want to do dependency updating!Another solution is to install your own "source control" server for dependencies. Surprise: Most projects already have source control, only that works with no additional setup!
Maven builds are incredibly slow. Fiddling with network updates alleviates this, but Maven builds are still slow. And horribly verbose.
The Maven plugin (M2Eclipse) integrates most poorly with Eclipse. Eclipse integrates reasonably smoothly with version control software and with Ant. Maven integration is very clunky and ugly by comparison. Did I mention slow?
Maven continues to be buggy. Error messages are unhelpful. Too many developers are suffering from this.
Good question. I've just started a large project at work and part of previous projects was to introduce modularity to our code-base.
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:
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:
- Make
pom.xmlfile less verbose - 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.
참고URL : https://stackoverflow.com/questions/861382/why-does-maven-have-such-a-bad-rep
'Programming' 카테고리의 다른 글
| UIStackView 내부에 추가 된 뷰에 선행 패딩을 추가하는 방법 (0) | 2020.08.19 |
|---|---|
| grunt : 터미널에서 실행할 때 명령을 찾을 수 없음 (0) | 2020.08.19 |
| 한때 마음에 들었던 프로그래밍 관행에 대해 마음이 바뀌 었습니까? (0) | 2020.08.19 |
| Linux에서 MbUnit, F # 프로젝트 내에서 사용됩니까? (0) | 2020.08.19 |
| GMSGroundOverlay 애니메이션-CATiledLayer를 사용해야합니까? (0) | 2020.08.19 |