Skip to content

Conversation

@chock-cho
Copy link
Member

@chock-cho chock-cho commented Mar 24, 2025

💡 작업 내용

  • 멀티 모듈 전환 후 루트 프로젝트의 build.gradle 파일에 필요한 의존성만 남겨 정리했습니다.
  • 모든 모듈에Ktlint 를 적용했습니다.

✅ 셀프 체크리스트

  • PR 제목을 형식에 맞게 작성했나요?
  • 브랜치 전략에 맞는 브랜치에 PR을 올리고 있나요?
  • 테스트는 잘 통과했나요?
  • 빌드에 성공했나요?
  • 본인을 assign 해주세요.
  • 해당 PR에 맞는 label을 붙여주세요.

🙋🏻‍ 확인해주세요

  • 관련된 Discussion 등이 있다면 첨부해주세요

Summary by CodeRabbit

  • Style

    • 코딩 스타일 가이드라인을 적용하여, 파일 인코딩, 들여쓰기 및 공백 처리가 일관되게 유지됩니다.
  • Chores

    • 빌드 설정이 모듈화되어 플러그인 적용 및 종속성 관리가 개선되었습니다.
    • 새로운 플러그인 관리 블록이 추가되어 다양한 플러그인과 그 버전이 정의되었습니다.
    • Ktlint 플러그인이 여러 모듈에 추가되어 코드 스타일 검사가 통합되었습니다.

🔗 Jira 티켓


https://yappsocks.atlassian.net/browse/YS-391

@chock-cho chock-cho self-assigned this Mar 24, 2025
@coderabbitai
Copy link

coderabbitai bot commented Mar 24, 2025

Walkthrough

이번 PR은 두 가지 주요 변경 사항을 포함합니다. 첫째, 프로젝트의 최상위에 위치하는 새 .editorconfig 파일이 추가되어 UTF-8 인코딩, 4칸 스페이스 들여쓰기, 최종 줄바꿈 및 후행 공백 제거와 같은 코딩 스타일을 명시합니다. 둘째, build.gradle.kts 파일이 재구성되어 플러그인 선언에서 버전 번호가 제거되고, Ktlint 플러그인이 추가되었으며, 하위 프로젝트에 대한 새로운 설정 블록이 도입되었습니다.

Changes

파일/경로 변경 요약
.editorconfig UTF-8, 4칸 스페이스 들여쓰기, 최종 줄바꿈, 후행 공백 제거 설정이 포함된 새 파일 추가
build.gradle.kts 기존 설정 삭제 및 하위 프로젝트에 대한 새로운 subprojects 블록 추가
application/build.gradle.kts 플러그인 버전 삭제 및 Ktlint 플러그인 추가
common/build.gradle.kts 플러그인 버전 삭제 및 Ktlint 플러그인 추가
domain/build.gradle.kts Ktlint 플러그인 추가
infrastructure/build.gradle.kts 플러그인 버전 삭제 및 Ktlint 플러그인 추가
presentation/build.gradle.kts 플러그인 버전 삭제 및 Ktlint 플러그인 추가
settings.gradle.kts 새로운 pluginManagement 블록 추가 및 플러그인 및 저장소 선언

Suggested labels

📄 DOCS

Poem

안녕! 새 규칙의 아침이 밝았네,
토끼 난 코드 숲을 뛰노는 중,
깔끔한 스페이스와 줄바꿈의 미소,
플러그인 조용히 숨 쉬며 변화하네,
모두 함께 달리자, 즐거운 코드의 세상으로! 🐇

Hop, hop—우리의 변화는 영원하리!

✨ Finishing Touches
  • 📝 Generate Docstrings

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Generate unit testing code for this file.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit testing code for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and generate unit testing code.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai generate docstrings to generate docstrings for this PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai plan to trigger planning for file edits and PR creation.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

@chock-cho chock-cho marked this pull request as draft March 24, 2025 12:22
- 루트 build.gradle.kts 에서 모든 서브모듈에 공통 적용할 필요 없는
  플러그인 선언을 제거하고, essential한 설정만 남김
settings.gradle

- 각 모듈의 빌드 스크립트에 흩어져있던 플러그인 버전관리를 settings.gradle의
  pluginManagement로 이동
