Методология, которая позволяет использовать единую базу кода Java, охватывающую множество разных версий?

Я работаю в небольшом магазине, где у нас есть много устаревшего кода Cobol и где была принята методология, позволяющая максимально свести к минимуму разветвление и разветвление.

Для данной версии мы имеем три уровня:

CORE - нижний уровень, этот код является общим для всех выпусков
GROUP - необязательный код, общий для нескольких клиентов.
CUSTOMER - дополнительный код, специфичный для одного клиента.

Когда программа необходима, ее сначала ищут в CUSTOMER, затем в GROUP и, наконец, в CORE. Данное приложение для нас вызывает много программ, которые все ищут в этой последовательности (думаю, файлы exe и PATH под Windows).

У нас также есть Java-программы, взаимодействующие с этим устаревшим кодом, и поскольку механизм взаимодействия с ключевыми группами и клиентами не позволяет легко реализовать его в Java, он имеет тенденцию расти в филиале CVS для каждого клиента, требуя слишком много поддержки, Часть Java и внутренняя часть имеют тенденцию развиваться параллельно.

Мне было поручено выяснить, как можно встретить два мира.

По сути, мы хотим, чтобы Java-среда, которая позволяет нам иметь единую базу кода с источниками для каждой версии, где мы легко можем выбрать группу и клиента и работать с приложением, как это происходит для этого клиента, а затем легко переключаться к другому кодовому набору и ЭТОТ клиент.

Я думал о сценарии с проектом Eclipse для каждого ядра, клиента и группы, а затем использовал Project Sets для выбора тех, которые нам нужны для данного сценария. Проблема, о которой я не могу рассказать, заключается в том, как мы будем создавать надежный код в проектах CORE, которые будут работать независимо от того, какая группа и клиент выбраны. A Factory класс, который знает, какой подкласс класса переданного объекта класса вызывается вместо каждого нового?

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

РЕДАКТИРОВАНИЕ: Вывод этой проблемы выше заключался в том, что CVS необходимо заменить системой управления исходным кодом, которая лучше подходит для одновременного взаимодействия со многими веткими и переноса источника из одного компонента в другой при сохранении истории. Вдохновленный недавней миграцией с помощью slf4j и logback, мы в настоящее время смотрим на git, поскольку он отлично справляется с ветвями. Мы также рассмотрели subversion и mercurial, но git, по-видимому, лучше подходит для проектов с одним местоположением и с разветвленной связью. Я спросил о Perforce в другом вопросе, но моя личная наклонность направлена на решения с открытым исходным кодом для чего-то столь же важного, как это.

EDIT: после нескольких размышлений мы обнаружили, что наша фактическая точка боли заключается в том, что мы используем ветки в CVS, и что ветки в CVS легче всего работать, если вы введете ВСЕ файлы! Пересмотренный вывод состоит в том, что мы можем сделать это только с помощью CVS, перейдя в лес java-проектов, каждый из которых соответствует одному из уровней выше, и используйте пути сборки Eclipse, чтобы связать их вместе, чтобы каждая версия CUSTOMER втягивала соответствующую группу и проект CORE. Мы по-прежнему хотим переключиться на лучшую систему управления версиями, но это так важно для решения, поэтому мы хотим как можно больше задержать его.

EDIT: теперь у меня есть концептуальная реализация концепции CORE-GROUP-CUSTOMER с использованием Google Guice 2.0 - тег @ImplementedBy - это то, что нам нужно. Интересно, что делают остальные? Использование, если повсюду?

EDIT: теперь мне также нужна эта функциональность для веб-приложений. Guice был до тех пор, пока JSR-330 не на месте. Кто-нибудь с опытом управления версиями?

EDIT: JSR-330/299 теперь работает с эталонной реализацией JEE6 Weld на основе JBoss Seam, и я пересмотрел доказательство концепции Weld и вижу, что если мы будем использовать @Alternative вместе с... в beans.xml мы можем получить желаемое поведение. То есть обеспечить новую реализацию для данной функциональности в CORE без изменения бит в банках CORE. Первоначальное чтение в спецификации Servlet 3.0 указывает, что оно может поддерживать ту же функциональность для ресурсов веб-приложений (а не кода). Теперь мы проведем первоначальное тестирование на реальном приложении.

Ответ 1

Вы спрашиваете: "Как мы можем спроектировать наше программное обеспечение, чтобы избежать необходимости разработки определенного типа релизов? Я не знаю ответа на этот вопрос, но я прочитал ваше описание, и я беспокоюсь об этом. root, я думаю, что это проигрышная игра, чтобы сделать ваши основные разработки программного обеспечения подчиненными вашим технологиям разработки релизов.

Другими словами, если ваши клиенты действительно нуждаются в отдельных выпусках, то вам придется иметь дело с этим. Я читал, что вы говорите, что вы хотите использовать Eclipse для выполнения той работы, которую должно выполнять ваше программное обеспечение для контроля версий. Это не кажется мне жизнеспособным решением.

Могу поспорить, вы можете видеть, куда я иду с этим. Если проблема заключается в том, что "ветвление в CVS слишком болезненно", то я думаю, что техническое решение заключается в "переходе на CVS к чему-то, что обеспечивает более надежное и простое ветвление и интеграцию".

В мире свободного программного обеспечения это обычно означает Subversion. Хорошей коммерческой альтернативой является Perforce. Я могу сказать, что работал в компании, которая выпустила множество версий программного обеспечения для многих клиентов и часто кросс-интегрировала изменения из одного ветки в другой. Мы использовали Perforce, и ветвление (и интеграция) было достаточно простым, чтобы любой инженер мог и делал это регулярно, не прерывая свою повседневную работу.

Ответ 2

Согласитесь с @peterb, Eclipse - это не способ справиться с этим. Ветвление в вашей системе управления версиями предназначено для этой цели, поэтому выберите тот, который сделает это как можно проще (Subversion должно работать нормально).

Вы также можете рассмотреть возможность использования Maven (или чего-то подобного), чтобы затем определить управление зависимостями для разных сценариев клиентов. Затем вы можете сгенерировать как ваши проекты eclipse с maven, так и ваши фактические разработки, а также сборки релизов.