spring-boot-starter versus spring-boot-starter-xxx - spring-boot

I noticed that the Spring Boot Sample Data Redis declares the following dependencies:
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.data</groupId>
<artifactId>spring-data-redis</artifactId>
</dependency>
See here for full POM: https://github.com/spring-projects/spring-boot/blob/v1.0.0.RC4/spring-boot-samples/spring-boot-sample-data-redis/pom.xml
I see no mention of the <artifactId>spring-boot-starter-redis</artifactId>
My question is: when do I use spring-boot-starter versus spring-boot-starter-xxx where xxx is the name of the project (here Redis)?

The answer to the specific question: spring-boot-starter is a baseline for the others, and for standalone (non-web) apps that don't use any other Spring components - it has basic support for Spring, Logging, and Testing, but nothing else (no webapp features, no database etc.). Since all the other starters depend on it, once you use another one you can remove the vanilla starter. EDIT: see here https://github.com/spring-projects/spring-boot/commit/77fd127e09963a844f8fb4e574e1f0d9d3424d4e.
Up to you on the redis starter, but I would use the starter if it exists, since it will typically cut down on the number of dependencies you need to declare. The redis one actually doesn't add a lot of value (hence it didn't exist until recently), but it probably ought to be used in the sample.

Related

Spring: spring-data-mongodb or spring-boot-starter-data-mongodb

Which's the difference between
<dependency>
<groupId>org.springframework.data</groupId>
<artifactId>spring-data-mongodb</artifactId>
</dependency>
and,
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-mongodb</artifactId>
</dependency>
I'm developing an spring boot service.
spring-boot-starter-data-mongodb contains configuration classes for Spring Boot. It also includes the spring-data-mongodb library so you would only need to include the start in your boot app:
https://search.maven.org/artifact/org.springframework.boot/spring-boot-starter-data-mongodb/2.0.5.RELEASE/jar
spring-boot-starter-data-mongodb is a spring boot starter pom. For more information on starters:
spring-boot-starters
Dependency management is a critical aspects of any complex project. And doing this manually is less than ideal; the more time you spent on it the less time you have on the other important aspects of the project.
Spring Boot starters were built to address exactly this problem. Starter POMs are a set of convenient dependency descriptors that you can include in your application. You get a one-stop-shop for all the Spring and related technology that you need, without having to hunt through sample code and copy paste loads of dependency descriptors.

Maven - Force to use dependency

