Migrate to Jakarta EE namespace about alpine HOT 3 OPEN

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 #1. Lots of annotations have changed, causing increased manual refactoring effort, especially on the Dependency-Track side.

from alpine.

@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
• 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?

from alpine.

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.

from alpine.