-
Notifications
You must be signed in to change notification settings - Fork 90
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Introduce possibility to use different renderers #67
Conversation
This looks like a pretty big change. I'm ok with it, but can I make you a committer in case we have to maintain it going forward? |
It mostly refactoring but it does introduce a few new mechanisms indeed. |
Introduce possibility to use different renderers
Merged, and welcome to the team :) |
Thanks :) |
BTW, when you're going to cut a new release, do not hesitate to ping me here or on Twitter so that I can update the README to document that feature ;) |
I was gonna ask if you want to hand merge all the PRs you just broke :) |
I'm currently looking at #58 |
I'll take #61 ! |
Shall I merge them all ? |
Working on #65 now |
Currently, sbt-buildinfo only allows to write the build info in the form of a Scala class.
It could, however, be interesting to allow to dump the build in another format, e.g. JSON.
This PR introduces
BuildInfoRenderer
(along with a few other data types), a trait which allows just that.The current logic for the creation of the Scala class is moved to a dedicated class,
ScalaClassRenderer
and retrofitted to implementBuildInfoRenderer
, set as the default renderer.Existing users of sbt-buildinfo won't be affected by this PR, as the existing model or no pre existing key, only a new key is introduced to specify the renderer to use.