Maven 의존성 전이, 스프링 마이그레이션시 참고사항, UML 의존관계

스프링 마이그레이션 관련 사전검토를 진행하면서 조사한 내용들에 대해서 공유드립니다.

 

 

Maven 의존성 전이, 스프링 마이그레이션시 참고사항, UML 의존관계

 

 Maven 

 

1. pom파일 dependencyManagement 태그

maven으로 관리하는 multi module 프로젝트에서는 하위 프로젝트의 의존선을 dependencyManagement에 버전등을 명시하여 관리한다.이 방식으로 프로젝트 의존 버전을 관리하면 하위 모듈에서 공통으로 사용하는 라이브러리 버전 변경시 일괄적으로 수정할 수 있다는 이점이 있다.

 

To-do.

- dependencyManagement vs properties 태그와 비교 및 정의

- mutli module 프로젝트 직접 코드구현 해볼 것 (완료) https://timotimo.tistory.com/77

[Maven] 간단한 Multi-Module 프로젝트 만들기

 

 

Maven 관련 개념공부도 필요하지만 현 시점에선 필요한 내용들만 먼저 체크하고 추후에 핵심 개념정리할 것.

 

 

2. Maven Dependency Mechanism

- Transive Dependencies 의존성 전이 : 메이븐은 프로젝트에 특정 라이브러리 의존관계를 명시하면 관련 라이브러리들을 모두 받아온다. 그러다보면 버전이나 참조되는 위치만 다른, 같은 이름의 라이브러리 중 어떤 라이브러리를 받아오는 경우도 생긴다. 이 때 어떤 라이브러리를 참조해야 하는지를 자동으로 결정하여 종속성을 포함시켜주는 것을 말함.

 

의존성 전이를 사용하면 라이브러리 그래프가 커지기 때문에, 개발자가 의존성 전이를 설정을 통해 제한할 수 있다.

 

 

- nearest definition : 컴파일되는 라이브러리 기준으로 가장 가까이 참조되는 라이브러리를 종속성에 포함하는 원칙.

 

  A
  ├── B
  │   └── C
  │       └── D 2.0
  └── E
      └── D 1.0

위 경우에 A와 가까운 D 1.0을 참조하는 의존성 전이를 말한다.

 

 

다른 제한 기능은 아래 링크 참조

https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html

 

 개발 중인 프로젝트에서 프레임워크 및 라이브러리 마이그레이션 작업을 진행하다보니, 프로젝트에 포함된 라이브러리가 어떤 라이브러리를 참조하고 있는지 정확한 이해가 필요했다. 실제 버전 업그레이드를 진행했을 때 영향도를 정확하게 파악하기 위해서 위 링크에 포함된 내용들은 Maven 핵심 개념이기 때문에 시간나는 대로 서둘러 정리 예정이다.

 

 

3. omitted for conflict 충돌로 인한 생략

인텔리제이 Maven Plugin에서 모듈 dependency를 체크해보면 특정 라이브러리의 종속성을 확인해보면 아래와 같은 메시지가 회색으로 표시되어 있어서 무엇인지 궁금하여 관련내용을 찾아봤다.

 

- omitted for conflict for duplicate

대상이 되는 라이브러리가 상위 종속성에 포함되어 있어서 같이 참조하여 중복 포함을 하지않는다는 의미.

 

- omitted for conflict with x.x.x version

해당 라이브러리를 컴파일할 때 요구되는 라이브러리 버전이 있으나, 해당 프로젝트 또는 상위 프로젝트에서 대상이되는 라이브러리 버전을 직접 의존성(버전을 직접 명시) 을 추가한 경우 발생하는 충돌. 이 때는 직접 명시한 버전을 사용하게 된다.

 

- 참고링크 : https://stackoverflow.com/questions/7742312/interpreting-omitted-for-conflict-in-maven-2-dependency-tree

 

 

4. Maven Repository에서 Compile Dependencies 확인하기

특정 라이브러리가 컴파일 될 때 필요로하는 version은 Maven Repository에서 확인할 수 있다. 이렇게 하위 버전을 확인하는 이유는 예를들어 spring-data-redis 라이브러리는 버전에 따라 서로 다른 버전의 spring 종속성을 가지고 있는데, 의존성 전이에 의해서 해당 버전이 컴파일이 안되는 충돌이 발생하는지 여부를 확인할 수 있기 때문이다. 특히나 큰 규모의 프로젝트에서는 마이그레이션 작업시 이런 부분들을 세세하게 신경써야하는 것 같다.

 

 

5. Compile Dependencies의 Version과 Updates열

https://stackoverflow.com/questions/35354334/maven-dependencies-version-vs-updates

maven에서 특정 라이브러리의 compile dependencies를 확인하면 version과 update열에 각각 버전이 명시되어 있다. 각 열이 어떤 의미인지 명확한 설명을 찾아보려고 했는데, 위 링크를 참조하면 개략적인 내용은 알 수 있으나 클리어한 의미는 알 수 없었다. 공식문서에서 관련내용을 찾을 수 있을지 한번 찾아봐야 할 것 같다.

 

 

 

 Spring 

 

1. 스프링 마이그레이션시 참조해야할 페이지

현재 스프링 최신버전은 6.0.x 이다. 더 낮은 버전의 스프링 버전에서 마이그레이션하려면 아래 페이지를 참조하여 검토하면 된다.

 

- https://github.com/spring-projects/spring-framework/wiki/What%27s-New-in-Spring-Framework-5.x

- https://github.com/spring-projects/spring-framework/wiki/What%27s-New-in-Spring-Framework-6.x

- https://github.com/spring-projects/spring-integration/wiki/Spring-Integration-5.2-to-5.3-Migration-Guide

 

 

2. 스프링 OSS Support 기간 확인하기

https://spring.io/projects/spring-framework#support

 프로젝트에서 사용하고 있는 프레임워크 또는 라이브러리의 버전은 마이너 버전이 릴리즈될 때마다 주기적으로 마이그레이션해주는 것이 좋다. 새로운 버전이 릴리즈 될때마다 코드에 영향이 갈 수 있는 사항을 빠르게 대응해서 추후 변경될 수 있는 코드량을 줄여주는 관점에서 리스크를 줄여줄 수 있다고 생각한다. 

 

 OSS Support 기간은 위 관점이 아니더라도 보안, 안정성 관점에서 어떤 프레임워크나 라이브러리가 업그레이드해야할 최소한의 버전 기준을 제안하는 것이라고 생각하면 좋을 것 같다. 항상 프로젝트에서 사용하고 있는 프레임워크 버전이 OSS Support 기간이 만료되기 전에 마이그레이션 작업을 해주어야 한다.

 

 보안, 안정성이 중요하다는 것은 알겠지만 그럼에도 실제 개발 건을 대응하는 것보단 중요하지 않게 생각될 수 있다. 하지만 프레임워크나 라이브러리에서 문제가 생겼을 때 책임소재가 누구에게 있는지에 대한 관점으로 생각해보면, OSS Support 기간을 준수하고 있을 때 책임소재를 명확히 할 수 있다는 이점이 있을 걸로 생각이 된다.

 

 서비스에 장애가 나거나 보안상 크리티컬한 이슈가 발생했을 때는 그 원인에 대한 명확한 분석이 필요하고 회사에서는 그런 부분에 대해서 책임질 일도 생긴다. 이 때 그런 책임 소재를 명확히하고 더 안정적으로 서비스를 관리하기 위해서는 이런 부분에서 항상 신경을 쓸 필요가 있을 것 같다.

 

Spring-data-redis OSS Support 기간 확인하기

https://spring.io/projects/spring-data-redis#support

 

 

 

 UML 다이어그램 

 

1. Dependency 의존관계

어떤 클래스가 다른 클래스를 참조하는 것을 나타낼때 사용한다. UML 표기는 점선 화살표로 한다.

 

A ----------> B

A에서 B를 사용

 

의존이라는 용어에 대한 좀 더 명확한 정의는 추후에 알아볼 것

 

2. https://www.diagrams.net/

Diagram Software and Flowchart Maker

이전에 draw.io라는 이름으로 알려져있었던 무료 UML 툴. 현재는 diagrams.net이라는 도메인으로 변경되었다고 한다. 온라인에서 무료로 설치없이 UML을 사용할 수 있어서 편리하고 기능도 상당히 잘 구현되어있어서 UML을 그릴때 편하게 사용할 수 있을 것 같다. 사용방법은 필요판단하여 추후에 포스팅을 해볼 예정이다.

 

https://www.diagrams.net/