Установка Apache Archive на Ubuntu Server

Из цикла '1001 велосипед'.

Есть такая замечатлеьная програмка как Archive. Помогает сэкономить кучу времени и нервов разработчикам, работающим с Maven проектами (особенно актуально для контор, не могущих позволить себе нормальный интернет канал).
Так вот, есть следующая задача:
а) установить это чудо на Ubuntu Server (ssh, без XServer-а)
б) сделать автоматический запуск и остановку
в) разнести исполняемый код\конфиги и данные по нужным даректориям
г) сделать это с минимальными исправлениями самого дистрибутива archiv-ы

С первым пунктом вроди-бы все понятно. Со вторым - болие или менее. С третиьим - пришлось чуть чуть помудрить, потому как приложение написано так, что все находится в одной папке (бинарники, конфиги, базы данных и кеш артифактов).

Перепост: Совершенствование кода с помощью плагинов Eclipse

Статья Совершенствование кода с помощью плагинов Eclipse - обзор парочки плагинов для статического анализа кода. Средства простые 'до безобразия', но могут съэкономить кучу времени и нервов.

Замечание: статья 2007-го года, так что некоторая информация чуть устарела:
1. CheckStyle за последние несколько лет "чуть выросла". Одно из вкусных дополнений - это способность измерять\проверять циклическую слоность кода (CCN) и длину методов\классов (NCSS).
2. Coverlipse на данный момент выглядит какимто полузаброшенным проектом. В тоже время есть довольно неплохой плагин eCobertura.
3. Metrics - может оказаться ненужным, потому как базовые мтрики можно контролировать с помощью Checksyle\PMD.
4. Есть еще довольно спорный плагин для FindBugs. Спортный потому что, на сайте приведено довольно много "пафосных бла бла бла", но при этом управлять плагинами для maven и eclipse довольно проблематично (точнее не плагинами и наборами правил и исключений).

Перпост: Очищаем скрипты сборки от запахов

Небольшая статья о том, чего не надо делать со скриптами сборки:

Автоматизация для людей: Очищаем скрипты сборки от запахов

Еще мысля по Jenkins API

Интересная API у этой системы... заставляет чувствовать себя полным идиотом :(
Все, как будто, ясно, красиво и очевидно, но на реализацию простейших вещей уходит уйма времени.

Что помогает:

• Наличие комментариев. JavaDoc-и есть и они довольно объемные (иногда даже информативные).
• Наличие огромного количества примеров. Имеется ввиду уже написанных плагинов, а точнее исходников к ним.

Что мешает:

• Отсутствие высокоуровневой документации. Javadoc-и это конечно хорошо, но составить общую картину по ним довольно сложно. Разбирательство c API напоминает разгадывание ребуса (с применением накопленного опыта, интуиции и русского мата).
• Довольно высокий уровень косвенности. Множество вещей (модулей и сущностей) связаны неявными правилами и эти связи проявляются только в run-time. Узнать как правильно реализовывать некоторые виды плагинов довольно проблематично: информации из javadoc-ов не достаточно и посмотреть как они(плагины) обрабатываются самой системой тоже трудно. Спасают только примеры (плагины с аналогичной функциональностью).
• Довольно большая часть информации устарела (туториалы, документация, примеры): либо ссылки битые, либо API уже изменилась. Так что, выполнение первого туториала может вылиться в довольно долгую и увлекательную задачу.

Надо как то собраться с мыслями, и записать "накопанные" знания.

Java в Ubuntu

В Ubuntu по умолчанию стоит OpenJDK, что для разработчика 'как то не привычно'. Xочется видить и пользовать Sun JDK.

1. Разрешаем использовать пакеты из зеркал партнеров. Для этого:
- открываем /etc/apt/sources.list и раскоментриуем вхождения для restricted и pertner зеркал.
- обновляем список пакетов sudo apt-get update

2. Устанавливаем желаемую JDK:
sudo apt-get install sun-java6-bin sun-java6-jdk sun-java6-jre

3. Добиваемся использования Sun JDK вместо OpenJDK. Тут есть варианты:
3.1. Прописать в настройках приложений (например Eclipse) пути именно к /usr/lib/jvm/java-6-sun и на этом успокоится.
3.2. Изменить 'JDK по умолчанию': sudo update-alternatives --config java. Логика подсказывает, что это наиболее безопастный способ, но другая логика подсказывает, что держать на винчестере 2 экземпляра джавы как то не правильно (расточительно). Поэтому....
3.3. Полное удалени неиспользуемых пакетов. Лучше делать через Sinaptic: грохнуть все пакеты, которые начинаются с openjdk. В результате освобождаем 100-200 МБ

Вот так 404!

http://proteys.info/404/

Знакомство с Hudson

Пришлось познакомится с CI системой Hudson.
Первое впечатление очень даже ничего:

• при своей бесплатности, выглядит на редкость представительно и имеет кучу возможностей;
• довольно просто устанавливается и конфигурируется;
• для тех кому мало существующего функционала, есть возможность дописывать свои плагины. Кстати API выглядит довольно многообещающе;
• ну и естественно, кросплатформенное приложение.

На первый взгляд, система довольно легко может заменить такие продукты как TeamCity и Bamboo. А мрачное убожество СС здесь и рядом не стояло:)

Из минусов:

• для разработчика плагинов ну очень мало информации. Возможно я еще чего то еще не знаю, но пару обзорных статей и устаревших/не работающих туториалов как то не внушаю оптимизма;
• последние пол года проект как то колбасит. Видно что недавно они перехали на новый домен java.net + совсем недавно проект решил сменить свое название на Jenkins (тут и тут). И это, тоже, вносит свою долю неразберихи.