이미 Eclipse가있는 경우 Maven 또는 Ant가 필요한 이유는 무엇입니까?
이 질문은 Compare to the IDE for Java 의 확장이라고 생각합니다. 여전히 Ant가 필요합니까?
위의 질문에 대한 답변이 있지만 Eclipse에서만 Maven 또는 Ant를 사용하는 구체적인 예를 알고 싶습니다.
Eclipse에서 개발할 때 Eclipse가 모든 작업을 수행하므로 실행 버튼을 클릭하기 만하면됩니다. 또한 Eclipse를 사용하면 코드를 실행 가능한 jar 또는 Windows 용 .exe로 내보낼 수 있습니다.
그래서 왜 Maven이나 Ant가 필요한지 모르겠습니다.
또한 필요한 경우 Maven 또는 Ant 중 어느 것을 선택해야합니까?
- 동료가 NetBeans 또는 IDEA를 선호 할 수 있기 때문에
- 설정이 Eclipse 설치마다 다를 수 있기 때문에
- 종속성을 자동으로 얻고 싶을 수 있기 때문에
- 빌드, jar, 정적 코드 분석 적용, 단위 테스트 실행, 문서 생성, 일부 디렉토리에 복사, 환경에 따라 일부 속성 조정 등 전체 빌드를 자동화하고 싶기 때문입니다.
- 자동화 된 후에는 변경 될 때마다 또는 매시간마다 애플리케이션을 빌드하는 지속적인 통합 시스템을 사용하여 모든 것이 여전히 빌드되고 테스트가 여전히 통과하는지 확인할 수 있습니다.
- Maven은 구성에 대한 규칙을 사용하기 때문입니다.
- IDE가 필요한 멋진 코드 생성 / 변환을 지원하지 않을 수 있기 때문입니다.
- 빌드 스크립트가 빌드 프로세스를 문서화하기 때문입니다.
Eclipse는 개발 환경입니다. 그러나 그것은 빌드 도구가 아닙니다.
나는 개인적으로 Maven을 싫어하지만 YMMV. gradle, buildr 등 많은 대안이 있습니다.
Maven은 autoconf가 최첨단 코드 자동화라고 생각하고 객체 코드 에 객체 환경이 있어야 한다는 사실을 이해하지 못하는 과거의 날짜별로 판매 된 c-shell 스크립트 꼬마들이 작성한 무언가의 경우로 저를 때립니다 . 개발이나 배포에 효율적입니다. Ant는 충분히 나빴지 만 Maven은 Ant와 Ivy의 모든 최악의 기능을 결합합니다. 그것은 개체 환경을 만들지 않으며, 그렇게하는 도구와 잘 작동하지 않습니다.
간단히 말해, 객체 환경에는 모든 클래스 객체, 즉 시스템에서 사용할 수있는 객체 유형을 결정하는 객체가 있어야하며 항상 사용 가능해야합니다. 거기에서 내가 원하는 것은 무엇이든 할 수 있고, 클래스의 여러 객체를 인스턴스화하고, 다양한 시퀀스 및 인스턴스화 규칙을 설정하는 등의 작업을 수행 할 수 있습니다. 환경이 완전히 활성화되어야하므로 필요 하지 않습니다.빌드 도구입니다. 내 앱을 배포하는 측면에서 내 앱을 구성하는 네임 스페이스의 코드에서 참조하지 않는 모든 클래스 개체를 환경이 단순히 폐기하는 것은 어렵지 않습니다. JVM의 가비지 수집기는 오늘날 거의 동일한 작업을 수행합니다. 그 시점에서 나는 내 객체와 내 객체가 참조하는 모든 객체 (주로 클래스 객체), 즉 내 애플리케이션과 모든 종속성으로 구성된 배포 환경을 갖게됩니다. 이것이 가상 머신이 작동하는 방식입니다. (우리의 VM이 너무 잘못 작성 되었기 때문에 다른 Linux VM의 VMWare VM에서 Linux VM의 Java VM에서 Spring VM을 실행해야하는 것은 소프트웨어 개발의 또 다른 예입니다). 종속성이 업데이트되면 환경에서 개발자에게 이전 코드를 새 라이브러리에 병합하라는 메시지를 표시하는 것은 간단합니다. 새 라이브러리를 사용하여 코드를 이전 버전으로 병합하거나 두 버전을 모두 유지하십시오. 프롬프트는 개발자가 모든 라이브러리의 20 개 버전을 피하는 데 필요한 약간의 수정을 수행하도록 권장하는 반면, Maven과 같은 도구는 사용자가 20 개 버전을 가지고 있다는 사실을 숨기고 결과적으로 Java 앱에서 일반적으로 막대한 런타임 팽창을 초래합니다.
Java 개발 공간에서 Eclipse는 적절한 객체 환경에 가장 가깝지만 다양한 방식으로 패러다임을 깨는 플러그인이 많이 있습니다. Maven을 사용하는 대부분의 이유는 비판적으로 살펴보면 무너집니다.
Netbeans 및 Idea는 개체 환경이 아니라 과장된 텍스트 편집기이지만 수천 개의 Eclipse 플러그인에서 다루지 않는 도구를 사용하려는 경우 둘 다 Eclipse 프로젝트를 가져오고 유지할 수 있으며 빌드가 개발자에 비해 지나치게 느립니다. Eclipse를 사용하지만 어쨌든 순수한 Netbeans 또는 Idea 프로젝트라면 속도가 느릴 것입니다.
Maven을 사용하는 심각한 이유는 아닙니다.
Eclipse에서 설정 내보내기 / 가져 오기의 용이성 (모든 팀이 어떤 경우 에든 IDE에서 수행해야하는 작업)은 개발 팀의 게으름 (또는 공백 대 탭에 대한 종교적 논쟁, 웃음)에 지나지 않고 다양한 설정 문제를 만듭니다. .
다시 말하지만 Maven을 사용하는 심각한 이유는 아닙니다.
팀 환경? GIT 또는 SVN과 같은 저장소를 아직 사용하지 않는 팀을 보여주세요. Nexus 리포지토리도 설정하여 기능과 유지 관리 문제를 모두 복제해야하는 이유는 무엇입니까?
그것은 실제로 Maven을 사용 하지 않는 좋은 이유 입니다.
서버 빌드를 실행 중입니까? 이제 넥서스로 푸시되는 무작위 빌드가 아니라 실제로 소스 리포지토리에 체크인 된 코드로 시작하면 안 되나요? 이것은 Git, 특히 Maven을 사용한 Git에 대한 요점을 제시합니다. Git에서는 브랜치에서 작업하지 않고 로컬로 테스트 한 다음 커밋 (부분적으로 로컬 테스트가 Jenkins와 Eclipse의 Maven 구성의 차이로 인해 서버 빌드가 작동 함을 증명하지 않기 때문에)에 변경 사항을 커밋해야합니다. 서버 Maven 빌드가 실패했는지 확인하기 위해 다른 분기를 찾은 다음 문제를 해결하기 위해 추가 변경을 커밋하여 저장소에서 읽을 수없는 소스 기록을 만듭니다. 체크인 된 코드는 최소한 단위 테스트를 빌드하고 통과해야합니다. Git과 Maven이 그림에서 벗어나면 보장되어야합니다.
Eclipse에서 헤드리스 빌드를 내보내는 것은 실제로 살펴보면 간단합니다. 필요한 것은 ant 또는 Gradle, Eclipse에서 이미 유지 관리하는 개발자 빌드 및 몇 가지 Eclipse jar (Eclipse는 헤드리스 빌드에 필요한 모든 파일을 디렉토리 또는 zip 파일 또는 ftp를 빌드 서버로 전송). Hudson / Jenkins와 같은 서버 빌드 도구는 대부분의 소스 저장소에서 업데이트 된 코드를 가져 와서 빌드 스크립트를 호출 할 수 있으며 Maven에 대한 종속성이 없습니다. Maven을 사용하면 개발자가 누구에게도 적합하지 않은 도구를 사용하고 엔지니어를 빌드하도록 강요하거나 (M2E를 사용하더라도 빌드하는 데 걸리는 시간이이 경우에 충분합니다) 또는 서버가 빌드 할 가능성을 가지고 살고 있습니다. 작동하지 않는 꽤 있는 워크 스테이션 빌드처럼 여전히과다한 M2E 플러그인을 사용하여 두 가지를 통합하는 모든 번거 로움을 겪으면 참입니다. 어느 쪽이든 느리고 더 취약한 서버 빌드를 위해 더 느리고 더 취약한 워크 스테이션 빌드를 얻을 수 있습니다. 내가 작업 한 모든 Maven 기반 프로젝트에서 가능한 모든 M2E 플러그인을 설치하고 올바르게 구성 하지 않는 한 Eclipse에 표시되지 않는 일시적인 Hudson / Jenkins 오류를 보았습니다. 대부분의 개발자는 그렇게하지 않습니다.
Maven을 피해야하는 또 다른 큰 이유 인 것 같습니다.
Java 네임 스페이스 및 XML 네임 스페이스를 파괴하는 네임 스페이스, 실제 배포 환경의 어떤 것과도 관련이없는 빌드 단위 (POM)와 같은 Maven의 더 근본적인 문제 중 일부는 다루지 않습니다. POM을 통해 완성 된 제품에서 실제로 무엇을 수행하고 있습니까? 아무것도 아닙니다. 모든 것이 실행 되는 다른 빌드 단위로 관심사와 기능을 분리했다는 잘못된 인식입니다.하나의 단일 코드 조각으로; 복잡한 구성 파일을 수동으로 유지 관리해야하는 번거 로움은 OSGi 또는 다른 컨테이너를 사용해야하고 Maven 구성에 영향을 미치고 이에 영향을받는 다른 구성 파일을 유지해야하는 경우에만 더 악화됩니다. 코드를 실행할 전체 환경없이 단위 테스트를 실행하려고 할 때 발생하는 문제 의존성뿐만 아니라 Maven 특정 플러그인의 무수한 버전 (실제로 여러 Maven 플러그인이 충돌하는 종속성을 사용 하는 Maven 빌드 자체 에서 JAR 지옥을 보았습니다 . Maven이 해결 해야하는 문제 중 하나입니다 .
예, Maven으로 개체 코드를 빌드 할 수 있습니다 . 당신은 할 수 있습니다 또한 C 또는 어셈블러에서 순수 오브젝트 코드를 작성하지만, 당신이 싶어 이유를 모르겠어요.
Maven을 피해야하는 가장 좋은 이유는 위에서 언급 한 모든 문제 (및 언급되지 않은 수많은 문제)에 지쳤을 때 일련의 프로젝트를 de-mavenize하는 데 필요한 엄청난 양의 작업입니다.
개발주기가 코드 작성, 컴파일, 어셈블, 빌드, 배포, 테스트, 다시 반복으로 구성된다는 C 개발에서 물려받은 사고 방식은 개체 환경에서 절망적으로 구식입니다. 어떤 시점에서 우리는 이러한 사고 방식을 가진 모든 사람들에게 개발 방법을 다시 배워야한다고 말할 필요가 있습니다. 이렇게하면 Maven, Git 및 시간 낭비 만하는 다른 도구가 필요하지 않습니다.
개체 개발은 수정 된 개체가 라이브이기 때문에 코드 변경이 저장 될 때 테스트되는 라이브 개체 환경에서 수행되어야합니다. 배포는 해당 환경에서 개발 전용 아티팩트를 제거하고 개발 및 테스트에서 실행중인 앱이 사용하는 모든 것을 포함하는 런타임을 생성하는 것으로 구성되어야합니다.
I'm currently dealing with a problem caused by creating deployment assemblies for an OSGi app using the maven-assembly plugin. The app works perfectly in the Eclipse environment, which hot deploys all code changes into a running OSGi container within the environment. However the configuration doesn't survive intact through the maven-assembly process, despite having a very good configuration/build engineer whose sole job is to accomplish that process. If we got rid of Maven (very difficult now due to the amount of code, but possible) and used the BNDTOOLS Eclipse plugin we could simply export the Eclipse build as an Ant or Gradle headless build (note, the OSGi developers who write BND and BNDTOOLS don't support Maven, and for good reason, the Maven plugin is written by the Felix developers who themselves use Netbeans and Maven, and no live environment other than at the end of the deploy cycle), where both tools set up the same environment as Eclipse, without the GUI objects that are only meant for developers anyway. The result would be an identical configuration and build for deployment. This would easily save 2-3 hours per day per developer currently spent watching slow Maven or M2E builds, and free up the config/build engineer to do more testing of the app on the deployment hosts.
Getting over the mindset of write/compile/assemble/build/deploy/test is the only major impediment. Pretending you're coding on a 1979 VT100 terminal instead of a modern machine doesn't make you a 'real' developer, it just demonstrates that your methods are 35 years out of date.
Of the developers on the team, none of the others properly understands a live object environment like Eclipse sufficiently to get it to work as a live environment with M2E and OSGi, and they are top developers, they just haven't been exposed to it due to the prevalence of outdated command line development tools. They only realized it was possible to do so when we were pair programming to solve the configuration problem and I was sharing my screen, causing one of the other team members to exclaim "that's how you write code so damn fast", when he saw my code change instantly test itself in the background OSGi container. I can use a bash shell when I have to, such as when I'm looking at logs on a remote server, in fact I do so fairly efficiently precisely so I can get out of that environment as quickly as possible and return to the 21st century.
There are soo many advantages to using Ant or Maven.
Maven is more or less an update concept of Ant. Instead of giving you a bullet point answer I have decided to take another approach into answering this question. I'll ask you a simple question. I'am assuming here that you would be a developer; or have some sort of OO programming background.
So If your manager was to ask you to copy two hundred directories, but ignore jar, war and ear files within those directories and once copied. You then deploy those two hundred directories to another destination but deploy only .class files; copy rest of the files into another destination etc.
For you to do this in java; it will be lots of logic, lots of code and would not be extensible or adaptable to change. So that in mind Ant or Maven will accomplish and prepare all this on the fly with less overhead for your application to use. The size of the code in ant or Maven will be 1/4 compare to Java.
Click on the links for more technical benefits:
Ant I could not find an authentic answer with benefits, but I'm sure this would convince you ;)
Maven and Ant are used to script builds so that they may be executed in batch jobs like with Jenkins or on the command line.
In fact Eclipse itself uses Ant extensively to build plugins.
If you were to learn one of the two, learn Maven, it's the one pretty much everyone uses these days (replacing Ant).
Maven is generally used to build the plugins or jars for a particular application.
Suppose you have developed an application but you don't want to go for adding the jars needed for that application manually. In this situation Maven or Ant is very helpful. Once you have written your code just got to Run As -> Maven Build (click on Maven Build) , it will generate all the required plugins or jars and include in your application library build-path. A doubt may come like how the application will get those jars, For each application there is a xml file named as POM.xml where reference of all the jars are kept there for downloading purposes.
참고URL : https://stackoverflow.com/questions/10764576/why-do-we-need-maven-or-ant-if-we-already-have-eclipse
'Programing' 카테고리의 다른 글
| 사용자가 사용을 거부 한 후 사용자에게 위치 서비스를 켜도록 프롬프트하려면 어떻게해야합니까? (0) | 2020.10.30 |
|---|---|
| 내 패키지 내에서 data.table 패키지 사용 (0) | 2020.10.30 |
| Chocolatey와 NuGet의 차이점 (0) | 2020.10.30 |
| C #에서 매일 특정 시간에 메서드를 호출하는 방법은 무엇입니까? (0) | 2020.10.30 |
| Node.js의 이벤트 중심의 차이점은 무엇입니까? (0) | 2020.10.30 |