[웹 개발 환경-1] IDE & Framework

adam adam·2022년 9월 21일

IDE & Framework

IDE = Integrated Development Environment ; eclipse
Framework ; spring, spring boot

돌아다니다보면, framework vs api vs libraries set 해서 서로 비교해서 판정하는 게 있긴한데, 방향성이 유사해도 개발자가 서로 합의해서 만든것도 아니고, 각자 발전해온 걸 그냥 교집합과 차집합이 있겠지 하고 마무리.

그리고, 나는 세상 모든 framework를 비교대조하기 보다, spring framework에서 소개하는 이것으로 framework를 부분 이해 하겠음. 하다보면 좀 늘것지

IDE와 plugin 호환성

eclipse
spring tool suite(STS)
Intellij

최신 IDE일수록 이전 플러그인들과 호환되지 않는 경향이 있다. 만약 지금까지 나온 모든 플러그인 및 관련 jar를 들고있다면 IDE 자체 용량만 수십기가에 이를 것이다.

가령, 22년 9월 기준, STS 4.16.0 은 spring legacy prj를 생성하기 위해 설정을 했지만 플러그인을 깔아도 무수히 많은 에러가 뜬다. 추가적인 수동 설치나 조정이 필요한 것으로 보인다.

Prerequisite

IDE의 java 프로젝트를 서버에서 구동하려면 jdk와 was가 사전에 설치되고, 이클립스 상에서 설정되야한다.

JDK 11

WAS

web application server

Tomcat

9.0.65 버전 - download Windows-x64

참고로, boot에서는 아에 내장 시킴, 이게 답이다.

Windows OS에서 tomcat 구동에 따르면, 리눅스 OS에서 tomcat 구동해서 초기화면 봤을때의 감격을 Windows OS에서도 맛볼 수 있다. 물론 이 부분은 이클립스를 통해 제어하는 게 더 효과적이다.

undertow

web server인 apache가 nginx로 바뀌어 간다면, tomcat 다음은 뭘까해서 찾아봄.
tomcat과 undertow 설명

IDE and plugins

STS4, eclipse 2022-09, eclipse 2022-03 이클립스 순으로 spring Legacy Project 생성하는 과정을 설명

참고로, Intellij가 가장 쉽고 빠르게 Spring Legacy Project 를 생성할 수 있을 것으로 보인다. Intellij로 생성 시 생성되는 applicationContext.xml, dispatcher-servlet.xml 는 root-context.xml, servlet-context.xml 대응하는 것으로 보인다. - goto

software 설치 시 유의사항 : 된다면 ZIP으로 다운받자. exe말고

~.exe파일로 설치하면 Users/User 폴더 하위에 영문모를 .p2, .~ 같은 폴더나 파일들이 잔뜩 쌓인다. 제어도 안되고

zip으로 받아서 반디집으로 압축해제하는 것도 클릭 수 차이 없다. 다운로드는 지원하는 한 .zip이나 .jar가 권장

STS : spring-tool-suite-4

이클립스에 이러저러한 플러그인들 왠만한건 다 깔아준 IDE, 심신안정에 매우 좋음. STS 4.16.0 의 경우, Spring Boot Project가 기본이다.

추가 : 내 sts의 버전과 뼈대 eclipse 버전 확인하는법

STS 설치, spring legacy 설정

sts 설치

Legacy prj 세팅

위와 링크를 따라 세팅 시, 나의 경우, 디펜던시 Missing 에러문이 뜬다. 또한, 최근 글에서 나와 동일한 사례가 검색된다.

Missing 된다는 것 관련 jar를 추가하라는 상단 댓글에 따라 진행해도해당 jar의 3.7을 요구하는데, 공식사이트에 나오는건 3.25이라 해결되지 않는다.

추가적으로 링크를 따라서 add-on 설치 외 다른 jar나 자료를 다운받았지만 나는 안됬다.

여전히 추가 설정해야할 에러들이 많이 보인다. 왜냐하면 STS 4.16.0은 legacy prj를 지원하는 Spring Tools Add-on for Sprint Tools 4 와 호환되지 않기 때문이라고 볼 수 있다.

물론 과거의 글들을 보면, 아주 손쉽게 Spring Tools Add-on for Sprint Tools 4만 다운로드 받으면 legacy prj 생성이 가능해지는 것으로 보이나, STS 4.16.0 이전 버전을 사용했을 것으로 예상된다. goto previous versions

