-
Notifications
You must be signed in to change notification settings - Fork 75
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
Migrate javax.inject and javax.annotations to Jakarta #1056
Comments
- Only use Import-Package to for javax.annotation and javax.inject - Always use closed version ranges [1.X,2) with a minor lower bound Part of eclipse-platform/eclipse.platform.releng.aggregator#1056
- Only use Import-Package to for javax.annotation - Always use closed version ranges [1.X,2) with a minor lower bound - Remove unused dependencies Part of eclipse-platform/eclipse.platform.releng.aggregator#1056
- Only use Import-Package to for javax.annotation - Always use closed version ranges [1.X,2) with a minor lower bound - Remove unused dependencies Part of eclipse-platform/eclipse.platform.releng.aggregator#1056
- Only use Import-Package to for javax.annotation and javax.inject - Always use closed version ranges [1.X,2) with a minor lower bound Part of eclipse-platform/eclipse.platform.releng.aggregator#1056
- Always use closed version ranges [1.X,2) with a minor lower bound - Mark package-import that is not optional as such Part of eclipse-platform/eclipse.platform.releng.aggregator#1056
- Always use closed version ranges [1.X,2) with a minor lower bound Part of eclipse-platform/eclipse.platform.releng.aggregator#1056
- Only use Import-Package to for javax.annotation and javax.inject - Always use closed version ranges [1.X,2) with a minor lower bound Part of eclipse-platform/eclipse.platform.releng.aggregator#1056
- Only use Import-Package to for javax.annotation and javax.inject - Always use closed version ranges [1.X,2) with a minor lower bound Part of eclipse-platform/eclipse.platform.releng.aggregator#1056
- Only use Import-Package to for javax.annotation and javax.inject - Always use closed version ranges [1.X,2) with a minor lower bound Part of eclipse-platform/eclipse.platform.releng.aggregator#1056
The javax.inject/annotation bundles are also contained in some products and one feature. I think we can simply remove them there. |
- Always use closed version ranges [1.X,2) with a minor lower bound Part of eclipse-platform/eclipse.platform.releng.aggregator#1056
- Always use closed version ranges [1.X,2) with a minor lower bound Part of eclipse-platform/eclipse.platform.releng.aggregator#1056
Use the javax namespace bundles provided by Jakarta. Remove all corresponding bundles provided by Orbit. Remove the unused javax.xml bundle, the modern JREs provide the contained packages by default. Part of eclipse-platform#1056
Use the javax namespace bundles provided by Jakarta. Remove all javax bundles provided by Orbit. Remove the unused javax.xml bundle, the modern JREs provide the contained packages by default. Part of eclipse-platform#1056
During builds these annotation providing bundles are pulled in as transitive dependencies any ways. Removing them from this features simplifies the exchange of the atucally providing bundle and therefore the migration to Jakarta. Part of eclipse-platform/eclipse.platform.releng.aggregator#1056
Use Import-Package in all wizards/templates and tests instead of relying on the name of the bundle that provides the javax.inject/annotation packages. Part of eclipse-platform/eclipse.platform.releng.aggregator#1056
to ensure it is provided and to maintain backwards compatibility until support for javax annotations is finally removed. Part of eclipse-platform#1056
to ensure it is provided and to maintain backwards compatibility until support for javax annotations is finally removed. Part of eclipse-platform#1056
to ensure it is provided and to maintain backwards compatibility until support for javax annotations is finally removed. Part of eclipse-platform#1056
Once the following PRs are submitted I consider the migration as completed:
Should we already open an issue in eclipse.platform about the eventual removal of support for javax-annotation in the injector? |
to ensure it is provided and to maintain backwards compatibility until support for javax annotations is finally removed. Part of #1056
This prevents spotbugs provided "javax.annotation" packages to be consumed by bundles that expect default (not spotbugs) "javax.annotation" packages that were previously shipped with "javax.annotation" bundle with SDK. The problem appears since 4.30 SDK doesn't ship "javax.annotation" bundle anymore, so spotbugs exported packages are taken as alternative if the application doesn't have other providers and in worst case they are not what applications actually expected to receive or cause dependency cycles (spotbugs requires some bundle that requires some other that imports "javax.annotation" package that is coming from spotbugs). The packages originally were needed by detectors shipped as bundles for IDE, but this is a very seldom case and in that case spotbugs-annotations is the better alternative. We should not export "wrong" javax packages anymore, it wasn't nice and it can cause only trouble now. See eclipse-platform/eclipse.platform.releng.aggregator#1056
This prevents spotbugs provided "javax.annotation" packages to be consumed by bundles that expect default (not spotbugs) "javax.annotation" packages that were previously shipped with "javax.annotation" bundle with SDK. The problem appears since 4.30 SDK doesn't ship "javax.annotation" bundle anymore, so spotbugs exported packages are taken as alternative if the application doesn't have other providers and in worst case they are not what applications actually expected to receive or cause dependency cycles (spotbugs requires some bundle that requires some other that imports "javax.annotation" package that is coming from spotbugs). The packages originally were needed by detectors shipped as bundles for IDE, but this is a very seldom case and in that case spotbugs-annotations is the better alternative. We should not export "wrong" javax packages anymore, it wasn't nice and it can cause only trouble now. See eclipse-platform/eclipse.platform.releng.aggregator#1056
Is there anything still to be done here? |
With #1510 being merged, I now consider this as resolved. |
- Always use closed version ranges [1.X,2) with a minor lower bound Part of eclipse-platform/eclipse.platform.releng.aggregator#1056
Rework the E4 InjectorImpl and introduce the AnnotationLookup class to handle a potential absence of javax-annotations at runtime. Print a warning if the 'old' javax-annotations are available at runtime to encourage users to migrate. The warning can be suppressed with the VM-property -Declipse.e4.inject.javax.warning=false Make the remaining imports of javax.inject/annotation packages optional. Annotations who's classes cannot be loaded at runtime are silently ignored by the JVM, as if they where not declared. Part of eclipse-platform/eclipse.platform.releng.aggregator#1056
- Only use Import-Package to for javax.annotation - Always use closed version ranges [1.X,2) with a minor lower bound - Remove unused dependencies Part of eclipse-platform/eclipse.platform.releng.aggregator#1056
This is an umbrella issue to coordinate and collect the migration steps of the
javax.inject
andjava.annotations
bundles to Jakarta.Migrate to the javax.inject|annotations bundles provided by Jakarta but with unchanged package names
Only use Import-Package with a closed version range to reference
javax.inject|annotations
in Plugin Manifests.javax.annotation
package provided by thecom.google.code.findbugs/jsr305
artifact. It is not used within the Eclipse platform but it guards down-stream consumers that could have it in their TP. E.g. Guava has a transitive dependency on it, so there is some chance it ends up in a TP if one is not careful.Refactor code to not relay on the bundle-symbolicName of the javax-annotations provider bundle so that it can be easaly exchanged
Replace javax-artifacts in the TP with the ones provided by Jakarta
Support Annotations from
jakarta.inject|annotations
in all processors in the Eclipse platformLooks like there are not more.
Migrate all uses of the
javax.inject|annotations
packages tojakarta.inject|annotations
I'll start to work on the steps and update this initial comment with the created PRs.
The text was updated successfully, but these errors were encountered: