-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Incorrect class name is used when the generated test class requires a number to be added (e.g. Client.class in EE 10 but was split into Client1/2/3/4 in EE 11) #91
Comments
I looked in the current Platform TCK sources and think that we might only have this problem with jpa tests. Connector + JDBC do have some tests like connManagerClient1.java or callStmtClient1.java but I think those map to the same class names in EE 11 so are unlikely to hit this bug. |
I just counted the number of generated source files that have this problem and it happens in 1276 jpa tests. So, think I will find the cause and see if I can fix it. |
Look at updating parseVehiclePackage() to pass in clazz.getName() (e.g. "ee.jakarta.tck.persistence.core.annotations.access.field.Client1") to be used instead of "ee.jakarta.tck.persistence.core.annotations.access.field.Client.class". |
I'm going to push my hack for this fix to a branch but don't expect that we need to merge it as it needs further refinement. |
The problem here is that the EE10 build.xml parse is using the EE10 test class which no longer exists. I don't see why the hack you have would change this. This is really another name mapping problem, but we can't add all these new client classes to the mapping. It seems like the code is going to have to look for the EE10 version of the input EE11 client class after mapping, and if it ends in a number and does not exist in the EE10 code, look to map the EE10 non-numbered class to the input numbered class. I'll take a look at this tomorrow as its late. |
As best as I can tell from looking around at different Client1.java tests in the EE 10 TCK vs EE 11 TCK, the EE 11 jpa tests are the only examples of where we split EE 10 Client.java into multiple (EE 11) Client1.java + Client2.java sources. So the class name mapping issue is limited to the JPA tests. My hack in diff form is:
My hack is very specific to the JPA compile failures that I was seeing. Initially, I looked up the call stack in the debugger and didn't see a quick solution so just hacked in the (thread unsafe) system property solution to pass the class name in.
It did seem like the TestPackageInfoBuilder#parseVehiclePackage did already have the EE 11 test class in variable |
Ok, I was looking at the wrong commit then. See the latest changes I pushed up in #95 that add a mapping from the current test class if it ends with a digit and does not exist in EE10, but the non-digit class does. This is producing jpa code that compiles. If that works for you I can put out a 1.0.0-M3. Note that the |
I'm not sure but with this change + https://github.com/scottmarlow/jakartaee-tck-tools/tree/jakartaee-tck-tools-pull-95, I am getting the following compile failure (without my hack change that I mentioned earlier):
From platform-tests/src/main/java/ee/jakarta/tck/persistence/core/criteriaapi/CriteriaQuery/Client4AppmanagedTest.java:
It looks like com.sun.ts.tests.jpa.core.criteriaapi.CriteriaQuery.Client.ExpectedResult.class` was for nested Client.ExpectedResult class in the EE 10 Client.java |
Example from jpa/platform-tests/src/main/java/ee/jakarta/tck/persistence/core/entityManager/Client2AppmanagedTest.java:
The text was updated successfully, but these errors were encountered: