...internal.Iterables is used in Asserts generated by assertj-assertions-generator (java9)

[RainerGanss]

Summary

Hi,
I am migrating from java 8 to 17 and had big trouble getting the generated assertions to work (actually is does not work at all, is it dead?)

But even with great hacks I cannot get arround that the generated code imports the internal class org.assertj.core.internal.Iterables which is (of course) not exported by assertj-core. Could this become public? Or could the code-generator be updated? Which btw has medium CVEs in it's dependencies.

Example

import org.assertj.core.internal.Iterables;
//this is part of the generated code
public YAssert hasXs(X... xs) {
    // check that actual Y we want to make assertions on is not null.
    isNotNull();

    // check that given X varargs is not null.
    if (x== null) failWithMessage("Expecting x parameter not to be null.");

    // check with standard error message, to set another message call: info.overridingErrorMessage("my error message");
    Iterables.instance().assertContains(info, actual.getX(), xs);

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

Package 'org.assertj.core.internal' is declared in module 'org.assertj.core', which does not export it to module 'my.assertions'

In other words: Is does not compile in Java > 8 which renders the complete code generation useless.

[scordio]

Thanks for reporting it, @RainerGanss. The assertions generator projects have been neglected due to lack of capacity, but we'll do our best to refresh them.

Just to make sure we aim for the right target, how are you using the assertions generator? Is it via the Maven or Gradle plugin?

[RainerGanss]

Hi @scordio,

I am using the maven plugin. I am right now customizing the code generation via the templates to avoid the call to the internal API.

Thx for the quick response. Once I am done with the template fiddling I'll attach it here for other fokes. It's not pretty though...

[RainerGanss]

my_has_elements_assertion_template_for_iterable.txt

I replaced the calls to the internal API with public ones that I hope do the same...

I spent many hours yesterday trying to get this to work and on that journey encountered serveral severe bugs in this plugin. I am migrating more than a dozent projects to java 17 and the hacks I had to make to get this to "work" are unbearable.

For that reason I have decided to completely remove generated assertions from all my projects. Sad to see this project die...

[scordio]

The usage of the internal API is also something we faced with assertj-guava and refactoring is ongoing to avoid it.

The same strategy could be applicable also for the assertions generator.

[joel-costigliola]

I still like the assertion generator but indeed we have not the capacity to really maintain it.
The issue seems related to the java module, a combination of the generator using internal stuff (which is bad) and assertj-core not exporting them.

[RainerGanss]

I loved the generator used it widely. For now I will run it one last time, hack the hell out of the code to get it work with java > 9, check it in under src/main and will either migrate away from the plugin completely or wait and hope that it gets fixed.

In case you wanna give the plugin some love, here are some other issues:

• In the documentation here https://joel-costigliola.github.io/assertj/assertj-assertions-generator-maven-plugin.html#custom-templates for assertionClass the closing tag is missing the /
  • In general is the complete type definition for TemplateType missing in the plugin.xml -> no auto completion in the IDE
• Both entryPointClassPackage and generateAssertionsInPackage are broken if the model is not in one package and has inter-package dependencies (imports are missing and return types are wrong in the Assertions and SoftAssertions classes.

In general it would be great if the generator + the maven/gradle plugins would specifically be targeted to run in projects > 9. There is a lot more to be considered... It took me 6 hours and plenty of hacks just to get it compiling - let alone executing tests based on those assertion classes.

Cheers guys,
Rainer

[scordio]

@joel-costigliola I would also evaluate merging all the generators in a Maven multi-module, it could simplify the overall maintenance