위 에러들 하나씩 상대하다보면 끝은 있겠지만, 처음부터 spring legacy prj에 맞을 만한 이클립스와 플러그인을 사용하는 게 낫다.

2022-09 eclipse

22년 9월 기준 가장 최신 IDE이다. download

Project create

이클립스 상에서 spring plugin 설치 안 할 시, File => New => Other... 해서 나오는 프로젝트 생성 위자드에 스프링이 안뜨지 않는다.

그래서 아래와 같은 최신 spring plugin을 설치

위 plugin 과 이미지의 'Spring Tools 3 Add-On for Spring Tools 4 3.9.22.RELEASE를 깔아도,다른 글과 달리, restart하면 spring legacy prj는 뜨지 않는다. 사실 STS 4와 동일해졌을 뿐이다.

위와같은, 이클립스 2022-09 에서의 설치 에러 로그 살펴보면, 이클립스가 접근하는 서버에서 이클립스 버전 2022-09의 디렉토리에서는 해당 플러그인을 maintained 되지 않는 것으로 보인다.

이클립스 플러그인 파일서버가 있다면, 버전별로 플러그인들을 따로 저장하고 제공하지 않나 싶다.

이를 통해 이클립스 버전에 따라 호환되는 플러그인이 있다 정도로 정리할 수 있다. 이러한 맥락에서 spring legacy prj보다 과거의 dynamic web 등의 prj는 더 지난 이클립스를 써야 할 것으로 예상한다.

이제보니까 pluglin 설명에 설명은 되있으나, 설명서 다읽고 노트북 쓰는 사람없다는 점에서 그렇구나 하고 지나간다.

구체적인 버전은 more info 클릭해야 보이는구만, 다음부터는 클릭할듯

2022-03 eclipse

앞선 plugin 설명에 2022-03까지 지원된다고 되어있으므로, 2022-03 version으로 설치. 그래도 반년전 정도꺼 까지 지원된다는 게 대단한듯, 무료인 거 생각하면 할수록 eclipse는 위대한 듯, 한편 spring legacy prj가 생각보다 오래 전에 만들어진 거 같음.

하지만
역시 쉽게 되는 게 없음. 아래 2개의 플러그인이 앞선 경우와 달리 잘 깔리나, prj 생성 wizard에 spring legacy가 안뜬다. update를 해야한다.

여기 까지 딱 12시간 걸렸다. sts, eclipse 2022-09에서 진전은 있지만 끝이 없는 에러의 굴레에서 시간을 너무 썼다.

하지만
이것도 아직 끝이 아니다.

설명에 따르면 2022-03이면 jdk 11 version 써야 해서 그런듯 하다.

그리고 추가로 eclipse.exe와 동일한 디렉토리의 .ini를 설명에 따라 .ini 파일 바꿔야함

근데 이런걸 도대체 어떻게 아는거고, 어떻게 공부한담, 만든 사람이 어디다가 올려놨겄지? 링크 남겨줬으면 좋겠다

임시결과

spring legacy prj 속 home.jsp. 자동생성 시 최소 값이 home.jsp이다.

사실 index라는 단어의 한글 해석 1순위가 목차라는 점에서 요즘과 같이 다채로운 화면구성에 어색한 표현이라고 매번 느낌.

반가운 home 화면 가운데 ? 가 있음. 이건 친숙한 인코딩 설정문제임

workspace encoding

설명에 따라 workspace 수준에서 jsp 포함 인코딩을 설정한다.

일케 한 다음 prj 수준에서 인코딩 불맛 보려고 encoding 임의로 바꾼거 아니면 그대로 따라감

Config JDK of Project

설명에 따라, Project 수준에서 prj facet에서 추가 설정해야함

결과

lombok of eclipse 2022-03

설명에 따라, 롬복은 spring plugin과 같은 급이다. 실제로 인텔리제이에서는 플러그인 형태로 제공한듯하다. 그러나 이클립스는 무료니까 따로 연결해야한다.

이로서 이클립스에서 모두에게 제공하는 spring Legacy 프로젝트 생성과 설정이 마무리 되었고, 다음부터 보다 프레임워크 관점에서 맞춤 시작

Framework

spring, spring boot, django 등 여기서 지원하는 기능들과 목표들, 그 모든 것. 쓰다보면 공통점도 있고, 차이점도 있것지, 나는 그 경계 뒤지기보단 우선 적재적소

