Jhipster 7 - swaggerUI not available - jhipster

Using JHipster with version 7.1.0 I cannot get the swaggerUI to work.
Running the application with mvnw or from Intellij results with 404 page.
The route I try is http://localhost:8080/swagger-ui.html.
Api docs are available - both version 3 and 2, but the swagger page is not.
What is even more interesting is the fact that running the application with mvn clean spring-boot:run command - and the swagger page would work fine.

Things have changed from v6, you need an UI and login with admin user. Then, it's available under http://localhost:8080/admin/docs
Refer to this question here.

You can add dependency swagger-ui into your project.
<dependency>
<groupId>io.springfox</groupId>
<artifactId>springfox-boot-starter</artifactId>
<version>3.0.0</version>
</dependency>
<dependency>
<groupId>io.springfox</groupId>
<artifactId>springfox-bean-validators</artifactId>
<version>3.0.0</version>
</dependency>
<dependency>
<groupId>io.springfox</groupId>
<artifactId>springfox-swagger-ui</artifactId>
<version>3.0.0</version>
</dependency>
Then, update maven. The SwaggerUI will be available on :
http://localhost:8080/swagger-ui/index.html

Related

activating asciidoctor diagram extension plantuml in maven pom.xml

I use asciidoctor and maven with the asciidcotor-maven-plugin
I use asciidoctorJ and asciidoctorJ-diagramm
Now i have in my src-code of the document to render
plantuml::input.puml[]
with mvn -X compile I get now information in the console :-(
In the generated document I see the line of the src identically iaw not rendered at all.
What is the problem?
<plugin>
<groupId>org.asciidoctor</groupId>
<artifactId>asciidoctor-maven-plugin</artifactId>
<version>${version.admvpl}</version>
<dependencies>
<dependency>
<groupId>org.jruby</groupId>
<artifactId>jruby-complete</artifactId>
<version>${version.jrcm}</version>
</dependency>
<dependency>
<groupId>org.asciidoctor</groupId>
<artifactId>asciidoctorj-pdf</artifactId>
<version>${version.adjpdf}</version>
</dependency>
<dependency>
<groupId>org.asciidoctor</groupId>
<artifactId>**asciidoctorj-diagram<**/artifactId>
<version>${version.addia}</version>
</dependency>
</dependencies>
do I have to add something like
<configuration>
<requires>
<require>asciidoctor-diagramm</require>
</requires>
</configuration>
In the internet I only find configurations with gradle and gems, but not with maven... the problem is in backend HTML and PDF.
You find a fully working example here: https://github.com/asciidoctor/asciidoctor-maven-examples/tree/master/asciidoctor-diagram-example
Yes, you have to add both the dependency to asciidoctorj-diagram and you have to specify the requires/require in the configuration like you did in your question.

Log4J 2 failing to configure

I have a Jetty 9 based application that I inherited. I am trying to put in some logging functionality. I am using slf4j with log4j2. I have added the appropriate jars for this using Maven:
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.7.22</version>
</dependency>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-slf4j-impl</artifactId>
<version>2.7</version>
</dependency>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-api</artifactId>
<version>2.7</version>
</dependency>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-core</artifactId>
<version>2.7</version>
</dependency>
Unfortunately, the application keeps failing to find the log4j2.xml file:
ERROR StatusLogger No log4j2 configuration file found. Using default configuration: logging only errors to the console.
I have placed copies of that XML file in the webapps folder, the main folder under my server, and in the folder where the libraries are -- all places on the web application's classpath. The application still doesn't find it.
Can someone please advise on how I can make this application find the XML file?
Please take a look at the Log4j2 manual page for web applications.
By default Log4j2 looks in the WEB-INF folder of your web application.

Groovy ShortTypeHandling ClassNotFoundException

I have a groovy application that uses groovy version 2.2.1. My groovy app was previously running fine but has recently started throwing this exception:
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:108)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:116)
at com.app.Main.main(Main.groovy:83)Caused by: java.lang.ClassNotFoundException: org.codehaus.groovy.runtime.typehandling.ShortTypeHandling
at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
The ShortTypeHandling class was not even introduced until groovy 2.3.0. How can it be referenced in a groovy app running version 2.2.1? I can solve this problem by replacing the groovy-all-2.2.1.jar with groovy-all-2.3.0.jar in my pom but that doesn't root cause the issue.
ShortTypeHandling was introduced in groovy-all-2.3.0.jar so the quick fix was to replace the older groovy-all-x.x.x.jar with groovy-all-2.3.0.jar. This solved the runtime ShorTypeHandling ClassNotFoundException but also created new problems by introducing a new groovy-all.jar dependency in the application.
The real issue was how the groovy compiler was being invoked via maven. Because I introduced spock which required groovy 2.0, I needed to update the maven entries for the groovy-eclipse-compiler dependency. Here are the updated maven entries for working with groovy 2.x:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.1</version>
<configuration>
<compilerId>groovy-eclipse-compiler</compilerId>
<!-- Java version -->
<source>1.7</source>
<target>1.7</target>
</configuration>
<dependencies>
<dependency>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy-eclipse-compiler</artifactId>
<version>2.8.0-01</version>
</dependency>
<dependency>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy-eclipse-batch</artifactId>
<!-- Groovy version -->
<version>2.1.8-01</version>
</dependency>
</dependencies>
</plugin>
With this in place, I could leave my groovy-all dependency the way I originally had it for the working/fully tested application like this:
<dependency>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy-all</artifactId>
<!-- If possible, its better if this matches 2.1.8 in the plugin definition -->
<!-- but 2.2.1 worked fine here and allowed me to keep the original pom definition -->
<version>2.2.1</version>
</dependency>
The application runtime no longer references the ShortTypeHandling class and everything worked as it previously did.
You have to add (If you are using Gradle)
compile 'org.codehaus.groovy:groovy-backports-compat23:2.4.5'
I've just had this after updating the groovy-eclipse Feature in Eclipse (in order to try and fix intermittent save issues caused by https://jira.codehaus.org/browse/GRECLIPSE-1519). Specifically in my case, my Groovy JUnit tests were throwing this exception.
In light of the suggestions above, I checked my Eclipse settings, and it was using Groovy 2.3.4.xx whereas my Maven POM was specifying 2.1.8.xx. I went to Window -> Preferences -> Groovy -> Compiler and clicked "Switch to 2.1.8.xx...", restarting Eclipse when prompted, and this fixed it.
I've solved this issue by adding this dependency on my POM:
<dependency>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy-backports-compat23</artifactId>
<version>2.4.5</version>
</dependency>
Then, it works like a charm.
Matthew Wise's solution worked for me, but in addition to restarting eclipse, I also had to do a project -> clean for it to recompile with the new compiler.
(I would have commented on his answer, but stack overflow has this stupid rule that you can't comment until you get more reputation)
I faced similar issue in our project. Surprisingly groovy version was not an issue.
I was building the project with older version of gradle than the expected gradle version for the project. That resolved the error.
Add following dependency to your pom.xml
<dependency>
<groupId>org.codehaus.groovy.maven.runtime</groupId>
<artifactId>gmaven-runtime-default</artifactId>
<version>1.0-rc-3</version>
<exclusions>
<exclusion>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy-all</artifactId>
</exclusion>
</exclusions>
</dependency>
Kuldeep Singh

How to configure code coverage to work in Sonarqube using JaCoCo when unit tests are written in Groovy

I'm writing an application whose target classes (in src/main/java) are written / compiled to Java 7 but whose unit tests (in src/test/java) are written in Groovy. I am trying to get metrics from Sonarqube when I run mvn sonar:sonar. I get most everything, but I don't get code coverage metrics from JaCoCo. Instead I get the following message when the runner gets to the JaCoCo sensor:
Project coverage is set to 0% as no JaCoCo execution data has been dumped: C:\Users\fiddlerpianist\Projects\emailnotifier\target\jacoco.exec
However, when I run the EclEmma coverage (which uses JaCoCo) inside of Eclipse, I get full coverage reports with these Groovy tests. It just doesn't work through Sonarqube. Does anyone know why it doesn't work, or if there is a way I can configure something differently to make it work? I've tried a bunch of permutations of configuration, but so far... no luck.
The Maven java compiler plugin I'm using is configured a little differently (i.e. I use lombok):
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.1</version>
<configuration>
<compilerId>groovy-eclipse-compiler</compilerId>
<source>1.7</source>
<target>1.7</target>
<compilerArguments>
<javaAgentClass>lombok.core.Agent</javaAgentClass>
</compilerArguments>
<fork>true</fork>
</configuration>
<dependencies>
<dependency>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy-eclipse-compiler</artifactId>
<version>2.7.0-01</version>
</dependency>
<dependency>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy-eclipse-batch</artifactId>
<version>2.0.8-01</version>
</dependency>
<dependency>
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
<version>1.12.6</version>
</dependency>
</dependencies>
</plugin>
And I have my Groovy dependency scoped as test:
<dependencies>
<dependency>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy-all</artifactId>
<version>2.0.8</version>
<scope>test</scope>
</dependency>
</dependencies>
I'm using Sonarqube 3.7.4, Maven 3.1.1, Groovy 2.0.8, and Java 7. I'm using all the defaults for the Sonar Maven plugin (version 2.2).
So it turns out that you have to have at least one file with the .java extension (doesn't even have to be a test) in the src/test/java folder, and then everything works. It reminds me of a Groovy integration bug with Maven that used to require one Java file in with your Groovy code, but they since fixed that.

which jsf-impl should i use?

Where can i find a jsf-impl for my jsf 2 webapp ?
In maven's repo i got the 1.2 version.
In the http://download.java.net/maven/2/javax/faces/, i can see only the jsf-api, but no jsf-impl
Im currently using tomcat 7, and experimenting with primefaces.
Thank you !
UPDATE
I've been able to get both the api and the impl using this, but im still not sure which impl i should really use :
<dependency>
<groupId>com.sun.faces</groupId>
<artifactId>jsf-api</artifactId>
<version>2.0.3</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>com.sun.faces</groupId>
<artifactId>jsf-impl</artifactId>
<version>2.0.3</version>
<scope>compile</scope>
</dependency>
UPDATE
Sorry for not being clear, but it's not only about which version i should use.
I was doubtful because :
I notice the existence of 2 groupIds of javax.faces and com.sun.faces
I dont see the jsf-impl from the maven repository
What repository i should use to get the newest version
Thank you :-) !
My suggestion is to use jsf-api and jsf-impl version 2.0.4. Because it has lot of bugfixes and improvements over 2.0.3.
You can download them from this page at this link. And have a look at the MigrationGuide also.

Resources