We Keep Coding

quarkus-maven-plugin reports: [WARNING] [io.quarkus.arc.processor.BeanArchives] Failed to index

I'm trying to setup a legacy (jboss-eap) project on quarkus
I cannot find a maven dependency to CXF but I know its a "provided" dependency in one of my common-libs since CXF is offered by JBOSS.
Now I run into a warning during build:
INFO] --- quarkus-maven-plugin:1.10.5.Final:build (default) # gmw_rest_dispatch ---
[INFO] [org.jboss.threads] JBoss Threads version 3.1.1.Final
[INFO] [org.hibernate.Version] HHH000412: Hibernate ORM core version 5.4.26.Final
[WARNING] [io.quarkus.arc.processor.BeanArchives] Failed to index org.apache.cxf.phase.AbstractPhaseInterceptor: Class does not exist in ClassLoader QuarkusClassLoader:Deployment Class Loader
[INFO] [io.quarkus.arc.processor.IndexClassLookupUtils] Class for name: org.apache.cxf.phase.AbstractPhaseInterceptor was not found in Jandex index. Please ensure the class is part of the index.
[WARNING] [io.quarkus.arc.processor.BeanArchives] Failed to index org.apache.cxf.feature.AbstractFeature: Class does not exist in ClassLoader QuarkusClassLoader:Deployment Class Loader
[INFO] [io.quarkus.arc.processor.IndexClassLookupUtils] Class for name: org.apache.cxf.feature.AbstractFeature was not found in Jandex index. Please ensure the class is part of the index.
I want my build as clean as possible. So I'd like to get rid of this warning. How can I achieve that?
As a side-note: I can't view what jandex writes to its jandex.idx. So I've no means to debug. Note that the mentioned (org.apache.xf.phase.AbstractPhaseIntercepter and org.apache.cxf.feature.AbstractFeature) classes are also not annotations (AFAIK).

What is the recommended project structure for spring boot rest projects? [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed last year.
The community reviewed whether to reopen this question last year and left it closed:
Original close reason(s) were not resolved
Improve this question
I'm a beginner with spring boot. I'm involved in the beginning of a project where we would build rest services using spring boot. Could you please advise the recommended directory structure to follow when building a project that will just expose rest services?

From the docs:, this is the recommended way
The following listing shows a typical layout:
com
+- example
+- myapplication
+- Application.java
+- customer
+- Customer.java
+- CustomerController.java
+- CustomerService.java
+- CustomerRepository.java
+- order
+- order.java
+- OrderController.java
+- OrderService.java
+- OrderRepository. java
The Application. java file would declare the main method, along with the basic SpringBootApplication as follows:
package com.example.myapplication;
import org. springframework.boot.springApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
#SpringBootApplication public class Application {
public static void main(string[] args)
{
springApplication.run(Application. class, args);
}
}

config - class which will read from property files
cache - caching mechanism class files
constants - constant defined class
controller - controller class
exception - exception class
model - pojos classes will be present
security - security classes
service - Impl classes
util - utility classes
validation - validators classes
bootloader - main class

You do not need to do anything special to start. Start with a normal java project, either maven or gradle or IDE project layout with starter dependency.
You need just one main class, as per guide here and rest...
There is no constrained package structure. Actual structure will be driven by your requirement/whim and the directory structure is laid by build-tool / IDE
You can follow same structure that you might be following for a Spring MVC application.
You can follow either way
A project is divided into layers:
for example: DDD style
Service layer : service package contains service classes
DAO/REPO layer : dao package containing dao classes
Entity layers
or
any layer structure suitable to your problem for which you are writing problem.
A project divided into modules or functionalities or features and A module is divided into layers like above
I prefer the second, because it follows Business context. Think in terms of concepts.
What you do is dependent upon how you see the project. It is your code organization skills.

Though this question has an accepted answer, still I would like to share my project structure for RESTful services.
src/main/java
+- com
+- example
+- Application.java
+- ApplicationConstants.java
+- configuration
| +- ApplicationConfiguration.java
+- controller
| +- ApplicationController.java
+- dao
| +- impl
| | +- ApplicationDaoImpl.java
| +- ApplicationDao.java
+- dto
| +- ApplicationDto.java
+- service
| +- impl
| | +- ApplicationServiceImpl.java
| +- ApplicationService.java
+- util
| +- ApplicationUtils.java
+- validation
| +- impl
| | +- ApplicationValidationImpl.java
| +- ApplicationValidation.java
DAO = Data Access Object.
DTO = Data Transfer Object.

Use Link-1 to generate a project. this a basic project for learning. you can understand the folder structure.
Use Link-2 for creating a basic Spring boot project.
1: http://start.spring.io/
2: https://projects.spring.io/spring-boot/
Create a gradle/maven project Automatically src/main/java and src/main/test will be created. create controller/service/Repository package and start writing the code.
-src/main/java(source folder)
---com.package.service(package)
---ServiceClass(Class)
---com.package.controller(package)
---ControllerClass(Class)

