From Fedora Project Wiki

< SIGs‎ | bigdata‎ | packaging

(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.  This means that 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.
<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> directoryBecause 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.


<code>%global remap_version() sed -i -e 's/"%{1}" %% "%{2}" %% "[^"]*"/"%{1}" %% "%{2}" %% "'%{3}'"/g' %{4} </code>
<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.


<code>%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}</code>
<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}

Using climbing-nemesis