Spring starter dependencies - spring

I just started out learning spring boot and I can immediately see that there are two types of dependencies, at least those I have encountered,those labelled starter and those that are not. My question is what is the difference and when should I use one over the other.

The starter dependencies are just dependencies that contain a bunch of transitive dependencies. Try to Ctrl + Click them, you will see what other dependencies they contain.
Spring has packaged these dependencies to make your life easier and make you able to add all common dependencies needed to do certain tasks.
This is all based on their motto of convention over configuration.

The short answer is that those "starter" packages are autoconfigurable. They don't need any particular configuration to work out of the box, but you may configure them to fit your particular needs, which makes them perfect for the Spring Boot's focus on simplicity.
Those dependencies are thought to be used with Spring Boot, but the others were/are there for Spring (non Boot) projects. I haven't really dived in to them to pinpoint specific differences, but they pretty much work the same (I've successfuly build and run projects with autoconfigurable dependencies in Spring non Boot projects, but take that with a grain of salt, as those were practice projects in controlled environments).
Ideally you'd want to use 'regular' dependencies with non Boot projects and you'd want to use 'starters' for Boot projects, but it is not a hard rule. Just make sure to use properly mantained dependencies.

Related

How do big bundled open source projects like Spring Boot ensure compatibility between modules?

Spring Boot contains loads of dependencies: Spring Framework, Spring Data, etc. How do the Spring maintainers accomplish releasing everything while different teams work on different Spring projects?
We have a similar situation, we have 4-5 teams each making different libraries which are used by other teams. We prefer to be able to allow teams to release independently but this is a huge undertaking to ensure binary compatibility of interface and behaviour.
Each release of Spring Boot provides a curated list of dependencies it supports. In practice, you do not need to provide a version for any of these dependencies in your build configuration as Spring Boot is managing that for you. When you upgrade Spring Boot itself, these dependencies will be upgraded as well in a consistent way.
The curated list contains all the spring modules that you can use with Spring Boot as well as a refined list of third party libraries. The list is available as a standard Bills of Materials (spring-boot-dependencies) and additional dedicated support for Maven and Gradle are available as well.
URL: https://docs.spring.io/spring-boot/docs/1.3.8.RELEASE/reference/html/using-boot-build-systems.html

Is it necessary to use a spring initializr for creating spring applications?

I have started learning about spring and in every tutorial they start from spring initializr, i was wondering is it necessary to use it or we can create a project without using spring initializr ?
No, it is no necessary. You can do everything by your own hands. It just helps you to start quicker so that you focus more on the Spring concepts instead of spending much time on "infrastructure" like configuring dependencies. You run it and it just works. Then you can extend it step by step. This can be especially helpful if you just start learning Spring. Later on you should of course spend some time on other aspects that initializr provides you.
Adding to whatever is already mentioned.
No , it is not necessary to create a project with Spring Initializr
The site provides a curated list of dependencies that you can add to
your application based on the selected Spring Boot version. You can
also choose the language, build system and JVM version for the
project.
https://spring.io/blog/2019/02/20/what-s-new-with-spring-initializr.
https://github.com/spring-io/initializr/
Using Spring Initializr the right dependencies are preconfigured for the Spring Boot version used. These preconfigured projects reduces the setup time and one can start implementing the code rather than investing time on which dependencies to go with.

Is bad practice to have spring boot starter project for starter project?

Spring boot starter project provides extensive set of functionalities auto configured. But for our application we want to have only a subset of functionality. May be only one feature out of the spring boot starter project. So is it advised to have custom starter project on top of spring boot provided starter project to mask some of the features or write new starter project directly from lower level libraries?
Spring boot starter project provides extensive set of functionalities
auto configured
There are two separate concerns you are talking about.
I think the auto configured part is something which is Spring boot's opinionated way of configuring. As an example if in classpath it finds a in-memory database library ( like H2) it automatically creates a datasource (pointing to embedded in-memory database) which is available for autowiring without you writing the configuration in a Java config class. Of course you can create you own datasource of choice by including appropriate driver jar for that database. Similarly lots of other configurations are done by default by classpath scanning and availability of certain jars and classes.
The second part - is more of a dependency issue in general. Say you want to use web mvc part in Spring boot. This will require a consistent set of dependencies and transitive dependencies as well. Rather than finding and declaring the dependency in your build tool of choice ( maven, gradle etc) it has created the concept of starter projects where you simply mention the parent and all the right dependencies would be pulled on. This gives a great way to correctly lock your dependencies. However if you want to include any different version than what is provided by boot starter ( provided there is no compatibility issues with those different versions) you can still add explicitly in your build tool. For e.g., maven will by default include the highest version of a particular dependency among all available via transitive dependencies when it resolves dependency for an artifact.

Is there any particular reason why Spring boot starters using Maven? Is it straightforward to use gradle for custom starter with artifactory?

I am trying to balance time and avoid stepping on mines, on one side we have artifactory which is gradle based and need corresponding work to integrate with maven/gradle plugin(preferably with latter as most of our projects are gradle based) on another side all spring boot default starters in source are pom.xml + I only found single gradle custom repo:
https://github.com/web3j/web3j-spring-boot-starter in several pages of search results which uses gradle. But the build file looks pretty convoluted and includes a lot of maven parts.
I am happy to invest time into gradle if someone gives a green light with example/guide/share experience. Thanks. Just to understand if there is some particular reason why the situation is like that or I am afraid of ghosts?
A Spring Boot starter is a jar file containing some compiled classes and, typically, a META-INF/spring.factories file that lists some auto-configuration classes. As such, they can be built equally well with Maven or Gradle. Spring Boot's own starters are built with Maven purely because that's the build system that the whole project uses. If we were starting again from scratch now, we'd probably chose Gradle over Maven.
Some of the third-party starters listed here are build with Gradle, for example:
azure-application-insights-spring-boot-starter
charon-spring-boot-starter
session-couchbase-spring-boot-starter

Spring Boot: starter modules - do i need to keep them?

I am starting yet another project based on spring boot.
For start it's pretty obvious and easy to go with spring-boot-starter dependencies. But for example I have projects which already live for 2 years and it becomes more challenging and time consuming to upgrade versions of those modules. Mostly because lot's of things auto-confugured under the hood, and there is only hidden knowledge to control them.
What would be the best practice to plan the new project for long term support and be able without any problems upgrade spring boot versions?
Are starter modules really just for start? After some time they should be fully replaced with pure modules from Spring framework?
The intention of Spring Starter modules is not necessarily intended to be aimed at being replaced by manually defining your dependencies. In fact, it's more the opposite, as the set of dependencies defined in starters are tested to work as expected as it provides an opinionated set.
The pattern laid out by Spring Boot is two fold, autoconfigure modules and starter modules:
Autoconfigure modules that generally do not, unless necessary, require dependencies downstream. Autoconfigure modules will compile against one or many modules, and then enable configurations within your application context based on rules generally governed by what libraries and components are available at context initialization. This is useful as it provides reasonable baseline configurations that can be used in a variety of scenarios, without enforcing what particular libraries/vendors downstream consumers must use. However, because they are intended to be used in a variety of scenarios, it is incumbent upon you as the consumer to ensure you have a valid context.
Starter modules are complimentary to autoconfigure modules. They provide an opinionated set of dependencies downstream, along with autoconfigure dependencies, to allow consumers to get started. Generally, but not necessarily, starter modules themselves are fairly empty and often do not contain any classes, as their main purpose is to just provide a POM that can be used for transitive dependencies.
Although your query is not about developing custom auto-configuration, the Spring Boot documentation regarding developing your own auto-configuration does a good job explaining the pattern.
Traditionally when we develop a Spring application, we need to include all the required dependencies (spring or other framework jar) by ourself. Starter is intended to minimize such configuration . It does not have any codes or logic inside . You can think that it is just a configuration setting which pre-defines some dependencies. Including a starter will automatically include all of the dependencies defined by this starter to your project thanks to the build system (e.g Maven) 's "transitive dependencies" features.
So you can see that starter provides one of the SpringBoot philosophy, which enable developer to create a Spring app that can "just run" quickly without much configuration , it definitely will not be replaced by the Spring.

Resources