일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- JPA예제
- 플러터 공부
- JPA스터디
- 자료구조공부
- 스프링공부
- Axon framework
- Flutter
- 코테준비
- JPA 공부
- 자바공부
- nestjs
- 스프링
- 기술공부
- 플러터 개발
- 스프링부트공부
- JPA공부
- nestjs공부
- 카프카
- DDD
- nestjs스터디
- 알고리즘공부
- 스프링부트
- 코테공부
- K8S
- JPA
- 스프링 공부
- 기술면접공부
- Kafka
- 프로그래머스
- querydsl
- Today
- Total
DevBoi
Spring Camp 1 본문
1. Gradle vs Maven
빌드 관리 도구? (프로젝트 생성, 테스트 빌드,배포, 외부라이브러리 다운로드)
우선 빌드 자동화 도구는, 프로젝트 내에서 작성한 Java코드와 프로젝트 내에 필요한 각종 xml, properties, jar파일들을
JVM이나 WAS가 인식할 수 있도로고 패키징 해주는 과정을 빌드 자동화 도구라고 할 수 있다.
-프로젝트 생성, 테스트 빌드, 배포 등의 작업을 위한 전용 프로그램이라고 할 수 있다.
-애플리케이션 개발을 하면서, 일반적으로 개발에 필요한 외부 라이브러리를 다운로드하고
해당 라이브러리를 사용하여 개발해야하는 상황이 많다.
이때 각 라이브러리 들을 번거롭게 모두 다운받을 필요없이, 빌드도구 설정파일에 필요한 라이브러리 종류와 버전들
종속성 정보를 명시하여, 필요한 라이브러리들을 설정파일을 통해 자동으로 다운로드 해주고 이를 간편히 관리해주는 도구이다.
Maven
pom.xml 파일에 명시, Maven은 외부저장소에서 필요한 라이브러리와 플러그인들을 다운로드하고, 로컬시스템의 캐시에 모두 저장
Gradle
업데이트가 이미 반영된 빌드의 부분은 즉 더이상 재실행되지 않는다. (Gradle은 프로젝트의 어느부분이 업데이트 되었는지 알 수 있다.)
Maven vs Gradle
Gradle은 작업 의존성 그래프를 기반으로하고, Maven은 고정적으로 선형저인 단계의 모델을 기반으로 한다.
Gradle은 어떤 task가 업데이트되었고 안되었는지를 체크하기 때문에 성능측면에서 Incremental build를 허용한다.
이미 업데이트 된 테스크에 대해서는 작업이 실행되지 않으므로 빌드시간이 훨씬 단축된다.
-> 빌드 설정 규모가 점점 커지면 커질수록, 빌드시간의 차이도 Maven과 비교하여, 꽤 격차가 벌어질 수 있을 것같다.
1) 멀티프로젝트 동작 방식 다름
maven은, 멀티프로젝트에서 특정 설정을 다른 모듈에서 사용하려면 상속을 받아야 한다. gradle은 설정 주입방식을 제공한다.
2) 캐시 허용
Gradle은 concurrent에 안전한 캐시를 허용한다.
두개 이상의 프로젝트에서 동일한 캐시를 사용할 경우, 서로 overwrite되지 않도록 checksum 기반의 캐시를 사용하고
캐시를 repository와 동기화 할 수 있다.
즉, Maven에 비해 Gradle이 테스크 업데이트 캐싱 및 Incremental build를 허용하여 빌드시간이 빠르다
(점진적으로 프로젝트를 캐싱하여, 이미 업데이트한 빌드도구에 대해서는, 추가로 반복 작업을 수행하지 않는다.)
추가적으로, 빌드 작업에 대한 소스 설정도 훨씬 간결하여, 가독성 측면에서도 뛰어나다.
2. Java vs Kotlin
코틀린은 타입을 직접 명시할 필요가 없다.
프로그래머는 코틀린을 사용하는 동안, 타입선언을 생략할 수 있다.
함수형 프로그래밍 상으로, 고차원 함수 API를 지원해준다.
왜냐면 코틀린은 함수형 프로그래밍 언어로 태어났기 때문이다.
코틀린은 Null-safety를 언어 차원에서 지원해준다.
NPE를 획기적으로 줄여주기 위해, 컴파일 시점에 Null 위험성을 검사하여, 오류를 훨씬 많이 방지해준다.
3.Nexus 서버
Maven이 아닌 다른 Repository를 통해 라이브러리를 관리한다.
Nexus는 메이븐에서 사용할 수 있는 Repository다, 외부에서 dependency 수고를 덜고
local nexus로 사용함으로써 빠르게 라이브러리를 끌어올 수 있고, 개발팀에서 사용하는 공용 라이브러리를
local nexus에 배포하여, 팀간 공유도 가능하다.
회사/단체에서 화이트리스트로 인해 외부 리포지토리에 접속하기 어려운 경우, 프록시 역할을 한다.
특히나, 비상시 외부 인터넷이 느리거나 리포지토리가 다운되는 등 여러 상황에서도 빠르게 받을 수 있다.
쉽게 말하면, 사설 리포지토리고 외부 인터넷이 느리거나 리포지토리가 다운되는 등 여러 상황에서도 빠르게 받을 수있다.
정리하면, 외부에서 디펜던시를 끌어오는 수고를 덜고, local nexus를 프록시로 캐싱하면서 빠르게 라이브러리를 끌어올 수 있고
공용 라이브러리를 local nexus에 배포해서 팀간 공유를 할 수 있다.
쉽게 얘기하면, 외부에서 디펜던시를 매번 끌어오는게 아니라, 한번 끌어와서 저장해놓는 공간이다.
'Develop > [Spring]' 카테고리의 다른 글
3. Spring core Setting - 1 (0) | 2022.07.03 |
---|---|
2. admin 화면 로그인 화면 단순 구현 + Spring admin (0) | 2022.06.26 |
[Spring] initBinder (0) | 2022.05.11 |
[Spring] SessionLocaleResovler (0) | 2022.05.11 |
[Spring] HandlerInterceptor (0) | 2022.05.10 |