Background: Scalariform is a critical part of scala-ide tooling. It enforces uniform code formatting in scala projects. Indeed, regressions to scalariform can be a serious blocker for organisations wishing to upgrade scala-ide.

As you may be aware, the original author of scalariform has been AWOL for quite some time and efforts to contact him, or to transfer the ownership of the upstream repository, have failed:

https://github.com/mdr/scalariform/issues/137

The responsibility of scalariform has informally been transferred to

https://github.com/daniel-trinh/scalariform/

and an effort last year, by myself and Daniel, resulted in Daniel obtaining the rights to publish to the org.scalariform groupId on Maven Central.

Unfortunately, a few major regressions have crept into the new releases of scalariform such that an upgrade results in mass edits to the user's codebase. A great example is akka (try it out).

https://github.com/daniel-trinh/scalariform/issues/29

It is clear that regression testing has not been a focus of the newer chain of releases:

https://github.com/daniel-trinh/scalariform/pull/58

For this particular issue, a fix has been proposed, and it is clear from the list of unreviewed PRs that Scalariform is become somewhat dormant:

https://github.com/daniel-trinh/scalariform/pulls
https://github.com/mdr/scalariform/pulls

Daniel has admitted that he is open to receiving help in maintaining, reviewing PRs, releasing and testing of Scalariform:

https://twitter.com/notakenplz/status/649740666159828992


I proposed that ensime could take ownership, but after discussion on the gitter channel, it sounds like scala-ide may also be in a position to help. I would welcome this.

This ticket is a request for scala-ide to:

0. (probably not going to happen, but don't let it stop us from proceeding) try to contact mdr and ask him to transfer his repo (with open tickets/PRs) to scala-ide
1. discuss with Daniel about how best to receive ownership of his repository (therefore transferring over all the open tickets and pull requests). I suspect he will be open to this.
2. put in place some integration / regression testing vs version 0.1.4 of scalariform. I have some ideas on how to do this if you would like to discuss technicalities.
3. apply fixes to address major regressions
4. make a release under the org.scalariform groupId (permission to be obtained from sonatype)
5. consolidate the popular versions of sbt-scalariform: https://github.com/sbt/sbt-scalariform/issues/20

I hope this makes sense and that everybody is in agreement! :-D

Personally, I am blocked from using ENSIME to edit some projects because of this constraint and I am certain that scala-ide users suffer the same.