On looking at the spring-boot-starter-web, spring-boot-starter-security projects on github, i find them to be empty with just a build.gradle file present there.
I hope this is as expected, but this leads me to understand where the actual source code can be found. And I use maven, so I was expecting atleast a pom.xml in these projects. But since it is not present, I am wondering how spring boot team publishes there artifacts to maven central repo.
I hope this is as expected
This is as expected. Spring Boot's starter modules exist purely to being multiple dependencies together into a convenient "package". For example, if you want to write a Servlet-based web application using Spring MVC and Tomcat, a single dependency on spring-boot-starter-web provides all of the dependencies that you need. You can learn a bit more about the starters in the reference documentation.
Where the actual source code can be found
The majority of the code can be found in spring-boot-autoconfigure. For more production-focused features, you'll also find some code in spring-boot-actuator-autoconfigure. The code in these two modules is activated automatically when the dependencies that it requires are on the classpath. You can learn more about this conditional activation and auto-configuration in the reference documentation.
And I use maven, so I was expecting atleast a pom.xml in these projects. But since it is not present, I am wondering how spring boot team publishes there artifacts to maven central repo.
Spring Boot is built with Gradle which, unlike Maven, completely separates the configuration needed by the build system to build the project and the information needed by a build system to consume the project. The build.gradle files provide all of the information that Gradle needs to build the project. As part of this, it generates Gradle module metadata files and Maven pom.xml files that contain all of the information needed to consume the project with Gradle and Maven respectively. These generated files are then published to Maven Central alongside the jar files, source code, etc.
Related
I am building a SpringBoot application in which i want to handle some of the cross cutting concerns like logging, caching, persistence in to a project on its own so in future other rest spring boot components can adopt it and use it as a dependency.
I am using Gradle for dependency management. My question is :-
How can i manage this concerns without publishing it to the public artifactory.
If i have to publish then which is the free artifactory i can use for my development practice
If creating jar is an option as a temp solution then how can it be achieved via gradle. Most of the examples over the internet is for creating the executable jar files.
What are the other options i can try.
How can i manage this concerns without publishing it to the public artifactory.
Publishing has to happen regardless where it will be published to. You can use a private solution such as Nexus Repository.
If i have to publish then which is the free artifactory i can use for my development practice
For development, you can simply publish to your local Maven repository. This is typically ~/.m2. Using the Maven Publish plugin, you can easily publish locally by invoking the publishToMavenLocal task.
If creating jar is an option as a temp solution then how can it be achieved via gradle. Most of the examples over the internet is for creating the executable jar files.
Since you're creating a Spring Boot library, use the Java Library plugin to create the JAR artifact and in combination with the Maven Publish plugin to publish.
In the end, there are 2-3 key components that get published when using Gradle:
JAR artifact
pom.xml: https://maven.apache.org/pom.html
Gradle Module Metadata: https://docs.gradle.org/current/userguide/publishing_gradle_module_metadata.html
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
We are trying to migrate our existing Spring MVC applications to Spring Boot application. Our existing applications are using 3.2.9, so tons of XML configurations. All the beans are defined in the XML files. What we have done is first we have upgraded our existing applications to Spring 4.2.5 version since Spring Boot will work only with Spring 4 versions.
Our requirement is to have both FAT JARs and WAR files from the build. Most of our existing customers would prefer Application Server deployment, so we have to create WAR file for them. Also for our internal testing and new deployments, we are planning to use FAT JARs.
How can we achieve them in the Maven file, we are able to provide separately as below. Is there any maven plug-in to generate both in single build?
<packaging>jar</packaging>
or
<packaging>war</packaging>
We are publishing our artifacts into Nexus repository. So, we want to have the separate repository location for JAR files and WAR files. Can we do that using the single pom.xml file?
Also another question, we have all the XML configurations under WEB-INF folder. When we are moving to the Spring Boot application, it has to be under the resources folder. How can we handle them easily. When we build FAT jars, the resources are not looked under WEB-INF because it simply ignores the webapp project.
I am looking forward for some guidance to complete the migration. Infact, we have already done that changes and it is working fine, but we are confused on this WAR / JAR generations.
Update:
I have got another question in mind, if we are converting our existing applications to spring boot, do we still have to maintain WEB-INF folder in the web-app or can move everything to the resources folder?. While building the WAR file, whether spring boot takes care of moving the resources to WEB-INF? How spring boot would manage to create the WAR file if you are putting all the resources under the resources folder.
Building WAR and FAT JAR is very easy with Gradle.
With Maven, I would try multi module setup, where one sub-module will build fat JAR and second will build WAR file.
Application logic can be as third sub-module and thus being standalone JAR with Spring configuration and beans. This application logic JAR would be as dependency for fat JAR and WAR module.
WAR specific configuration can be placed in Maven WAR sub-module.
I didn't have such requirement before, so don't know what challenges may occur. For sure I wouldn't try to integrate maven-assembly-plugin or other packaging plugins with spring-boot-maven-plugin.
Concerning location of config files, just place them into src/main/resources or it's sub-folders according Spring Boot conventions. Spring Boot is opinionated framework and will be most friendly to you if you don't try to resist defaults.
Maven does not handle this gracefully, but its far from difficult to solve. You can do this with 3 pom files. One parent pom that contains the majority of the configuration, and one each for the packaging portion of the work. This would neatly separate the concerns of the two different assembly patterns too.
To clarify -- I'm not recommending a multi-module configuration here, just multiple poms with names like war-pom.xml and fat-jar-pom.xml, along with parent-pom.xml.
Is Spring tightly coupled with Maven ? Most of the examples in the internet shows Spring and Maven to configure spring dependent jars, this post explains so many cons of Maven. All commercial projects are should to be using only this combination ?
Please explain
Thanks
Both of them serve different purposes, Spring examples use Maven because maven is highly adopted as a build, dependency management framework. That has nothing to do with Spring coupling with Maven. Spring is a framework to build enterprise applications and Maven is a build and deploy tool.
You can use Gradle, ivy or even manually download the libraries instead of relying on Maven as the dependency management framework.
No. You can use whatever you want to build your Spring-based app. BTW, all the Spring tutorials show examples using Gradle (that Spring also uses internally).
What is true, though, is that Spring jars are available from the Maven central repository and the Spring repository, and that their dependencies is thus described in a Maven pom.xml file. But nothing prevents you from downloading the required jars manually and add them in the classpath.
I have several set's of Spring configurations (XML files for bean initialization and properties files), for different kind of services/servers. I've also use maven to manage the dependencies and build (alternating with eclipse).
My intent was to have a flag I could pass to maven to build the project with a selected configuration profile.
Example:
mvn package production
will put the conf/production files in WEB-INF/classes
I've solved the problem by using the approach of Spring profiles as suggested by #gerardribas.
I've looked at the Jhipster implementation and follow that way. If somebody is following the same path, be aware that your need to upgrade your servlet version to 3.x.