I found two way of adding dependencies for spring boot rest service application.
Method 1 :
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter</artifactId>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-web</artifactId>
</dependency>
Method 2:
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
Both method given above does the same job? Any difference in performance?
Thanks in advance
The difference between these methods is that spring-boot-starter-web contains more dependencies than just spring-boot-starter and spring-web.
For the version 1.5.8.RELEASE it will be:
spring-boot-starter
spring-boot-starter-tomcat
hibernate-validator
jackson-databind
spring-web
spring-webmvc
All other stuff depends on your requirements. For instance, if you're developing commercial product you must check all included transitive dependencies for their licenses.
The general advice is to use only features you need. Don't forget that you still can depend on top level artifact excluding not required parts using Maven feature.
At for the performance boost, basically it should not be that much. The difference is only if the Spring (with top-level artifact dependency) will load and auto configure some features which are not practically used in your code (during the classpath scanning). The startup time could be slightly increased by the same reason.
Hope it helps!
Obviously second approach is better i.e. using springboot starter pom.
Reasons I say that for are as follows:-
It allows zero configuration or auto configuration i.e. most of the web related settings would be given to you by default. e.g. by default tomcat server would be integrated, springboot dependencies would be added for you, automatic registration of converter and other web related dependencies etc. See this link.
You could take advantage of easy override i.e. if tomorrow you want to use jetty in place of tomcat just add the jetty dependency and it's configurations and now you could use jetty.
Your pom.xml would be neater and more readable as less no. of dependencies are put inside it and picked from starter poms.
Easy compatibility management. By default spring-boot picks up the version of starter parent. Hence, you could rest assured that all compatible dependencies would be downloaded as part of mvn dependencies and if you specifically want to upgrade any of those you could. But this gives advantage of upgrading to compatible dependencies by just changing the version of springboot starter parent(Note: You could use dependency management as well in place of starter parent pom. See this link).
Performance wise there would be a trade-off as springboot by default downloads more dependencies than minimum required initially. But over the time as application starts becoming mature most of these dependencies are used anyways.
Related
We are building independent reusable spring data jpa modules without spring boot. Let's call them db modules. These modules will be imported in another spring boot app. In the db modules, we are including
<dependency>
<groupId>org.springframework.data</groupId>
<artifactId>spring-data-jpa</artifactId>
<scope>provided</scope>
</dependency>
However, in the main spring boot have we have included
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-jpa</artifactId>
</dependency>
All spring dependencies in db module are of scope provided and expected to be present during runtime provided by main spring boot app. Is this the right way to do it?
Also, should each db modules have it's own properties file for db connection or should they reply the main spring boot app. All db modules connect to the same database. These modules represent different domains in the application.
No, using <scope>provided</scope> is not correct.
As the Maven documentation says:
provided
This is much like compile, but indicates you expect the JDK or a container to provide the dependency at runtime. For example, when building a web application for the Java Enterprise Edition, you would set the dependency on the Servlet API and related Java EE APIs to scope provided because the web container provides those classes. A dependency with this scope is added to the classpath used for compilation and test, but not the runtime classpath. It is not transitive.
Said another way, it is "provided" by the runtime, outside of your deployment assembly.
If the dependency must be included when packaging your code for deployment, then you are certainly not expecting it to be provided for you.
Remember, your library need to tell the build system that depends on your library, what it needs to include other libraries as well as your library. That is the entire purpose of transitive dependencies, so by not making spring-data-jpa a transitive dependency, you're doing it wrong.
I have a scenario as follows:
I am using maven as a build process. I am creating a web project in which I want to use a specific version of spring. This project also depends on a third party library which internally depends on different version of spring. I have a doubt that this will result two different versions of spring n class-path and unexpected behavior will be observed. I have few information which I wanted to get more clarification on.
Can I use maven BOM concept for this?
Can somebody explain with example how to achieve this?
Can somebody explain how do we make sure that third party wont behave abnormally if overall project depicts using a specific version using BOM?
If somebody can throw light on it and give a detailing reference, that would help me a lot.
Maven should know how to evict one or more of conflicting versions of an artifact.
However, you can influence that by simply excluding one of the transitively included dependency.
Example: the following code excludes the io.netty (transitive) dependency. In this way, you'd leave maven with the only other version as you decide/prefer.
<dependency>
<groupId>org.apache.hbase</groupId>
<artifactId>hbase-client</artifactId>
<version>${hbase.version}</version>
<!-- The exclusion below makes sure that this specific version imported by hbase does not end up deployed -->
<exclusions>
<exclusion>
<artifactId>netty</artifactId>
<groupId>io.netty</groupId>
</exclusion>
</exclusions>
</dependency>
Regarding runtime behavior, you have to test and decide for yourself (that is if you aren't lucky to have your direct artifact that documents versions of its own dependency)
You can use the concept of BOM but this won't avoid the conflicting issue of libraries by itself. It's very common that projects have one or more library which depends on the same other with different versions. In this case, when you want to force some specific library version for that third party library you must explicit it in your POM by using < exclusion > markups. This is not an easy task, once that projects usually have many libraries. So you need a tool to provide you an easy way to visualize a dependency hierarchy of your project libraries. There are some IDE plugins for this. Some versions of Eclipse, for example, have the maven plugin included in it, which provide a Dependency Hierarchy view ( a kind of dashborad of libraries and their dependencies ). Once you detected a library which should not using other library dependency ( wrong version for example ), you go at the this dependency in the pom and use the exclusion markup adjust the dependency version. Using the tool will make this task very simple.
I haven't yet found an answer to this question which is bugging me for long. I am trying to integrate Hibernate (3.6.7) with Spring (1.2.8). In order to do so i have to get a bunch of jars just to get it running. Isn't there a more cleaner of way of getting this done. The jars i am using rather forced to use are as below:
spring-1.2.8.jar
commons-logging-1.0.4.jar
hibernate-3.6.7.jar
hibernate-jpa-2.0-api-1.0.0.Final.jar
dom4j-1.6.1.jar
slf4j-api-1.6.1.jar
javassist-3.12.0.GA.jar
Is there no leaner way? The big list of dependent jars could potentially cause conflict during deployment to my appserver in the future. So its making me rethink about spring-hibernate integration. Is there a way to reduce this dependency list. My issue is not related to management of jars as maven is already being used, it more to do with the usage.
This answer was posted before the OP mentioned that he was using Maven. The question seems to be asking how he can use code without including it in his project. Given that there is no answer to that question I'll answer assuming he wants a better way of managing the dependencies that he needs.
The leaner way to do this is to use a dependency management tool such as maven. This allows you to define your project's dependencies in an xml file.
The dependencies you specify will also have dependencies and so on. These are transient dependencies and are very hard to manage without an automated tool.
This is also the best way to ensure that you only have the jars you require.
The dependencies you require are:
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-orm</artifactId>
<version>3.1.1.RELEASE</version>
</dependency>
and:
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-core</artifactId>
<version>3.6.10.Final</version>
</dependency>
I created a Maven project in Eclipse using the webapp artifact and put the following lines in the .pom file upon reading an online tutorial.
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring</artifactId>
<version>3.0.5.RELEASE</version>
</dependency>
In the tutorial however, the version is 2.5.6. I replaced it with 3.0.5.RELEASE considering its the latest version.
But for this version eclipse is giving out an error
Missing artifact org.springframework:spring:jar:3.0.5.RELEASE:compile
What does this mean ? Can I add the required jar files to a lib folder and ask .pom file to take it from there as its being done in another tutorial on spring source website that uses Ant ?
Also Maven projects come with a different directory structure and seems to be doing much more than what Ant does in the spring source tutorial.
I am completely new to maven. in fact only a beginner in developing web applications using java. I did some tutorials from spring source and could deploy and run a spring mvc hello world app on apache tomcat. For this I used Ant and found it a great tool. But as I checked-out some example apps from spring source repo and it seems that Maven is more preferred and powerful than Ant. I am finding it a bit difficult to understand though.
Thanks
In version 3, Spring no longer provides the all-in-one Spring jar.
Note: The spring.jar artifact that
contained almost the entire framework
is no longer provided.
Source:
2.4 New module organization and build system
Depending on your project needs, use
<dependency>
<groupId>org.springframework</groupId>
<artifactId>${artifactId}</artifactId>
<version>3.0.5.RELEASE</version>
</dependency>
where ${artifactId} may be e.g.
spring-context (IOC core, standard ApplicationContext implementations)
spring-orm (ORM technologies: Hibernate, JPA, (I|My)Batis)
spring-webmvc (The Spring Web MVC framework)
spring-aop (Aspect-Oriented Programming support)
etc.
The selected dependencies will pull in their required libraries as transitive dependencies, so you usually just need the "most exotic technology". E.g. if you select Spring MVC and Spring ORM, you also get AOP, TX, Context, Web etc.
Reference:
Obtaining Spring 3 Artifacts with
Maven
In Spring 3.x they remove they removed this artifact. Now you have to declare dependencies on separate modules of Spring, such as
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>3.0.5.RELEASE</version>
</dependency>
and so on.
Also see spring 3.0.5 library jars for the list of modules and description of dependencies between them.
Is there a tutorial somewhere which shows how to use spring framework with maven instead of ant? This one seems very good but it's all built with ant.
EDIT
I really don't know which answer to accept both are valid. I'll wait for some time let the community decide
Basically, the build.xml of the tutorial has 3 main targets :
build the application
deploy it on Tomcat server
Unit testing using a in-memory database (hsqldb)
Regarding the first point, you will just need to create a war project on Maven. As you told in your comment, you are already using Maven in anothers projects, so I don't think it will cause you lots of troubles. You will just need to add the Spring dependency:
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring</artifactId>
<version>2.5.2</version>
</dependency>
The second part concerns the deployment on Tomcat. Just use the cargo plugin for that.
For the last point, you will just need to add the HSQLDB dependency in your pom.xml:
<dependency>
<groupId>hsqldb</groupId>
<artifactId>hsqldb</artifactId>
<version>1.8.0.7</version>
<scope>test</scope>
</dependency>
Then, you will have to instanciate the database in one of your JUnit test case...
If you already know maven, then you can quickly start working with spring using this archetype
appfuse-basic-spring
Note that it sets everything up for Spring MVC, Spring and Hibernate so you should remove unnecessary files. Still, it's a great start.
If you don't know much about maven templates check this URL that explains how to use archetypes. An archetype is basically a project template.
The complete list of templates can be found here.
The Spring 3.0 samples are Maven based:
https://src.springframework.org/svn/spring-samples/mvc-basic/trunk/
https://src.springframework.org/svn/spring-samples/petclinic/trunk/
https://src.springframework.org/svn/spring-samples/spring-travel/trunk/