I'm just curious about the level of support Spring Boot has for multimodule maven projects. There's so much work that has to be done when creating a good layered set of projects (especially getting the various JPA/JDO enhancers set up). All of the samples I've seen put everything into one project, which is fine for simple demos.
Can Spring Boot create a nice multimodule Maven project, complete with parent pom where all dependency versions are managed, plugins are configured, and other relevant best practices, and then set up child projects for the following modules (from the bottom of the dependency chain up):
commons (common stuff everything depends on, utils, etc)
domain (persistent domain objects -- JPA, JDO, etc)
service (service layer)
web (web & rest layer)
This would be really helpful. It takes HOURS to set this up initially, and lots of time to maintain it properly.
Spring-Boot (or spring in general) has nothing to do with the structure of the project in terms of maven modules.
Maven operates at build time, to compile and package the necessary artifacts (jars, wars...). Maven is the one that depends on the project structure.
Spring operates at runtime, once the applications is already built. The way it was built does not matter. What matters to Spring is the content of the resulting application classpath, which can absolutely be composed of multiple artifacts in the case of a multi-module project.
So yes, spring can work in a multi-module project, because it does not care about the structure of the project. It only needs the classpath to contain all required resources once the application is running.
Yes..You can use Spring-Boot for multi module maven project.Just you need to include proper dependency wherever you need.
Related
Is it possible to have a multi module Maven project using JHipster?
At first sight seems not but I want to know if there's a way to share common classes like domain classes or repository classes among different web modules in my Project using Maven.
Suppose to have a Web module with an HTML GUI made with Thymeleaf (no React / Angular), a classic Backoffice.
Then I want to have another web module that expose some REST API that needs for the same domain classes and the existing repository layer.
At first It seems that I've have to duplicate these classes and code into another JHipster application but obviously It's not the best solution.
Without JHipster I create a multi module Maven project with 2 web modules (Backoffice + API) and a third module with these common classes packaged in a shared JAR included as dependency in the first two modules.
How (if It is possibile) can achive this with JHipster?
Thanks
JHipster won't be able to generate what you want, it's up to you manually refactor the generated project to suit your needs and it's not difficult because JHipster puts entity classes in domain package and repositories in repository package. You will then have to decide how you want to execute the Liquibase migrations.
You can generate only backend code using --skip-client option, see command line options in doc.
An alternative (if you are motivated) would be to write a JHipster blueprint to generate a project with the structure you want.
I have set up my project in multiple modules based on the Spring framework. Currently there is only one runnable application combining all those modules.
Some of the modules provide functionality that might be reusable by other projects (or at least I could imagine reusing them in an other project). Some (but not all) modules also provide s spring Configuration. However when trying to create an application based on that configuration alone, requires defining many beans on top. This suggests that the configuration at that level does not make much sense, as there are dependencies on the level of Maven, which are not reflected in the Spring configuration.
As I am moving toward Spring Boot does this set up make sense or should the beans be defined at the level, where the configuration dependencies and Maven dependencies do match?
I have 2 projects, which are developed using PlayFramework 2.4. Although they are completely separate in concept, they share some common features, like evolution management (Liquibase), CRUD administrative mechanism, notification (email, sms) mechanism, etc. So, it was decided to split every project in 2 modules: common "core" module, which holds all described logic, and "project" module, which hold project-specific services, templates, views.
Recomended approach for achieving this in Play Framework is "subproject" concept. But it's clearly not an option, due to at least two reasons:
Projects are developed by different teams, that's why they they can't be located in one directory structure
These 3 modules ("core" and 2 "project" modules) MUST be versioned in separate VCS repos (Mercurial)
My current solution is to create core module, and provide it as a dependency in "project" Play application. An though this approach partially works, there are major downsides:
If you add routes file in module, they will override project routes file
You cant place views in core module, because due to fig.1 you cant access public assets
Due to downside n.1 and 2, you cant place Controllers in core module, because you cant specify a view to render
static assets (public directory) is not included in module distribution
I'm forced to copy common templates into both projects, I practically can't write common controllers which is annoying SO much
Appreciate any help. Maybe this can be achieved in some sort of highly-custom build and publish process for the core module?
I think you should not add the role core project as a dependency for the other 2 projects.
You could break the core project into core classes and core resources.
The templates and views in play framework are compiled classes, so you can pack then in a jar perfectly. The templates you create would be packaged alongside the core classes (or you can break them too). You can publish this jars into a dependency application like artifactory or nexus and import in the other projects. For the resources, you can package them like webjars do. So you can access them from any other view of your other projects.
All -
we have several web applications, all based on some version of Spring developed over time by different team across organizations. They each produce their own WAR, have a different context to work within, and often gets deployed on the same machine, as their functionalities are closely knit together. So we end up with:
tomcat/webapps/{A, B, C ... }
upon deployment, each use a very similar set of tool chains, replicate all Spring jars and dependencies all around.
I am wondering if there is a way to make the project structure better, deploy as a SINGLE war, while allowing each webapp live in their own source repo and have its own pace of development??
Any pointer or references are much appreciated.
Oliver
Deploying in a single WAR will couple all the projects together. Modifying one will mean redeploying all, with the accompanying QA effort to validate and do regression. I wouldn't recommend that.
Multiple copies of Spring JARs can be addressed by putting them in the Tomcat /lib; they're loaded by the Tomcat class loader instead of the WAR class loader. That will mean that every app has to be on the same version of Spring; upgrading one means upgrading all. You'll have to regression test all at once.
What harm is separate WAR files doing you? What do you care if the Tomcat /webapps directory has lots of deployments? One advantage is that they CAN be on separate release schedules. That's a big one to give away. Be sure you have a good reason before doing it.
you would have to probably move to an app server like jboss, but couldn't you use an ear file and have maven build the modules for you? That way you could probably put them in separate repos if you want each with it's own pom and then have another project with a pom for the ear file:
here is the maven ear plugin:
http://maven.apache.org/plugins/maven-ear-plugin/
here is an older blog post about multiple spring app ear file (single applicationContext fo all wars to share if you need):
http://blog.springsource.com/2007/06/11/using-a-shared-parent-application-context-in-a-multi-war-spring-application/
Based on one of your comments to another response, it sounds like you might be more interested in maven's multi-module project feature. This will allow you to define a parent POM with consistent dependencies and project layouts managed across multiple projects.
You might benefit from combining each project into a single WAR, but I do think this is really one of those 'the grass is always greener' problems. One key thing I would keep in mind is figuring out how much longer (or shorter!) is redeployment going to take if the projects were combined.
Think about OSGi. You can deploy all the dependencies just once, build your separate but interrelated modules as OSGi bundles, and deploy and upgrade them all independently. You can also choose whether to deploy them all as WARs (web bundles) or to deploy them as JARs with one or many WARs importing them to tie everything up. Virgo Web Server, formerly Spring DM Server, is really nice and comes ready to do this kind of stuff right out of the box.
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.