Unit тестирование и Jackrabbit (JCR)

Вот есть такая замечательная поделка как Jackrabbit - кладязь сюрпризов и неожиданностей. И захотелось как то пописать тесты на классы, которые работают с этим Jackrabbit-ом.

Вообщем, есть такая задача:
Есть JCR репозиторий и есть некие модули, которые работают с этим репозиторием. Задача: создать среду для тестирования этих модулей.

Тестирование: начало (ч.2)

Размышления на тему: "что надо сделать, чтобы превратить загадочное слово 'тестирование' в нечто реально полезное для разработчиков?"
Ответить на ряд вопросов:
1. Чего мы хотим добиться?
2. Нужно ли нам это?
3. Можем ли мы это себе позволить?
4. Заниматься этим систематически, т.е. постоянно (это не вопрос, а утверждение).

Мысля о качестве ... и не только

По долгу службы сейчас "изучаю" CMMI. А еще часто на проектах пытаются измерить качество. А еще качество, ну это "такое замечательное" свойство...
Вообщем, родилась некоторая аналогия между этими явлениями. Начнем с конца.

CXF: Шаг 0 - XSD to Java

Почему шаг 0?

Почему шаг нулевой: на мой взгляд этот шаг имеет нулевую пользу и если это возможно, нужно его пропустить. Почему?

• Мы в этот файл вкладываем информацию о типах данных, которыми будем оперировать в интерфейсах. При преобразовании XSD to Java эта информация изменится (возможно довольно сильно), при преобразовании Java to WSDL получившаяся измененная информация еще больше исказится.
• Все комментарии, разметка и прочая вспомогательная информация, заложенная в XSD, уйдет "в никуда".
• Ну и куча "мелочей", от лишних 10 сек при компиляции до необходимости хранить знания об интерфейсе в двух раздельным местах на двух разных языках.

Если вышенаписанное не убедило отказаться от написания XSD или по другому не получается, то вот несколько рецептов "от головной боли":

Экономия или скупость?

Лирическое вступление

Вот всегда было интересно, почему в одних конторах с обеспечением "железками" все нормально, а в других вечные проблемы. Имеется, ввиду следующее:

Вот работал я в организациях где к вопросу железа подходили ну довольно просто, в 3 этапа:
1.Со старта дают нормальный (достаточно мощный ПК)
2.В случае надобности, делают апгрейд в довольно короткие сроки (1-10 дней).
3.И сервера, как правило, работают на действительно серверных железках (а не хламе, который остался от прошлого апгрейда).

А вот бывают случаи противоположные. На проекте хронических дефицит ресурсов(железных) - ПК программистов слабенькие, билд серверу не хватает памяти для своего нормального функционирования и т.д. Запросы на добавление памяти(ну супер дорогой ресурс!) либо обрабатываются месяцами, либо на них забивают. И аргументы как всегда железные: «это дорого» и «сейчас нету средств».

Причем, то что я видел, это либо первый случай, либо второй. Так что бы сегодня так, а через месяц по другому практически не видел.

Появилась мысль, что нехватка оперативки и "черепаший" винчестер должны воровать не только нервы у разработчиков, но и деньги у организации. И появилась идея, прикинуть сколько это стоит? И стоит ли...? :)

Задача

Итак, условие задачи: