Static metamodel class is not generated - jhipster

I just started learning and using Jhipster. I have a question about JPA Static metamodel generation. The following is what I have done according to the Jhipster website but the static matemodel class(Class X_) is not generated:
I created an entity called: SalesByDepartment. After this entity generated, I changed its JOSN file from folder:.jhipster under my project folder by setting service to serviceImpl from no, and jpaMetamodelFiltering to true. My understanding is that I need to re-run entity sub-generator to regenerate the same entity to enable Filtering feature after I've done this change to this entity's JSON file. However, I only can find 'SalesByDepartmentCriteria' and 'SalesByDepartmentQueryService'. There is no class 'SalesByDepartment_' under the domain package. I also checked pom.xml and I can find the plugin:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>${maven-compiler-plugin.version}</version>
<configuration>
<annotationProcessorPaths>
<path>
<groupId>org.mapstruct</groupId>
<artifactId>mapstruct-processor</artifactId>
<version>${mapstruct.version}</version>
</path>
<!-- For JPA static metamodel generation -->
<path>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-jpamodelgen</artifactId>
<version>${hibernate.version}</version>
</path>
</annotationProcessorPaths>
</configuration>
</plugin>
May I know if anything else I have missed to generate 'SalesByDepartment_' under domain package?
Thank you for the help.
By the way, it worked fine when I generated the first project. I did the same way and static metamodel classes were created automatically under project folder: 'com.xxx.domain'. I also can find them under target folder after build process with Maven. I guess there are something wrong but still have no idea why is that. Below is the screen shot for two projects that I have created using 'jhipster'. A is the previous project which I could generate static metamodel, but B doesn't work:
enter image description here

I had this problem too, the best way that I found for myself - add the dependency to maven and to annotation processor path
<dependencies>
...
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-jpamodelgen</artifactId>
<version>${hibernate.version}</version>
</dependency>
</dependencies>
annotation processor
<build>
<plugins>
...
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>11</source>
<target>11</target>
<annotationProcessorPaths>
<path>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-jpamodelgen</artifactId>
<version>${hibernate.version}</version>
</path>
...
</annotationProcessorPaths>
</configuration>
</plugin>
</plugins>
</build>
Hope it helps somebody )

JPA Static metamodel is generated by build process (maven or gradle) as explained in JHipster doc so you just have to build your app and you'll find SalesByDepartment_.java under target for maven and under build for gradle.

In my case the problem was a problem in services that the compiler don't notice.
I change a service class from implemented service to service so the implementation class was still existing, i erase that file an everything works fine.

Related

Quarkus best way to provide beans from library

I want to provide quarkus beans from a separate codebase, brought in as a dependency. What is the best way to do this?
My first thought was to find the artifact that has the annotations such as #ApplicationScoped, etc and making them part of my library dependencies, but after some searching it isn't obvious of the correct dependency.
I have also seen extensions, but making an extension feels fairly heavy; I don't need to change how Quarkus runs, just define some beans in a library.
I wish I could provide more in this question, but unsure of best-practice-wise where to go from here.
Besides using a producer method, as said by #Turing75, you may enable bean discovery by generating a Jandex Index for your library:
A dependency with a Jandex index is automatically scanned for beans.
To generate the index just add the following to your pom.xml:
<build>
<plugins>
<plugin>
<groupId>org.jboss.jandex</groupId>
<artifactId>jandex-maven-plugin</artifactId>
<version>1.2.2</version>
<executions>
<execution>
<id>make-index</id>
<goals>
<goal>jandex</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>

Publishing Karate test report to Cucumber Open Report [duplicate]

We are using Karate heavily for various projects and though the report generated using karate Reports are more than anyone would need. I am still interested in getting Allure integrated in the mix.
Added allure-junit4 dependency and added allure listener
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.20</version>
<configuration>
<argLine>
-javaagent:"${settings.localRepository}/org/aspectj/aspectjweaver/${aspectj.version}/aspectjweaver-${aspectj.version}.jar"
<!-- -Dcucumber.options="--plugin io.qameta.allure.cucumberjvm.AllureCucumberJvm"-->
</argLine>
<properties>
<property>
<name>listener</name>
<value>io.qameta.allure.junit4.AllureJunit4</value>
</property>
</properties>
</configuration>
<dependencies>
<dependency>
<groupId>org.aspectj</groupId>
<artifactId>aspectjweaver</artifactId>
<version>${aspectj.version}</version>
</dependency>
</dependencies>
</plugin>
Now allure-results is getting created and I can see report but it's almost blank.
How can I get allure report generated on karate based project?
If Allure supports the Cucumber JSON output it should work. Else suggest you take this up with the Allure team.
You can refer to this thread (for Extent): https://github.com/intuit/karate/issues/619
EDIT: Since I refer anyone asking about extending / custom reports to this answer, read on.
In Karate 1.0 onwards, the Results object can be used to get all data about the test results. Also multiple JSON files will be output to the <build>/karate-reports. You can even re-try some tests and merge the results: https://github.com/intuit/karate/wiki/1.0-upgrade-guide#retry-framework-experimental
Also please be aware of changes to the Java hooks, it is called RuntimeHook now: https://github.com/intuit/karate/wiki/1.0-upgrade-guide#hooks

