What repo should we follow?

[hazendaz]

I think https://github.com/evolvedbinary/jvnet-jaxb-maven-plugin should be flagged archived with notes to use this repo. Issues not open over there so hoping with your recent integration you could reach author to do that.

Now, then the upstream is problematic. Its moved again without any regard for far more support here. Maybe they just don't know. Opening similar issue there. For now this seems the most feature complete because it supports JakartaEE. The upstream still does not. Even mavens mojohaus variation supports jakartaEE. So I think this needs ironed out as its a bit confusing to users IMHO.

[phax]

Well, the history is simple:

• highsource JAXB plugin seems to be stalled
• I needed a fix and forked it
• elaboratebytes wanted JAXB 3.0 support and I don't - they agreed to take over
• I needed support for JAXB 4.0 and they didn't - so I took it back

It's confusing, I agree.

Edit: changed "highsource" to "elaboratebytes" in the third bullet point

[hazendaz]

Thank you for the answer, this will certainly help others. Jaxb and the like are a tangled mess in general. We will continue using your version as its better future proofed.

[laurentschoelens]

Well, the history is simple:

* highsource JAXB plugin seems to be stalled

* I needed a fix and forked it

* highsource wanted JAXB 3.0 support and I don't - they agreed to take over

* I needed support for JAXB 4.0 and they didn't - so I took it back

It's confusing, I agree.

Hi @phax what fix did you need on highsource plugin ?
We are planning to do jaxb3 and jaxb4 support (both using jakarta packages) very soon, so if you found something that needed to be fixed on original project that is not based on jakarta migration, could you please tell us what it was or even more, provide a PR to fix it :)
Thanks

[phax]

Hi @laurentschoelens, with "we" you mean you are now part of the highsource committers?
My original intent is and was highsource#173

hth, Philip

[laurentschoelens]

I'm not (still) direct committer to highsource repositories (in comparison to mattprav) but I'm in direct contact with him and provide many PR to make the project go ahead with issues and migration.
I've seen you provide a PR (which you closed without merge) and the initial issue was open in 2019.
I'll try look at it and see if the issue is still opened on the project since many things changed from then (jdk11 and jdk17 support for example).
Maybe we'll provide a similar PR as you first do to fix and see if there's no other issue raised.

For example, I'm trying to work on highsource#244 which is a very old issue but I've tried to fix with a simple change on catalog resolution handling.

[laurentschoelens]

Hi @laurentschoelens, with "we" you mean you are now part of the highsource committers? My original intent is and was highsource#173

hth, Philip

Hi @phax
Waiting for my last PR to be merged and then will provide the same PR as yours for highsource/jaxb-tools project for issue highsource#173 since no problems found by integrating your code in plugin.
I'll try to keep you updated with it.

[phax]

Excellent, thank you

[laurentschoelens]

Hi @phax

PR provided to highsource repo but with modification in code since it may fails if you get files like
a.xsd / b.xsd / common-a.xsd and includes them in same order
it may return a.xsd / common-a.xsd / b.xsd -> which is not the correct order you specified.
It should be integrated in future milestone of jaxb-maven-plugin (2.0.4) and then in jakarta's version (v3 and v4)

Regards

[phax]

Okay thanks. What are your plans on Jakarta 3 + 4 integration? Will you add it as well?

[laurentschoelens]

Yes. We're consolidating all jaxb-related repos in jaxb-tools main repository.
Once done, we'll start migrating to jakarta 3 and then jakarta 4 with jdk11 baseline for the latest

[laurentschoelens]

@phax : in fact I finally find out why you had your issue.

codehaus-plexus/plexus-utils#70 :

File.list() does not guarantee any order: Reproducible Builds require reproducible scan result
Optionally sorting entries while scanning will provide a useful feature

The plexus-utils DirectoryScanner utils does not guarantee any order in returned files.
Knowing that, I've rewrite your PR in order to be sure that the includes order is kept after plexus-utils returns the file, even with wildcard characters, since I'll consider that if you put b/* in second position of includes, that means that the xsd files in b directory have to be loaded before whatever comes after that.

You can see the PR that shall be included in 2.0.4 release : highsource#287