I installed scala using macports

$ sudo port install scala29

As macport provides different scala versions, I use scala-select to set up my scala default version: 2.9.0

$ sudo port select scala scala29

Unfortunately macport provides an old sbt version, so I proceed with a manual installation. Just copy to jar file to the desired location, I chose /usr/share/sbt, and create a shell script to launch it:

/usr/share/sbt
├── bin
│   └── sbt
└── lib
│ └── sbt-launch.jar


And the sbt script content:

java -Dfile.encoding=UTF8
-Xmx1536M
-Xss1M
-XX:+CMSClassUnloadingEnabled
-XX:MaxPermSize=256m
-jar /usr/share/sbt/lib/sbt-launch.jar "$@"


Finally I created a symlink to the sbt script

$ ln -s /usr/share/bin/sbt /usr/bin/sbt


You can find a very basic project in my github account to test it:

As the scalatra website recommends, I installed giter8 via conscript.

$ cd
$ curl https://raw.github.com/n8han/conscript/master/setup.sh | sh
$ ~/bin/cs n8han/giter8


At this point the installation failed because it couldn’t find commons-logging dependency, so I added that dependency to my basic sbt project and it was available next time I rerun the giter8 installation. Now you can create a scalatra template running:

$ ~/bin/g8 scalatra/scalatra-sbt

I experienced problems with my favourite window manager, XMonad, and because I was unable to fix it, incapacity to enter text, I moved temporary to Enlightenment which does not show that disgusting behaviour. It seems that issue can be solved using xmonad module ICCCMFocus, but it isn’t packaged for FreeBSD yet.

UPDATE: Swing Java reported issue with Xmonad here.

FreeBSD documentation is the best resource, and this post doesn’t intend to be a replacement, just a quickguide. I strongly recommend read it for further clarifications and to get a proper understanding of what you’re doing.

Basically I reboot my Thinkpad X60s with the minimum services, no tomcat, no database, no X system. You can see my rc.conf here.

OK, so now we are in front a nice old school terminal, log in as root, sync code for the base system (here you can find my supfile for csup utility), build the kernel, reboot in single user mode and install the new built base system.

FreeBSD can be seen as two different parts: the operating system, what I called base system, and the third party applications. We finished with the first part, the second one is quite similar as we get the code (sync ports) and upgrade the applications using packages when they are available.

Again I used csup and my ports supfile can be found here.

La documentación de FreeBSD al respecto es muy buena, y aconsejo su lectura.

Esta ha sido mi experiencia, que se resume en reiniciar con los servicios mínimos, recompilar el kernel con la ultima versión del código disponible, y actualizar mis aplicaciones mediante el sistema de ports.

Primero desactivo servicios innecesarios, mi /etc/rc.conf puedes verlo aquí.

Tras reiniciar, en modo texto, pues una terminal es lo único que necesitamos, adapto el supfile de ejemplo (/usr/share/example/supfile) que usare para sincronizar con csup quedando así.

A continuación como se describe en la forma canónica para recompilar el núcleo. Donde la diferencia es que he ejecutado make con la opción j8 porque tengo un core 2 duo y de esta forma reduzco considerablemente el tiempo necesario para las compilaciones.

Si todo ha ido bien tenemos la ultima versión del núcleo, y procedemos a actualizar las aplicaciones en este caso con portupgrade y usando paquetes precompilados siempre que sea posible. También he creado un supfile que se ajusta a mis necesidades.

Para ello se edita el fichero /etc/grub.d/40_custom:


#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries. Simply type the
# menu entries you want to add after this comment. Be careful not to change
# the 'exec tail' line above.
menuentry "FreeBSD 8.0-RELEASE AMD64" {
set root=(hd0,0)
chainloader +1
}


Una vez terminado se actualiza grub con el comando update-grub.

La solución que he encontrado consiste en dejar de usar la versión de maven embebida, y reemplazarla por la instalada en mi sistema. Para ello se accede al menú Window/Preferences/Maven/Installations y se añade el maven2 resisdente en mi sistema (en mi caso un debian squeeze):

/usr/share/maven2

El paquete usepackage viene en nuestra ayuda. En debian podemos instalarlo como

apt-get install usepackage

A continuación se escribe en los ficheros de configuración las variables de entorno a cargar según el entorno deseado. Va a usarse como caso práctico diferentes versiones de grails.

Editamos .bashrc para cargar use al inicio de sesión:

. /usr/share/usepackage/use.bsh

Se crea el fichero /etc/usepackage/grails.conf con el siguiente contenido:

# GRails 1.1.1
>> grails1.1.1: "Grails 1.1.1" <<
grails1.1.1 * * * * : GRAILS_HOME = /usr/local/grails-1.1.1,
PATH+= /usr/local/grails-1.1.1/bin;

# GRails 1.2.1
>> grails1.2.1: "Grails 1.2.1" <<
grails1.1.2 * * * * : GRAILS_HOME = /usr/local/grails-1.2.1,
PATH+= /usr/local/grails-1.2.1/bin;

Y finalmente creamos ~/.packages para insertar:

(include /etc/usepackage/grails.conf)

Refrescando la configuración (source .bashrc) y ejecutando use -l podremos ver los diferentes entornos disponibles, de los que nos interesan:

grails1.1.1 - Grails 1.1.1
grails1.2.1 - Grails 1.2.1

Y cargamos el deseado con use grails1.2.1 por ejemplo.

Me he decidido por esta entrada porque trabajo en un proyecto consistente en bastantes módulos, y como muchos desarrolladores han pasado por ahí, todos y cada uno ha dejado su granito de arena y un poco más (típicamente mierda). El caso es que desde la línea de comandos se puede compilar todo sin problemas, pero no todo el mundo quiere trabajar así.

El procedimiento es sencillo, se crea un nuevo proyecto Java (New Java Project) y se selecciona la opción Create project from existing source, apuntando al directorio que contiene todo el código, y que por buenas practicas hemos dejado en el workspace, no es plan de hacer copias innecesarias.

Comprobamos el entorno de ejecución, versión Java a usar, pulsamos siguiente o next para comprobar que se incluyen los directorios con los diferentes módulos y pinchamos sobre la pestaña de librerías para verificar que se han incluido. Si el proyecto tiene una estructura que se ajusta a las convenciones (src/main/java para el código, src/test/java para las pruebas, lib para las librerías y conf o src/resources para los ficheros de configuración) todo debería cargarse automáticamente, si no es así tocará añadirlo a mano y aprenderemos el valor de las convenciones.

<dependency>
    <groupId>org.testng</groupId>
    <artifactId>testng</artifactId>
    <version>5.11</version>
    <classifier>jdk15</classifier>
    <scope>test</scope>
</dependency>

En determinados entornos no tenemos disponible un IDE o ni siquiera un entorno de ventanas, pero aún así se puede editar código Java. Primero hablemos de la configuración de Vim para numeración de líneas, identación de código con cuatro espacios y resalte la sintáxis.

set nu
set tabstop=4
syntax on


La anterior configuración debe añadirse al fichero .vimrc en nuestro directorio HOME de usuario. Los leguajes más populares están soportados, y de no ser así en la web de podemos encontrar los ficheros necesarios para otros lenguajes.

public class Hello {
    public static void main(String[] args) {
        System.out.println("Hello World!");
    }
}