I'm using swagger with Spring Boot and the UI does not shows the controllers.
My project looks like: I have a few gradle modules in root project.
There are two of them for REST:
documentation (in this module I have package *.documentation and there I have a few interfaces with swagger annotations)
rest (in this module I have package *.controller and there each controller implements documentation interface from module documentation)
When I'm trying to run swagger-ui there is no resources on the UI.
BUT! when I move my controllers into documentation module then everything works fine or when I move interfaces with swagger annotations to rest module. Problem is only when I use two modules, one for swagger annotations and one to implement those interfaces.
What should I do to make it works with two modules? I tried also ComponentScan annotation in my SwaggerConfig class(this class is also in documentation module) but it does not works too.
My project structure:
|-- Project
| |-- app
| |-- src/main/java
| |-- mypackage
| |-- App.java
| |-- documentation
| |-- src/main/java
| |-- mypackage
| |-- config
| |-- SwaggerConfig.java
| |-- documentation
| |-- ProductSwaggerInterface.java
| |-- rest
| |-- src/main/java
| |-- mypackage
| |-- controller
| |-- ProductController.java
In 'app' module I just run the SpringBoot app, in 'documentation' module I have interfaces with swagger annotations and in module 'rest' I implementing those interfaces in my controller.
Related
This is the structure of my project.
The parent contains no code.
module child1 is a spring boot application.
modules child2, child3 are jars libraries.
child1 depends on child2 and child3
parent
| build.gradle
| settings.gradle
| [no code]
child1
| build.gradle
| src/
| main/
| java/
| resources/
| application.properties
| test/
| java/
| resources/
| application.properties
child2
| build.gradle
| src/
| main/
| java/
| test/
| java/
child3
| build.gradle
| src/
| main/
| java/
| test/
| java/
I have a property called "datapath" that I would like to inject into classes in each of the modules.
There are two possible values for "datapath", one for tests and one for production.
I set the production value in
child1/src/main/resources/application.properties
and the test value in
child1/src/test/resources/application.properties
I have tried creating configuration classes and specifying PropertySource.
But the result has been that though child1 picks up the correct application properties in both test and main, spring does not find them in other modules.
Can you propose a strategy for me to implement this?
In particular:
The tests in the child1 are annotated SpringBootTest but preferably child2 and child3 should not depend on spring boot (just spring framework for autowiring)
I would like to be able to use the #Value annotation on configuration classes in the child modules.
How do I direct spring to resolve these properties from the application.properties in the child1 module, using the one in src/test/resources for tests and the one in src/main/resources for production?
As I have chosen a very "classical" structure, I would like to be able to achieve this with as few as possible moving parts. In particular I would prefer not to have to specify paths explicitly in annotations.
I assume that in child2 and child3 you need application.properties only for test. Then in test you can use #TestPropertySource where you can point relative path to properties file in child1 or add datapath explicitly:
#TestPropertySource(properties = { "datapath=value" })
public class Child2Test {
I have multiple independent projects ( Java - Maven ) in this SVN repo :
|-- exemple.com/svn/java/apps/
|
| |-- Application_1
| | |-- branches
| | |-- tag
| | |-- trunk
|
| |-- Application_2
| | |-- branches
| | |-- tag
| | |-- trunk
Can I create a generic Jenkins maven build job with this SVN repository URL exemple.com/svn/java/apps/ and put as parameter the project name and branche name ?
Something like this ${Project_Name} and ${Branch_name}
You can, but that would mix up the job histories, someone trying to check it would be confused by the alternating histories.
It's more work, but it would probably be better, in my opinion, if you use a Jenkins Pipeline or the Jenkins Job DSL (a job generator).
usually when I start a project the structure in the package explorer is something like this:
src/main/java
|- org.companyname.myproject
|- repositories
| |- ClassA.java
| |- ClassB.java
|- services
| |- userservice
| | |- ClassC.java
| |- otherservice
| | |- ClassD.java
so in the package explorer I can quickly expand and collapse all the relevant packages.
However recently when I import projects as a gradle project this structure is converted to:
src/main/java
|- org.companyname.myproject.repositories
| |- ClassA.java
| |- ClassB.java
|- org.companyname.myproject.services.userservice
| |- ClassC.java
|- org.companyname.myproject.services.otherservice
| |- ClassD.java
I know this is only esthetically but for me it's so obnoxious and unreadable. Any tips on how to restore the original structure view?
If I remember correctly I didn't have this issue earlier when I imported gradle projects.
Thank you very much.
Your view package presentation setting needs to change. Just change it from flat to the hierarchical section shown below.
I'm working on a spring application that contains submodules, roughly looking like the following:
project
|-- module1
||-- src
|| -- main
|| |-- java
|| -- resources
|| |-- null
|| -- pom.xml
Module 2:
|-- module2
| |-- src
| | -- main
| | |-- java
| | -- resources
| | -- spring-dao.xml
| -- pom.xml
-- pom.xml
now,I'm using Juit4 to test module1,while I have to offer spring-dao.xml in module1,like this:
#ContextConfiguration({"classpath*:spring/spring-dao.xml"})
But the spring configuration file(spring-dao.xml) is in module2, and module2 is dependent on module1. That causes I can't put module2.jar into module1 via the pom.xml of module1 as it causes a module cycle.
How can I test module1?
I'm not sure I understand completely, but here's how I read it:
Module 1 has a dependency on Module 2, and Module 2 has a dependency on Module 1.
The short answer is you cannot do this. The idea behind modules is to segregate unrelated code. I often do this with generated code, keeping that in a separate module. The generated code shouldn't have any dependencies on my main application, but my main application depends on the generated code.
I can think of a couple solutions:
If the two modules are that heavily dependent on each other, they should be refactored into a single module. This seems like the best approach, based on what you've described.
If this still isn't desireable, make a third module to hold common dependencies between the two projects.
I'm currently working on changing building process of legacy project. Right now it is built by a custom-made solution and our aim is to adjust it to a standard one - maven.
This is a standalone application and current output of a build is a directory with following structure:
OUR_APPLICATION
|
|_bin
| |_start.sh
| |_stop.sh
|
|_etc
| |_app.properties
|
|_jar
| |_app_classes1.jar
| |_app_classes2.jar
|
|_lib
|_third_party_library.jar
I am wondering what's the best way to achieve similar output with maven and still follow best practises (or at least break them as little as possible).
I'm leaning towards creation of multi-module project (separate modules for Java code, configuration files and shell scripts) and then using maven-assembly-plugin for combining it all together, but I'm not entirely sure how (if at all) it can be properly done.
Still I'm not sure whether its the best fit for me and I will be very grateful for any feedback.
You are on the right way (imo): Maven is a good tool for producing deployable artifacts. And the maven-assembly-plugin fits the needs that you described. It could produce a ZIP file containing the application structure you described.
The default artifact type that Maven produces is simply a JAR. This is ok for libraries. The application structure that you described seems to have three of them: app_classe1.jar, app_classes2.jar, and third_party_library.jar (I know, there could be more of them).
The Maven setup that I would suggest (and keep in mind: other ways exist): Create a multi-module project, which has modules for each application JAR and one module for assembling them. The parent project then simply builds them all. Like this:
ParentProject
|
|-- pom.xml (the parent one, that describes all modules)
|
|-- Module1 (producing app_classes1.jar)
| |
| |-- pom.xml
| |-- src/...
|
|-- Module2 (producing app_classes2.jar)
| |
| |-- pom.xml
| |-- src/...
|
|-- AssemblyModule (the one that produces a ZIP, for example)
|
|-- pom.xml (with type POM because it does not produce a JAR)
The assembly module should not have the default artifact type (JAR), but should be set to type POM. The pom.xml of that assembly module then configures the maven-assembly-plugin to create a ZIP file. The content of this ZIP file is highly configurable. Additionally, this plugin attaches the result artifact (the ZIP) to the build, so that it will be uploaded to a repository, if that is also configured.