sbt와 Gradle 비교 [닫기]

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

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

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

• SBT : Ivy , 고정 된 버전 (예 : 1.5.2) 또는 최신 (또는 동적) 버전으로 제공 될 수있는 개정판.
  " Ivy Dependency "를 참조하십시오. Mark Harrah 가이 스레드 에서 자세히 설명
  하더라도 "-SNAPSHOT"메커니즘 지원이 문제가 될 수 있음을 의미합니다 .

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

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

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

아시다시피, Ivy 및 Maven 스냅 샷 종속성 문제는 Gradle이 결국 Ivy를 자체 종속성 관리 코드로 대체 한 이유 중 하나였습니다. 큰 일 이었지만 우리에게 많은 장점을 가져다주었습니다.

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

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

(두 도구 모두 서로 배울 수 있음 )

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

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

단점은 다음과 같습니다.

• 신규 사용자를 실망시키는 경향이있는 상형 문자 구문 (특히 Java에서 온 경우)
• "작업"을 정의하는 쉬운 방법이 없습니다. 특별한 빌드 절차가 필요한 경우 플러그인을 찾거나 직접 플러그인을 작성해야합니다.

sbt는 Scala DSL이고 Scala는 일류 시민이므로 원칙적으로 잘 맞는 것 같습니다.

그러나 sbt는 버전간에 호환되지 않는 주요 변경 사항으로 인해 작업에 대한 올바른 작동 플러그인을 찾고 작동하도록하기가 어렵습니다.

나는 sbt가 해결 한 것보다 더 많은 문제를 일으키고 있었기 때문에 개인적으로 포기했습니다. 나는 실제로 gradle로 전환했습니다.

그림을 이동.

저는 gradle을 처음 접하고 sbt를 처음 사용합니다. 지금까지 sbt에 대해 정말 좋아하는 것은 대화 형 콘솔입니다. 무슨 일이 일어나고 있는지 더 잘 이해하기 위해 '검사'와 같은 명령을 사용할 수 있습니다. AFAIK gradle은 이와 같은 atm을 제공하지 않습니다.

Sbt와 gradle은 둘 다 정적으로 형식화 된 언어를 기반으로하지만 sbt에는 몇 가지 장점이 있습니다.

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