In my posts, I refer to Spring ‘Modules‘ and ‘Projects‘ as if they are separate in Spring Ecosystem. Are they?
Here is a fun fact for new Spring Framework users:
Before Spring 3 came out, you could download the entire spring framework as one big jar file.
Yup. One big all-in-one uber jar. True Story.
Just like groovy.
If you didn’t know, You can download groovy as groovy-all.jar even today. All groovy features, libraries packed into one jar.
Don’t you love it when everything you need is available as one download?
For one, You have no conflicts to worry about. If you upgrade, you can throw away the uber jar and replace it with the new one.
So, What made Spring Framework stop bundling everything in one jar?
I will give you a hint. It had something to do with the modules.
Let me pause here and bring up another discussion that will coincide well here.
If you haven’t, I urge you to check out my introduction to the Spring Projects here. This discussion today would be incomplete if you don’t know Spring Projects. The post would help you relate what I am going to say here.
In my post, I mentioned Spring Modules with as much brevity as I could and tried to skip the topic with haste.
I avoided the distinction between Spring Projects and Modules that exists within Spring Ecosystem. There was a simple reason for that – I did not want to muddy the waters.
But the Spring Modules mention was crucial regardless.
Today I will expand that conversation. I will go over different Spring Modules that exist in Spring Framework.
Why do you care about Spring Modules?
Spring Modules are the building blocks of Spring Projects and Spring Framework.
They are what Spring Framework is today. They are what defined Spring Framework.
They have existed from the day one. Although they have evolved over time.
They are what you see when you look under the hood of Spring Project.
They are common, reusable components that Spring Projects and Spring Framework builds upon.
They are the artifacts you would pull from Spring repositories. I will give an example of this soon.
And last but not least. If you are still using Spring 3.x, you would need to understand them for two reasons:
a) You need to identify dependencies based on the features you are building. These features would translate into spring modules at its core.
b) You may need to resolve conflicts in case you end up with different versions of spring related jars.
Why would you run into these conflicts? Read on.
If you were using Spring 2 or older versions, You did not encounter this issue. As long as you had spring-all.jar in your project, no conflicts arose.
Spring even came with two download flavors: spring-all and spring-all-with-dependencies. That ensured no conflict.
If you are using Spring 4, you won’t run into conflicts I mention above (with most projects). My post about Spring Projects explains the Bill of material (BOM) concept as well.
Why wouldn’t you run into conflicts with Spring 4?
With BOM, you get a bundle with all dependencies and versions identified. When you include a new Spring Module or Subproject, You don’t specify the version. The BOM will know to pull appropriate version.
With Spring Boot, this problem is non-existent. Spring Data Project follows the BOM model well. Spring Framework Project has a BOM as well.
One thing that makes Spring Framework successful is its ability to adapt and re-invent.
With Spring 3 release, there were so many projects in existence working at their own pace. At times, I would see Spring Projects having to play catch up with the Spring Framework core upgrades.
That led to conflicts or compatibility issues in my own projects. Acegi’s upgrade to Spring Security comes to mind right away.
Spring Security upgrade took away all the security filters we were having to define as part of Acegi. This made perfect sense. But the upgrade path was painful.
It helped to know the underlying modules to resolve the situation.
Luckily, Spring does a good job of staying backwards compatible in most cases.
Have Spring Modules always existed?
There IS a big difference between Spring Modules and Spring Projects. Did I mention there are Spring Subprojects as well?
Let me mention few of them and see if you can identify them.
Spring JDBC is a module.
Spring Data is a project.
Spring Cloud Netflix is a subproject…
Spring Web is a module.
Spring LDAP is a project.
Spring Data JPA is a subproject…
Spring AOP is a module.
Spring Web Flow is a project.
Spring Social Facebook is a subproject…
What is going on?
This distinction between Spring Projects vs Modules vs Subprojects has not existed forever. If you have been away from Spring for the past 4-5 years, I won’t blame you if you couldn’t tell them apart.
It wouldn’t surprise me if you pointed me to spring modules website that used to exist on java.net.
It wouldn’t surprise me if you called them packages either.
But there is one thing that old timers can point out: The so-called modules from above are well known to them. They have always existed within Spring Framework.
Let me take you back into the world when Spring Framework had just emerged. You will get to see how these modules evolved over time to where we are today.
Let’s start with Spring 0.9 version.
Core Modules: Spring 0.9 to Spring 1.0
Spring Framework 0.9 is earliest spring framework code that still exists on SourceForge.
If you look at the spring framework 0.9 zip file here, you will notice that it came with 15 packages.
Even in initial stages of Spring Framework, these 15 packages would be available as 5 Modules.
If spring.io were drawing the structure that existed back then, I think they would draw this:
Spring Core Module consisted of packages: Beans Core JNDI Utils
Spring Context Module: AOP Context ORM Transaction Validation
Spring EJBImpl Module: EJB
Spring JDBC Module: Dao JDBC
Spring Web Module: Web UI Remoting
The logical division of packages made perfect sense back then. Check out this post for why Spring Framework needed to exist.
Not too long from 0.9 release, the packages were re-grouped again:
Few key things that changed between versions 0.9 and 1.0:
1) Spring AOP combined with source-level metadata became its own module. AOP was part of Spring Context earlier.
Spring AOP Aspect Oriented Programming can help out in different layers.
You can use Spring AOP to audit requests coming from the web for let’s say security reasons.
You can also handle transactions in service layer without touching the business logic.
You can use Spring AOP for logging specific method calls and not have to change the code in it.
It made sense to move it out of the core and into its own module.
2) Spring Web and Web MVC split into two modules.
3) JNDI, EJB and Remoting packages are moved to Spring Context.
4) A new package Mail gets added to Spring Context.
5) Transaction moves to Spring JDBC which is now renamed as Spring DAO.
6) The new Spring ORM Module encapsulates Hibernate, JDO and iBatis support now.
Core Modules: Spring 1.0 to Spring 2.0
Things start to get murky now. The modules lose their meaning here in my opinion.
There were seven modules identified in the diagram but the image shows six divisions.
The ‘dist‘ directory lists 21 jars under ‘modules’ folder.
This does not align with the previous version definitions of modules.
The uber jar continues to include everything which is helpful.
1) We see a new JEE module now. EJB, Remoting and Email packages move here from Spring Context. New packages JMX, JMS and JCA introduced.
2) Spring Context moves into Spring Core Container Module.
3) Spring ORM Module adds JPA, Toplink support.
4) Spring MVC moves back into Spring Web. Portlets, Jasper Reports, and various other view technologies introduced.
Core Modules: Spring 2.0 to Spring 3.0
The module definition reflects the diagram again. The documentation is clear.
Spring adopts ivy build mechanism throughout and cleans out the directory structure.
Few important changes that came in:
1) The Modules fall under the following five categories now.
Spring Web
Spring Test
Spring Data Access/Integration
Spring AOP and Instrumentation
Spring Core Container
I plan to go over them in my next post. For now, it is ok to assume that they are reusable components within Spring Framework.
2) Spring Core container lays out Beans, Core, Context.
Spring Expression Language is a newcomer in the container.
3) Spring Test is a first class citizen now.
4) Spring OXM module makes an entry. The Object/XML mapping helps with XML Marshalling/UnMarshalling of objects.
The modules are well defined and independent now. Spring has 20 different modules. The list has grown over the years.
Spring’s ecosystem is growing with ever-increasing support for technologies.
It does not make sense to include them all in one jar anymore.
If my project does not need Object to XML Mapping, I don’t need the module in my jar.
This independence of modules will lead to a leaner Spring Project as I provide few examples below.
Before that, Let me close out the topic with the current state of Modules.
Core Modules: Spring 3.0 to Spring 4.0
The consistency from Spring 3.0 is visible in Spring 4.0 as well. Few minor additions I see:
1) A new ‘WebSocket’ Module exists under The Web now.
2) A new module ‘Messaging‘ exists under its own category now. See the six categories now:
Spring Web
Spring Test
Spring Data Access/Integration
Spring AOP and Instrumentation
Spring Core Container
Spring Messaging
3) Spring Web Category has Spring WebMVC Module now. This replaces Servlet and Struts Modules from Spring 3.0
Spring Modules and Spring Projects
One great positive effect of having clean modules shows up in Spring Projects.
Spring Projects can provide a complete feature offering for your application now. Thanks in part to Spring Modules.
When you have a project that leverages Spring LDAP project let’s say. You won’t see just one ‘spring-ldap.jar‘ for inclusion.
You will see the following modules packaged underneath:
1) Spring LDAP Core Module
2) Spring Beans Module
3) Spring Core Module
4) Spring Transactions Module
The Project will only include the modules that serve the feature.
With BOM concept, these projects also regulate the release schedule now. This helps developer not have to worry about version issues anymore.
Last but not least, I did not mention Spring Subprojects. But they are Spring Projects that fall under one umbrella. They pull modules just like Spring Projects and are independent of others in the same project.
Spring Data Project has support for several databases. Each database support feature is a subproject within Spring Data Umbrella Project.
In closing, I will throw some numbers here again.
There are 18 or more Spring Projects:
Some of these projects have subprojects:
Spring Cloud has 7 subprojects:
Spring Data has 9 subprojects.
Spring Security has 4 subprojects.
And Spring Social has 4 subprojects.
There are 20 Spring Core modules.
A grid of projects and the modules they share is available in case you were curious here.
Now that we see the connection between Spring Projects and Spring Modules, I can go over the spring modules in more depth and explain core concepts of Spring Framework going forward.
If you think this post helped you in any way, I would love to hear your comments below. If there is anything specific you would be interested in going over, please let me know as well.
Thanks
-Amit
