Closed lefou closed 2 years ago
I started a new project: https://github.com/com-lihaoyi/mill-moduledefs
Once, we get it to properly publish, we can refactor to use that external project instead.
@lihaoyi I don't think we already have organization-wide secrets? Hence, could you please add the respective secrets to the new project? Thank you!
SONATYPE_DEPLOY_USER
, SONATYPE_DEPLOY_PASSWORD
, SONATYPE_PGP_SECRET
, SONATYPE_PGP_PASSWORD
@lolgab Thanks for the info. I'll use these too, then.
We have essentially two compiler plugins in Mill which we currently build as one:
override
on overriddendef
s andval
s and special handlemill.moduledefs.Cacher
instancesmill.moduledefs.Scaladoc
, se we can later extract and re-use them inmill inspect
Those are currently packaged in one ordinary Scala artifact
mill-moduledefs
based on Scala binary version. Instead, they should be packaged for the full Scala version, to avoid conflicts.Also, because of their packaging, they are currently not really usable outside of Mill, which makes developing external Mill plugins a bit more inconvenient, as e.g. the scaladoc encoding would be useful for external plugins too.
Contrary to the fact, that these modules change quite seldom, they need to be (re-)released whenever new Scala versions come out.
I suggest, to make them standalone project with their own release cycle and well defined compatibility scheme, so we can use them in Mill accordingly.