Currently, multiloader projects or project supporting multiple MC versions have to be spread out over multiple subprojects. This is not optimal, as the different subprojects are really providing the same "thing" -- and so would be more idiomatically represented as feature variants of a single component. However, doing this when you can only have one MC or neo version per project is difficult -- you either end up publishing variants that "bounce" to published subproject variants (which are then, themselves, not very idiomatic... exactly what I'd like to avoid) or you end up bouncing lots of deps back and forth between subprojects and the publishing project (what I currently do; possible, if a bit painful to set up nicely). This could be solved if moddevgradle could be configured per-source-set; at the same time, however, we want to be careful not to increase the complexity of moddevgradle substantially.
This PR moves the major object that the neoForge extension is linked to from projects to source sets. Since it's basically just s/project/sourceSet/d in terms of how everything is designed, this does not involve an increase in complexity -- things done at the project level before are just done at the source set level now. The NeoForgeExtension on the root project is just the extension on main, meaning that for the average user of the plugin nothing should change. For advanced users, the extension/tasks/etc for other source sets may be created with neoForge.forSourceSet(sourceSets.whatever) {...}.
Some discussion on discord worried that this would cause an increase in the complexity of the mental model of how moddevgradle works -- this is not the case, as the only substantial change to this model is replacing project as the holding object with sourceSet, and prefixing tasks and the like accordingly (which is not something you ever have to actually deal with, as SourceSet#getTaskName handles it for you.
Currently, multiloader projects or project supporting multiple MC versions have to be spread out over multiple subprojects. This is not optimal, as the different subprojects are really providing the same "thing" -- and so would be more idiomatically represented as feature variants of a single component. However, doing this when you can only have one MC or neo version per project is difficult -- you either end up publishing variants that "bounce" to published subproject variants (which are then, themselves, not very idiomatic... exactly what I'd like to avoid) or you end up bouncing lots of deps back and forth between subprojects and the publishing project (what I currently do; possible, if a bit painful to set up nicely). This could be solved if moddevgradle could be configured per-source-set; at the same time, however, we want to be careful not to increase the complexity of moddevgradle substantially.
This PR moves the major object that the
neoForge
extension is linked to from projects to source sets. Since it's basically justs/project/sourceSet/d
in terms of how everything is designed, this does not involve an increase in complexity -- things done at the project level before are just done at the source set level now. TheNeoForgeExtension
on the root project is just the extension onmain
, meaning that for the average user of the plugin nothing should change. For advanced users, the extension/tasks/etc for other source sets may be created withneoForge.forSourceSet(sourceSets.whatever) {...}
.Some discussion on discord worried that this would cause an increase in the complexity of the mental model of how moddevgradle works -- this is not the case, as the only substantial change to this model is replacing
project
as the holding object withsourceSet
, and prefixing tasks and the like accordingly (which is not something you ever have to actually deal with, asSourceSet#getTaskName
handles it for you.