highsource / jaxb-tools

The most advanced JAXB2 Maven Plugin for XML Schema compilation.
Other
422 stars 98 forks source link

jaxb-maven-plugin > 4.0.0 doesn’t mention “Jakarta XML Binding” anymore in Javadoc #547

Open yvanzo opened 2 months ago

yvanzo commented 2 months ago

I tried to update jaxb-maven-plugin version from 4.0.0 to a more recent version (4.0.2, 4.0.3, 4.0.6) and noticed that the generated Javadoc comments are mentioning “JAXB” again instead of “Jakarta XML Binding”.

For the pom.xml, please see https://github.com/metabrainz/mmd-schema/tree/61108f9cc220d4561154244715a886b7ceabb0a1/brainz-mmd2-jaxb

I’m just reporting this curiosity in case it might be revealing a deeper regression, possibly related to the issue https://github.com/highsource/jaxb-tools/issues/545.

laurentschoelens commented 2 months ago

Hi @yvanzo Thanks for the report

Could you tell me one file generated where I can spot the difference ?

One suggestion regarding your pom.xml : why do you generate java code under src/main/java ?

yvanzo commented 2 months ago

Could you tell me one file generated where I can spot the difference ?

See for example those two lines: https://github.com/metabrainz/mmd-schema/blob/61108f9cc220d4561154244715a886b7ceabb0a1/brainz-mmd2-jaxb/src/main/java/org/musicbrainz/mmd2/AliasList.java#L62-L63 and our earlier switch to v4: https://github.com/metabrainz/mmd-schema/commit/ea31b79319ad9d436e3079709c8d197e8011a6ce#diff-752754302fcb7bb00fe65daadc2b90cfdaa4395d9164073998939ba977b2e2f8

One suggestion regarding your pom.xml : why do you generate java code under src/main/java ?

No particular reason AFAIK but I’m not the original author either. I’m open to any suggestion that can improve maintainability.

laurentschoelens commented 2 months ago

Could you tell me one file generated where I can spot the difference ?

See for example those two lines: https://github.com/metabrainz/mmd-schema/blob/61108f9cc220d4561154244715a886b7ceabb0a1/brainz-mmd2-jaxb/src/main/java/org/musicbrainz/mmd2/AliasList.java#L62-L63 and our earlier switch to v4: metabrainz/mmd-schema@ea31b79#diff-752754302fcb7bb00fe65daadc2b90cfdaa4395d9164073998939ba977b2e2f8

Thanks for pointing me the list getter

The problem came from jaxb-ri change here : https://github.com/eclipse-ee4j/jaxb-ri/commit/7188568a522805ac829ed082ba398ee98234c40e The message set in properties is not the exact same message from java file.
I'll see to fix that.

One suggestion regarding your pom.xml : why do you generate java code under src/main/java ?

No particular reason AFAIK but I’m not the original author either. I’m open to any suggestion that can improve maintainability.

Generating java code from XSD in src/main/java folder makes it available in your source control

So each time your config change, you'll have to commit generated files also.

By default, generated files goes into target/generated-sources/xjc folder, which won't be commited and pushed into git working-tree but will then be available as source files in mvn build.

It depends of your use-case

laurentschoelens commented 2 months ago

PR done in jaxb-ri to fix javadoc reference and restore the Jakarta XML Binding reference. After that is merged and released, we'll need to update this in jaxb-tools to fix this issue

yvanzo commented 2 months ago

Generating java code from XSD in src/main/java folder makes it available in your source control So each time your config change, you'll have to commit generated files also. By default, generated files goes into target/generated-sources/xjc folder, which won't be commited and pushed into git working-tree but will then be available as source files in mvn build. It depends of your use-case

In our case, we have to patch some of the generated Java source files through a script, so we cannot just use Maven, which is very unfortunate indeed.

mattrpav commented 2 months ago

@yvanzo I suggest executing the script that does class patching as a Maven step after the generated classes are processed. This way, the classes still remain in target/generated-sources and the script execution is tied to the Maven lifecycle which would be best practice.

Checkout the exec-maven-plugin to run the script you have now, or consider converting the changes to be done via Java.