I made custom dependency which uses spring 4.x version and I include it in a project which uses spring 3.x version. When a method from this dependency is called it uses classes from spring 3.x version not from 4.x. Is it possible to force this dependency to use spring 4.x whereas the project itself will use spring 3.x ?
I don't think that is possible due to the fact that, when finally project is running, the dependencies are resolved on the basis of group id and artifact id and not on their version. Which is why your application is using 3.x dependency as it is overriding the one mentioned in the parent project. Hope this helps.
Yes, you can if you separate your application (which you probably don't want to). Another approach: You might think about using another class loader within the same JVM. This, however, leads to a probably bigger bunch of problems, especially using Spring.
Dzone article about loading the same class from libs with different versions.
As pvpkiran noted, you want to exclude the spring v3 transitive dependency from your custom artifact. From the maven documentation - Optional Dependencies and Dependency Exclusions:
<project>
...
<dependencies>
<dependency>
<groupId>sample.ProjectA</groupId>
<artifactId>Project-A</artifactId>
<version>1.0</version>
<scope>compile</scope>
<exclusions>
<exclusion> <!-- declare the exclusion here -->
<groupId>sample.ProjectB</groupId>
<artifactId>Project-B</artifactId>
</exclusion>
</exclusions>
</dependency>
</dependencies>
</project>

Using spring-boot-starter dependency on a non boot project, Is a good practice?

lets say that I need to develop a not boot app to develop an application that uses redis cache to store and retrive data.
I can use the spring-boot-starter dependency instead adding multiple dependencies, and it is working fine.
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-redis</artifactId>
<version>1.5.1.RELEASE</version>
</dependency>
Now my question..
Is it a good practice to add spring-boot-starter dependency on a non boot project?
Sure you can, just keep in mind that it will bring some transitive dependencies into your project, like org.springframework.spring-{context,beans,core,tx,...}.

What exactly represent these dependency used to database access of a Spring project?

I am pretty new in JPA\Hibernate and I have the following doubt.
Into the pom.xml file of a Spring MVC projet I found the following dependency that are added to my project (that use JPA to implement my repository).
<dependencies>
<dependency>
<groupId>org.hibernate.javax.persistence</groupId>
<artifactId>hibernate-jpa-2.1-api</artifactId>
<version>1.0.0.Final</version>
</dependency>
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-core</artifactId>
<version>4.3.11.Final</version>
</dependency>
<dependency>
<groupId>org.springframework.data</groupId>
<artifactId>spring-data-jpa</artifactId>
<version>1.8.2.RELEASE</version>
</dependency>
</dependencies>
So I am trying to understand the architecture of this projet and what exactly does these dependendency.
So from what I know JPA is only a specification and I can't use it without an implementation. So is JPA something like a set of interface that specify what operation I can perform and then I need something that implement that operation?
1) So, from what I have understand, the first artifact (the hibernate-jpa-2.1-api) should be the JPA specification.
Here the structure documentation: https://docs.jboss.org/hibernate/jpa/2.1/api/ and infact looking into the listed package it seems to me that are almost interfaces but not implementation classes.
If this assertion is correct my doubt is: why if it is the JPA specification it is provided under hibernate that should be an implementation o this specification? (Exist different version of the JPA spcificication or is it unique?)
2) The hibernate-core artifact should be the JPA implementation (from what I know exist various implementation and Hibernate is one of these, another one is EclipseLink and so on). So this artifact provide me the tool that allows me to interact concretely with the database)
3) The spring-data-jpa is a part of the Spring Data that make easier create JPA repository (for example allow me to use the "Specification" concept to create query)
Is it my reasoning correct or am I missing something?
JPA is just annotations (kind of interfaces) you can use to mark your class Entities and relations. Later you can use Hibernate (or EclipseLink) as implementation of the JPA.
Thus you can change implementation leaving annotations (interfaces).
Check also this

Spring framework compatibility between various projects

I am learning Spring framework and while trying "various" sub-projects within this, I got this doubt.
Spring framework has "core spring" at the heart of it. Now, as the project grows, e.g. trying other features like: spring-mvc, spring-web flow , spring security etc. Are all those sub-projects part of same release. For example, if I look for spring 4.0.2 release, would all these sub-projects be included in this? (hence release for various sub-project with same number: 4.0.2).
If this is not correct, then how do we ensure to chose the compatible sub-projects?
Thanks
spring-mvc is part of the spring framework, the others are separate projects following their own versioning. In general there is a minimum version for the projects and most work fine with newer versions.
If you want to be sure use the Spring IO Platform to manage your dependencies.
In your pom add
<dependencyManagement>
<dependencies>
<dependency>
<groupId>io.spring.platform</groupId>
<artifactId>platform-bom</artifactId>
<version>1.1.0.RELEASE</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
Then you can simply add the dependencies (without version) to your dependencies section
<dependencies>
<dependency>
<groupId>org.springframework.security</groupId>
<artifactId>spring-security-web</artifactId>
</dependency>
</dependencies>
For a list of managed dependencies (and version) check Appendix A of the reference guide.
Spring framework has "core spring" at the heart of it. Now, as the
project grows, e.g. trying other features like: spring-mvc, spring-web
flow , spring security etc. Are all those sub-projects part of same
release
spring-mvc and spring-web are both individual artifacts that you'll find within a single Spring release. They are versioned together, and you should always use the same version for all of them in any given project.
spring-security, however, is a completely different beast. It sits on top of Spring, but it's versioned completely separately. You need to make sure that the version of Spring Security you use is combined with a compatible version of Spring.

Resources