sbt와 Gradle 비교

sbt와 Gradle 비교

---

나는 스칼라에 뛰어 들어 SBT를 발견했다. java / groovy 프로젝트에서 Gradle에 매우 만족했으며 Gradle 용 스칼라 플러그인이 있다는 것을 알고 있습니다.

Scala 프로젝트에서 Gradle보다 sbt를 선호하는 좋은 이유는 무엇입니까?

---

SBT와 Gradle의 주요 차이점 중 하나는 종속성 관리입니다 .

• SBT : 아이비 (Ivy ) : 수정 버전 (예 : 1.5.2) 또는 최신 (또는 동적) 버전으로 제공 될 수 있습니다.
  " Ivy Dependency "를 참조하십시오.
  이는 Mark Harrah 가이 스레드 에서 세부 사항을 수행 하더라도 "-SNAPSHOT"메커니즘 지원에 문제가있을 수 있음을 의미합니다 .

캐시가 혼란 스러울 수는 있지만 아이비가 스냅 샷 해결을 이해하지 못하는 것은 아닙니다. 유진은이 점을 다른 스레드, 아마도 관리자 목록에서 설명했습니다. 0.12에서 해결 된 sbt의 자동 업데이트에 문제가 있습니다.

내가 아는 한 아이비가 지원하지 않는 것은 Maven과 같은 방식으로 스냅 샷을 게시하는 것입니다. 나는 이것을 다른 곳에서 언급했다고 생각하지만, 누군가가 상황을 개선하고 싶다면 Gradle 팀과 협력하여 종속성 관리 코드를 재사용하는 것이 최선의 노력이라고 생각합니다.

• Gradle : 이 스레드 는 ( Peter Niederwieser )를 언급합니다 .

아이비와 메이븐 스냅 샷 의존성 문제는 Gradle이 아이비를 자체 의존성 관리 코드로 대체 한 이유 중 하나입니다. 그것은 큰 일 이었지만 우리에게 많은 선을 가져 왔습니다.

이 트윗 은 모든 상황이 미래에 진화 할 수 있다고 언급합니다.

Mark는 과거에 SBT에 Ivy 대신 Gradle을 사용하는 데 관심이 있다고 말했습니다.

(두 도구 모두 서로 배울 수 있습니다 )

---

저에게 SBT의 주요 기능은 다음과 같습니다.

• 빠른 컴파일 (보다 빠름 fsc).
• 지속적인 컴파일 / 테스트 : 명령 ~test은 수정 사항을 저장할 때마다 프로젝트를 다시 컴파일하고 테스트합니다.
• 여러 스칼라 버전에서 크로스 컴파일 및 크로스 퍼블리싱.
• 올바른 스칼라 버전 호환성으로 종속성을 자동으로 검색합니다.

단점은 다음과 같습니다.

• 새로운 사용자를 방해하는 경향이있는 상형 문자 구문 (특히 Java 사용자 인 경우)
• "작업"을 쉽게 정의 할 수있는 방법은 없습니다. 특별한 빌드 절차가 필요하면 플러그인을 찾거나 직접 플러그인을 작성해야합니다.

---

sbt는 스칼라 DSL이며 스칼라는 일류 시민이므로 원칙적으로 적합합니다.

그러나 sbt는 버전간에 호환되지 않는 주요 변경 사항으로 인해 작업에 맞는 올바른 플러그인을 찾아서 작동시키기가 어렵습니다.

나는 그것이 해결 된 것보다 더 많은 문제를 일으켰 기 때문에 개인적으로 sbt를 포기했다. 나는 실제로 gradle로 전환했다.

그림을 이동.

---

나는 gradle을 처음 접했고 sbt를 처음 접했습니다. 지금까지 sbt에 대해 정말 좋아하는 것은 대화 형 콘솔입니다. 'inspect'와 같은 명령을 사용하여 진행 상황을 더 잘 이해할 수 있습니다. AFAIK gradle은 이와 같은 ATM을 제공하지 않습니다.

---

Sbt와 gradle은 모두 정적으로 유형이 지정된 언어를 기반으로합니다. 그러나 sbt는 몇 가지 장점이 있습니다.

• 더 나은 플러그인 지원, 특히 자동 플러그인
• 작업 간의 작업 생성 및 종속성 관리
• sbt는 증분 빌드를 지원한다는 점에서 스칼라 프로젝트에 특히 적합하며 대부분의 sbt 자체는 스칼라로 작성되고 sbt 빌드 정의는 스칼라로 작성됩니다
• sbt는 많은 유용한 내장 작업을 통해 대화 형 셸을 지원합니다.
• sbt 기본 수명주기는 매우 유용하며 적은 노력으로 초보자를 시작할 수 있습니다.

참고 URL : https://stackoverflow.com/questions/11061938/comparing-sbt-and-gradle