Spark: Avoiding Namespace Conflict when building modified spark

I am building a custom spark into a jar file. And I want to use that while using the default spark build.
How do I change the namespace from org.apache.spark.allOfSpark into org.another.spark.allOfSpark without going through all files?
I want to do this in order to avoid conflict when importing modules. Thanks in advance.
Depending on the build tool you are using, you could use Maven's relocation feature to move your custom spark into a new package at build-time. There are similar features in sbt and other build tools.
If you specify what you are using to build your project, I can further help on your issue.
-- UPDATE
Here is a sample code for your pom.xml that should help you getting started :
<project>
<!-- Your project definition here, with the groupId, artifactId, and it's dependencies -->
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>2.4.3</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>shade</goal>
</goals>
<configuration>
<relocations>
<relocation>
<pattern>org.apache.spark</pattern>
<shadedPattern>shaded.org.apache.spark</shadedPattern>
</relocation>
</relocations>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>
This will effectively move all of Spark into a new package called shaded.org.apache.spark when you package your application (when you ask Maven to produce a jar).
If you need to exclude certain packages, you can use the <exclude> tag as shown in the link of Maven's relocation.
If what you are trying to achieve is simply to customize some parts of Spark, I would advise you to either fork Spark's code and directly rewrite parts of MLLib, and then build it only for you (or contribue it to the community if it can useful).
Or you could simply pull it as a dependency from Maven and just overwrite the classes you are modifying, Maven should then use your own class instead of the one in the original Spark package.

FacesContext.getCurrentInstance() returns null even in managed bean thread

I have a fairly standard archirecture where a PrimeFaces page calls a login action in a class annotated with javax.inject.#Named and javax.enterprise.context.#SessionScoped.
The doLogin() method receives null back from FacesContext.getCurrentInstance() even though the Faces Servlet should be properly invoked.
There are many posts that say essentially, "the only time FacesContext.getCurrentInstance() will return null is when it's called outside a managed bean thread". But I did find one post on another forum that identified a build/class loader issue that causes it. Somehow, due to improperly specified dependencies, your FacesContext class can get loaded for the container and again for the app. So what is supposed to be a singleton turns into two singletons (somehow...?). Anyway, I'm posting this to record the fix, not to fully explain the problem behind the symptom.
I'm using JBoss Developer Studio, building with Maven for JBoss EAP 6.2. EAP comes with modules for JSF 1 and JSF 2.1. I want to use 2.1, which is stored here:
C:\JBoss\jboss-eap-6.2.0\modules\system\layers\base\javax\faces\api\main.
In my EJB project POM I had incorrectly added a dependency for jsf-api <scope>compile, which resulted in FacesContext.getCurrentInstance() returning null as described above.
The solution was: in the POM for my ejb and my web projects, I added this dependency:
<dependency>
<groupId>org.jboss.spec.javax.faces</groupId>
<artifactId>jboss-jsf-api_2.1_spec</artifactId>
<scope>provided</scope>
</dependency>
And to make sure my deployed ejb project also tells JBoss about that I needed to make sure it gets published with this in it's MANIFEST.MF:
Dependencies: javax.faces.api:main
That can be done by Maven too, by putting an archive configuration in the POM for the ejb project where the build plugin was created:
<!-- most of this <build> element was already in my POM -->
<build>
<plugins>
<plugin>
<artifactId>maven-ejb-plugin</artifactId>
<version>2.3</version>
<configuration>
<ejbVersion>3.1</ejbVersion>
<!-- I added this <archive> element to tell Maven to add the dependency line in MANIFEST.MF -->
<archive>
<manifestEntries>
<Dependencies>javax.faces.api:main</Dependencies>
</manifestEntries>
</archive>
</configuration>
</plugin>
</plugins>
</build>
For me, the maven-ejb-plugin entry was already there and I just added the archive definition to the existing <configuration>. I assume if you are building with ejb-jar-plugin or ejb-war-plugin, the same <archive>...</archive> definition could be used.

How to enforce a strict Maven dependency policy (dependency chain attack)

