Skip to content

fix(rte.rdt): 버전 업데이트가 프로퍼티로 지정된 dependency 의 version 을 실제 값으로 덮어써 모듈 버전이 갈리는 문제 수정 - #156

Merged
eGovFrameSupport merged 2 commits into
eGovFramework:mainfrom
EricSeokgon:patch-6
Sep 18, 2026
Merged

eGovFrameSupport merged 2 commits into
eGovFramework:mainfrom
EricSeokgon:patch-6

Conversation

@EricSeokgon

Copy link
Copy Markdown
Contributor

수정 사유 Reason for modification

소스를 수정한 사유가 무엇인지 체크해 주세요. Please check the reason you modified the source. ([X] X는 대문자여야 합니다.)

  • 버그수정 Bug fixes
  • 기능개선 Enhancements
  • 기능추가 Adding features
  • 기타 Others

수정된 소스 내용 Modified source

문제

PomObject.changeVersion() 이 dependency 의 <version> 엘레멘트를 항상 실제 버전 문자열로 덮어씁니다.

public void changeVersion(String dependencyId, Version version) {
    Dependency dependencyTochange = dependencies.get(dependencyId);
    dependencyTochange.getElement().getChild("version", getNamespace()).setText(version.toString());
}

프로젝트 pom 이 <version>${spring.framework.version}</version> 처럼 프로퍼티로 버전을 관리하고 있으면, TableList.InstallDependency() 의 업데이트 경로에서 그 dependency 만 값이 박히고 프로퍼티는 옛 버전으로 남습니다. 같은 프로퍼티를 쓰는 나머지 모듈은 갱신되지 않아, 한 번의 업데이트로 라이브러리 모듈 버전이 서로 갈립니다.

재현

프로퍼티로 spring 버전을 관리하는 pom(설치 6.2.9, master 6.2.11)에 현재 코드를 그대로 적용한 결과입니다.

### 현재 동작 — pom.changeVersion("6.2.11")
   <spring.framework.version>6.2.9</spring.framework.version>     ← 그대로
   <artifactId>spring-core</artifactId>
   <version>6.2.11</version>                                      ← 값이 박힘
   <artifactId>spring-beans</artifactId>
   <version>${spring.framework.version}</version>                 ← 6.2.9 로 남음

업데이트 한 번에 spring-core 6.2.11 + spring-beans 6.2.9 로 갈립니다.

수정

설치된 버전이 이 pom 의 <properties> 로 지정된 것이면 <version> 대신 프로퍼티를 고치도록 했습니다. 이미 있는 changeProperty(key, value) 를 그대로 사용합니다.

### 수정 후
   <spring.framework.version>6.2.11</spring.framework.version>    ← 프로퍼티가 갱신됨
   <version>${spring.framework.version}</version>                 ← 표기 유지
   <version>${spring.framework.version}</version>                 ← 같은 버전 유지

Version.isPropertyVersion() 은 이 pom 의 <properties> 에서 값을 찾았을 때만 true 이므로, 부모 pom 의 프로퍼티처럼 이 pom 에서 고칠 수 없는 경우에는 이 경로로 들어오지 않습니다. 버전이 리터럴이면 종전대로 <version> 을 고칩니다.

JUnit 테스트 JUnit tests

  • JUnit 테스트 JUnit tests

  • 수동 테스트 Manual testing

  • 결함 재현 테스트 2건과 리터럴 버전 회귀 테스트 1건을 PomObjectTest 에 추가했습니다. 수정 전 코드에서는 재현 테스트 2건이 실패(Tests run: 6, Failures: 2), 수정 후 6건 전부 통과합니다.

  • 저장소의 기존 테스트도 그대로 통과합니다 — VersionTest, DependencyTest 5건, PomObjectTest 6건, SecureSAXBuilderTest 7건.

함께 확인하다 발견한 것 (이 PR 범위 밖)

  1. TableList.changeProperty(Version) 은 같은 목적으로 만들어져 있으나 현재 어디에서도 호출되지 않습니다. 이 수정으로 changeVersion 이 프로퍼티까지 다루게 되므로 그 메서드를 정리하는 편이 좋을지 의견 주시면 별도 PR 로 올리겠습니다.
  2. PomObject.assayDependency() 는 <dependencies> 와 첫 <dependency> 사이에 공백 텍스트가 있다고 가정합니다(getContent(indexOf(lastDependency) - 1)). 줄바꿈 없이 한 줄로 쓰인 pom 에서는 파싱 자체가 IndexOutOfBoundsException 으로 실패합니다. 필요하다고 보시면 별도 PR 로 올리겠습니다.

테스트 브라우저 Test Browser

  • 기타 Others

Eclipse 플러그인(RCP) 코드라 브라우저가 관여하지 않습니다. JDK 21 · JUnit 4.7 로 테스트했습니다.

테스트 스크린샷 또는 캡처 영상 Test screenshots or captured video