Please use Spring Tool Suite (Eclipse-based development environment that is customized for developing Spring applications). Create a Spring Starter Project, it will create the directory structure for you with the spring boot maven dependencies.

How to resolve overlapping dependencies in Java? [duplicate]

This question already has answers here:
Maven build [WARNING] we have a duplicate class
(8 answers)
Closed 5 years ago.
I would like to use Maven-shade-plugin to create uber-jar. But when I call mvn package command Maven reports that there are some overlapping classes. I am attaching all problematic overlapps, some of them are caused because older and new verion of a library (Log4J), but some of them seems to have the same classes - e.g. javax.mail and mailapi/smtp/imap et cetera.
What is the best to do in this situation? Is there some key how to decide which overlapping is safe to ignore a which needs to be correct?
- mailapi-1.4.3.jar, javax.mail-1.5.0.jar define 166 overlappping classes
- spring-2.5.6.SEC03.jar, spring-tx-3.1.4.RELEASE.jar define 176 overlappping classes:
- spring-beans-3.1.4.RELEASE.jar, spring-2.5.6.SEC03.jar define 283 overlappping classes:
- slf4j-log4j12-1.7.5.jar, slf4j-impl-2.0-beta2.jar define 3 overlappping classes:
- spring-2.5.6.SEC03.jar, spring-context-support-3.1.4.RELEASE.jar define 55 overlappping classes:
- aopalliance-1.0.jar, spring-2.5.6.SEC03.jar define 9 overlappping classes:
- imap-1.5.0.jar, javax.mail-1.5.0.jar define 87 overlappping classes:
- commons-logging-api-1.1.jar, commons-logging-1.1.3.jar define 19 overlappping classes:
- spring-2.5.6.SEC03.jar, spring-core-3.1.4.RELEASE.jar define 161 overlappping classes:
- spring-2.5.6.SEC03.jar, spring-context-3.1.4.RELEASE.jar define 326 overlappping classes:
- log4j12-api-2.0-beta3.jar, log4j-1.2.17.jar define 23 overlappping classes:
- spring-aop-3.1.4.RELEASE.jar, spring-2.5.6.SEC03.jar define 237 overlappping classes:
- spring-jdbc-3.1.4.RELEASE.jar, spring-2.5.6.SEC03.jar define 239 overlappping classes:
- quartz-1.8.6.jar, quartz-jobs-2.2.1.jar define 15 overlappping classes:
- smtp-1.5.0.jar, javax.mail-1.5.0.jar define 17 overlappping classes:
- spring-asm-3.1.4.RELEASE.jar, spring-2.5.6.SEC03.jar define 31 overlappping classes:
EDIT: this application "A" uses as a Maven dependency my another Java application - I'll call this app "B". This B application uses javax.mail ver 1.5.1. This library uses the first application too. But when I call mvn package command, Maven notices that javax.mail-api-1.5.1.jar, javax.mail-1.5.1.jar define 135 overlappping classes.
Is this problem and if so, how to solve it or can I ignore it?

The first thing to do is remove as many of the obvious causes of overlapping classes as you can. For instance:
You have dependencies on both spring 2.5.6 and spring 3.1.4, which will give you more problems than just in the shade plugin. Set up your module dependencies so you have just one version of spring. Use dependency exclusions if you have to (say you have transitive dependencies that you do not control).
Once the dependency version clashes are fixed, you can also configure which jars go into the uber-jar with the shade plugin configuration, as described at http://maven.apache.org/plugins/maven-shade-plugin/examples/includes-excludes.html
Some of the jars probably contain all of the classes from their overlapping jars.
I suspect that commons-logging-1.1.3.jar has a superset of the classes declared in commons-logging-api-1.1.jar. If this is the case, you can exclude the api jar.
In response to the edited question, javax.mail-1.5.1.jar contains a superset of the classes in javax.mail-api-1.5.1.jar. Since these are clearly the same version and the overlapping classes should be identical, it will do no harm to build the shaded jar with the overlapping classes (it will take the classes from whichever jar it processes last). However, the build will be tidier and slightly faster if you exclude the api jar.
It's unlikely that you will need to retain conflicting versions of the classes in the shaded jar. If you do, the shade plugin also allows the relocation of classes, as described at http://maven.apache.org/plugins/maven-shade-plugin/examples/class-relocation.html

