ENargit

Приемлемое решение найдено. Как писал в комментарии выше, решил использовать плагин duns.github.com/maven-nar-plugin. Стоит отметить, что он сыроват, и по-моему, уже ко всему прочему мертв(последний коммит в 2010 году). Но в какой-то мере своё предназначение выполняет. Мне только пришлось перековырять его код и добавить возможность различать пакеты не только по связке AOL(Architecture,OS,Linker), а еще и по дополнительным классификаторам, в которые я теперь пишу версию Octave.
Думаю, когда всё это реализую, можно будет и статейку написать. Хотя, конечно, спектр применимости у NAR-плагина весьма узкий.

У меня появилась еще идея для Вас.
А зачем вы используете такой огромный вложенный второй цикл? Ведь для точки (0,0) второй цикл пробежит по сути весь массив (сколько он у Вас там — 3000х2000 ?). Можно было бы пробегать лишь [x1,x1+rasstKriteria],[y1,y1+rasstKriteria]. Думаю, это эффективнее.

Мне не каежтся, что здесь вопрос действительно лишь в непонимании специфики Java. Мне бросаются в глаза несколько моментов:
— обнуление «к черту» я бы проводил в одном месте полным двойным циклом вначале (меньше побочных эффектов надо отслеживать).
— смущает округление Math.round. Это точно Вам нужно? Просто, в принципе, это может быть причиной потери нескольких вариантов.
— ну и проверьте, не забыли ли Вы учесть удвоение радиуса в rasstKriteria.

А вообще, действительно, сложно строить предположения не видя хотя бы какого-нибудь примера.

Решил самостоятельно, как написано тут.

К сожалению, данный подход вообще не оправдал себя. Встроить модули в плагин Spring_а получилось, но при этом потерялись преимущества модульной архитектуры (если 2му плагину потребуется Spring — его опять придется подкладывать его в архив).

Кроме того, фреймворк Apache Camel, ради которого все затевалось, не умеет работать в OSGI окружении с обычным спрингом. Видимо, нужно переделывать всё на использование Spring DM / Eclipse Gemini Blueprint