UI 화면이 아닌 pom 파일 변경 결과라, 실제 pom 을 파싱해 changeVersion 을 호출하고 저장한 결과를 위 "재현"·"수정 후" 블록으로 갈음합니다.

수정 전(main) PomObject + 새 테스트
1) changeVersionOfPropertyVersionUpdatesPropertyNotVersionElement
2) changeVersionOfPropertyVersionKeepsModulesOnTheSameVersion
Tests run: 6,  Failures: 2

수정 후
OK (6 tests)

참고: 같은 판정 경로의 Version.compareTo 자리별 비교 수정은 #155 로 따로 올렸습니다. 두 PR 은 파일이 겹치지 않아 서로 독립적으로 적용할 수 있습니다.

… 버전이 갈리는 문제 수정

PomObject.changeVersion() 이 <version> 엘레멘트를 항상 실제 버전 문자열로 덮어써서, 프로퍼티로
버전을 관리하는 pom 에서는 해당 dependency 만 값이 박히고 프로퍼티는 옛 버전으로 남았다.
같은 프로퍼티를 쓰는 다른 모듈은 갱신되지 않아 한 번의 업데이트로 spring-core 6.2.11 +
spring-beans 6.2.9 처럼 버전이 갈렸다.

설치된 버전이 이 pom 의 <properties> 로 지정된 것이면 기존 changeProperty(key, value) 로
프로퍼티를 고치도록 했다. isPropertyVersion() 은 이 pom 의 properties 에서 값을 찾았을 때만
true 이므로 부모 pom 의 프로퍼티는 이 경로로 들어오지 않는다. 버전이 리터럴이면 종전대로
<version> 을 고친다.
프로퍼티로 버전을 관리하는 pom 에서 changeVersion 이 프로퍼티를 갱신하고 <version> 표기를
유지하는지, 같은 프로퍼티를 쓰는 다른 모듈이 같은 버전으로 남는지 검증한다.
리터럴 버전은 종전대로 <version> 이 바뀌는지도 함께 확인한다.
수정 전 PomObject 에서는 앞의 2건이 실패한다.
@eGovFrameSupport
eGovFrameSupport merged commit 4417272 into eGovFramework:main Sep 18, 2026
1 check passed
swanpark8538 added a commit that referenced this pull request Sep 18, 2026
changeVersion 이 프로퍼티 값을 고치는 경로에 세 가지 결함이 있었다.

- 바꿀 버전의 원본 문자열을 기록해, 마스터 pom 의 버전이 같은 키의 프로퍼티 참조이면
  <spring.version>${spring.version}</spring.version> 처럼 자기 자신을 가리키게 됐다.
  실제 버전을 기록한다.
- 프로퍼티가 다른 프로퍼티를 참조하면 연쇄의 첫 키를 리터럴로 덮어써, 실제 값을 가진
  프로퍼티는 옛 버전으로 남았다. Version 이 연쇄의 마지막 키를 기억하게 하고 그 키를 고친다.
- 프로퍼티를 고쳐도 dependency 의 Version 은 옛 실제 버전을 들고 있어, 같은 프로퍼티를
  쓰는 dependency 를 이어서 처리하면 더 낮은 버전으로 다시 덮어썼다. changeProperty 가
  실제 버전을 다시 해석하게 하고, 바꿀 버전이 현재 값보다 높을 때만 프로퍼티를 고친다.

Refs: #156
swanpark8538 added a commit that referenced this pull request Sep 18, 2026
changeVersion 이 프로퍼티 값을 고치면 그 프로퍼티를 쓰는 모든 dependency 의 버전이 함께
바뀐다. 서로 다른 라이브러리가 프로퍼티 하나를 함께 쓰는 pom 에서는, 서비스 하나를
업데이트했을 뿐인데 선택하지 않은 라이브러리가 마스터 pom 과 다른 버전이나 존재하지 않는
버전으로 올라갔다.

마스터 pom 의 dependency 맵을 받는 changeVersion 을 추가하고 TableList 가 이를 쓰게 했다.
같은 프로퍼티를 쓰는 dependency 가 모두 마스터에서 바꿀 버전과 같은 버전일 때만 프로퍼티를
고치고, 마스터에 없거나 버전이 다른 dependency 가 섞여 있으면 해당 dependency 의
version 만 실제 버전으로 고친다.

Refs: #156
swanpark8538 added a commit that referenced this pull request Sep 18, 2026
프로퍼티로 지정된 버전의 갱신은 PomObject.changeVersion 이 담당하게 되어,
같은 목적으로 만들어졌으나 어디에서도 호출되지 않던 TableList.changeProperty(Version) 는
같은 로직의 중복으로만 남았다. 연쇄 프로퍼티의 첫 키를 고치는 옛 방식이기도 해서
남겨 두면 잘못 쓰일 수 있다. 메서드와 그것만 쓰던 import 를 제거한다.

Refs: #156
@swanpark8538

Copy link
Copy Markdown
Collaborator

