[java] 왜 소수의 사람들이 Maven을 사용합니까? 대체 도구가 있습니까?



Answers

IMO Maven은 지나치게 엔지니어링 된 Rube Goldberg 머신 또는 Graeme Rocher ( Grails 프로젝트 리드)의 말로 "빌드 도구의 EJB2" 입니다.

Maven 프로젝트의 목표는 매우 가치 있다고 생각합니다. 컨벤션에 대한 협약? 큰! 자동 종속성 해결? 감독자! 그러나 불행하게도이 관행은 이론과 매우 다릅니다. 내 경험에 비추어 볼 때 이전에 Ant로 빌드 된 프로젝트에 Maven을 도입 할 때마다 해결해야 할 문제보다 더 많은 문제가 발생했습니다. 한 경우에 메이븐 (Maven)은 우리 시대의 많은 부분을 차지하기 시작하여 결국 앤트 (Ant)로 다시 이주했다.

나는 Maven이 서로에 의존하는 수많은 프로젝트를 만들고 개발이 널리 분산되어 있다면 고통의 가치가 있다고 생각합니다. 그러나 단일 응용 프로그램을 작성하고 "이 디렉토리의 항목에서 WAR 빌드"와 같은 간단한 작업을 수행하려는 경우 Maven에서 마일을 실행할 것입니다.

내가 Maven과 협의 한 문제는 Maven의 규칙과 달리 실행해야하는 경우 실제로는 매우 융통성이 없다는 것입니다. 몇 가지 사소한 경우에 (예를 들어 소스 폴더의 이름을 src 에서 source 변경하는 등) 이러한 규칙을 무시할 수 있지만 일부 규칙은 프로젝트별로 하나의 아티팩트와 같이 돌로 설정되는 것처럼 보입니다. 생성물이 .war 파일 인 Maven 웹 프로젝트의 예제를 보자. 이제 우리는 .var 파일 이름에 현재 SVN 개정 번호를 포함하고자한다고 상상해보십시오. 이것은 달성하기가 특히 어려워야하는 것처럼 보이지 않지만, 이미이 작업을 수행하는 플러그인을 찾을 수 없다면, 달성하기 위해 자신 만의 플러그인을 작성해야 할 것입니다. 이는 사소한 작업이 아닙니다. Maven의 라이프 사이클 및 목표 모델을 이해해야합니다.

대안에 관한 질문의 두 번째 부분에 대답하려면 : 저는 개인적으로 사용하지 않았지만 Gradle 에 관해 아주 좋은 것을 들었습니다. 이전에 Maven으로 빌드 된 Spring 및 Hibernate와 같은 많은 양질의 JVM 프로젝트가 최근에 Gradle로 전환되었습니다.

Question

저는 Java를 처음 사용하고 개발을 시작할 때 프로젝트 관리를 위해 Maven을 추천했습니다. 나는 거의 즉시 그 도구가 필수 불가결하다는 것을 깨달았고, 그 당시 나는 모든 프로그래머가 그것을 사용하고 있다고 생각했다. 그러나 NetBeans 사이트에서 통계를 볼 때 나는 놀랐다. 67 %의 개발자가 Maven을 사용하지 않고있다. 왜? 프로젝트 관리를 쉽게하는 대체 도구가 있습니까?

최신 정보

나는 100 %에 feicipet와 동의한다.

  1. IDE 독립성은 정말 좋습니다. 이것은 내 자신의 경험으로 입증되었습니다. 먼저 우리 팀이 이클립스를 사용한 다음 IDEA를 사용하여 프로젝트를 도와 준 사람들 인 NetBeans로 전환하기로 결정했습니다. 그리고 프로젝트가 콘솔에서도 실행될 수 있기 때문에 중요하지 않습니다. :)

  2. 잘 구조화되고 깨끗한 프로젝트. 테스트와 메인 코드가 분리되어 있기 때문에 Maven 구조 규칙이 매우 유용하다고 생각합니다.

  3. 프로젝트 관리. Maven은 빌드 도구 일뿐만 아니라 환경을 구성하고 단위 테스트를 실행하며 보고서를 작성할 수있는 기능을 제공합니다.

필자는 경험이 많은 프로그래밍이 Maven의 어려움에 대해 이야기 할 때 놀랐다. Maven의 어떤 프로젝트에서 Ant가 나를 보았을 때 Maven은 나를 기적으로 보았다. 그리고 Ant에서 전환의 복잡성에 대한 모든 의견은 이상합니다. 이것은 두 가지 논리입니다. 무엇을 기대합니까?

문서화에 몇 가지 문제가 있습니다. 이것은 정말 나쁩니다. 그러나 나는이 상황이 더 나은 방향으로 바뀔 것이라고 생각한다.




Maven은 확실히 당신의 스타일에 경련을 일으킬 수 있습니다. 내가 상호 의존성을 가진 프로젝트를 엄청나게했기 때문에 나는 개미 빌드를 maven으로 전환했다. 나는 짐을 싸울 준비가되어 있지만 짐승 주위에 머리가있는 것 같지 않습니다.

