Closed lefou closed 1 year ago
I'm in favor of (1.).
I'm having trouble coming up with an example where having resources during compilation is necessary. I know in theory macros or compile plugins could read resources, but I don't know of any existing macros or plugins that actually do.
Combining the relativey low chance of semantic breakage, with the fact that this is a binary compatible change, makes me feel like accepting the small semantic breakage will be less painful than having to for-ever-after tell people "use runResources
, it's what you actually want, not resources
"
We may also collect some info how other build tools handle resources, e.g. sbt, Maven, Gradle, etc. Despite of our decision, when it is significantly different than in other tools, we may want to add some clarifying text to the documentation.
If we decide to go with a semantic change, we should still increment to the next Mill binary platform version, as external modules will need a way to deal with the changed semantics. E.g. my plugins which touch the compiler or packaging aspects (mill-kotlin, mill-aspectj, mill-osgi) will go crazy, if we introduce this change in a patch level release.
I'd be interested in implementing this (1.), of course I'll need a lot of direction along the way and will ask for reviews/comments but feel free to assign this to me :)
I'd be interested in implementing this (1.), of course I'll need a lot of direction along the way and will ask for reviews/comments but feel free to assign this to me :)
Great! Just open a draft pull request once you have some code.
Mill currently only has one
resources
target. It's content will end up in the built jar and also in the classpath. But it is also evaluate before and feed intocompile
target. This has various implications:resources
will trigger a recompilationSee also the following discussion on Gitter: https://gitter.im/lihaoyi/mill?at=6246909d9a09ab24f3d00982
To improve the resource handling, I'm interested in your opinion. Which route do you prefer?
resources
intocompile
and add acompileResource
target which is feed intocompile
insteadresources
target as is and introduce a newrunResources