I found the maven dependency tree plugin very useful to find out from where is the nested dependency coming from , and then add an exclusion for it.
$ **mvn dependency:tree -Dverbose -Dincludes=aopalliance**
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building petshop cli 1.0
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-dependency-plugin:2.1:tree (default-cli) # cli ---
[INFO] com.sample.petshop:cli:jar:1.0
[INFO] \- **org.springframework:spring-context**:jar:4.1.3.RELEASE:compile
[INFO] \- org.springframework:spring-aop:jar:4.1.3.RELEASE:compile
[INFO] \- **aopalliance:aopalliance**:jar:1.0:compile
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 5.865s
[INFO] Finished at: Fri May 08 15:12:01 IST 2015
[INFO] Final Memory: 14M/223M
[INFO] ------------------------------------------------------------------------
The aopalliance jar is being referenced from spring-context-support which indicates that we could possibly exclude it.

This question duplicates this one, where you could find more examples.
But in case you are sure you don't have overlapping dependencies (like i had), cleaning project could help. See this answer for more details

Spring Webflow Jsf integration war not working in Glassfishv3 server

Spring-Webflow JSF intgration war example(http://www.springsource.org/webflow-samples/spring-booking-faces.war) file from spring site is not working in GlassfishV3 server. It works in Tomcat6.0.
In Glassfish, It throws following exception
Caused by: java.lang.UnsupportedOperationException
at javax.faces.context.FacesContext.getAttributes(FacesContext.java:141)
at com.sun.faces.util.RequestStateManager.get(RequestStateManager.java:194)
at com.sun.faces.util.Util.getFacesMapping(Util.java:564)
at com.sun.faces.application.view.MultiViewHandler.derivePhysicalViewId(MultiViewHandler.java:483)
at com.sun.faces.application.view.MultiViewHandler.restoreView(MultiViewHandler.java:142)
at org.springframework.faces.webflow.FlowViewHandler.restoreView(FlowViewHandler.java:77)
at org.springframework.faces.webflow.JsfViewFactory.getView(JsfViewFactory.java:97)
at org.springframework.webflow.engine.ViewState.resume(ViewState.java:198)
at org.springframework.webflow.engine.Flow.resume(Flow.java:551)
at org.springframework.webflow.engine.impl.FlowExecutionImpl.resume(FlowExecutionImpl.java:263)
... 40 more

I received a similar error that you are facing sometime back . Try replacing your JSF jars with the following jars.I guess it is using Primefaces too . Use following combination of jars
[INFO] +- com.sun.faces:jsf-api:jar:2.0.3-b05:compile
[INFO] +- com.sun.faces:jsf-impl:jar:2.0.3-b05:runtime
[INFO] +- org.primefaces:primefaces:jar:2.2.RC2:compile
Please let me know if you still face any problem

Hibernate: What am I missing? Can't find #Id, instead #Index

Every example I have found uses #Id, but when I try to write my code, many of the annotations that I'm used to are gone, there are annotatoins like #Index, and the #Entity parameters have changed. I've looked through the Hibernate documentation, and can't find anything talking about changing all of their annotations, so am I looking at a bogus version?
Even #Column() with a name is gone, this is extremely confusing, I'm using Hibernate 3, but I find it hard to believe they went through and broke EVERY annotation that they used to support.
I downloaded the most recent version of Hibernate3.jar, that's all I've included, looking through the JAR I see the annotations packages
import org.hibernate.annotations.Entity;
import org.hibernate.annotations.Table;

I think a wrongly defined class path on your side is more likely than a bogus version. And without more details about the version of Hibernate you're using, the JARs you have on the class path, I don't know what to add.
Update: I'd suggest to use JPA annotations over Hibernate annotations. Here are the dependencies I'm using with the latest version of Hibernate Entity Manager:
org.hibernate:hibernate-entitymanager:jar:3.5.3-Final:compile
+- org.hibernate:hibernate-core:jar:3.5.3-Final:compile
| +- antlr:antlr:jar:2.7.6:compile
| +- commons-collections:commons-collections:jar:3.2:compile
| +- dom4j:dom4j:jar:1.6.1:compile
| | \- xml-apis:xml-apis:jar:1.0.b2:compile
| \- javax.transaction:jta:jar:1.1:compile
+- org.hibernate:hibernate-annotations:jar:3.5.3-Final:compile
| \- org.hibernate:hibernate-commons-annotations:jar:3.2.0.Final:compile
+- cglib:cglib:jar:2.2:compile
| \- asm:asm:jar:3.1:compile
+- javassist:javassist:jar:3.9.0.GA:compile
\- org.hibernate.javax.persistence:hibernate-jpa-2.0-api:jar:1.0.0.Final:compile

No, the annotations haven't changed.
It's hard to us for know if you are looking at a bogus version without knowing what is on your classpath.
Are you sure that hibernate-annotations is on your classpath? As well as the JAR containing the javax.persistence classes (such as hibernate-jpa-2.0-api-1.0.0.Final.jar)?