- 플러그인 버전 일관성
Comment on lines +1 to +15
pluginManagement {
plugins {
id("org.jetbrains.kotlin.jvm") version "1.9.25"
id("org.jetbrains.kotlin.plugin.spring") version "1.9.25"
id("org.jetbrains.kotlin.plugin.jpa") version "1.9.25"
id("org.jetbrains.kotlin.kapt") version "1.9.25"
id("org.springframework.boot") version "3.4.1"
id("io.spring.dependency-management") version "1.1.7"
id("org.jlleitschuh.gradle.ktlint") version "11.6.1"
}
repositories {
gradlePluginPortal()
mavenCentral()
}
}
Copy link
Member Author

@chock-cho chock-cho Mar 29, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

기존에는 각 모듈에서 버전을 명시해줘서 버전 관리가 흩어져서 각 모듈 간의 버전 충돌이 발생할 수 있겠다는 우려가 있었어요. 🥺
따라서 pluginManagement 블록을 통해 모든 하위 모듈에서 사용하는 플러그인들의 버전을 한 곳에서 통합 관리하도록 리팩토링했습니다.

이 설정을 settings.gradle.kts 에 둔 이유는, gradle이 프로젝트 초기화 시점에 pluginManagement 블록을 가장 먼저 읽는다는 이유 때문이었어요.
따라서 하위 모듈에서 사용하는 플러그인 버전들을 전역적으로 일관되게 관리하기 위해서는 settings.gradle.kts 에 정의하는 것이 가장 안전하고 권장되는 방법이라고 판단했습니다. 🤔

참고로, 제가 참고한 Gradle 공식 문서 > Plugin Management 챕터에서도 플러그인 버전 관리를 settings.gradle.kts 파일의 최상단에 위치시키는 것이 best practice라고 합니다!

이런 리팩토링 방향성에 대해 지수님의 의견이 듣고 싶습니다. ✨👀

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

좋은 리팩토링입니다! 여러 모듈에서 버전을 따로 관리하면 충돌이 생길 수 있는데, pluginManagement 블록을 통해 한 곳에서 버전을 관리하면 안정적이고 일관성 있게 관리할 수 있겠네요. 👍

@chock-cho chock-cho marked this pull request as ready for review March 29, 2025 07:37
@chock-cho chock-cho requested a review from Ji-soo708 March 29, 2025 07:37
@chock-cho chock-cho added ⚙️ CHORE config, workflow.yaml ♻️ REFACTORING 리팩토링 labels Mar 29, 2025
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

제가 common 계층을 만들면서 bootjar 비활성화 코드를 빠뜨렸네요...!

common에도 다른 모듈처럼 아래 코드 추가해주시면 감사하겠습니다~ ☺️

tasks.getByName<org.springframework.boot.gradle.tasks.bundling.BootJar>("bootJar") {
	enabled = false
}

tasks.getByName<Jar>("jar") {
	enabled = true
}

Copy link
Member Author

@chock-cho chock-cho Mar 29, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

지수님께서 common 모듈 작업하면서 당시 common 모듈에 해당 bootJar 비활성화 코드를 추가하지 않으신 이유가 bootJar 비활성화 코드가 스프링 프레임워크에 의존하고 있기 때문이 아닐까... 하는 생각이 듭니다!

현재 domain 모듈이 common 모듈을 의존하고 있어서, common 에 스프링 관련 설정이 들어가면 의존성 전파로 인해 도메인 계층까지 스프링에 물들게 되는 구조가 되는지라 이 부분을 의도적으로 분리하신 게 아닐까 싶어요 👀

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

오 맞습니다. 이 부분은 지금처럼 유지해주시면 되겠습니다! 👍

