hibernate-jpamodelgen fails to process the current Data 1.0.0-SNAPSHOT TCK code #1
Comments
This looks like we need to compile with
This looks like the TCK has not been updated to use |
This is the TCK requiring something it has no right to require. |
This is because you're running tests designed for NoSQL with a Hibernate-backed repo. |
|
The TCK does pass in <plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>${maven.compile.version}</version>
<configuration>
<source>17</source>
<target>17</target>
<compilerArgs>
<arg>-parameters</arg>
</compilerArgs>
</configuration>
</plugin>and adding that to the tck runner pom does not change the errors: I'll see if I can find where the error is coming from. |
Ok, I'll double check the tck property configurations to avoid those tests. |
Yeah I know but I question that this actually works: jakartaee/data#586 |
That has been fixed by excluding the nosql source. |
This looks like a bug in my code. |
Oh no, it's not, it's because the method signature in the TCK should be: My code is fine. |
|
There is a problem with the generation of the target/generated-sources/annotations/ee/jakarta/tck/data/web/validation/Rectangles_.java file. The start looks like the following where you can see an incorrect embedding of the @jakarta.validation.Valid annotation in the first import: package ee.jakarta.tck.data.web.validation;
import ee.jakarta.tck.data.web.validation.@jakarta.validation.Valid Rectangle;
import jakarta.annotation.Generated;
import jakarta.annotation.Nonnull;
import jakarta.annotation.PostConstruct;
import jakarta.annotation.PreDestroy;
...This is related to the processing of the save This is the full state of the |
|
Yeah, OK, I will take a look and sort that out tomorrow. (It's because it's an annotation of the type, and apparently the annotation processor APIs retain that when rendering a type as a string.) The bug is I suppose at line 1198 of Apparently I will need to find a way to strip the annotation off of that. There's a few other places I also use |
|
So this is a bug in the toString() annotation processor code under Java SE 21. If I run under Java SE 17, the code is generated correctly sans the Repository(ee.jakarta.tck.data.framework.read.only.AsciiCharacters) as kind:INTERFACE
...
find(@jakarta.data.repository.By("thisCharacter") char,java.lang.@jakarta.data.repository.By("hexadecimal") String):METHODIt is fine on the primitive type, but messed up on the |
The issue is that the api jar also needs to be compiled with -parameters. I have added that comment to the data issues. When that is added the error becomes: |
Right, it's what I was trying to say last night, it's because it's a
Ah, OK, that helps explain why I have not run into this before. Do you know if it's been reported? |
|
One problem I have here is that the original "old" |
|
@starksm64 with hibernate/hibernate-orm#8044 you should get better info about those errors relating to inherited members. |
|
We could just generate the source using Java SE 17 and then run the TCK with either 17 or 21. I have not found a bug report as yet, so I was going to create a small reproducer and submit one. |
Why exactly are we even using 21 here? |
This is with two fixes to my implementation, and Java 17. Those problem are all bugs in the TCK. |
|
Of course, the next problem is going to be all those Query-by-Method-Name methods. |
|
A ratifying compatible implementation will need to pass with both 17 and 21 for EE 11. If we just want to pass the TCK, it can be either. |
|
OK, no problem, hibernate/hibernate-orm#8050 works around this bug, and validation annotations on repo method parameters now work perfectly. |
This one is a bug/limitation in Hibernate 6 core. |
|
OK, done. We are left with the unimplemented Query by Method Name methods. 
|
|
So today I tried to get the tests running by marking all the query by method name methods with I eventually got to the point where all the repository implementations were generated correctly, and I believe that the errors I'm now seeing are not on my side. 
Unfortunately, to get to this point, you'll need a heavily-patched version of the TCK. |
|
Can you push those tck repo changes somewhere so I can look into the
failures?
…On Fri, Mar 29, 2024 at 11:02 AM Gavin King ***@***.***> wrote:
So today I tried to get the tests running by marking all the query by
method name methods with @query and fixing/removing methods which are
testing things *not* required by the spec (of which there were a few).
I eventually got to the point where all the repository implementations
were generated correctly, and I believe that the errors I'm now seeing are
not on my side.
Screenshot.2024-03-29.at.5.58.41.PM.png (view on web)
<https://github.com/jakartaredhat/hibernate-data-tck/assets/579974/7b9ddea2-4f51-4b39-b2f1-3a5aab57bbb7>
Unfortunately, to get to this point, you'll need a heavily-patched version
of the TCK.
—
Reply to this email directly, view it on GitHub
<#1 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AACRDMVVGM65344L4VGV47TY2WF6TAVCNFSM6AAAAABFHYWISKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMRXGQ4TAOBWG4>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
This seems resolved, so I'll create a new issue for the next phase. |
This is either a bug in the TCK code, or the hibernate-jpamodelgen annotation processor. Attempting to run the Data 1.0.0-SNAPSHOT fails as follows:
The text was updated successfully, but these errors were encountered: