[java] 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 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으로 완료되었습니다.