I would like to enforce a strict Maven dependency policy which goes beyond the basic checksumPolicy=fail approach.
This is an attempt to provide protection against a modified release dependency which still has a valid digest value also known as a "dependency chain attack".
This situation could arise from the following scenarios:
the dependency has been updated, but the author has not updated the version number and managed to overwrite the earlier release (or their repo account has been compromised)
a man-in-the-middle attack is in place (with on-the-fly rewriting/hashing)
the repository itself has been compromised
In discussions with other developers one approach to combat the above is to have a list of known MD5/SHA digests in the pom.xml and have Maven verify that the downloaded dependency has the same digest. This ensures that so long as the source code repository remains secure, any included dependencies that have been compromised will be detected.
Thus my question is twofold:
are there any alternative approaches that would work more efficiently?
are there any existing implementations/plugins that do this job?
If anyone is wrestling with this issue themselves I've created a Maven Enforcer Plugin Rule that deals with it. You can specify a list of artifact URNs that include the expected SHA1 hash value and have the enforcer verify that this is indeed what is being used in the build.
It is available through Maven Central under MIT license, with source code in GitHub here: https://github.com/gary-rowe/BitcoinjEnforcerRules
While the project indicates that it is for the Bitcoinj library, it is actually a general purpose solution which could be included in any security conscious build process. It will also scan your existing project and identify any problem area while it automatically builds the whitelist for you.
Below is an example of the configuration you'd require in your project to use it.
<build>
<plugins>
...
<!-- Use the Enforcer to verify build integrity -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-enforcer-plugin</artifactId>
<version>1.2</version>
<executions>
<execution>
<id>enforce</id>
<phase>verify</phase>
<goals>
<goal>enforce</goal>
</goals>
<configuration>
<rules>
<digestRule implementation="uk.co.froot.maven.enforcer.DigestRule">
<!-- Create a snapshot to build the list of URNs below -->
<buildSnapshot>true</buildSnapshot>
<!-- List of required hashes -->
<!-- Format is URN of groupId:artifactId:version:type:classifier:scope:hash -->
<!-- classifier is "null" if not present -->
<urns>
<urn>antlr:antlr:2.7.7:jar:null:compile:83cd2cd674a217ade95a4bb83a8a14f351f48bd0</urn>
<urn>dom4j:dom4j:1.6.1:jar:null:compile:5d3ccc056b6f056dbf0dddfdf43894b9065a8f94</urn>
<urn>org.bouncycastle:bcprov-jdk15:1.46:jar:null:compile:d726ceb2dcc711ef066cc639c12d856128ea1ef1</urn>
<urn>org.hibernate.common:hibernate-commons-annotations:4.0.1.Final:jar:null:compile:78bcf608d997d0529be2f4f781fdc89e801c9e88</urn>
<urn>org.hibernate.javax.persistence:hibernate-jpa-2.0-api:1.0.1.Final:jar:null:compile:3306a165afa81938fc3d8a0948e891de9f6b192b</urn>
<urn>org.hibernate:hibernate-core:4.1.8.Final:jar:null:compile:82b420eaf9f34f94ed5295454b068e62a9a58320</urn>
<urn>org.hibernate:hibernate-entitymanager:4.1.8.Final:jar:null:compile:70a29cc959862b975647f9a03145274afb15fc3a</urn>
<urn>org.javassist:javassist:3.15.0-GA:jar:null:compile:79907309ca4bb4e5e51d4086cc4179b2611358d7</urn>
<urn>org.jboss.logging:jboss-logging:3.1.0.GA:jar:null:compile:c71f2856e7b60efe485db39b37a31811e6c84365</urn>
<urn>org.jboss.spec.javax.transaction:jboss-transaction-api_1.1_spec:1.0.0.Final:jar:null:compile:2ab6236535e085d86f37fd97ddfdd35c88c1a419</urn>
<!-- A check for the rules themselves -->
<urn>uk.co.froot.maven.enforcer:digest-enforcer-rules:0.0.1:jar:null:runtime:16a9e04f3fe4bb143c42782d07d5faf65b32106f</urn>
</urns>
</digestRule>
</rules>
</configuration>
</execution>
</executions>
<!-- Ensure we download the enforcer rules -->
<dependencies>
<dependency>
<groupId>uk.co.froot.maven.enforcer</groupId>
<artifactId>digest-enforcer-rules</artifactId>
<version>0.0.1</version>
</dependency>
</dependencies>
</plugin>
...
</plugins>
</build>
Sounds like a good job for the repository itself. Check out this other thread regarding a similar question.
I've no familiarity with the PGP signing scenario in Nexus, but does that sound like a good start?

Resources