refactor: restructure server packages & include Simple-ML core Jar

[lars-reimann]

Closes partially #327.

Summary of Changes

• Restructure server packages (flatter hierarchy)
• Include Simple-ML core Jar
  • Use this to generate code for function stubs

Testing instructions

• Structure should make sense, but no need to go through all the changes to names and imports
• Should still be able to generate code from the client
• Tests should still run

Additional notes

• I'll also update the stub creators for classes and modules in a future PR.
• The Jar will be pulled from Maven Central once it's published there.

[github-actions]

MegaLinter status: ✅ SUCCESS

Descriptor	Linter	Files	Fixed	Errors	Elapsed time
✅ CREDENTIALS	secretlint	yes		no	1.92s
✅ GIT	git_diff	yes		no	0.01s
✅ KOTLIN	ktlint	18	0	0	35.67s
✅ TYPESCRIPT	eslint	1	0	0	8.62s
✅ TYPESCRIPT	prettier	1	0	0	1.35s

See errors details in artifact MegaLinter reports on GitHub Action page
Set VALIDATE_ALL_CODEBASE: true in mega-linter.yml to validate all sources, not only the diff

[lars-reimann]

@paul0314 Reviewing this is not urgent. However, I'd ask you to base new branches on this one rather than on main.

[paul0314]

@paul0314 Reviewing this is not urgent. However, I'd ask you to base new branches on this one rather than on main.

I'll look over it tomorrow

[paul0314]

There seems to be 2 (nearly) identical "RenameAnnotationProcessorTest"-files in server.annotationProcessing and transformation. One should probably be deleted.

[lars-reimann]

There seems to be 2 (nearly) identical "RenameAnnotationProcessorTest"-files in server.annotationProcessing and transformation. One should probably be deleted.

Well spotted, thanks.

[paul0314]

Tests and adapter generation still worked and most of the changes were structural.

The codegen for Stub files in Kotlin was a bit challenging to read and I'd probably have some problems changing it in the future. However, I probably don't need to touch it in the near future, right?! Also, can I assume that all "createSml..."-methods from the CreatorsKt.class already return the desired Strings?!
I haven't really figured out what the use of methods like "createSmlDummyResource" / "createSmlCompilationUnit" /... is, but I don't think I need to, right?

[lars-reimann]

The codegen for Stub files in Kotlin was a bit challenging to read and I'd probably have some problems changing it in the future. However, I probably don't need to touch it in the near future, right?!

You don't. Whatever I convert to Kotlin is basically done from your side.

Also, can I assume that all "createSml..."-methods from the CreatorsKt.class already return the desired Strings?! I haven't really figured out what the use of methods like "createSmlDummyResource" / "createSmlCompilationUnit" /... is, but I don't think I need to, right?

I've recently added these methods in Simple-ML. They create yet another model, this time representing a Simple-ML program. This has some advantages over outputting strings directly:

• The model is validated, so errors like identifiers that contain dashes are immediately reported.
• Some value conversion happens. For example, identifiers that are at the same time Simple-ML keywords are automatically escaped. This also works in case I add new keywords in the future. Another example is that quotes in a string are escaped (" is replaced by \").
• The output is automatically formatted using the built-in Simple-ML formatter. Any improvements there will also affect the code generation here.
• All those components are already well tested, so it's not necessary to repeat that work here.

In general, the entire pipeline from the JSON files that are imported in the frontend to the outputted Python & Simple-ML files is a series of model-to-model transformations, with code generation at the end. This includes the annotation processors, which transform a package data model onto another package data model.