Use Terra-- 2.0

[SmylerMC]

Features

• All Terra-- files are now stored within the Terra+- plugin directory
  • HTTP cache
  • Configuration files (osm.json5, custom elevation dataset directory, custom tree coverage dataset directory)
• README.md files are now dropped in dataset configuration folders, giving some hints on how to use them
• Proper HTTP user agent identifying Terra+- (includes plugin ID and version, Terra-- name and version, and plugin URL)

Internal changes

• Adjust existing code to work with Terra-- 2.0
• Remove the many unused dependencies
• Remove dependencies that bring very little (LZMA/XZ)

[Zoriot]

LGTM
Haven't tested the koppen_map, but I guess you have just recompressed it. Long Term, I think this shouldn't part of the Repo and fetched when needed via CDN, or use a similar system like heights.

One thing, it would make sense to me to keep the readmes for heights and tree_cover in the t-- repo and write it a bit more general. i think that can be used for every "plattform" & is also more coupled to t-- then t+-. Why haven't you done that?

[Zoriot]

Your PR introduces a new warning when building, please fix this.
Also if you want/can fix the other build warnings.

[WARNING] Unknown enum constant com.fasterxml.jackson.annotation.JsonInclude.Include.NON_EMPTY
Reason: Class file for com.fasterxml.jackson.annotation.JsonInclude$Include not found
[WARNING] Unknown enum constant com.fasterxml.jackson.annotation.JsonCreator.Mode.PROPERTIES
Reason: Class file for com.fasterxml.jackson.annotation.JsonCreator$Mode not found
[WARNING] Unknown enum constant com.fasterxml.jackson.annotation.JsonInclude.Include.NON_EMPTY
Reason: Class file for com.fasterxml.jackson.annotation.JsonInclude$Include not found
[WARNING] Unknown enum constant com.fasterxml.jackson.annotation.JsonCreator.Mode.PROPERTIES
Reason: Class file for com.fasterxml.jackson.annotation.JsonCreator$Mode not found
[WARNING] Unknown enum constant com.fasterxml.jackson.annotation.JsonInclude.Include.NON_EMPTY
Reason: Class file for com.fasterxml.jackson.annotation.JsonInclude$Include not found
[WARNING] Unknown enum constant com.fasterxml.jackson.annotation.JsonCreator.Mode.PROPERTIES
Reason: Class file for com.fasterxml.jackson.annotation.JsonCreator$Mode not found
[WARNING] Unknown enum constant com.fasterxml.jackson.annotation.JsonInclude.Include.NON_EMPTY
Reason: Class file for com.fasterxml.jackson.annotation.JsonInclude$Include not found
[WARNING] Unknown enum constant com.fasterxml.jackson.annotation.JsonCreator.Mode.PROPERTIES
Reason: Class file for com.fasterxml.jackson.annotation.JsonCreator$Mode not found
[WARNING] Unknown enum constant com.fasterxml.jackson.annotation.JsonInclude.Include.NON_EMPTY
Reason: Class file for com.fasterxml.jackson.annotation.JsonInclude$Include not found
[WARNING] Unknown enum constant com.fasterxml.jackson.annotation.JsonCreator.Mode.PROPERTIES
Reason: Class file for com.fasterxml.jackson.annotation.JsonCreator$Mode not found
[INFO] <user>/IdeaProjects/TerraPlusMinus/src/main/java/de/btegermany/terraplusminus/commands/TpllCommand.java: Some input files use or override a deprecated API.
[INFO] <user>/IdeaProjects/TerraPlusMinus/src/main/java/de/btegermany/terraplusminus/commands/TpllCommand.java: Recompile with -Xlint:deprecation for details.

[SmylerMC]

On Koppen map LZMA to GZIP

Haven't tested the koppen_map, but I guess you have just recompressed it.

Pretty much. It you have a local copy of the branch, you can verify the data with the following set of commands:

git checkout master
cat src/main/resources/koppen_map.lzma | unlzma | sha256sum
git checkout deps/update
cat src/main/resources/koppen_map.gz | gunzip | sha256su

The checksum should be 4f9d4c7f8e197acaaa5b3f890c422676374dbb64aff5e500bb3416bc3c8f7509 in both cases.

On the custom dataset READMEs

One thing, it would make sense to me to keep the readmes for heights and tree_cover in the t-- repo and write it a bit more general. i think that can be used for every "plattform" & is also more coupled to t-- then t+-. Why haven't you done that?

That's a good point, but if they were to be added upstream, I would prefer it that happened in Terra++ and it would then make it's way to Terra-- and Terra+-

I do however believe that Terra+- could benefit from having its own documentation that takes into account its specificity (e.g. files are not in the same places), and that would benefit from keeping the files here. What's your take on this?

On the Jackson warnings

Your PR introduces a new warning when building, please fix this. [...]

[WARNING] Unknown enum constant com.fasterxml.jackson.annotation.JsonInclude.Include.NON_EMPTY
Reason: Class file for com.fasterxml.jackson.annotation.JsonInclude$Include not found
[WARNING] Unknown enum constant com.fasterxml.jackson.annotation.JsonCreator.Mode.PROPERTIES
Reason: Class file for com.fasterxml.jackson.annotation.JsonCreator$Mode not found
[...]

We are hitting a specific JDK bug here. The warnings should be harmless, but I have added back Jackson as an explicit dependency to get rid of them.

On the TPLL deprecation warning

Your PR introduces a new warning when building, please fix this. [...]

[...]
[INFO] <user>/IdeaProjects/TerraPlusMinus/src/main/java/de/btegermany/terraplusminus/commands/TpllCommand.java: Some input files use or override a deprecated API.
[INFO] <user>/IdeaProjects/TerraPlusMinus/src/main/java/de/btegermany/terraplusminus/commands/TpllCommand.java: Recompile with -Xlint:deprecation for details.

This is caused by the use of org.bukkit.ChatColor in TpllCommand.java. I agree that it should be fixed, but it was already there and is not being introduced by this PR, so I don't think now would be the right time to tackle it.

On other warnings

Also if you want/can fix the other build warnings.

Sure. Got rid of

[INFO] Annotation processing is enabled because one or more processors were found
  on the class path. A future release of javac may disable annotation processing
  unless at least one processor is specified by name (-processor), or a search
  path is specified (--processor-path, --processor-module-path), or annotation
  processing is enabled explicitly (-proc:only, -proc:full).
  Use -Xlint:-options to suppress this message.
  Use -proc:none to disable annotation processing.

by explicitly configuring Maven to run the Lombok annotation processor. See this JDK bug entry.

[Zoriot]

That's a good point, but if they were to be added upstream, I would prefer it that happened in Terra++ and it would then make it's way to Terra-- and Terra+-

That's fine for me, I thought T-- is a hard fork, at least it seems to be fairly far away from T++ commit wise. Also i think at some point it would make sense to make T++ a Mod which implements the T-- Library. It's fine for me to merge this in, and then when it's in T-- remove the files & adjust the paths - you should make a tracking issue then.

I do however believe that Terra+- could benefit from having its own documentation that takes into account its specificity (e.g. files are not in the same places), and that would benefit from keeping the files here. What's your take on this?

I agree, but that's not the README's place. The README's are in the place where the actual files have to be, so you can just refer to the current dictionary. We shouldn't refer to anything T+- specific.
For t+- specific docs we have the README which also can be expanded or split into multiple files & the config files itself.

[SmylerMC]

I thought T-- is a hard fork

No, I am trying to keep it as close to Terra++ as possible. That still requires a lot of changes though. Last merge from upstream was a year ago and not much has happened since.

Also i think at some point it would make sense to make T++ a Mod which implements the T-- Library

I fully agree. Or split Terra++ into a core module and implementations for different mod loaders. It doesn't really matter how at this point, but it would be infinitely better to have the generation engine at a single well defined place. The things is Terra++ development has been hanging onto BuildTheEarth/terraplusplus#29 for years now. There are so many changes in this PR it is hard to anything ambitious with the current master branch that won't come in conflict, and there are so many good changes in the PR that it would be a shame to give it up. And only @DaMatrix can really work on it at this point.

I agree, but that's not the README's place. The README's are in the place where the actual files have to be, so you can just refer to the current dictionary.

I don't really get your point here. The README's are dropped where the actual files should be, in <server directory>/plugins/Terraplusminus/<dataset config directory>/README.md. This is T+- specific, so if someone gets there, it would be best to give them instructions specific to T+- instead of generic T--/T++ ones imo.

[Zoriot]

instructions specific to T+- instead of generic T--/T++ ones

Wdym with T+- specific instructions? There should'n be any specifics in there, because why do we need to have anything specific for paper?

[SmylerMC]

Wdym with T+- specific instructions? There should'n be any specifics in there, because why do we need to have anything specific for paper?

Configuration paths are different, and configuration options specific to Terra+- can come into conflict with native Terra-- configuration features (e.g. surface blocks, biome overrides). There is no such issue with the two datasets we are adding READMEs for, but moving them to Terra-- would risk splitting these kind of files in multiple places in the future as we support more features but with some caveats.