비록 스프링이 엔터프라이즈와 다른 외부 도구들에 대한 광범위한 통합과 지원을 제공하더라도 의도적으로 의존성을 최소한으로 유지해야 한다. 간단한 사용을 위해서 (자동으로 한다고 하더라도) 많은 jar 라이브러리를 다운받아 설치하지 말아야 한다. 기본적인 의존성 주입을 사용하려면 오직 하나의 외부 의존성만 필요하고 이는 로깅을 위한 것이다(로깅 옵션에 대한 더 자세한 내용을 아래를 봐라).

다음은 스프링에 의존하는 애플리케이션 설정하는 필요한 기본적인 과정을 설명할 차례이다. 먼저 Maven을 살펴보고, Gradle, 그리고 Ivy를 살펴볼 것이다. 모든 경우에, 불명확한 것이 있다면, 여러분의 의존성 관리 시스템의 문서를 참고하거나, 예제코드를 보아라. 스프링은 개발과정에서 의존성 관리를 위해 그래들를 사용하고, 샘플들은 대부분 그래들이나 Maven을 사용한다.

Maven으로 의존성을 관리한다면 로깅 의존성을 명시할 필요도 없다. 예를 들어 애플리케이션 컨텍스트을 생성하고 애플리케이션 설정에 의존성 주입을 사용하려면 Maven 의존성은 다음과 같을 것이다.

<dependencies>
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-context</artifactId>
        <version>4.1.5.RELEASE</version>
        <scope>runtime</scope>
    </dependency>
</dependencies>

이것이 전부다. 스프링 API를 참조하여 컴파일할 필요가 없다면 scope를 runtime으로 선언할 수 있다. 이는 기본적인 의존성 주입의 유즈케이스다.

위의 예제에서는 Maven Central의 저장소로 동작한다. 스프링 Maven 저장소를 사용하기 위해서는 (예. 마일스톤이나 개발 스냅샷을 위해), 여러분의 Maven 설정에 저장소 경로를 지정할 필요가 있다. 전체 릴리즈를 사용하려면 다음과 같이 작성한다.

<repositories>
    <repository>
        <id>io.spring.repo.maven.release</id>
        <url>http://repo.spring.io/release/</url>
        <snapshots><enabled>false</enabled></snapshots>
    </repository>
</repositories>

마일스톤을 사용하려면 다음과 같이 작성한다.

<repositories>
    <repository>
        <id>io.spring.repo.maven.milestone</id>
        <url>http://repo.spring.io/milestone/</url>
        <snapshots><enabled>false</enabled></snapshots>
    </repository>
</repositories>

개발 스냅샷을 사용하려면 다음과 같이 작성한다.

<repositories>
    <repository>
        <id>io.spring.repo.maven.snapshot</id>
        <url>http://repo.spring.io/snapshot/</url>
        <snapshots><enabled>true</enabled></snapshots>
    </repository>
</repositories>

우연찮게 Maven을 사용하여 스프링 JAR들의 여러 버전들을 섞어서 사용할 경우가 있을 것이다. 예를 들어, 서드-파티 라이브러리나 다른 스프링 프로젝트를 찾았는데 그것들이 옛날 릴리즈를 이행적(transitive)으로 의존을 하고 있다고 하자. 혹시 의존성을 당신 스스로 명시적으로 선언하는 것을 잊어버렸다면, 예상하지 못한 이슈들이 발생할 수 있다.

그러한 문제들을 해결하기 위해 Maven은 "제품 구성 사항" (BOM)의 개념을 제공한다. 모든 스프링 의존성들이 동일한 버전에 있는 것을 보장(직접 혹은 이행적인 것 모두)하기 위해서 당신의 dependencyManagement 섹션에 spring-framework-bom를 추가할 수 있다.

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-framework-bom</artifactId>
            <version>4.1.5.RELEASE</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

BOM을 사용하게 되면 스프링 프레임워크의 아티팩트들의 의존성을 지정시에 더이상 특정 <version> 속성을 지정할 필요가 없어지게 되어 부가적으로 편해진다.

<dependencies>
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-context</artifactId>
    </dependency>
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-web</artifactId>
    </dependency>
<dependencies>

Gradle 빌드 시스템으로 스프링 저장소를 사용하기 위해서는, repositories 섹션에 적절한 URL을 포함시킨다.

repositories {
    mavenCentral()
    // 그리고 추가적으로...
    maven { url "http://repo.spring.io/release" }
}

repositories URL 대신에 적절히 /release를 /milestone이나 /snapshot 로 바꿀 수 있다. 일단 저장소가 설정이 되면, 보통의 Gradle 방식으로 의존성들을 선언할 수 있다.

dependencies {
    compile("org.springframework:spring-context:4.1.5.RELEASE")
    testCompile("org.springframework:spring-test:4.1.5.RELEASE")
}

Ivy를 사용하여 의존성 관리를 하길 좋아하더라도 라이브러리 이름과 설정옵션은 비슷하다.

아이비를 설정하려면 여러분의 ivysettings.xml에 스프링 저장소를 가리킬 수 있게 다음의 resolver를 추가한다.

<resolvers>
    <ibiblio name="io.spring.repo.maven.release"
            m2compatible="true"
            root="http://repo.spring.io/release/"/>
</resolvers>

root URL을 적절히 /release/ 대신에 /milestone/이나 /snapshot/로 바꿀 수 있다.

일단 설정을 하고나면, 보통 하는 방법대로 의존성들을 추가할 수 있다. 다음은 하나의 예이다(ivy.xml).

<dependency org="org.springframework"
    name="spring-core" rev="4.1.5.RELEASE" conf="compile->runtime"/>

비록 추천하는 스프링 프레임워크를 획득하는 방법이 의존성 관리의 지원을 받는 빌드 시스템을 사용하는 것이지만, 여전히 배포되는 zip 파일을 다운로드하는 것이 가능하다.

배포판 zip파일들은 스프링 Maven 저장소에 공개된다. (Maven 저장소를 사용하는 것은 단지 편의를 위한 것이지, 그것들을 다운로드 받기 위해 Maven이나 기타 빌드 시스템이 필요하지는 않다).

패포판 zip을 다운로드 받기위해서 웹 브라우저를 http://repo.spring.io/release/org/springframework/spring로 이동하고, 적절한 원하는 버전의 서브폴더를 선택한다. 배포 파일들은 -dist.zip로 끝난다. 예를 들면, spring-framework-4.1.5.RELEASE-RELEASE-dist.zip와 같다. 배포판들은 milestones과 snapshots버전도 있다.

안타깝게도 commons-logging의 런타임 탐색 알고리즘은 엔드유저에게는 편리하지만, 문제의 소지가 있다. 시간을 거꾸로 돌릴 수 있거나 스프링을 새로운 프로젝트로 다시 시작한다면 런타임 디스커버리 알고리즘은 다른 로깅 의존성을 사용할 것이다. 첫 번째 선택은 아마 Simple Logging Facade for Java (SLF4J)일 것이다. 이것은 이미 그들의 애플리케이션에서 스프링과 함께 많이 사용하는 도구이다.

commons-logging을 사용하지 않는 방법은 크게 두 가지가 있다.

commons-logging을 제외하기 위해서, dependencyManagement에 다음 내용을 추가한다.

<dependencies>
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-core</artifactId>
        <version>4.1.5.RELEASE</version>
        <exclusions>
            <exclusion>
                <groupId>commons-logging</groupId>
                <artifactId>commons-logging</artifactId>
            </exclusion>
        </exclusions>
    </dependency>
</dependencies>

이제 이 애플리케이션은 클래스 패스상에 JCL API의 구현이 없기 때문에 빌드가 깨질 것이다. 따라서 새로운 구현체를 추가하면 이 문제를 해결할 수 있다. 다음 섹션에서 예제를 통해 SLF4J를 사용하는 JCL의 대체할 구현체를 제공하는 방법을 살펴볼 것이다.

SLF4J는 commons-logging에 비해 의존성이 깔끔하며, 다른 로깅 프레임워크들이 런타임에서 탐색을 수행하는 대신에 SLF4J는 컴파일시 바인딩하기 때문에 런타임이 더 효율적이다. 달리 말하면 SLF4J는 런타임에서 벌어질 일을 더 명시적으로 지정해야 한다는 의미이다. 따라서 의존성을 선언하고 적절하게 설정해야 한다. SLF4J는 대부분의 로깅 프레임워크에 대한 바인딩을 지원하므로 기존에 사용하던 로깅 프레임워크를 계속 사용할 수 있다. 사용하는 로깅 프레임워크를 설정과 관리에 바인딩하면 된다.

SLF4J는 JCL을 포함한 많은 로깅 프레임워크에 대한 바인딩을 지원한다. 반대로 다른 로깅 프레임워크가 SLF4J로 바인딩할 수도 있다. 즉, 다른 로깅프레임워크와 SLF4J사이에 브릿지로 사용할 수도 있다. 그래서 스프링과 SLF4J를 함께 사용하려면 commons-logging의존성을 SLF4J-JCL 브릿지로 바꿔야 한다. 일단 설정을 바꾸었으면 스프링에서 호출된 로깅은 SLF4J API를 호출하는 로깅으로 전환된다. 따라서 애플리케이션의 다른 라이브러리가 같은 API의 로깅을 사용한다면 한 곳에서 로깅을 설정하고 관리할 수 있다.

스프링에서 브릿지를 통해 SLF4J로 연결하고, 다시 명시적으로 SLF4J를 Log4J로 바인딩하는 것이 가장 일반적이다. 브릿지, SLF4J API, Log4J로의 바인딩, Log4J구현체의 4가지 의존성을 추가해야 한다 (기존에 존재하던 commons-logging는 제외 처리). Maven이라면 다음과 같이 추가한다.

<dependencies>
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-core</artifactId>
        <version>4.1.5.RELEASE</version>
        <exclusions>
            <exclusion>
                <groupId>commons-logging</groupId>
                <artifactId>commons-logging</artifactId>
            </exclusion>
        </exclusions>
    </dependency>
    <dependency>
        <groupId>org.slf4j</groupId>
        <artifactId>jcl-over-slf4j</artifactId>
        <version>1.5.8</version>
    </dependency>
    <dependency>
        <groupId>org.slf4j</groupId>
        <artifactId>slf4j-api</artifactId>
        <version>1.5.8</version>
    </dependency>
    <dependency>
        <groupId>org.slf4j</groupId>
        <artifactId>slf4j-log4j12</artifactId>
        <version>1.5.8</version>
    </dependency>
    <dependency>
        <groupId>log4j</groupId>
        <artifactId>log4j</artifactId>
        <version>1.2.14</version>
    </dependency>
</dependencies>

단순히 로깅을 사용하기 위해 너무 많은 의존성을 추가한 것처럼 보일 수 있다. 하지만 이는 선택사항이고 평범한 commons-logging보다 나은 동작을 한다. 특히 commons-logging는 OSGi 플랫폼 같은 엄격한 컨테이너를 사용한다면 클래스로더 이슈도 고려해야 한다. 또한, 바인딩이 런타임이 아닌 컴파일 시점에 이뤄지기 때문에 성능적인 이점도 있다고 알려져 있다.

SLF4J 사용자들 사이에는 더욱 보변적인 선택이 있는데 Logback으로 직접적으로 바인딩하는 방법이다. 이는 더 적은 단계들과 의존성들의 발생을 줄여주는 방법이다. Logback은 SLF4J를 직접적으로 구현하고 있기 때문에 추가 바인딩 단계를 줄일 수 있다. 따라서 4개가 아닌 2개( jcl-over-slf4j 와 logback)의 라이브러리에만 의존할 수 있다. 클래스패스 상에 오직 한가지 버전의 API만 존재하기를 바라기 때문에, 스프링이 아닌 별도의 외부 의존성들로 부터 slf4j-api에 대한 의존성을 제외할 필요가 있다.

많은 사람들이 설정과 관리 때문에 로깅 프레임워크로 Log4j를 사용한다. Log4j는 사용하기 편하고 잘 구성되어 있다. 사실 스프링을 만들고 테스트할 때 런타임에서 Log4j를 사용했다. 스프링은 Log4j의 설정과 초기화를 위한 몇 가지 유틸리티도 제공한다. 그래서 스프링의 몇몇 모듈에는 컴파일 시점에 Log4j에 대한 선택적인 의존성이 존재한다.

기본 JCL 의존성(commons-logging)과 함께 Log4j가 동작하게 하려면 클래스패스에 Log4j를 두고 클래스패스의 루트에 설정파일 (log4j.properties 나 log4j.xml)을 두면 된다. 메이븐 사용자라면 의존성 선언에 추가한다.

<dependencies>
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-core</artifactId>
        <version>4.1.5.RELEASE</version>
    </dependency>
    <dependency>
        <groupId>log4j</groupId>
        <artifactId>log4j</artifactId>
        <version>1.2.14</version>
    </dependency>
</dependencies>

다음은 콘솔에 로그를 출력하는 log4j.properties의 예제이다.

log4j.rootCategory=INFO, stdout

log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.ConversionPattern=%d{ABSOLUTE} %5p %t %c{2}:%L - %m%n

log4j.category.org.springframework.beans.factory=DEBUG