Migrate to Jakarta Equivalents #959
Conversation
Main changes that were outside of the simple scope of this change: * Migrated from spotify's data library to derive4j. The Spotify code generated code with `javax.annotation.Generated` which is no longer the correct package name for modern libraries. Derive4j is modern. * Migrated some tests to Junit5 and a newer version of Dropwizard which supports the Jakarta prefixes.
Generate changelog in
|
…er/migrate-jakarta * 'develop' of github.com:palantir/tracing-java: Excavator: Upgrades Baseline to the latest version (#958) Excavator: Upgrade gradle wrapper to the latest version (#957) Excavator: Update gradle-jdks infrastructure plugins (#956) Excavator: Upgrade dependencies (#955) Excavator: Upgrades Baseline to the latest version (#953) Excavator: Format Java files (#954)
There was a problem hiding this comment.
Overall LGTM, defer to @carterkozak on merge.
I am assuming we'll want to minimize the window of dual javax/jakarta support, so wondering if we should open source the gradle-jakarta-renames plugin as a bridge until everything migrates artifact coordinates. Looks like there a few other stragglers with javax dependencies in non-test classpaths:
- https://github.com/palantir/sls-packaging/blob/0f4f12160c525ef7e4dc6ea8ec517801d2b0d89a/versions.lock#L23
- https://github.com/palantir/encrypted-config-value/blob/f477d33ac3d353528c3c874c44f9e22f58815c36/versions.lock#L50-L56
- https://github.com/palantir/gradle-baseline/blob/6452ab19fcdb7cfa9c85b8a85e6eeec0bc3abd4d/versions.lock#L47-L48
- https://github.com/palantir/cassandra-manager/blob/1b37306e09325521bec1f385c2054bfbca48add1/versions.lock#L51
| dependencies { | ||
| api project(":tracing") | ||
| api "jakarta.ws.rs:jakarta.ws.rs-api" | ||
| api "javax.ws.rs:javax.ws.rs-api" |
There was a problem hiding this comment.
Should we @Deprecate everything in the non-Jakarta modules to flag these for migration?
There was a problem hiding this comment.
Maybe I follow up a commit to deprecate everything? I still have at least 6 other libraries that have to migrate first before I could even provide an alternative for someone to migrate to.
| import java.io.OutputStream; | ||
| import java.util.concurrent.Callable; | ||
|
|
||
| public final class JaxRsTracers { |
There was a problem hiding this comment.
I'm assuming anything currently using tracing-jaxrs should migrate to tracing-jaxrs-jakarta and we'll deprecate/remove the non-Jakarta implementations in a future major breaking release, right?
There was a problem hiding this comment.
Sort of? Generally, people should migrate as gradually more and more things will start breaking, to the point that eventually we can retire the legacy versions of these. But until that happens across all libraries, we can't really say: You should do this.
Does that make sense?
…-java into mglazer/migrate-jakarta * 'mglazer/migrate-jakarta' of github.com:palantir/tracing-java: Add generated changelog entries
|
As for the question on open sourcing the internal plugin, I don't have strong opinions on this. However, given the seemingly endless set of edge cases, we ended up opting for the more discoverable: "Copy/Paste" approach which while a fair bit more work, ends up being easier to maintain in the long term for some of these stable libraries, ie: we can just delete directories wholesale in the future, rather than having to make further modifications to the legacy projects. What we will very likely end up doing is writing automation to convert projects from the |
|
Released 6.13.0 |
|
Also, I realized I mis-spoke since we sort of have 2 jakarta-javax bridge plugins. The one you're thinking of probably makes sense to open source, but I think what I want to do first is add some functionality to it to ensure that component constraints are respected with regards to not having 2 tracing libraries on the classpath (for example). |
Before this PR
There was no jakarta equivalent for the libraries, this would prevent tracing-java from being used in modern services which upgrade to the Jakarta equivalents.
After this PR
==COMMIT_MSG==
Introduced jakarta equivalents of all modules which had a javax dependency
Additionally had to do a few things:
==COMMIT_MSG==
Possible downsides?