I am a Spring Boot newbie. I'd like to initialise a project which consists of:
A console application that acts on command line arguments so the JAR files could be later used in scheduled tasks.
Consumes a RESTful service
Logging
Which package dependencies should I choose in Spring Initializer? Apart from the necessary packages, are there any libraries that are optional but make development easier?
Depends on how you want to consume the restful service, but you may not need any extra starters, the core spring-boot-starter that you get when you just hit "Generate Project" and is usually implied with all the common starters like -web, -security, .. has logging and dependency injection and is all you need to create a jar that can easily be started with java -jar
However, it does not come with RestTemplate which is a common way to build rest clients in spring. For that you'll need to manually add a dependency on org.springframework:spring-web like you can see examples for in https://spring.io/guides/gs/consuming-rest/
But you can as well use other rest client libraries if you like them better.
There is also Feign that can be used as rest client and it's available from the initializer, examples at https://cloud.spring.io/spring-cloud-netflix/multi/multi_spring-cloud-feign.html - have not tried it and I'm not sure how much extra cloud dependencies will be added when you add the starter.
I also like having Lombok in all projects but that's preference. The obvious sounding choice of DevTools doesn't give you much benefit in a console application but is great for live reloading of web servers.
[...] so the JAR files could be later used in scheduled tasks.
sounds like you're trying to create a library / module of a larger application. You don't need an application that works standalone for that though so maybe https://spring.io/guides/gs/multi-module/ is good to read for you. Difference for libraries is that you don't need the spring boot plugin for maven/gradle which can package a standalone jar, just the dependency management.
Related
I am new to Spring and I have tried Googling this, but I am not finding any practical guidance.
I have a Maven Spring utility application that has its own Spring configuration.xml.
I would like other consuming applications (also Maven and Spring most likely) to call this utility by including it in their classpath, and with a minimimum of adjustment, just have the utility application work.
In summary, I would like to have a jar containing my utility code and Spring xml files, then place that jar in the classpath of a consumer application with a minimum of adjustment to the consumer's spring config or command line, and have the utility just work in the consumer application context.
What is the best way to accomplish this?
The scenario you're describing is what Maven was made for. You can simply make the utility module a stand-alone Maven module (with its own pom.xml) that will produce a jar artifact (which is the default type). This jar should and will contain all the Spring configs as well. Later on, when ever you need it, you just declare a dependency to the utility artifact and Maven will make sure it ends up on the classpath so you can use its features.
Our team is writing a server-client application where the frontend is an Angular.js single page application which uses a Spring MVC java backend. The backend serves the application files and the REST endpoints used by the browser end. We are using Maven as the main build system for the application.
We like to take advantage of require.js and r.js to minify the app at the end, and we are also using client side dependency management. Currently we are using bower to download Javascript libraries required but it doesn't feel right to me to download client dependencies to src/main/webapp since this is a source folder. However in order to avoid rebuilding the whole frontend module each time something changes in the client files, this seems the only sensible way to us. This way we can start a web server and it will automatically pick up changes without restart, but as i said this doesn't fit Maven's folder layout.
I'm experimenting with Webjars which seems a better choice in our Maven oriented build and dependency management. Because in Servlet 3.0 containers webjar resources are provided automatically on the server container path it's very easy to use and manage them. It's also possible to create a require.js config to refer to libraries contained in webjars since they are on the webserver path the same way if they were static files, the serving is being done transparently in the client applications point of view.
My only problem is that i don't know how could we achieve r.js minification with this layout, since the source files are in jar files r.js cannot access them. Also the require.js config refers to the runtime server paths which are simply not there in build time.
I see that webjars now have some integration with Require.js + Play Framework but we are not using Play just simple Spring MVC in our case. I really hope there is a way to handle this case because i like the Webjar way of client dependency handling.
You need an asset compiler / pipeline in your build process. There are probably many options but the one I know of is wro4j: http://alexo.github.io/wro4j/
I am trying to create a java email batch program that sends an email with an attachment each day to a specific email address, and I have to use Spring as the framework for this program. It is not going to be a web application, but since I'm implementing Spring into this, how would I go about this? I am totally new to Spring (and Java for that matter), but am unsure of which direction I need to go. Which jar files do I need? Spring Batch or Spring Framework? Also, where can I download the jar files for Spring Framework? The spring.io site won't let me download those jar files.
I very strongly suggest you use a build tool that handles dependency management. Such tools are Ant+Ivy, Maven and Gradle. They will take care of downloading the appropriate jars based on your declaration of what dependencies you need and will take care of all the transitive dependencies.
One good way of getting started with Spring Batch is to follow this tutorial using either Maven or Gradle (the latter would probably be easier since you don't need to install it - the tutorial's code has a wrapper).
The tutorial uses Spring Boot which vastly simplifies Spring configuration (which is a serious benefit especially for someone who is new to Spring)
As others already told you, I personally would not start any spring based project (means: any project) without maven! You have so much benefits from it, not only depencency management.
To start a spring app outside an application context:
#Configuration
public class AppConfig {
//any bean configurations here
}
//your entry class
static void main(String args[]) {
//get a reference to the spring context. use this context throughout your app!
ApplicationContext ctx = new AnnotationConfigApplicationContext(CacheConfig.class).get();
//optain any beans from the context. inside these beans, you can use any spring feature you like, eg #Autowired
ctx.getBean(YourBean.class).executeMethod();
}
I'd recommend starting with Spring Boot which will handle all of that for you. As others have mentioned, pick a build tool (Maven or Gradle) and follow the guide we provide on building a batch application here: http://spring.io/guides/gs/batch-processing/.
I'm writing a Java API for several clients, and would internally like to use Spring and it's several features, but I don't want to expose to the client my dependencies.
Is this possible?
So if my client uses a different version of spring would they be insulated from my internal Spring dependencies.
If so, would my spring dependencies be bundled internally inside my jar? As well as would a custom class loader be required by my client application?
I have heard you can use this through OSGI bundles, but I'm wondering if this would satisfy my requirement.
The clients of my API wouldn't be OSGI enabled or we have no current environment that utilizes OSGI bundles.
It is not really feasible, or desirable to do so. Why would you want to "hide" the dependencies? Would you also want to hide a dependency on whatever logging package you may be using (for example)?
If you have the dependencies in your implementation, then they are best published as it will cause a lot less grief on the part of users of your API since they will know what conflicts may exist before they even attempt to use your code.
Don't forget, your users are actually developers and I am sure that they would rather be aware of any landmines or requirements up front.
Edit - Regarding OSGi:
OSGi will definitely take care of your conflicting dependencies issues, but it also would rely on deploying in an OSGi environment, which you haven't mentioned is the case for your clients. In addition, it is still not recommended to "hide" those dependencies in a bundle. The very nature of OSGi allows those conficting depencies to cooexist in the same application.
we are trying to develop a web application framework and build implementatins on top of it. This framwork will be versioned in SVN, live its own life in parallel to those implementations. It will have lots of spring config files, security config and so on. We would like to use those in those implementations.
What structure should such an project have? Keep everything together? Link particular folers (implementations) in "svn: externals"? We would like to use Maven, and create an archetype for those implementations, but is it possible to update the archetype after it has been changed in implementation applications?
Regards,
This is a good example :
http://www.sonatype.com/books/mvnex-book/reference/web.html
Also this book is very useful resource when starting with maven
I found this also :
http://www.avajava.com/tutorials/lessons/how-do-i-create-a-web-application-project-using-maven.html
I'd suggest you create your framework project as a simple jar project to include in your implementation, which would be war projects. For the Spring config files you have three options then:
Package them into your framework jar. This would make it hard for the implementations to customize it. I would not recommend it, unless your configuration is definitively fixed.
Use svn: externals. I have not much experience with that, but I think dependencies between svn repositories would be hard to manage.
Maintain these configuration files per implementation. So, an archetype would help to get started with an initial configuration. Then maintain these configuration files as your framework evolves. This is what we do most of the time. The good thing about Spring configuration is that it often rarely needs to be touched once you are confident with it.