-
Notifications
You must be signed in to change notification settings - Fork 77
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
Dependency on outdated JTA API #608
Comments
+1 to remove. |
The EE10 version of JTA is 2.0.1. There is no upgrade in EE10. We cannot build the current javadoc without this dependency:
This class really should be a cdi additional library produced by the JTA project, but we are where we are. There also should be a javadoc scope for dependencies to make it clear the nature of the dependency. It is not a dependency of the API in any hard sense. We can discuss this in the CDI meeting and platform group call before doing anything about it. |
@starksm64 I agree and I have sent a PR where I changed the |
In the meeting it was agreed that we would also want to remove EJB dependency and rewrite any code links to just |
Sorry, I already merged the JTA PR. Add a new one for EJB removal. |
I was away from PC yesterday and didn't get to it earlier. |
The latest release of CDI 4 has a dependency on
jakarta.transaction-api
in version2.0.0
.That artifact is actually not Jakarta EE 10 (there is no such artifact as of now it seems?) and it in turn depends on CDI 3.0, see this POM.
The dependency is not even
optional
.This causes a cyclic dependency that has been mentioned in the jakarta-platform mailing list - link to the archive. This is nothing new and the dep has existed prior to our release.
As far as I can tell, we could completely remove the JTA API dependency as it is only used in javadoc inside
TransactionPhase
enum.Granted, the javadoc won't be as nice but we'll get rid of the dep altogether. OTOH, JTA certainly cannot remove dep on CDI API, so we are the only ones who can break that cycle.
So we have two choices:
Personally, I think we can easily remove the dependency.
Either way, we should then have an SP release and I am not sure what would that take- cc @starksm64.
The text was updated successfully, but these errors were encountered: