Requests

• The directory structure of a scala installation should stay the same, except for the meta folder which contains sbaz metadata.
• bin for runner scripts
• doc/package-name for documentation on package package-name
• lib for jars / dlls
• man/man1
• misc/package-name for misc files (e.g. test files)
• src for sources
• It would probably be nice to keep the same packages as described here http://lampsvn.epfl.ch/trac/scala/wiki/SbazBuild, i.e. separate the library and the compiler. Some users might want to only have the library.
• We need to keep a downloadable Scala release which works without maven.

Other sbaz features

There are some other features of sbaz that we would like to keep when switching to maven:

• Everybody is allowed to share his packages to the scala-dev universe to make them available for others
• We need to provide documentation and tools (Ant task) for developers that want to create maven packages. We also need that ourselves, for instance to distribute compiler plugins like "units".

From Discussions

• An easy way for anyone to quickly set up an account and deploy their Scala jars to a public Maven repository. The community (at least the Lift community, though I'm sure some non-Lifters use it too) has standardized around scala-tools.org. It'd be amazing if there was a way for just anyone to quickly and easily deploy their jars to scala-tools.org. (sbaz does a pretty good job of this, but sbaz has other problems.) - Jorge Ortiz
• Have the Maven Scala plugin be more Scala-aware. This is especially important since Scala releases very often break binary compatibility. If my Scala project uses Scala 2.7.1 and I try to add a Scala library that was built with 2.7.0, Maven should freak out on me unless I specifically tell it that it's fine. Even better (and this is a bit of a stretch) would be if Scala projects in Maven could list multiple Scala versions to compile under. That is, my Scala project might be compiled and deployed under 2.7.0, 2.7.1, and 2.7.2-rc1. If someone adds my project as a dependency, Maven will pick the correct version they need from the version of Scala that they're using. This because binary compatibility often breaks, but source compatibility is sometimes preserved. - Jorge Ortiz
• Replace current nightly build scripts with something that can be run on Hudson. - Geoffrey Washburn
• The Maven solution appears (to me) to be fairly ambitious because it is replacing and enhancing the existing installation, upgrade, project management, scripting environment and project sharing mechanism that already has history in the field. Do you anticipate the tools will be rolled out in phases, in parallel, or a longer lead time "big bang"? I suspect the call for maintainers was driven by a more immediate need than a "big bang" may allow. Should maintenance of sbaz continue until the Maven solution is ready? Could an abrupt "sink or swim" cut over be a reasonable and acceptable approach? While this last approach is the easiest to implement, I suspect it would frustrate a lot of people... just a guess. - James Matlik
• I would like to add another thought related to how the transition to the new tool set should be managed. Scala already has a decent user base, and the changes being made as part of the transition to Maven has the potential of being disruptive. The obvious risk is supporting large numbers of legacy packages that have only been managed under sbaz. Would it be possible to automatically migrate to the new Maven format? If this cannot be done easily, what would the recommended transition process be, dual tools? Is this even a legitimate concern? Then there is the change in architecture (physical storage). Maven uses centralized repositories that can be aggregated on the client side. Sbaz uses a centralized catalog (the Universe) to point to packages that can exist anywhere a URL can point. This may not be a big issue for transitioning, but it is bridging into sysadmin and infrastructure territory vs. pure software design and implementation. - James Matlik

The Vision

• provide Maven packages for the software currently available using Sbaz, manage the repository
• automatically generate Maven packages for the core Scala distribution as part of the distribution building process
• Post Scala releases to the Maven Central Repository: guide.
• provide documentation for installation and use of the Scala Maven packages
• Replace/Enhance sbaz with some utility that is "Maven repository aware" and pulls down artifacts into a "scala_home" distro (for anti-maven/ivy users)
• Wire in a nice repository viewer (somewhat like scala-tools.org, or possibly Nexus/Archiva) that provides searching capabilities.
• Possibly host scaladocs / reports for various scala projects
• Use scala's rich inheritance model and "scriptability" to write pure-scala maven replacement that works in the eco-system (HA, given enough free-time or money)
• Web-Start Scala installer that can pull packages off Maven Repository at request of user.

Plan

1. Figure out "what" to put in the maven repository
2. Figure out "where" to put maven repository
3. Figure out "how" to put items in the maven repository
4. Figure out "who" is going to do which tasks

What

Initial Packages ("Core" Repository)

We should take what scala-tools has already done, and expand on it...

I say we deploy these projects from the scala-build file:

• org.scala-lang:scala-library
• org.scala-lang:scala-compiler
• org.scala-lang:scala-swing
• org.scala-lang:scala-msil (attaches msil library dll... needs NMaven research)

Note: All these include attached sources. For now only scala-library will have a "scaladoc" attachement

Here's from Lukas' trac wiki page:

• The main Scala project creates five sbaz packages:

o scala-library (scala-library.jar, scala-dbc.jar, scala-swing.jar + sources) o scala-devel (compiler, runner scripts, man pages) o scala-test (partest, test files, runner scripts) o scala-devel-docs (api, examples, README, LICENSE) o scala-msil (msil library dll, runner scripts)

• Currently, two other SVN projects create sbaz packages for a distribution

o Scala tool support o Scala Documentation (PDF documentation) o (Scalap was also one of these, but is currently not part of the distribution)

Where

Scala Tools vs EPFL pros/cons

• Scala Tools already has an infrastructure that people use (myself included)
• EPFL hosts subversion and trac and may want control of the maven repo. Scala Tools could proxy this

Here's a proposal for final distros from Rob Dickens:

<project>
  <repositories>
    <repository>
      <id>scala-lang.org</id>
      <name>Final Releases</name>
      <url>http://scala-lang.org/m2arts/scala-dev</url>

<project>
  <repositories>
    <repository>
      <id>scala-lang.org</id>
      <name>Release Candidates</name>
      <url>http://scala-lang.org/m2arts/lamp-rc</url>

How

Sabbus Changes/Hooks

Look into dist.xyz and PackSabbus Use Maven Ant Task (or Ant Maven Task?) as this may be easier to distribute packages (Thanks David!)

Who

I figure we make a checklist of all the TODOs (via track items) and people can "choose" one to do by assigning it to themselves. That way, we can ensure everything is done and bug the appropriate people.

Task List

Moved to ScalaMavenSupportTaskList