많은 문제가 문서화됩니다. 정식 가이드는 종종 여러분이 지금 일어나고있는 완전히 다른 문제에 대한 포럼 게시물 또는 답변입니다.

이 가이드와 같이화물을 사용하는 방법 : maven-cargo 플러그인 웹 사이트에서 찾지 못한 maven에서 통합 테스트를하는 동안 외부 프로세스를 시작 하는 것입니다.하지만 우연히 를 통해 이동했기 때문입니다.

그러나 당신이 그 mojo와 그 다음 cargo 페이지를 볼 때, 평균 (개발자)에게 그것을 이해할 수 있습니까?

어쩌면 피고는 자본주의와 같고, 다른 모든 것을 제외하면 최악의 경우 일 것입니다.




I think maven is like object oriented programming in that it is hard to master after years of structured programming but it has strong benefits over imperative tools like Ant. I love maven even though I must admit it took me around 3 days to learn it to a sub-comfortable level and implement it with existing eclipse wtp projects with dependent projects and lots of external jars, and with eclipse and m2e. Once learned and implemented, it is way easier now and much more cleaner and organized.

I think that Maven has been massively adopted and I have to disagree with the statement that "so few people use Maven". If one googles for MVN Respository, or visit the SpringSource.org site one finds how many useful libraries and projects are built with Maven.




Maven은 Ant와 같은 도구에 비해 상대적으로 높은 진입 장벽으로 인해 어려움을 겪고 있다고 생각합니다. 이전 버전의 어려움과 2.0의 복잡성으로 인해 저를 멀리했습니다. 특히 IDE가 좋은 경우에는 100 % 필요하지 않습니다.




EBuild is a modern alternative to Maven.

We use it for all our development. It's really good. However, I must qualify that by stating that my brother wrote it.

It simply manages / builds all your projects for you. You check out a project, and ebuild handles the rest. It fetches all dependencies and builds them. When you are ready to release, the release script then produces the build for you.

Currently it is geared to being used with Eclipse and only works with SVN (designed with the intention to support other SCMs such as GIT etc).




Maven 기반 프로젝트 구조를 사용하면 SoC (Separation of Concerns)를 쉽게 적용 할 수 있습니다. 잘못하고 순환 종속성을 얻는다면, Maven은 빌드되지 않습니다.

릴리스, 관심 분리 및 종속성 관리와 함께 사용되는 Maven은 규율입니다.

만일 당신이 그 주위를 "해킹"하고 싶다면, 당신은 할 수 있습니다. 그러나 다시, 나는 Maven을 훈련으로 사용할 것을 제안 할 것이다. 훈련을 통해 팀을 운영 할 수 있습니다. 여러 분야를 택하면 (Maven에서 하나의 프로젝트를, Gradle에서 하나의 프로젝트 빌드) 말하면 인생은 여러 번 더 단단해진다.

새로운 분야로의 전환은 그것이 존재해야하는 이유에 대한 회사의 폭 넓은 인식을 필요로합니다. 소규모 팀이 아니라면 시간이 지남에 따라 훈련을 계속하십시오. Maven이 왔습니다.

Netbeans 개발자는 다른 사람들이 수행하기 때문에 Netbeans 개발자가하지 마십시오. 그것은 다른 사람들이하기 때문에 하나님을 믿는 것과 같습니다.

모두들 선상에 있다면 Gradle을 사용해보십시오.




이미 말했듯이, 진입 장벽이 높습니다. 이미 이미 빌드 스크립트 / 도구를 잘 구축해 놓은 많은 수의 오래된 프로젝트가 있습니다. 대부분의 경우 이미 maven과 작동하는 것을 대체하는 것은 의미가 없습니다.

부족한 / 흩어져있는 문서도 도움이되지 않습니다. 정말 좋은 자습서는 sonatype으로 작성된 전체 길이의 책입니다. 누군가에게 독서를 요청한 후 플러그인이 어떻게 독창적으로 작동 하는지를 배우는 것이 좋습니다. 목적은 pom.xml을 빌드 / 관리하여 프로젝트 구축 / 관리 방법을 정의하는 것입니다.

그 말로는 메이븐 (maven)은 훌륭한 도구입니다.




내가 만난 많은 Maven 불평은이 blog 항목에 나열되고 응답되었습니다. 제 경험은 자바 개발자들이 프로젝트를 완전히 제어하는 ​​데 익숙하다는 것입니다. 그들이 Maven에 반대하는 많은 이유는 기본적으로 "개미가 아니거나"내가 개미처럼 할 수없는 X "입니다.

분명히 유효한 불만이 있습니다. 설명서는 종종 비참하고 학습 곡선이 가파르고 구성이 상세합니다. 너무 많은 컨벤션이 관련되어 있기 때문에 무언가가 잘못되었을 때 플러그인에 결함이나 기능 / 버그가 있는지 판단하기가 어려울 수 있습니다.

네거티브가 주어지면 사람들이 자신이 알고있는 것 (개미 / 무엇이든)과 함께 가고 "일을 함"으로 나아갈 수있을 때 빌드 툴에서 시간과 노력을 투자하는 것을 싫어할 것입니다. 고객은 빌드 프로세스가 얼마나 섹시하지 않은지 신경 쓰지 않습니다.




메이븐 (Maven)은 훌륭한 툴입니다. 개념과 worlflow는 우리가 소프트웨어를 만들기 위해 테이프 코드를 함께 사용했을 때부터 지금까지는 큰 도약이었습니다. (지금은 1M LOC 이상의 레거시 Deplhi 앱으로 다이빙하고 있습니다. .. 아픈 고통 ... 얼마나 많이 내가 Maven을 놓치는 지)

이것은 말하고있다. IMHO maven은 여전히 ​​초기 단계에 있지만, 문서화는 이전보다 훨씬 좋지만 아직까지는 얻을 수 없다. 플러그인 컨트롤은 여전히 ​​빌드 환경을 완전히 제어하기 어려울 수 있다는 점에서 몇 가지 단점이 있습니다. 또한 시스템의 동작이 한 버전에서 다음 버전으로 많이 변경되므로 안정적인 빌드를 제 시간에 보장하기 어렵습니다.

그래서 사람들이 왜 Maven에서 Ant로 돌아가는지를 볼 수 있습니다. Ant 사용자를위한 Maven은 클라이언트에게 앱을 배포하기 시작할 때 안정적인 버전 관리를 원할 때 일반적인 설치 편집증에 잘 맞지 않는 불확실한 불확실성을 조성하는 많은 마법 속성 및 동작을 가지고 있습니다.

이 모든 노력에도 불구하고 올바른 방향으로 나아가고 있으며 느린 침투는 관리가 가능한 범위 내에서 시스템의 성장을 유지하여 문제가 시간 내에 다림질 될 것이기 때문에 실제로 "좋은 점"입니다.

Ant를 빌드 시스템으로 학습하는 것이 빌드의 요구 사항과 어려움을 이해하는 데 도움이되므로 더 나은 첫 번째 단계 일 수 있습니다. 또한 Maven이 원하는대로 동작하지 않으면 Ant로 돌아가서 더 큰 그림에 통합 할 수 있습니다.

메이븐 (Maven)이 성취하고자하는 목표는 훌륭하고 도로는 매우 복잡합니다. 그러나 Age of Information에서 세상이 어떻게 될지 추정 해보면 종속성을 수동으로 처리하면 Maven의 한 측면만을 명명하는 것이 곧 불가능해질 것이라는 것을 빨리 깨닫게됩니다.

메이븐 (Maven)이 채택 부족으로 실패 할 경우 컨피규레이션에 대한 개념 만 남겨두면 이미 좋은 결과를 얻었을 것입니다 ...

...하지만 그것은 그렇게 많이 더 있습니다.

짧은 이야기 짧게 :

  • 도구와 같은 Maven은 필수적이지만, 그것이 성숙되면서 당신을 물 것이다.
  • 빌드 메커니즘에 건전한 다양성을 유지하여 Maven이 특별한 필요를 충족시키지 못하면 항상 다른 간단한 메소드로 돌아갈 수 있습니다.
  • 뉴스 그룹을 구독하고 다른 사람들의 경험에서 많은 것을 읽으십시오. 문서를 작성하는 데 시간이 오래 걸리는 경우가 많으며, 특히 도구에서 피할 수없는 것만큼이나 구식입니다.
  • 귀하의 초기 좌절을 극복하고, 당신의 노력은 당신을 시간 내에 풍성하게 보상 할 것입니다.

내 2 센트




대안에 관해서, Ant를 사용하는 자생 시스템 이외에 내가 아는 유일한 것은 Apache Ivy




Maven makes Project Managers and other (non-developer) human interferences obsolete. So why not? Ok there are some issues and some shortcomings, but for now only ivy gets close enough. Upcoming releases should include a Functional Analysis generation Mojo or even extended integration of continuos build platforms and system set-up Mojo's. Personally I' m really fond of the grails way of handling project dependencies and plugins since a while now. Just love it.




나는 단 한가지를 말합니다. 너무 많은 사람들이 불평을합니다. 어쩌면 완벽한 도구는 아니지만, 많은 불평이있을 수 있습니다 ... 실제로 복잡성이 더해져 일부 도로 블록에 충돌 할 수 있습니다 (발견되지 않았습니다). 무엇이든 해결할 수 없지만) 결국에는 이점을 보게 될 것입니다.

몇 주 전에 Maven을 사용하려고 500 시간 이상을 보냈던 사람 (이것은 그가 주장하는 것)에 대해 읽었습니다 ... Maven 플러그인을 몇 개 작성하고 500 시간 안에 애플리케이션을 빌드 할 수 있습니다.

그리고 그건 그렇고, 그것은 오픈 소스이며, 문제가 발견되면 그것을보고하거나 고치십시오.

  • 실제로 그것이 문제가된다면 나는 그것이 고쳐질 것이라고 확신한다.
  • 그것이 좋은 제안이라면 나는 그것이 고려 될 것이라고 확신한다.

추신. 나는 메이븐 (Maven) 팀의 일원이 아니며 일반 사용자 일뿐입니다.






Related