Comment on lines +1 to +4
subprojects {
repositories {
mavenCentral()
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

각 모듈에서 공통으로 사용할 부분은 subprojects로 관리하는 점 좋습니다!
아래처럼 mavenCentral()뿐만 아니라 kotlin("jvm"), ktlint 같은 플러그인도 함께 관리하면 더 깔끔할 것 같은데 어떻게 생각하시나요??

Suggested change
subprojects {
repositories {
mavenCentral()
}
plugins {
kotlin("jvm") version "1.9.25" apply false
id("org.jlleitschuh.gradle.ktlint") apply false
}
subprojects {
apply(plugin = "kotlin")
apply(plugin = "org.jlleitschuh.gradle.ktlint")
java {
toolchain {
languageVersion.set(JavaLanguageVersion.of(17))
}
}
repositories {
mavenCentral()
}
dependencies {
implementation("org.jetbrains.kotlin:kotlin-stdlib")
}
}

Copy link
Member Author

@chock-cho chock-cho Mar 29, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

지수님 의견처럼 루트에서 공통 플러그인은 apply(plugin = "...") 로 일괄 적용하는 게
실제로 더 간편하고 실용적인 접근이라는 점에 완전히 공감합니다!

다만 이번 프로젝트는 클린 아키텍처 패턴을 strict하게 적용하는 게 목표이다 보니, 각 모듈에서 사용하는 플러그인을 명시적으로 선언해서 설정의 책임을 분리하고 모듈 간 의존성도 더 명확히 드러내는 방식에 저는 개인적으로 조금 더 마음이 끌리네요,,, 👀 😊

혹시 요런 방식에 대해서는 어떻게 생각하시나요?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

각 모듈에서 사용하는 플러그인과 라이브러리를 명확히 선언하는 차원에서, groupversion만 추가하는 것도 좋은 방법일 것 같아요! 👍

Comment on lines 10 to 11
group = "com.dobby"
version = "0.0.1-SNAPSHOT"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

모든 서브 모듈이 동일한 그룹 ID와 버전을 공유할 수 있도록 그룹과 버전은 루트 build.gradle에 그대로 두는 게 좋아보입니다!

group = "com.dobby"
version = "0.0.1-SNAPSHOT"

Comment on lines +1 to +15
pluginManagement {
plugins {
id("org.jetbrains.kotlin.jvm") version "1.9.25"
id("org.jetbrains.kotlin.plugin.spring") version "1.9.25"
id("org.jetbrains.kotlin.plugin.jpa") version "1.9.25"
id("org.jetbrains.kotlin.kapt") version "1.9.25"
id("org.springframework.boot") version "3.4.1"
id("io.spring.dependency-management") version "1.1.7"
id("org.jlleitschuh.gradle.ktlint") version "11.6.1"
}
repositories {
gradlePluginPortal()
mavenCentral()
}
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

좋은 리팩토링입니다! 여러 모듈에서 버전을 따로 관리하면 충돌이 생길 수 있는데, pluginManagement 블록을 통해 한 곳에서 버전을 관리하면 안정적이고 일관성 있게 관리할 수 있겠네요. 👍

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

🧹 Nitpick comments (1)
build.gradle.kts (1)

1-5: 서브 프로젝트의 저장소 설정 검토
subprojects 블록 내에 repositories 섹션을 정의하여 모든 서브 프로젝트에 대해 mavenCentral()을 사용하도록 한 점은 모듈화된 구조에서 일관성을 유지하는 좋은 접근입니다. 다만, 향후 특정 모듈에서 추가 저장소나 별도의 저장소 설정이 필요할 경우 이를 유연하게 확장할 수 있도록 고려해주시면 좋겠습니다.

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between e067172 and 95c4d36.

📒 Files selected for processing (2)
  • build.gradle.kts (1 hunks)
  • infrastructure/build.gradle.kts (1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
  • infrastructure/build.gradle.kts
⏰ Context from checks skipped due to timeout of 90000ms (1)
  • GitHub Check: build
🔇 Additional comments (2)
build.gradle.kts (2)

7-8: 루트 프로젝트의 그룹 및 버전 설정 검토
루트 빌드 파일에 groupversion을 정의하여 서브 모듈들이 동일한 그룹과 버전을 공유하도록 한 점은 모듈 간 일관성 유지 측면에서 적절합니다.


1-9: Ktlint 설정 적용 대상 확인 요청
PR 설명에 따르면, Ktlint가 코틀린을 사용하는 모듈에만 적용되어야 하는데, 현재 이 파일에서는 Ktlint 관련 설정이 보이지 않습니다.
혹시 별도의 설정 파일(예: settings.gradle.kts 또는 개별 모듈의 build.gradle.kts)에서 관련 구성이 이루어졌는지 확인 부탁드립니다.

@chock-cho chock-cho requested a review from Ji-soo708 March 29, 2025 10:00
Copy link
Member

@Ji-soo708 Ji-soo708 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, 고생하셨습니다! 👍

@chock-cho chock-cho merged commit 5ba0b73 into dev Mar 29, 2025
3 checks passed
@chock-cho chock-cho deleted the chore/YS-391 branch March 29, 2025 10:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

⚙️ CHORE config, workflow.yaml ♻️ REFACTORING 리팩토링

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants