I currently created a project Main Project with certain files that reside in my Common Project. The common projects uses Autowired in Junit which results in requiring an ApplicationContext.
I wanted to ask if is it the wrong to have #SpringBootApplication in my Common Project if this project is not meant to be ran and just suppose to function like a Common Library.
Related
We have a EAR project which has a WAR project. Maven is used, so pom.xml. As typical of any project, this project also contains a big feature (say Job Scheduling "JBS") among many other features. As it is planned to retire this whole project in the near future, it is discouraged heavily to spend much on working on this project (whether bugs or enhancements).
Therefore, for the sake of running the (JBS) feature as a separate application, the whole EAR project was duplicated (also to save time/cost). As a result, all the Java packages and classes (necessary for JBS project) were duplicated. In this situation, if we update one or more classes in the main project, this (JBS) feature project/application gets outdated (and needs update).
The fact is that this JBS feature project ONLY requires many packages of Java classes (from the main EAR-WAR project), and do not require 99% of the web modules and others. I am removing all the unnecessary things from JBS project. Then I would like to create a JAR library with all the java classes, so JBS project can have a dependency on this JAR.
I do not know if it is a good idea to separate these classes out of the main project (to create another Java project). I would like to continue to have these classes as part of the main project. Then, it will be good, as and when one or more of these classes are changed, a new version of the JAR will be generated (right away). And the JBS project would then make use of this updated JAR.
How can we accomplish this? I understand, through maven, we can do a build/package jar/war/ear on a project of that nature. I am not an expert with maven (and did not learn it systematically).
But, is there a way to create one or more JARs additionally from inside WAR pom.xml? In other words: I mean pom.xml of WAR will create a WAR. In addition to creating a WAR, can maven help create additional JAR? Or can maven create two packages out of one pom.xml?
Or should I create a separate module in the main project with all these packages/classes, and have its own pom.xml to generate the necessary JAR? For this, most probably I need to modify the structure of the main project. I would like to avoid this unless there is no way out.
Can you advice?
It seems like the best thing for you would be to create a multi-module project that both contains the JAR and the other project. This way, you can easily change/build them together, but you create separate artifacts.
Background
I wrote a spring boot project using gradle and it works fine.
I would like to split up the project into libraries (jars) so that I can reuse them.
These are the requirements
Each of the projects are in sibling folders, each containing its own .git repo.
The multi-build project should be in sibling folder, not in the folder that contains the child projects. It also contains its own .git repo.
Projects that are used as libraries only (jar) have tests annotated with #SpringBootTest and these should be runnable independently.
Projects that are used as class libraries should be provided to other projects as "thin jars" without any dependencies included. The using project needs to add whatever dependencies are accumulated by all the projects it uses.
It should be possible to build each child project independently. For projects that depend on other projects in the suite, this means that building the project will use the output of the other projects (jar) that it needs, and if that output is not ready, gradle will first build those projects.
It should be possible to build all projects from the mult-project parent (Dependencies will be worked out and only necessary builds will occur).
Building the entire suite with the multi-project will create a deployable folder containing the parent boot jar and all its dependencies.
I would like to be able to author the projects, edit and debug all of the above with Intellij.
Minimal, Reproducible Example
I have uploaded a minimal, reproducible example (reprex) here: https://github.com/david-sackstein/multiproject
It contains three folders:
productcommon is a jar with a public class ProductFactory.
productservice is a SpringBoot application with a single #RestController that invokes a public method of ProductFactory in one of its methods. productservice has a project dependcy on productcommon.
multiproject is a gradle project with no code that depends on productcommon and productservice
I setup the build.gradle and settings.gradle in all three projects accordingly.
When I build productservice it fails - evidently because the project import of productcommon fails.
What is missing or incorrect in this example?
Today I came across this excellent post on the subject:
https://reflectoring.io/spring-boot-gradle-multi-module by Tom Hombergs
Tom also provides a great example at:
https://github.com/thombergs/buckpal
I may have some follow on questions on the subject after working with his architecture but for the moment, I am happy with this solution.
I need to create a Spring MVC web application where each of the services should be created as a separate JAR file. Some of the docs suggest that multiple Maven modules can be used for this. But what I understood is, that each module also needs to be created as a separate Eclipse project.
Can I have all the controllers, service and DAOs in the same Eclipse project, while still creating separate jars for each service (and a war file for the whole application) with Maven?
Short answer:
Yes, you could create multiple build targets (jar files) out of single project by using maven-jar-plugin (profiles, executions).
https://maven.apache.org/plugins/maven-jar-plugin/
Should you do it?
I believe most people will agree with me that you should not do it, you should stick to one of the most important core concepts of Maven: modularity.
Now, Have you asked yourself the question, Do I really need to create multiple modules (jar Files) for my application? Can I manage all pieces of code in one single project?
Maybe you just need some guidance about how to organize your java packages in one single project.
https://dzone.com/articles/layered-architecture-is-good - Using layered architecture
http://www.javapractices.com/topic/TopicAction.do?Id=205 - Packages by feature vs Layers
NOTE: If you think that your project will grow fast and the number of classes will be a large number, it is probably a good candidate to be a multi module application.
If you still have the feeling that you have to create multiple modules, there are several interesting posts about how to address modularity in the design of applications, in these posts they provide very interesting reasons/criteria why you should split your application into modules.
How to decompose a system into modules?
Spring Java Maven Project + Module Design
Good Luck!
What is the problem of separate modules and hence separate Eclipse projects? If you declare a Maven dependency between the modules, you'll be able to have compile dependencies between the classes in the corresponding Eclipse projects.
So I suppose that it is possible to force multiple Maven modules into one Eclipse project, but I don't know any good reason to do so.
I want that a maven project can be used as a black box jar. This is needed because second project was born its way, and I don't want to integrate its code by hand. So the best way is that this project is going to save it's data on db, but it should use a service offered by the "wrapper" project to save them.
The idea is simple, the secondary project can expose just a method to which I will pass the service that offers the save method as a parameter.
The secondary project should not have configuration files, but should rely on the father application's properties.
Any idea to do this fast and almsot good? Thanks for any suggestion.
EDIT 2013/03/07: The idea behind this is that the second project should generate a classic jar library that looks a properties file into the classpath of the host project. Something like Quartz/Spring/... you import jar and you provide the properties file.
I just defined some classes to load properties from the classpath, and some interfaces to make the two projects interact.
In pom.xml of the parent project I imported the child project excluding it's dependencies to avoid conflicts.
It was a pretty easy task at the end.
I'm trying to build a project structure like this:
Project
|--Web_module.war
|--Data_module.jar(Spring)
|--Util_module.jar
|--other public api...
which means, different modules should be packed into different jars, so i have to have more spring configurations(application-context.xml) for different modules (e.g. for data module and for web module).
My question, how could I organize all the configuration files to include them correctly in the web module.
Thanks in advance.
Plan to have a single eclipse project for each jar file that you anticipate.
Choose the jars files / eclipse projects as per your project functionality to be modular and self contained, as far as possible.
Use junit tests in each eclipse project to thoroughly test individual projects/modules, using spring unit test support
Each eclipse project will contain its own spring config context file eg Util_module project might contain a util-context.xml
Finally have an eclipse dynamic web project as a wrapper web application which will aggregate all your "module" projects
UI artifacts like HTML, JS, JSPs, etc plus java code which uses web application contexts like controllers, servlet filters etc should be included in the eclipse web project
In the eclipse web project's java build path, but the module "projects" as "required" projects
In the eclipse web project's deployment assembly, add module "projects" as dependencies.
now when you build-all and deploy the web app, all depending module projects will compile and deploy as well, but more importantly, all project functionality will be divided into seperate modular projects
setup dependencies between projects with care, so as not to introduce cyclic dependencies
dont be afraid to refactor project structure when needed to maintain clean and relevant modules
For your modules to publish their own configuration (and your main application to detect them automatically), you can, in your main applicationContext.xml, import other context.xml files from the classpath using a pattern with wildcards :
<import resource="classpath*:conf/moduleContext.xml" />
This tells spring to find and read files in all jars that match conf/moduleContext.xml.
Note there is a little limitation to this : you must have your context files in at least one directory (not in the root of the classpath). This is why in my example you have de "conf" directory.