Migrate to Jakarta EE namespace

[nscuro]

The current stack is based on:

• Java EE (javax.servlet.* namespace)
• Jersey 2.x
• Jetty 9.x

Community support for Jetty 9.x has ended as of June 1st 2022. There will still be security patches, but it's a good indicator that we should look into updating it. Jetty 11, the latest major release of Jetty, does not support legacy Java EE APIs anymore and is based on the new Jakarta EE APIs instead.

The move to Jakarta requires an upgrade of Jersey to 3.x (migration guide here).

I'm sure there are more dependencies and breaking changes that will pop up once work on this is started.

[nscuro]

Some additional notes:

1. OpenRewrite has a recipe for the migration to Jakarta EE 9: https://docs.openrewrite.org/recipes/java/migrate/jakarta/javaxmigrationtojakarta. I tested it already and it works great, both for the Alpine and Dependency-Track codebase.

mvn -U org.openrewrite.maven:rewrite-maven-plugin:run \
  -Drewrite.recipeArtifactCoordinates=org.openrewrite.recipe:rewrite-migrate-java:LATEST \
  -Drewrite.activeRecipes=org.openrewrite.java.migrate.jakarta.JavaxMigrationToJakarta

2. swagger-core 1.x does not support Jakarta. We have to upgrade to 2.x, which also changes the OpenAPI spec from 2.x to 3.x. This means we have an implicit dependency on Add support for OpenAPI 3.0 #1. Lots of annotations have changed, causing increased manual refactoring effort, especially on the Dependency-Track side.

[nscuro]

@stevespringett What is your current opinion on how to deal with Alpine's OpenAPI integration?

• As mentioned above, updating the Swagger library is a precondition for moving forward with the Jakarta migration
  • Updating swagger-core will cause significant refactoring efforts in DT due to all the annotation changes
• Migrate Swagger to OpenAPI 3 DependencyTrack/dependency-track#840 states that auto-generated OpenAPI docs should be removed altogether from Alpine and DT, and switching to manually-maintained OpenAPI docs instead

Should we upgrade swagger-core, or should we drop it completely from Alpine?

I propose to:

1. Remove Swagger / OpenAPI from Alpine entirely (would this require a Alpine v3 release?)
2. Export the current auto-generated Swagger doc from DT
3. Remove all Swagger annotations from DT
4. Serve exported swagger.json in DT via static file servlet

In a next step, we can start working on DependencyTrack/dependency-track#840:

• As this will be a larger task, we can ship the new OpenAPI v3 manifest in addition to the legacy Swagger v2 file
  • e.g. /api/swagger.json and /api/openapi-v3.yaml
• OpenAPI v3 manifest will be worked on iteratively until it covers the entire API surface
• Once coverage reaches 100%, remove legacy swagger.json

Thoughts?

[stevespringett]

That sounds like a solid approach. We will eventually need to determine, possibly through a PR check, of modifications made to a resource which do not include modifications to the api docs. Keeping the api docs in sync with the code may be a challenge, but at least we'll have accurate docs at some point.

Alpine v3 sounds good to me.