latest version doesn't compile

[christian-frei]

compiling the testsuite from a fresh start
fails due to the missing model classes, e.g. de.gematik.tim.test.models.RoomDTO.

to reproduce this issue, clean the local m2 repository and run

mvn clean
mvn verify

my settings are

 mvn -version
Apache Maven 3.9.9 (8e8579a9e76f7d015ee5ec7bfcdc97d260186937)
Maven home: /opt/homebrew/Cellar/maven/3.9.9/libexec
Java version: 23.0.2, vendor: Homebrew, runtime: /opt/homebrew/Cellar/openjdk/23.0.2/libexec/openjdk.jdk/Contents/Home
Default locale: en_CH, platform encoding: UTF-8
OS name: "mac os x", version: "15.2", arch: "aarch64", family: "mac"

[INFO] --- compiler:3.7.0:compile (default-compile) @ TI-Messenger-Testsuite ---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 205 source files to /Users/christian/dev/kosyma/TI-Messenger-Testsuite/target/classes
[INFO] Some messages have been simplified; recompile with -Xdiags:verbose to get full output
[INFO] -------------------------------------------------------------
[ERROR] COMPILATION ERROR : 
[INFO] -------------------------------------------------------------
[ERROR] /Users/???/dev/kosyma/TI-Messenger-Testsuite/src/main/java/de/gematik/tim/test/glue/api/TestdriverApiEndpoint.java:[235,12] constructor TestdriverApiInteraction in class de.gematik.tim.test.glue.api.TestdriverApiInteraction cannot be applied to given types;
  required: no arguments
  found:    net.serenitybdd.screenplay.rest.interactions.RestInteraction,java.util.List<java.lang.Class<? extends de.gematik.tim.test.glue.api.TestdriverApiAbility>>
  reason: actual and formal argument lists differ in length
... snip
...and many more

[Beff42]

I'm not able to reproduce this. Even with a fresh and clean clone directly from Github everything compiles fine.

Both errors (missing models and TestdriverApiEndpoint.java issue) sound like there's something off with the api. We generate the models directly from the openAPI file (src/main/resources/api/TiMessengerTestTreiber.yaml). For this we use the openapi-generator-maven-plugin (see pom.xml).
In the TestdriverApiEndpoint class we create an easy to use enum from those paths.

Did you maybe change some things in the openAPI document for testing purpose? This might break the model generation.
In the latest version we did add some new endpoints to the api and we did a rename of some endpoints. So in case you keep a local copy you will have to merge those changes.

[christian-frei]

both me and my colleague couldn't compile this. did you try to delete the local .m2 repository before reproducing the error?

i use maven 3.9.9, my colleague uses 3.9.3. both use openjdk 23

[christian-frei]

hi Stefanie

i have fixed the issue.
can i create a pull request so that you can merge this into your pom.xml?

[chrkaatz]

That would be great, if the fix could go upstream.

[Beff42]

I checked again, also after deleting the .m2 repository and still have no issues.

But a PR is very welcome! If you prefer and if the fix only concerns the pom.xml you can also post it here and we will incorporate it into the next Release.
I'll have a look at the solution and will check for regressions.

Are you both using macOS?

[christian-frei]

a PR would be better. because i also upgraded the mvn plugin versions and otherwise i have to post here so many lines of code.

and yes, we both use macos

 mvn -version
Apache Maven 3.9.9 (8e8579a9e76f7d015ee5ec7bfcdc97d260186937)
Maven home: /opt/homebrew/Cellar/maven/3.9.9/libexec
Java version: 23.0.2, vendor: Homebrew, runtime: /opt/homebrew/Cellar/openjdk/23.0.2/libexec/openjdk.jdk/Contents/Home
Default locale: en_CH, platform encoding: UTF-8
OS name: "mac os x", version: "15.2", arch: "aarch64", family: "mac"

[christian-frei]

can you please grant me access to the repo so that I can create a PR?

[Beff42]

Sorry, I wasn't aware, that PRs are blocked. It's an organisation setting of Github it seems. We're working on it, I'll let you know once we have a solution.

[Beff42]

Ok mystery solved. PRs are always blocked for organisations, but opening a PR from a fork should still be possible: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request-from-a-fork

So as far as I can see you have a fork already. When you are making changes, it is recommended that you create a new branch for this purpose, based off of the main branch. After your changes are pushed back to your forked repository, you can then create a pull request from there.

If that works for you, I will update the contributing.md accordingly, so it is better documented that PRs can only be opened from forks.

[christian-frei]

that worked!
please have a look at my PR.
i don't think you have to change anything regarding this process. creating PR from forks is perfectly fine. it would be helpful though, if this would be mentioned in the developers guide.

[christian-frei]

i have the feeling my problems come from the maven version which i use.
3.9.9

i compiled the testsuite using the docker image maven:3.6.3-openjdk-17-slim and that worked

however compiling the testsuite with a docker image that reflects the setup of my computer maven:3.9.9-eclipse-temurin-23-alpine shows problems during compilation.

maybe you want to update your developer environments to the latest maven and java version and try to reproduce the error.

[Beff42]

Hi Christian,

yeah, we use Maven version 3.6.3. We will update soon to 3.8.6, but because of time limitations this will happen after the ePA and Pro registrations (probably somewhere near the end of this year).
There are no plans to update Java yet, but we might as well bump Java in the process.
So thank you for the extra information, I will come back to this issue once we do the mayor updates! Just letting you know, that this will take some time.

[chrkaatz]

It would be nice if such versions would be clearly written down and/or possibly coming with a dockerfile if there are fixed version requirements.

[Beff42]

Good morning,

you can find the Java version in the parent-pom.xml, the Maven version in the mvnvm.properties and both again in the Dockerfile. While the entrypoint.sh is still in the works you can use those as examples. Once we have a more complete docker set-up we will provide it too.

Unfortunately due to the rearrangement of our pom structure I was testing not actually all the changes provided in the related PR. In the upcoming release I will have to revert the addition of the compileSourceRoots, since they are not working in our environments.

Feel free to use your own local pom file with the changes necessary for your development environment. You can e.g. add a file local-pom.xml, then merging incoming changes into your fork will probably not conflict.

One disclaimer:
Locally you can change the environment as you like. For registration we will of course run the test suite and related components in the state they are provided on Github against your test driver. Since we run them from remote that should not make a difference, but I want to state this here clearly.

Suggestions and improvements are very welcome and we will try to incorporate whenever it's possible!
Thanks for you understanding.

Best Stefanie