This page is no longer maintained — Please continue to the home page at www.scala-lang.org

Looking for Maintainers

The Scala project is constantly evolving and expanding, and at times it is difficult for the Scala core team to follow all of the components of the distribution and its supporting tools. We are now looking for volunteers who can help with some Scala components that would benefit from external maintenance. If you think you can lend a hand and would like to help us out with the development of Scala, just raise your hand!

Components that are currently in need of maintaners include:

  • packaging infrastructure, either via Sbaz or Maven
  • better support for specific Linux distributions, installers for various systems
  • improvements to the testing suite

and possibly other components, as listed on our new external maintainers page. Read below for more details.
 

Sbaz packages → Maven?

An often-overlooked part of the Scala software is our packaging system. Apart from the main Scala distribution, many additional software components like libraries, glue code, and other utilities, are available using Sbaz, our current packaging system. Sbaz is a great tool, but it has not been maintained for quite a long time and its future is in question. We need a packaging mechanism that covers all of the software currently available using Sbaz, and can carry us forward with future distributions.

We are therefore considering two alternatives, and we welcome suggestions from the Scala community about the path that we should follow:

  • Sbaz: the first alternative is finding a new maintainer for the Sbaz system. The software in written in Scala and was designed by us, it is relatively simple and has served us quite well. We would need a volunteer who can maintain Sbaz itself (not much work is needed), and with making sure the repository of available software is kept up-to-date.
  • Maven: the second alternative is the use of a cross-platform packagin tool, and Maven seems an excellent choice. Some great work is this sense is currently being done by the guys at scala-tools.org, who routinely prepare Maven packages of the Scala distribution. Before we can retire Sbaz, we need to make sure that we have active maintainers for Maven packages covering everything that is currently available via Sbaz, in addition to an easy-to-follow installation guide.

In either case, we will list the names of the maintainers on our maintainers page, so that there is always a contact person for each component. Please give us feedback about your preference between Sbaz and Maven, or any additional suggestions you may have.

Distributions for Specific Platforms

In addition to the Sbaz/Maven packages, many people feel more at ease with installing a package that is consistent with the system used by their platform of choice: rpm, apt, maybe a native Windows installer, maybe an OSX dmg/installer, Fink/DarwinPorts, ebuild, and so enumerating. This is an effort that we cannot sustain internally, if just for the sheer number of possible platforms and software configurations. While there has been work done in this sense in the past, the packages tend to become rapidly outdated.

We would like now to coordinate those efforts by calling for volunteers to be active maintainers of these packages. Their role will be to make sure their packages work correctly on the corresponding platform, maintain updated installation instructions, make sure that updated packages are promptly released when a new distribution is released, and to respond to user feedback. We can provide a contact form on our website and a section on our Trac system to facilitate interaction with users, and of course we always have our mailing lists.

Testing Suite

The Scala source distribution comes with a reasonably large testing suite, that we all use at every step of development to make sure that all our modifications to the libraries and tools do not introduce unexpected bugs by breaking one or more features, or failing to work in corner cases. Maintaining the test suite is a cumbersome task in itself, and we would all benefit if the current suite could be extended and improved. Contributions are also welcome in this area. Even though we have not finalized a process or guidelines with which new tests can be submitted yet, that is likely to happen in the near future. If you have ideas about tests that could exercise parts of the Scala features that are currently under-tested, or if you would like to look into the tests that are currently incomplete or broken, we would welcome your help. Please let us know what you would be willing to help us with, and we will list you as the active maintainer for that component.

Other Software

Other Scala components may benefit from external assistance, and we will list them as needed on our external maintainers page. If you feel you may be able to assist with any of those components, we will warmly welcome your help.

Any chance of using Ivy?

Sbaz is a great tool but if you are thinking of alternative ways of managing Scalas updates and dependencies, have you not considered using Ivy?

Having used it on a number of projects I am quite a fan and would be happy to lend some advice if needed.

packages

I am not particularly familiar with Ivy, but from their website I read that Ivy is highly integrated with Ant. We are currently using Ant as our build system; however, it gives us so many headaches that we periodically try to get rid of the Ant build script and replace it with something else. Therefore it would be unwise for us to introduce additional Ant dependencies.

In addition, we are actually receiving a lot of interest concerning a Maven repository, so we have narrowed our choices to Sbaz and Maven at this stage. If the Maven effort ends up being unsuccessful, however, we will probably consider alternative solutions.

packages

I have worked with maven and ant. I recently migrated some 20 projects to maven build system, and in short: it is a headache! Far from an easy to use frielndly build system.

packages

There is a discussion on the scala-tools mailing list that I suggest anyone interested in this topic reads.  The discussion suggests that Maven, or more precisely its repository, is used for distributing libraries, not as a standardized build tool. You can check it out on Nabble.

ivy

I have found ivy to be quite the pain - its barely documented and has really terrible performance. I'd definitely dump it given the chance.

Debian Packages

I would be willing to put some time into maintaining Debian based packages for the latest builds. Perhaps this is something that could even be automated?

Debian

Thank you for your offer! We currently do have a maintainer for the Debian port of Scala, Min Huang; if you have suggestions about the packaging procedure, or would like to contribute to this port, you may want to contact him by using this contact page

About Maven

I think Maven2 is the way to go.

 

Most of the complaints I hear about Maven are severely outdated. People usually say they hate Maven, however in fact they used to hate it a long time ago, but they haven't tried a more recent version. In fact, Maven has evolved quite significantly since its early days. Maven2 was a complete rewrite of Maven1. The difference is profound (Has anyone compared Struts1 and Struts2? It's that big). I am not suggesting that it's perfect. Nothing is. But it is a good tool and it gets the work done.

 

A word of caution though, if you decide to go with Maven I would recommend documenting all major Maven-related goals and processes used in Scala (even if it means duplicating information from the official Maven web-site). Maven learning curve is still fairy significant and not many people can say: "Oh, its under Maven. Then it must be straight-forward." Moreover, Maven is very generic and there is going to be a lot of project-specific details. Some things work, others don't. Instead of making people learn things the hard way and to avoid frustration a little documentation on Scala's Maven setup would help a lot.

 

Yegor

Copyright © 2012 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland