Skip to content
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

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

Open
yvanzo opened this issue Jun 19, 2024 · 6 comments
Labels
bug-external Issue concerns an external dependency jaxb4 Issue with jaxb 4.x

Comments

@yvanzo
Copy link

yvanzo commented Jun 19, 2024

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 #545.

@laurentschoelens
Copy link
Collaborator

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
Copy link
Author

yvanzo commented Jun 19, 2024

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

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
Copy link
Collaborator

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 : eclipse-ee4j/jaxb-ri@7188568
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
Copy link
Collaborator

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
Copy link
Author

yvanzo commented Jun 19, 2024

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
Copy link
Collaborator

@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.

@laurentschoelens laurentschoelens added jaxb4 Issue with jaxb 4.x bug-external Issue concerns an external dependency labels Jul 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug-external Issue concerns an external dependency jaxb4 Issue with jaxb 4.x
Projects
None yet
Development

No branches or pull requests

3 participants