allow the jakarta version of `@Generated` instead of the javax one.

[Zegveld]

all javax modules are being replaced with jakarta, this includes @javax.annotation.Generated. This is replaced by @jakarta.annotation.Generated, allow users to choose which annotation they want on the generated classes.

(Related to assertj/assertj-generator#194 )
(I'm also making a PR for this one)

[dmitry-weirdo]

Yes, this is very important, the tests are broken when migrating to Spring Boot 3 because of this annotation.

Is there a new version of the plugin probably? Version 2.2.0 was released at March 2019 (see mvn repo) 😱 🙀

[dmitry-weirdo]

As a workaround for the current plugin version 2.2.0, I overrode the following templates in the plugin configuration,

The template files are taken from here, and just replaced @javax.annotation.Generated(value="assertj-assertions-generator") with @jakarta.annotation.Generated(value="assertj-assertions-generator")

                    <templates>
                        <!-- specify the base directory where to look for templates -->
                        <!-- !!! No file separator at the end, else it will still silently take the default templates -->
                        <templatesDirectory>${project.basedir}/src/test/resources/assertj/templates</templatesDirectory>

                        <assertionClass>_ins_custom_assertion_class_template.txt</assertionClass>
                        <softEntryPointAssertionClass>_ins_soft_assertions_entry_point_class_template.txt</softEntryPointAssertionClass>
                        <junitSoftEntryPointAssertionClass>_ins_junit_soft_assertions_entry_point_class_template.txt</junitSoftEntryPointAssertionClass>
                        <bddEntryPointAssertionClass>_ins_bdd_assertions_entry_point_class_template.txt</bddEntryPointAssertionClass>
                        <assertionsEntryPointClass>_ins_standard_assertions_entry_point_class_template.txt</assertionsEntryPointClass>
                    </templates>

[scordio]

Hi everyone, there is now assertj-assertions-generator 3.0.0-M3 which requires Java 17 and has improvements in this direction.

To use that version with the current Maven plugin, something like the following should be possible:

<plugin>
  <groupId>org.assertj</groupId>
  <artifactId>assertj-assertions-generator-maven-plugin</artifactId>
  <version>2.2.0</version>
  <executions>
    ...
  </executions>
  <configuration>
    ...
  </configuration>
  <dependencies>
    <dependency>
      <groupId>org.assertj</groupId>
      <artifactId>assertj-assertions-generator</artifactId>
      <version>3.0.0-M3</version>
    </dependency>
  </dependencies>
</plugin>

We will combine both assertj-assertions-generator-maven-plugin and assertj-assertions-generator into a multimodule to streamline the setup.

[dmitry-weirdo]

@scordio Very nice, but I don't understand how to use new assertj-generator as a maven plugin?
The readme from https://github.com/assertj/assertj-generator links to an outdated documentation of assertj-assertions-generator-maven-plugin 2.2.0 plugin.
Is there a possibility to use the new version as a maven plugin, or only as a CLI tool?

Update: I executed by adding a dependency as listed above, but still the generated annotations are with javax.annotation.generated :( Any additional configurations required?

[scordio]

The readme from https://github.com/assertj/assertj-generator links to an outdated documentation of assertj-assertions-generator-maven-plugin 2.2.0 plugin.

Indeed, sorry about it. Renewing the docs is on our to-do list.

Update: I executed by adding a dependency as listed above, but still the generated annotations are with javax.annotation.generated :( Any additional configurations required?

That's strange, it should use the appropriate annotation.

Do you have a project I could look at?

I plan to move the Maven plugin and release a new version for both, but it will require some time as we need to adapt these projects to the new Central Portal first.

[schmuka0501]

Hi @scordio ,

let me thank you first for your work. Because I was looking a long time that we can use records with AssertJ and can remove the templates.

The new version works perfectly in our project. Unfortunately, I found a bug with M4/M5. But maybe isn't bug, because our clever programming isn't that clever ;). Should I open an issue for that?

Short summary of the bug

• We have an Interface X which has method called id()
• We implement this Interface X in several classes. The typical implementation is
• String id = "someId"; public String id() { return id; }
• When AssertJ creates the *Assert classes it creates the method hasId twice, e.g.

 /**
   * Verifies that the actual Data's id is equal to the given one.
   * @param id the given id to compare the actual Data's id to.
   * @return this assertion object.
   * @throws AssertionError - if the actual Data's id is not equal to the given one.
   */
  public S hasId(String id) {
    // check that actual Data we want to make assertions on is not null.
    isNotNull();

    // overrides the default error message with a more explicit one
    String assertjErrorMessage = "\nExpecting id of:\n  <%s>\nto be:\n  <%s>\nbut was:\n  <%s>";

    // null safe check
    String actualId = actual.getId();
    if (!Objects.deepEquals(actualId, id)) {
      failWithMessage(assertjErrorMessage, actual, id, actualId);
    }

    // return the current assertion for method chaining
    return myself;
  }

  /**
   * Verifies that the actual Data's id is equal to the given one.
   * @param id the given id to compare the actual Data's id to.
   * @return this assertion object.
   * @throws AssertionError - if the actual Data's id is not equal to the given one.
   */
  public S hasId(String id) {
    // check that actual Data we want to make assertions on is not null.
    isNotNull();

    // overrides the default error message with a more explicit one
    String assertjErrorMessage = "\nExpecting id of:\n  <%s>\nto be:\n  <%s>\nbut was:\n  <%s>";

    // null safe check
    String actualId = actual.id();
    if (!Objects.deepEquals(actualId, id)) {
      failWithMessage(assertjErrorMessage, actual, id, actualId);
    }

    // return the current assertion for method chaining
    return myself;
  }

Simple workaround
Renaming the method id() to getId() solved the problem and all Assertions classes are created correctly.

[scordio]

Hi @schmuka0501, your description seems like a bug to me, so I've raised assertj/assertj-generator#278 to track the analysis.