dmz 개발창고

Maven같은경우는 pom.xml  이란 이름으로 쓰고 (Spring에서),

Gradle은 (스프링부트), (안드로이드) 에서 주로 쓰는것임 

pom?  -Project Object Model

-프로젝트 정보 ,빌드 설정, 빌드 환경 ,POM연관 정보

pom.xml파일을 말하며 Maven의 기능을 이용하기 위해 POM이 사용됨

보통 프로젝트를 진행하게 되면 많은 라이브러리들을 활용해서 개발함

라이브러리들의 수가 수십개가 훌쩍 넘어관리하는 것이 힘들어짐.

Maven은 내가 사용할 라이브러리 뿐만 아니라 해당 라이브러리가 작동하는데 필요한

다른 라이브러리들까지 관리하여 네트워크를 통해 자동으로 다운 받아줌

Maven은 JDK설치와 같이 설치가능.

환경변수 잡아주고 하면 cmd에서 mvn –version을 통해 버전을 알 수 있고 설치가 가능함

Gradle

Gradle이란 빌드 배포 도구임.

안드로이드 앱을 만들때 필요한 공식 빌드시스템이며 JAVA, C/C++, Python 등을 지원함

메이븐의 경우 XML로 라이브러리를 정의하고 활용하도록 되어 있으나, Gradle의 경우 별도의 빌드스크립트를 통하여 사용할 어플리케이션 버전, 라이브러리등의 항목을 설정

특징: 스크립트 언어로 구성 (XML과 달리 변수선언, if, else, for등의 로직이 구현가능)

(메이븐 레파지토리를 동일하게 사용할 수 있어서 설정된 서버를 통하여 라이브러리를 다운로드 받아 모두 동일한 의존성을 가진 환경을 수정가능)

Gradle이 메이븐보다  늦게 나온만큼 사용성, 성능 등 비교적 좋은 스펙!

Gradle이 Maven보다 좋은점

• Build라는 동적인 요소를 XML로 정의하기에는 어려운 부분이 많다.
  • 설정 내용이 길어지고 가독성 떨어짐
  • 의존관계가 복잡한 프로젝트 설정하기에는 부적절
  • 상속구조를 이용한 멀티 모듈 구현
  • 특정 설정을 소수의 모듈에서 공유하기 위해서는 부모 프로젝트를 생성하여 상속하게 해야함 (상속의 단점 생김)
• Gradle은 그루비를 사용하기 때문에, 동적인 빌드는 Groovy 스크립트로 플러그인을 호출하거나 직접 코드를 짜면 된다.
  • Configuration Injection 방식을 사용해서 공통 모듈을 상속해서 사용하는 단점을 커버했다.
  • 설정 주입시 프로젝트의 조건을 체크할 수 있어서 프로젝트별로 주입되는 설정을 다르게 할 수 있다.

속도! Gradle은 메이븐보다 최대 100배 빠르다.

지금 시점에서 Gradle을 사용하지 않을 이유는 익숙함 뿐인 것 같다

( Maven과 익숙해진 XML을 버리고 Gradle과 Groovy문법을 배우는 것은 적지않은 비용이 든다. 특히 협업을 하는 경우, 프로젝트 구성과 빌드만을 위해 모든 팀원이 Groovy 문법을 익혀야 한다는 사실은 Gradle을 사용하는데 큰 걸림돌이 된다.)

(협업과 러닝커브를 고려하여 여전히 Maven을 사용하는 팀이 많고 부족함 없이 잘 사용하고 있지만, 빌드타임 비용문제로 이어질경우 Gradle을 사용해야 할 것 같다. 왜냐하면 Gradle이 Maven보다 최대 100 배 빠르기 때문이다.)

출처

https://gradle.org/
https://maven.apache.org/
http://egloos.zum.com/kwon37xi/v/4747016
https://bkim.tistory.com/13

https://hyojun123.github.io/2019/04/18/gradleAndMaven/

POM은 프로젝트의 구조와 내용을 기술한 것

Project Object Model 

pom.xml 파일에 프로젝트 관리 및 빌드에 필요한 환경 설정,

의존성 관리 등의 정보들을 기술합니다

대부분 Maven의 중요 설정파일들이 들어가있으며,

라이브러리를 추가함으로써, 불러오는 기능인 '의존성' 이 있으며,

실제 라이브러리 파일이 저장되어 있는 저장소 서버의 위치를 지정하고,

사용할 라이브러리를 지정해줍니다.

그렇기 때문에, Maven을 통해서 라이브러리를 설정해놓고 잘 관리한다면,

라이브러리의 jar파일을 따로 관리할 필요 없이 pom.xml 파일만 관리하면 됩니다.

POM.xml에 Spring framework 라이브러리의 의존성 주입을 설정 합니다.

POM.xml 수정 후 반드시 eclipse에서 Maven update를 줘야합니다.

<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>1.3.3.RELEASE</version>
<relativePath/> 

<!-- lookup parent from repository -->

여기서 

<groupId>

는 모든 프로젝트 중에서 당신의 프로젝트를 식별하게 해주는 식별자입니다.
groupId는 Java의 패키지 이름 규칙을 따라야 함 즉 제어하는 도메인 이름의 반대로 시작합니다.

<artifactId>

artifactId is the name of the jar without version

jar파일의 이름. (버전없이)

<version>

배포를 하려면 숫자와 점으로 구성된 일반적인 버전(1.0,1.1,1.0.1,...)인 형태를 사용.

 POM.xml 파일에

라이브러리를 명시에 놓으면 원격 Repository에 있는 라이브러리가

내 컴퓨터로 다운되어 프로젝트에 해당 라이브러리를

쉽게 사용할 수 있도록 하는 역할을 하는 것입니다.
※ 모듈의 라이브러리 파일명은 artifactId + "-" + 버전명 +".jar" 로 표시합니다.

Artifact는 (필수)

프로젝트의 기본정보, 배포방식, 배포정도 등을 담습니다.

Properties는 (선택)

pom.xml내에서 자주쓰는 정보들을 정리해놓고 가져다 쓸수 있습니다.

프로젝트의 중요한 사항에 대해 따로 정리하여 보기쉽게 하려는 목적이 있습니다.

dependencies (필수)

pom.xml의 핵심, 의존성을 정리하는 부분이며 라이브러리들을 정의하여 불러올 수 있게 해주는 부분.

*Maven을 통해 불러온 라이브러리들은 JavaBuildPath에서 Maven Dependencies 목록으로 들어감.

따로 설정을 할 수 없으며, pom.xml을 통해서만 추가/수정/삭제 가능.

Build (필수)

빌드할때 사용할 플러그인 기술

Profiles (선택)

각각 다른 개발환경과 설정파일을 구축할 때 사용.

여러개의 profile을 가질 수 있음.

로컬, 개발, 운영서버를 나누어 배포하는 설정시 각각의 profile로 등록해서

배포시마다 profile값만 변경해주면서 패키징하면

설정파일, 개발환경 등이 세팅한대로 묶여짐.

maven의 package명령어를 통해 war등으로 묶을때 profile에 기술한 id를

함께 작성하면, 설정한 방식으로 빌드하여 배포 가능.

*단 이걸 사용하면 각 환경마다 빌드를 새로 해야하는 문제가 있으니

해당 설정을 이용해 별도 배포하는 것보다 spring 에서 제공하는

spring profile을 권장한다.