(added macros) |
(Added more tips and tricks) |
||
Line 5: | Line 5: | ||
This is a quick guide to getting Fedora packages built with <code>sbt</code>. Since <code>sbt</code> uses Ivy for dependency resolution, you'll either need to construct a local Ivy repository as part of the build (for F20) or rely on xmvn's improved support for Ivy metadata (in F21 and above after xmvn 2.0 lands). For now, this guide covers building packages on F20 with the [https://github.com/willb/climbing-nemesis/ climbing-nemesis] script. | This is a quick guide to getting Fedora packages built with <code>sbt</code>. Since <code>sbt</code> uses Ivy for dependency resolution, you'll either need to construct a local Ivy repository as part of the build (for F20) or rely on xmvn's improved support for Ivy metadata (in F21 and above after xmvn 2.0 lands). For now, this guide covers building packages on F20 with the [https://github.com/willb/climbing-nemesis/ climbing-nemesis] script. | ||
Eventually, I hope that the best practices around building Scala projects will coalesce into official Scala packaging guidelines, but for now it's sort of the wild west. | Eventually, I hope that the best practices around building Scala projects will coalesce into official Scala packaging guidelines, but for now it's sort of the wild west. Your feedback is welcome! | ||
== General tips and tricks == | == General tips and tricks == | ||
<code>sbt</code> build files are either written in a domain-specific language (<code>*.sbt</code> files) or are general Scala code that incorporates <code>sbt</code> as a library. | <code>sbt</code> build files are either written in a domain-specific language (<code>*.sbt</code> files) or are general Scala code that incorporates <code>sbt</code> as a library, and they typically either live in the root directory of a project's source tree or in the <code>project</code> directory. Because they aren't XML files, patches against <code>sbt</code> builds are typically less brittle than patches against Ant build files, and it's more straightforward to carry Fedora-specific build patches as <code>sed</code> commands. | ||
The Fedora <code>sbt</code> package is primarily intended to be used for packaging <code>sbt</code>-based projects in Fedora. While you'll be able to use it to do general Scala development as well, some features that <code>sbt</code> users expect to have available (most notably, cross-building for incompatible Scala versions and launching different versions of <code>sbt</code> for different projects) have been removed since it is difficult or impossible to support them while meeting Fedora packaging guidelines. | |||
<code>sbt</code> build files list dependencies in [http://www.scala-sbt.org/release/docs/Getting-Started/Library-Dependencies a particular format]: <code> GROUP % ARTIFACT % VERSION </code> or <code> GROUP % ARTIFACT % VERSION % CONFIG </code>. You will also occasionally see dependencies of the form <code> GROUP %% ARTIFACT % VERSION </code>; the double-percent sign indicates that the Scala version should be appended to the artifact name, as is common practice for Scala artifacts in Maven and Ivy repositories. | |||
You'll want to patch the <code>project/build.properties</code> file, if there is one, to make sure that the project expects the version of <code>sbt</code> that is packaged in Fedora. | |||
=== Helpful macros === | === Helpful macros === | ||
Line 15: | Line 21: | ||
The first of these macros, <code>remap_version</code>, takes a group ID, an artifact ID, a version string, and a <code>sbt</code> build file and updates the file so that any dependency on the given artifact is for the version specified in the macro invocation and not on whatever version was in the build file. | The first of these macros, <code>remap_version</code>, takes a group ID, an artifact ID, a version string, and a <code>sbt</code> build file and updates the file so that any dependency on the given artifact is for the version specified in the macro invocation and not on whatever version was in the build file. | ||
< | <pre> | ||
%global remap_version() sed -i -e 's/"%{1}" %% "%{2}" %% "[^"]*"/"%{1}" %% "%{2}" %% "'%{3}'"/g' %{4} | |||
</pre> | |||
<code>remap_version_to_installed</code> takes a group ID, an artifact ID, and a <code>sbt</code> build file and updates the file so that any dependency on the given artifact is for the version of that artifact installed on the build machine. | <code>remap_version_to_installed</code> takes a group ID, an artifact ID, and a <code>sbt</code> build file and updates the file so that any dependency on the given artifact is for the version of that artifact installed on the build machine. | ||
< | <pre> | ||
%global remap_version_to_installed() sed -i -e 's/"%{1}" %% "%{2}" %% "[^"]*"/"%{1}" %% "%{2}" %% "'$(rpm -q --qf "%%%%{version}" $(rpm -q --whatprovides "mvn(%{1}:%{2})" ))'"/g' %{3} | |||
</pre> | |||
== Using <code>climbing-nemesis</code> == | == Using <code>climbing-nemesis</code> == |
Revision as of 17:02, 10 February 2014
Building packages that use sbt
Overview
This is a quick guide to getting Fedora packages built with sbt
. Since sbt
uses Ivy for dependency resolution, you'll either need to construct a local Ivy repository as part of the build (for F20) or rely on xmvn's improved support for Ivy metadata (in F21 and above after xmvn 2.0 lands). For now, this guide covers building packages on F20 with the climbing-nemesis script.
Eventually, I hope that the best practices around building Scala projects will coalesce into official Scala packaging guidelines, but for now it's sort of the wild west. Your feedback is welcome!
General tips and tricks
sbt
build files are either written in a domain-specific language (*.sbt
files) or are general Scala code that incorporates sbt
as a library, and they typically either live in the root directory of a project's source tree or in the project
directory. Because they aren't XML files, patches against sbt
builds are typically less brittle than patches against Ant build files, and it's more straightforward to carry Fedora-specific build patches as sed
commands.
The Fedora sbt
package is primarily intended to be used for packaging sbt
-based projects in Fedora. While you'll be able to use it to do general Scala development as well, some features that sbt
users expect to have available (most notably, cross-building for incompatible Scala versions and launching different versions of sbt
for different projects) have been removed since it is difficult or impossible to support them while meeting Fedora packaging guidelines.
sbt
build files list dependencies in a particular format: GROUP % ARTIFACT % VERSION
or GROUP % ARTIFACT % VERSION % CONFIG
. You will also occasionally see dependencies of the form GROUP %% ARTIFACT % VERSION
; the double-percent sign indicates that the Scala version should be appended to the artifact name, as is common practice for Scala artifacts in Maven and Ivy repositories.
You'll want to patch the project/build.properties
file, if there is one, to make sure that the project expects the version of sbt
that is packaged in Fedora.
Helpful macros
The first of these macros, remap_version
, takes a group ID, an artifact ID, a version string, and a sbt
build file and updates the file so that any dependency on the given artifact is for the version specified in the macro invocation and not on whatever version was in the build file.
%global remap_version() sed -i -e 's/"%{1}" %% "%{2}" %% "[^"]*"/"%{1}" %% "%{2}" %% "'%{3}'"/g' %{4}
remap_version_to_installed
takes a group ID, an artifact ID, and a sbt
build file and updates the file so that any dependency on the given artifact is for the version of that artifact installed on the build machine.
%global remap_version_to_installed() sed -i -e 's/"%{1}" %% "%{2}" %% "[^"]*"/"%{1}" %% "%{2}" %% "'$(rpm -q --qf "%%%%{version}" $(rpm -q --whatprovides "mvn(%{1}:%{2})" ))'"/g' %{3}