Buildr, Gradle 또는 Maven 3을 기다리시겠습니까?
나는 항상 Maven 2로 고군분투하는 것에 지쳤습니다. 빌드 도구가 방해가되어서는 안됩니다. 최근에 저는 Buildr와 Gradle을보고 있습니다. Maven 3은 일부 어려움을 해결하는 것 같습니다. 그래서 지금은 무엇을해야합니까? 빌드? Gradle? 아니면 Maven 3을 기다리시겠습니까?
어떤 빌드 시스템도 마법의 총알이 아닙니다. Maven이 나에게 발생하는 것보다 더 많은 문제를 해결한다는 것을 알지만, 단점을 보완하기 위해 플러그인을 작성하는 것이 매우 편하고 수백 개의 프로젝트도 처리하므로 Maven의 상속 및 종속성 처리가 나에게 상당히 도움이됩니다.
조금 찾아 보면 Buildr와 Gradle 모두 문제가 있음을 알 수 있습니다 (Ant와 Ivy의 경우 동일), 일반적으로 한 세트의 문제를 다른 문제와 거래하고 가장 고통스럽지 않은 경우를 찾습니다.
Maven에 대해 특별히 신경 쓰이는 부분이 있습니까? 아니면 일반적인 가려움증입니까? 특정 문제인 경우 Jira 에서 Maven 3 문제를 살펴볼 가치가 있습니다 . 문제가 해결되지 않으면 문제를 제기 할 수 있습니다. 그렇지 않으면 대기 중에 약간의 요점이있을 수 있습니다.
나는 Maven 3에서 너무 많은 것을 기대하지 않을 것이다. 빌드 도구의 Maven 혈통 뒤에있는 사람들은 항상 프로젝트 빌드가 동종이라는 가정을 가지고 있었다. 즉, 모든 빌드 문제는 근본적으로 동일한 문제로 귀결된다. 이 세상에 대한 견해는 반대되는 견해에 직면하여 상당히 일관되게 유지 될 수 있지만 대가가 따릅니다. Maven에 스크립팅 로직이없는 경우 ( "당신이 뭔가 잘못하고 있다는 것을 알고있는 스크립트를 작성하고 싶을 때"), 번거로운 플러그인 API ( "일반적인 Maven 사용자는 플러그인을 작성하고 싶어하지 않음") 및 중앙 저장소 ( "we 모두 동일한 종속성을 갖습니다. ")는 모두이 중요한 가정의 증거입니다.
사람들이 다양한 이유로 소프트웨어를 빌드하기 때문에 현실 세계에서 빌드 문제는 이기종입니다. 그들은 우리 모두처럼 독특한 문제를 해결하기 위해 때때로 '드릴 구멍'을 '개발'합니다. 추상화 수준에 관계없이 임의의 빌드 문제를 비교할 때 항상 유사점을 찾을 수 있습니다. 이러한 유사점에 대한 존경과 Maven의 디자인에 대한 몰락 인 차이점에 대한 비난과 그것이 그토록 많은 결함을 유발하는 이유입니다. 기본적으로 Maven은 그 전망에서 권위주의적이고 유토피아 적입니다.
추신 : Maven은 구성에 대한 관례 및 저장소 사용 아이디어와 같은 좋은 기능을 가지고 있습니다 (이 아이디어의 Maven 구현은 번거 롭습니다).
여기서는 Maven을 사용하지만 간단한 프로젝트를 벗어나면 pom.xml이 점점 더 복잡해지기 시작합니다. 원하는 작업을 수행하도록 pom을 구성하는 방법과 다양한 문제를 해결하는 방법을 찾는 데 많은 시간을 할애합니다.
저를 진정으로 얻은 것은 우리가 만들고있는 귀였습니다. 우리는 귀 파일에 여러 전쟁이 있으며 Maven은 일반적으로 전쟁에서 라이브러리를 고수합니다. 그러나 전쟁의 크기를 줄이고 항아리를 모두 동일하게 유지하기 위해 우리는 전쟁간에 공유되는 항아리를 ear의 lib 디렉토리에 넣고 싶었습니다.
불행히도 Maven은 이것을 잘 처리하지 못합니다. 우리는 각 전쟁의 poms에 대해 이것을 수동으로 구성한 다음 이러한 모든 종속성을 ear 's pom에 추가해야했습니다.
다른 프로젝트에는 HTML 기반 도움말 파일이 있습니다. 도움말을 작성하는 사람들은이를 Microsoft Word로 작성한 다음 프로그램을 사용하여 HTML로 번역합니다. 단일 문자 변경은 수백 개의 파일에 반향을 일으킬 수 있습니다.
이 문제를 해결하기 위해 도움말 시스템은 소스 저장소에 단일 압축 파일로 저장됩니다. 문서 팀이 새로운 도움말 파일 세트를 만들면 압축하여 저장소에있는 파일을 대체합니다.
그래서 내 빌드의 일부는이 파일의 압축을 풀고 전쟁에 배치하는 것입니다. Ant에서 수행하기 쉬우 며, 완전한 플러그인 없이는 Maven이 처리 할 수없는 문제를 처리하기 위해 Ant 코드를 작성할 수있는 Antrun 플러그인을 사용하지 않는 한 Maven에서 수행 할 수 없습니다.
Maven이 무엇을하는지 볼 수 있지만 이론은 현실보다 앞서 있습니다. 내가 찾은 것은 Ivy와 Ant가 Pom을 작성하고 유지하는 모든 문제없이 Maven이 수행하는 대부분의 종속성 검사를 수행 할 수 있다는 것입니다.
Maven을 아직 사용하고 있지 않다면 먼저 Ant with Ivy를 사용해보십시오. 그런 다음 Maven 3이 나오면 시도하십시오. Maven 1에서 Maven 2 로의 전환이 기억납니다. 그들은 서로 완전히 호환되지 않았고 Maven 1을 사용하여 배운 모든 것은 쓸모가 없습니다. Maven 2에서 프로젝트를 배우고 다시 실행하여 갑자기 Maven 3의 모든 것을 다시 실행하는 것을 발견하는 것은 어리석은 일입니다.
maven 3.x는 이미 IDE에 포함되어 있습니다 (적어도 netbeans에서는 이 링크 에서 자세한 정보를 확인하십시오 ). netbeans로 Maven 프로젝트를 빌드하기 만하면 maven 3.x로 오늘 플레이 할 수 있습니다.
또 다른 좋은 소식은 maven이 IDE 프로젝트에서 EJB / WS를 통합함으로써 더 많은 '엔터프라이즈'지원을 받았다는 것입니다 (최소한 netbeans에서).
따라서 프로덕션 빌드에는 maven 2.x를 고수하고 개발에는 maven 3.x를 사용합니다.
Maven 2와 3은 모두 다양한 프로젝트에서 완벽하게 작동했습니다. 저는 현재 Eclipse Maven 플러그인과 함께 특히 잘 작동하는 Maven 3 alpha 7을 사용하고 있습니다.
Maven은 양방향으로 Ant와 원활하게 통합됩니다. 현재 프로젝트에서는 복잡한 통합 테스트를 수행하기 위해 Ant에서 Maven을 여러 번 호출합니다. 마찬가지로 우리는 Maven의 AntRun 플러그인을 통해 Ant를 사용하고 자체 Maven 플러그인도 작성했습니다. 그건 그렇고, 이것은 몇 분의 문제이며 주석이 달린 Pojo를 작성하는 것으로 요약됩니다.
Maven은 많은 개발자가 규칙이나 규칙을 좋아하지 않기 때문에 많은 결함을 얻습니다. 간단히 말해서 아무도 Maven을 사용하도록 강요하지 않습니다. 궁극적 인 자유를 원한다면 참여하는 모든 프로젝트에 대해 자신 만의 빌드 프로세스를 다시 작성하십시오. 그러나 모든 프로젝트에서 맞춤형 빌드 프로세스를 사용하여 바퀴를 재창조하는 것보다 소프트웨어를 만들고 싶다면 Maven을 선택하십시오.
코드를 잘 유지 관리하고 잘 정의 된 모듈로 분리하면 빌드 시스템 간의 이식이 사소한 문제가됩니다.
현재로서는 maven-2가 중간 2/3 프로젝트에 적합한 선택입니다. 정말 간단하지만 개미는 여전히 괜찮습니다. 정말 복잡한 경우 maven-2와 기타 도구 (antrun 등)의 하이브리드가 불가피합니다.
maven-2에 문제가있는 이유를 잘 모르겠습니다.
빌드 프로세스를 스크립팅하는 것이 아니라 설명하는 도구라는 점에서 ant 및 buildr와 다릅니다. 복잡한 빌드, 다중 동적 부분 및 중첩 및 / 또는 일시적 종속성이있는 빌드는 설명하기 어렵 기 때문에 빌드하기 어렵습니다.
Lattice https://github.com/hackingspirit/Lattice 를 사용해보세요. 나는 저자입니다. 다음은 특종입니다.
Lattice에서 빌드 파일은 XML이 아니라 Python 언어로 작성됩니다. 이점은 훨씬 더 나은 가독성과 Python에서 지원하는 강력한 명령형 빌드 스크립팅입니다. 다중 모듈 프로젝트의 경우. Lattice는 토폴로지 정렬을 사용하여 각 모듈을 빌드하는 올바른 순서를 결정합니다. 또한 Lattice는 모듈 컴파일을 병렬화 할 수있는 방법을 결정하기 위해 모듈 종속성을 분석 할 계획입니다. Lattice의 소스 코드는 매우 간결하며 현재 약 500 줄의 Python 소스 코드로 구성됩니다.
Maven에 대해 불평하는 사람들은 사용 가능한 플러그인을 조사하는 데 약간의 시간을 투자해야한다고 생각합니다. Maven이 견고하고 사용자 정의 빌드 로직을 사용하기 어렵게 만들고 빌드 프로세스에 대한 세밀한 제어를 제공한다고 불평하는 의견에 대한 응답으로 Maven 용 Ant 플러그인을 살펴 보는 것이 좋습니다 (실제로는 여러 개가 있지만 여기에 하나가 있습니다) : http://maven.apache.org/plugins/maven-antrun-plugin ). 수년에 걸쳐 Maven 빌드를 커스터마이징하는 데 큰 성공을 거두었습니다. 기본적으로 Maven 빌드의 일부로 Ant 명령을 실행할 수 있으며 Ant로 거의 모든 작업을 수행 할 수 있습니다.)
Ant with Ivy는 Maven이 수행하는 것과 동일한 종속성 관리를 수행하지만 (사실 동일한 URL 저장소를 포함하는 Maven의 전체 종속성 관리 인프라를 사용함) 모든 POM 구성이 엉망이되지 않습니다.
Ant with Ivy might be a way of handling the dependency issues for people who really don't want to use Maven. It solves 90% of the stuff that Maven was suppose to solve.
참고URL : https://stackoverflow.com/questions/1306579/buildr-gradle-or-wait-for-maven-3
'IT Share you' 카테고리의 다른 글
| Selenium WebDriverException을 수정하는 방법 : 연결하기 전에 브라우저가 종료 된 것 같습니다. (0) | 2020.12.03 |
|---|---|
| cout은 무엇을합니까 <<“\ n”[a == N]; (0) | 2020.12.03 |
| NSTextField에서 Enter-Key를 눌렀을 때 액션을 실행합니까? (0) | 2020.12.02 |
| 가시성 : 숨김 및 표시 간의 성능 차이 : 없음 (0) | 2020.12.02 |
| iOS 11 navigationItem.titleView 너비가 설정되지 않음 (0) | 2020.12.02 |