For discussing whether to create new submodules for component TCKs that we have already released for EE 11 #1344
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This draft pull request contains some JPA/Persistence test bucket changes (made via OpenRewrite automation). The changes to look at are under 5089f06
When you look at the 5089f06 commit, we should consider whether that is an appropriate change to make to EE TCK projects that have already been released even though we are not actually changing the (already released) JPA/Persistence test classes.
The (jpa) pom.xml version (see https://github.com/jakartaee/platform-tck/pull/1344/files#diff-925f90ce9555617cd3caa9da38987ea95f25366fec7d88b09a63ebc361a84e51) changes from
3.2.0
to3.2.1-SNAPSHOT
don't look right as we already have Persistence 3.2 TCK challenges that call releasing a3.2.1
Persistence TCK.This is something that we have discussed recently on https://www.eclipse.org/lists/jakartaee-tck-dev/msg02022.html (see
Generating a subclass like this without modifying the existing tests may be what Scott Marlow was talking about on the call on Wednesday.
).In addition to generating a new test class, I'm thinking we should really move the new test classes to a new submodule to have separation between submodules for component TCKs versus Platform TCK tests. I think that this will be important for when we have to release fixes for component TCKs versus releasing fixes for the EE 11 Platform TCK.