Your First Spring Program Using XML Configuration and Gradle Build Tool

We will use Gradle build tool in this example for creating your first spring program. All other notes in this section will be using Maven in general. You can refer to our notes section on Gradle for learning more about Gradle and translating the maven dependencies I specify. If you go to the Spring Framework page, you can see dependency details for Maven or Gradle builds.

PS: If you are not familiar with Gradle, or don’t want to build your application using Gradle, you can skip this note, as there is an alternate note that uses Maven, that also specifies how to directly use Spring dependency jars.




Problem Summary

We will create a simple class,, with a single method write. This class is a regular pojo (plain old java object) class with no spring specific code. We will create a simple spring config file, spring.xml with a simple bean definition to configure the class as a bean; and then test all these together using a simple test class, Note that the name of the config file can be anything.


Example Code

The has a single method write:

package com.javajee.spring;

public class JJWriter {

  public void write() {

    System.out.println("Default Writer");




The spring.xml file

The spring config xml spring.xml has a bean definition for JJFileWriter:

<?xml version="1.0" encoding="UTF-8"?>

<beans xmlns=""



               <bean id="jjwriter" class="com.javajee.spring.JJWriter">



We will give an id to each of our bean definitions so that we can refer to it with that name from our code.

You will need this file in the classpath while executing the application (while running gradle run). For the example, place it alongside com folder under build\classes\main after building (after gradle build).

Note: Make sure that you are using the latest xsd. You can find the xsds within your downloaded distribution under schemas folder.

The test class JJWriterMain will ask spring to create and return us an object of the class type defined using the class attribute of the bean using the bean id:

package com.javajee.spring;

import org.springframework.context.ApplicationContext;


public class JJWriterMain {

  public static void main(String[] args) {

    ApplicationContext context= new ClassPathXmlApplicationContext("spring.xml");

    JJWriter writer = (JJWriter)context.getBean("jjwriter");





Build.gradle file

Select an empty folder for this exercise.

Create a file called build.gradle with below contents:

apply plugin: 'java'

apply plugin:'application'


mainClassName = "com.javajee.spring.JJWriterMain"


dependencies {

    compile 'org.springframework:spring-context:4.0.5.RELEASE'

    runtime 'org.springframework:spring-context:4.0.5.RELEASE'



repositories {






Compiling the code using Gradle

Gradle provides some default conventions to reduce the code written and we will use those default conventions in this example. Note that we haven’t specified much details in the build file.

Place your source code maintaining the package folder structure (e.g. com\javajee\spring) under Gradle required folder structure src\main\java in the selected folder for this excercise. Final folder structure to place above java source files will be src\main\java\com\javajee\spring.

Compile the code by running ‘gradle build’ from command prompt (from the selected folder) as:

gradle build

You should get the output with BUILD SUCCESSFUL.

You can see that additional folders - build and .gradle - are created by Gradle. The folder build\classes\main will have the compiled class files in correct package folder structure.


Executing the compiled code using Gradle

Before calling run, you need to copy the spring.xml to build\classes\main. You can now run the application as:

gradle run

You will see the output with:

Default Writer


Executing the compiled code without Gradle

To execute the class JJWriterMain outside gradle you will need all the dependency jars in the classpath while executing, which are spring-core-x.x.x.RELEASE.jar, spring-beans-x.x.x.RELEASE.jar, spring-context-x.x.x.RELEASE.jar, spring-expression-x.x.x.RELEASE.jar and commons-logging-x.x.x.jar. These are expected to be there in the runtime environment.

You can add the below code to the build.gradle file if you want to package the contents of dependent jars also to the final jar file which is created under build\libs folder:

jar {

    from configurations.compile.collect { it.isDirectory() ? it : zipTree(it) }



Flat directory repository for offline building using Gradle

In case you have downloaded the jars and put in a folder, you can specify the flat directory, instead of a repository, to resolve dependencies using the flatDir configuration of the repository:

repositories {

  flatDir name: 'localDiskRepo', dirs: 'lib1'


If there are more directories, you can use the syntax:

repositories {

  flatDir dirs: ['lib1', 'lib2']


Here lib1 and lib2 directories should be in the same level as build.gradle file. You can also specify absolute or relative paths (with proper escaping if necessary):

flatDir dirs: ['D:\\GRADLE\\lib1', '../GRADLE/lib2']

Another thing to note here is that, when you specify flatDir to specify a flat directory, you need to specify all required dependencies, unlike before. So for compiling a basic Spring code, instead of specifying only compile 'org.springframework:spring-context:4.0.5.RELEASE', you need to specify as:

dependencies {

    compile 'org.springframework:spring-context:4.0.5.RELEASE'

    compile 'org.springframework:spring-core:4.0.5.RELEASE'

    compile 'org.springframework:spring-beans:4.0.5.RELEASE'

    compile 'org.springframework:spring-expression:4.0.5.RELEASE'

    compile  'org.apache.commons.logging:commons-logging:1.1.3'


I have placed all Spring jars in lib1 and commons logging jar in lib2. Gradle will assume the jar file name from the name and version part above (E.g. spring-core-4.0.5.RELEASE.jar), and search the folders specified as flatDirs. For compiling code, only first 3 jars are require. However to execute (run), you will need all 5 jars.


WAR Plugi-in

The WAR plugin can be used to package the deployable into a WAR file and we can also package any dependent jars in the WAR.


Spring, Gradle and Eclipse IDE

The Spring Tool Suite (STS) provides good support for working with Spring and Gradle in eclipse. There is also an eclipse plugin for Gradle that will generate all required files so that a Gradle project can be imported into eclipse.

Quick Notes Finder Tags

Activities (1) advanced java (1) agile (3) App Servers (6) archived notes (2) ArrayLists (1) Arrays (2) Best Practices (12) Best Practices (Design) (3) Best Practices (Java) (7) Best Practices (Java EE) (1) BigData (3) Chars & Encodings (6) coding problems (2) Collections (15) contests (3) Core Java (All) (53) course plan (2) Database (12) Design patterns (8) dev tools (3) downloads (2) eclipse (9) Essentials (1) examples (14) Exception (1) Exceptions (4) Exercise (1) exercises (6) Getting Started (18) Groovy (2) hadoop (4) hibernate (77) hibernate interview questions (6) History (1) Hot book (5) http monitoring (2) Inheritance (4) intellij (1) java 8 notes (4) Java 9 (1) Java Concepts (7) Java Core (8) java ee exercises (1) java ee interview questions (2) Java Elements (16) Java Environment (1) Java Features (4) java interview points (4) java interview questions (4) javajee initiatives (1) javajee thoughts (3) Java Performance (6) Java Programmer 1 (12) Java Programmer 2 (8) Javascript Frameworks (1) Java SE Professional (1) JPA 1 - Module (6) JPA 1 - Modules (1) JSP (1) Legacy Java (1) linked list (3) maven (1) Multithreading (16) NFR (1) No SQL (1) Object Oriented (9) OCPJP (4) OCPWCD (1) OOAD (3) Operators (4) Overloading (2) Overriding (2) Overviews (1) policies (1) programming (1) Quartz Scheduler (1) Quizzes (17) RabbitMQ (1) references (2) resources (1) restful web service (3) Searching (1) security (10) Servlets (8) Servlets and JSP (31) Site Usage Guidelines (1) Sorting (1) source code management (1) spring (4) spring boot (3) Spring Examples (1) Spring Features (1) spring jpa (1) Stack (1) Streams & IO (3) Strings (11) SW Developer Tools (2) testing (1) troubleshooting (1) user interface (1) vxml (8) web services (1) Web Technologies (1) Web Technology Books (1) youtube (1)