cleaner jars without Xtext and Xtend source and mapping files

[NiklasRentzCAU]

No description provided.

[sailingKieler]

@NiklasRentzCAU what's the reason for this?

This way you kill debuggability of Xtend-based classed in Xtend...

[NiklasRentzCAU]

Whenever any (external) product such as the KIELER language server in the semantics repository pulls KLighD as a dependency it will include the Xtend sources and the source mapping files in its executable jar, where they are not needed. For debuggability there are the source jars that are packaged alongside the build and provided on the P2 update sites and the Maven Central releases. These source jars have been used for debugging plain Java files previously and also include these Xtend and source mapping files, so they still work for debugging. This is also consistent with the jar structure of other projects, such as Sprotty.
Is there anything I missed in understanding these jars?

[sailingKieler]

Did you test the debugging experience with the setup you propose, i.e. with having the KLighD artifacts installed as dependencies?

Actually, I'm not super sure, whether the ._trace files are needed for debugging, or whether all information is attached to the instrumented class files. I wouldn't count on the latter.

What's the benefit of kicking them out? Disk space is probably not a critical issue, isn't it? Esp. since there're just a few of those files.

I'm not sure whether the comparison with Sprotty is valid, as it uses a totally different setup, and Xtend is only used for defining data types there (except the SModelCloner). Debuggability has never been a requirement there I guess.

[sailingKieler]

I just checked with some Xtext/Xtend bundles and it's like you proposed, so go ahead. 🚀

[NiklasRentzCAU]

I just checked it again, debugging works, it will automatically pull the .sources jar and take the Java/Xtend sources from there and debug correctly.
When I looked at our current language server jar that pulls the binaries from KLighD and other projects, I noticed that some source files were included, although we do not pull the sources into this executable jar. All sources added together sum up to multiple megabytes that are distributed, e.g. in the KIELER VS Code extension, that are not necessary, therefore I found this to be a consistent and easy way to fix it.
I will merge this soon when we planned to do new releases for the entire project chains (possibly next week).