chore(deps): update dependency org.jvnet.jaxb2_commons:jaxb2-basics to v0.13.1

[renovate]

This PR contains the following updates:

Package	Change	Age	Confidence
org.jvnet.jaxb2_commons:jaxb2-basics	0.6.0 → 0.13.1

---

Release Notes

highsource/jaxb2-basics (org.jvnet.jaxb2_commons:jaxb2-basics)

v0.13.1: Release

Compare Source

What's Changed

• Fix versions by @​mattrpav in #​156
• [#​154] First pass at fixing release and staging plugin fighting by @​mattrpav in #​155
• REVERTED: Update to Jakarta XML and use latest JAXB (3.0.0-M4). by @​brcolow in #​118
• [#​135] Add GH action to build on PRs and Merge by @​mattrpav in #​136
• [#​140] Update dependencies for latest jaxb v2 by @​mattrpav in #​141
• [#​142] Upgrade JUnit 4.13.2 by @​mattrpav in #​143
• [#​144] Upgrade to commons-io 2.11.0 by @​mattrpav in #​145
• [#​138] Update to use oss staging and release plugin by @​mattrpav in #​147
• [#​149] Update maven scm for release automation by @​mattrpav in #​150

New Contributors

• @​mattrpav is now the primary maintainer
• @​brcolow made their first contribution in #​118

Full Changelog: highsource/jaxb2-basics@0.12.0...0.13.1

v0.12.0: Version 0.12.0

Compare Source

Release notes

• Now works with JAXB/XJC 2.3.0 (see #​88). Unfortunately this means JAXB/XJC 2.2.x and ealier are no longer supported.
• Now works on Java 9 (see #​91).
• Removed JAXWS sample as jaxws-maven-plugin does not seem to work with XJC plugins.
• All issues fixed in this release

Backwards compatibility

• JAXB2 Basics no longer support JAXB/XJC 2.2.x and earlier. This is due to certain refactorings which were done in XJC (like the class Aspect was moved from the package com.sun.tools.xjc.model to the package com.sun.tools.xjc.outline). This essentially breaks compatibility of XJC plugins between XJC 2.2.x and 2.3.0. The only option I see is to develop and maintain two version of XJC plugins which is too much effort.
  This is why I've desided to support only one - most current version of XJC.
  You will need to upgrade your tools to use JAXB/XJC 2.3.0.
  For example, if you use maven-jaxb2-plugin, upgrade to version 0.14.0 or later.
• JAXB2 Basics can only be used with Java 1.7 and above. Java 1.6 and below is no longer supported.
• Java 9 is required to build the project.
• You can't combine modules built with pre-0.12.0 and post-0.12.0. For instance, cross-module equals or toString won't work.

v0.11.1: Version 0.11.1

Compare Source

Issues, fixed in this release

v0.11.0: Version 0.11.0

Compare Source

Release notes

• JAXBEqualsStrategy is now symmetic (#​22)
• Plugins now consider xjc:superClass (#​42)
• Plugins now consider default values (#​26, #​37, #​38, #​44, #​45, #​46, #​47)

All issues, fixed in this release

Backwards compatibility

This release mak break backwards compatibility.

Supporting default values

This release fixed a number of issues related to the support of default values (#​26, #​37, #​38, #​44, #​45, #​46, #​47).

In certain cases properties may have default values. For instance, it may correspond to an attribute with default value:

<xs:attribute name="testBoolean" type="xs:boolean" default="true"/>

Here's the getter that XJC generates for such a property:

    public boolean isTestBoolean() {
        if (testBoolean == null) {
            return true;
        } else {
            return testBoolean;
        }
    }

So the default value is not actually assigned to the field, it is returned from the getter if the field is not set.

With this release, default values are considered by the JAXB2 Basics plugins. You will typically get the following code for property accessors:

boolean theTestBoolean = (this.isSetTestBoolean()?this.isTestBoolean():true);

In previous versions, default values were ignored. This changes now and this change is not backwards compatible.

Considering "is value set" in strategies

Support for default values which was fixed in this version poses a new challenge.

Since we now consider default values of properties, how do you distinguish properties with explicitly set values versus properties with default values?

It is important to consider this difference. For instance, if you create a copy of an object, it wouldn't be correct to copy default values. Or if you merge two values, you'll probably choose explicitly assigned values over default values.

This means you have to know when the values was explicitly assigned and when this values is default.

To support this, it was necessary to extend existing strategis with parameters which describe if provided values are explicitly set in objects. A typical change is from:

public boolean copy(ObjectLocator locator, boolean value);

To:

public boolean copy(ObjectLocator locator, boolean value, boolean valueSet);

To support this change, we now have new strategies:

• org.jvnet.jaxb2_commons.lang.HashCodeStrategy2
• org.jvnet.jaxb2_commons.lang.EqualsStrategy2
• org.jvnet.jaxb2_commons.lang.ToStingStrategy2
• org.jvnet.jaxb2_commons.lang.CopyStrategy2
• org.jvnet.jaxb2_commons.lang.MergeStrategy2

Old strategies are now deprecated:

• org.jvnet.jaxb2_commons.lang.HashCodeStrategy
• org.jvnet.jaxb2_commons.lang.EqualsStrategy
• org.jvnet.jaxb2_commons.lang.ToStingStrategy
• org.jvnet.jaxb2_commons.lang.CopyStrategy
• org.jvnet.jaxb2_commons.lang.MergeStrategy

We also have new interfaces for schema-derived classes:

• org.jvnet.jaxb2_commons.lang.HashCode2
• org.jvnet.jaxb2_commons.lang.Equals2
• org.jvnet.jaxb2_commons.lang.ToSting2
• org.jvnet.jaxb2_commons.lang.Copy2
• org.jvnet.jaxb2_commons.lang.Merge2

Old interfaces are now deprecated:

• org.jvnet.jaxb2_commons.lang.HashCode
• org.jvnet.jaxb2_commons.lang.Equals
• org.jvnet.jaxb2_commons.lang.ToSting
• org.jvnet.jaxb2_commons.lang.Copy
• org.jvnet.jaxb2_commons.lang.Merge

Existing strategies now implement both new as well as old (deprecated) strategy interfaces:

• org.jvnet.jaxb2_commons.lang.DefaultHashCodeStrategy / org.jvnet.jaxb2_commons.lang.JAXBHashCodeStrategy
• org.jvnet.jaxb2_commons.lang.DefaultEqualsStrategy / org.jvnet.jaxb2_commons.lang.JAXBEqualsStrategy
• org.jvnet.jaxb2_commons.lang.DefaultToStringStrategy / org.jvnet.jaxb2_commons.lang.JAXBToStringStrategy
• org.jvnet.jaxb2_commons.lang.DefaultCopyStrategy / org.jvnet.jaxb2_commons.lang.JAXBCopyStrategy
• org.jvnet.jaxb2_commons.lang.DefaultMergeStrategy / org.jvnet.jaxb2_commons.lang.JAXBMergeStrategy

This means that new version of the JAXB2 Basics runtime should be backwards compatible with the old generated code. You don't necessarily need to regenerate your code to use the new runtime. However if you do regenerate your code, you'll have to use the new runtime. This may or may not be backwards compatible.

If you just generate code with JAXB2 Basics and use the default strategies provided in the JAXB2 Basics runtime, there should be no problem. However, if you have implemented your own strategies, you may need to update them.

v0.10.0: Version 0.10.0

Compare Source

Release notes:

• Generated "accessor"-style setter is now null-safe. See #​29.
• Generated equals methods are now symmetric (#​39, #​40). Many thanks to @​petega for fixes.
• Samples for CXF (#​24) and JAXWS (#​41).

All issues, fixed in this release

Backwards compatibility:

• Fixes for #​39 and #​40 are potentially not backwards-compatible. Generated code now compare classes instead of doing an instanceof. This makes generated code more correct but is a change.

v0.9.5: Version 0.9.5

Compare Source

Release notes:

• Issues, fixed in this release

v0.9.4: Version 0.9.4

Compare Source

This release features a few minor model enhancements:

• Added nillable information (#​25).
• Added qualified type name information (#​23).

v0.9.3: Version 0.9.3

Compare Source

Fixes and enhancements:

• jaxb2-simplify-plugin has now an option to pluralize the names of the generated collection properties. See issue #​18. Many thanks to Boris Marin for his contribution. Pluralization is turned off by default so this enhancement is backwards-compatible.

v0.9.2: Version 0.9.2

Compare Source

This release features:

• New plugins SimpleEquals Plugin and SimpleHashCode Plugin wich generate runtime-free reflection-free hashCode() and equals(...) methods. Many thanks to James Annesley for his ideas and help.
• New Plugin FixJAXB1058 which, well, fixes JAXB-1058.
• Moved to org.glassfish.jaxb artifacts (see issue #​16).
• Upgraded to JAXB version 2.2.11 (see issue #​15 ).
• Now using SLF4J for logging (see issue #​17).

v0.9.1: Version 0.9.1

Compare Source

v0.9.0: Version 0.9.0

Compare Source

Backwards compatibility:

• Simplify plugin will consider the cardinality of the target property. Previously, it always generated collection properties. Now it will consider if the source property is a collection or not. This may generate different code.

v0.8.4: Version 0.8.4

---

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[Naenyn]

I believe this and the other jvnet jaxb-related PRs need jakarta jaxb and java 11+.