Spring Framework

튜토리얼의 경우, 인코딩같은 세부세팅 잠시제쳐두고, 최신 버전인 boot를 통해 개괄적으로 spring framework 기본 개념 단어들 리마인드하기 좋음. 처음하는 사람들에겐 완전 비추

version

설명에 따라, GetMapping 등의 어노테이션 사용을 위해 pom.xml 에서

<org.springframework-version> 을 기본 3점대에서 4.3.18.RELEASE로 설정. 221007기준 5점대 존재.

spring.io ; spring framework

Best code structure

서비스 변동성이 작고, 작기를 희망한다면 by layer
서비스 변동성이 크기를 희망한다면 by feautre

code structure

상단 보라색 네모들, controller, service, repository들로 package 구조(code들이 들어가고 배치될 곳)를 설정 영역이 code structure라는 영역으로 칭하는 것 같다.

이러한 참고 글들의 출처의 출처를 거슬러 어디 공식 사이트가 나오면 좋겠지만, 충분하다고 생각하여 패스

그리고,
spring.io라는 스프링 프레임워크 공식사이트를 돌아본 결과, 아직까지는 spring framework 레벨에서 code structure를 정의하지 않아보인다.

설명에 의하면
There is no specific layout or code structure for Spring Boot Projects. However, there are some best practices followed by developers that will help us too.

이고, 2개의 code structure가 제시된다.

code structure by feature
code structure by layer

code structure by feature

domain을 1순위로 패키지를 구조화해서 코드들을 배치하는 것으로 이해하기 좋다. 참고로 그렇다고 controller, service, repository가 사라진 건 아니다.

code structure by layer

명시적인 controller, service, repository를 1순위로 패키지를 구조화해서 코드를 배치하는 것으로 이해할수 있고, 대체로 기존 프로젝트들의 code structure가 이를 준수하는 것으로 알고 있다.

그리고 나는 그동안,

spring framework is spring MVC of MVC
spring MVC is controller, service, repository
spring framework is controller, service, repository

이라고 여겨왔기에 다른 걸 상상하기가 어렵고, 비교할 게 없으니 이로 인한 문제도 불가피하다고 생각해왔다.

설명에 의하면 by layer는, 내가 몸소 경험해봤듯이,

Though the above structure looks feasible and easy to locate classes by a layer. It has few disadvantages when compared to Structure by Feature.

Features or Modules cannot be shipped separately.
Hard to locate a class pertaining to a certain feature.
Code Refactoring on a certain feature is difficult since the feature classes located in every layer.
It causes merge conflicts among developers using GitHub, BitBucket, etc. for Collaboration.

이러한 단점이 부각되고,

by feature는

Find a class to be modified is easy.
By deleting a particular sub-package, all the classes related to a certain feature can be deleted.
Testing and Refactoring is easy.
Features can be shipped separately.

이렇다고한다.

하지만, 프로젝트가 정말작고, 처음배우는 사람이 있으면, 위 by layer의 장점인 feasible(실행하기좋은), easy to locate 이득이 단점을 상회한다고 생각한다. 당장 위 spring MVC 도식과 연결지어 이해하고 검색하기 더 좋다고 생각한다.

MyChoice

이번 프로젝트의 경우, code structure는 계속 키울것이므로 by feature

이 부분은 gradle, boot로 바꿔도 동일할듯, java code일뿐이라

크게 3가지의 features; user, article, board (게시판 관련)에 따라서 code structure 설정 및 해당 클래스 추가

그리고, dto and entity 관련 글, dto entity 분리해야하는 이유 참고하여 dto, entity 구분

Junit

화면 안만들고 기능체크가능
멘탈 파괴 방지

바로 위 사진에서 볼 수 있듯이, src/test/java라는 디렉토리가 기본값이다. 이를 사용하기 위한 추가설정이 아래와 같이 필요하다.

최근 eclipse의 경우, Libraries path에 ModulePath, ClassPath 가 존재, 예전 버전일 수록 구분안했다. 설명 참고는 하고, 우선 '친숙한' classpath에 junit library를 배치하였다.

설명에 따라 처음에 junit dependency가 있지만 추가로 spring-test 더 넣어야한다. 참고로, vscode로 조회하면 눈이 매우 편하고, vscode를 통해 수정과 저장 후, eclipse에서 파일 다시 열면 충돌도 없고 매우 편한다. 프론트와 파일조회는 역시 vscode다.