기여해 주셔서 감사합니다. 프로퍼티로 버전을 관리하는 pom에서 모듈 버전이 갈리는 문제를 정확히 짚어 주셨고, <version> 대신 프로퍼티를 고치는 방향에도 동의합니다. 이 PR은 squash 방식으로 머지했습니다(4417272).

머지한 뒤에, 리뷰 과정에서 실제로 재현된 경계 조건들을 main에 후속 커밋으로 보완했습니다. 본문 끝에 남겨 주신 두 가지 질문에 대한 답도 함께 적습니다.

후속 커밋 1: 188fc9d (프로퍼티에 잘못된 값이 기록되던 세 가지 경우)

1) 바꿀 버전이 같은 키의 프로퍼티 참조이면 자기 참조가 기록되던 문제

changeProperty에 version.toString()(원본 문자열)을 넘기고 있어서, 사용자 지정 master pom이 <version>${spring.version}</version>을 쓰면 프로젝트 pom에 <spring.version>${spring.version}</spring.version>이 기록되었습니다. version.getRealVersion()을 기록하도록 바꿨습니다. 기본 pom_master.xml에는 프로퍼티를 참조하는 버전이 없어서 기본 설정에서는 발생하지 않습니다.

2) 프로퍼티가 다른 프로퍼티를 참조하는 연쇄에서 첫 키만 덮어쓰던 문제

<spring.version>6.2.9</spring.version>
<lib.version>${spring.version}</lib.version>

spring-core가 ${lib.version}을, spring-beans가 ${spring.version}을 쓰는 pom에서는 lib.version만 리터럴 6.2.11이 되고 spring.version은 6.2.9로 남아, 이 PR이 막으려던 버전 불일치가 그대로 발생했습니다(Version.setContent가 연쇄를 끝까지 해석하므로 이 경우에도 isPropertyVersion()은 true입니다). Version에 연쇄의 마지막 키를 돌려주는 getPropertyKey()를 추가하고, 그 키를 고치도록 했습니다.

3) 캐시된 실제 버전 때문에 공유 프로퍼티가 더 낮은 버전으로 다시 덮이던 문제

changeProperty가 프로퍼티 값만 고치고 각 Dependency의 Version에 캐시된 realVersion은 그대로 두었습니다. 그래서 lib-a(master 2.5.0)와 lib-b(master 2.1.0)가 ${common.version}(2.0.0)을 함께 쓰면, 프로퍼티가 2.5.0이 되었다가 2.1.0으로 다시 낮아졌습니다. changeProperty가 값을 고친 뒤 dependency들의 realVersion을 다시 해석하게 했고(refreshPropertyVersions), changeVersion은 바꿀 버전이 현재 값보다 높다고 확정할 수 있을 때에만 프로퍼티를 고칩니다.

이와 관련하여 테스트 5건을 추가했습니다(PomObjectTest 4건, VersionTest 1건).

후속 커밋 2: fb0e4da (서비스와 무관한 dependency의 버전까지 바뀌던 문제)

프로퍼티를 고치면 그 프로퍼티를 쓰는 모든 dependency의 버전이 함께 바뀝니다. spring-core와 spring-beans처럼 같은 라이브러리의 모듈이 프로퍼티를 공유할 때는 올바른 동작이지만, 서로 무관한 라이브러리가 프로퍼티 하나를 공유하는 pom에서는 서비스 하나를 업데이트했을 뿐인데 선택하지 않은 라이브러리가 master와 다른 버전이나 존재하지 않는 버전으로 올라갑니다.

Pom/PomObject에 master의 dependency 맵을 받는 changeVersion(dependencyId, version, masterDependencies)를 추가했고, TableList.InstallDependency가 이 메서드를 호출합니다.

  • 같은 프로퍼티를 쓰는 dependency가 모두 master에서 바꿀 버전과 같은 버전이면(compareTo == 0이므로 6.2.11과 6.2.11.RELEASE는 같은 버전) 프로퍼티를 고칩니다. 본문의 spring 예시는 이 경로로 처리됩니다.
  • master에 없거나 master 버전이 다른 dependency가 섞여 있으면, 해당 dependency의 <version>만 실제 버전으로 고칩니다.

기존의 2-인자 changeVersion은 그대로 두었습니다.

테스트 5건을 추가했습니다.

후속 커밋 3: 81382e5 (TableList.changeProperty 제거)

본문의 첫 번째 질문에 대한 답입니다. changeVersion이 프로퍼티 갱신을 담당하게 되면서 TableList.changeProperty(Version)는 호출되지 않는 중복 로직으로만 남았고, 연쇄의 첫 키를 고치는 옛 방식이기도 해서 제거했습니다. 별도 PR은 올리지 않으셔도 됩니다.

본문의 두 번째 질문: assayDependency()의 IndexOutOfBoundsException

<dependencies>와 첫 <dependency> 사이에 공백 텍스트가 있다고 가정하는 부분은 이번에 다루지 않았습니다.


전자정부 표준프레임워크에 기여해 주셔서 감사합니다.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants