Add easy way to disable mojmap conversion for forks based off pre 1.17

[theminecoder]

It is currently impossible to maintain a fork pre 1.17 with this because of the forced mojmap steps. It would be nice to have a setting to disable just those steps so we don't have to deal with hassle of either remapping all of the patches or manually editing the gradle task list.

[jpenilla]

I don't understand what this is asking, before 1.17 Paper did not using Mojang mappings or paperweight. You are perfectly able to continue maintaining a non-Mojang mapped 1.16 Paper fork using byof or Toothpick.

The point of paperweight is to write our patches in Mojang mappings, and we have only started using it in 1.17. If you do not want to update to 1.17 or use Mojang mappings, why are you using paperweight anyways?

[theminecoder]

I really wanna get away from the 5 different versions of fork management scripts/plugins that are floating around into one that is actually going to have time and effort put into it (I am aware that this comes with converting older forks into gradle but that's a 1 time easy step). To me it seems like it should be an easy switch to flip, do I remap or not as part of the build process.

[electronicboy]

having different non standard flows is a non-standard flow which we need to support and maintain, the implications of that are pretty meh, especially towards a toggle which very few will be using towards a mechanism which we no longer support.

I have heavy doubts that there is much interest here to butcher the existing flow to accommodate outdated setups, especially not going to be much of a priority vs other ongoing stuff

[DenWav]

My immediate reaction is :-1:. I'd probably be cool with merging a PR that accomplishes this assuming it's a reasonable change / not difficult to maintain. Paperweight does have the potential of being a very powerful platform, and it's already quite capable as it is, so I can see the desire to use this over other options.

But the point stands that paperweight exists entirely for Mojang mappings support and the other tooling required for this to work. So what you're asking for is definitely not something that has ever been on paperweight's radar.

If you want to attempt a PR here's what I recommend: Create a paperweight-legacy module next to the existing paperweight-core and paperweight-patcher modules. There you can configure the necessary tasks (all of the tasks that you need are in paperweight-lib, shared with all other modules). Should be significantly simpler / require a much smaller number of tasks total hopefully.

paperweight-patcher will need to stay compatible, so keep that in mind.