Является ли это правильным подходом к структурированию кодовой базы?

#maven-2 #netbeans

Вопрос:

У нас есть кодовая база Java, которая в настоящее время является одним веб-проектом Netbeans. По мере роста нашей организации и кодовой базы кажется очевидным, что мы должны разделить различные независимые части нашей системы на отдельные банки. Таким образом, одна библиотека Jar для уровня доступа к данным, одна для общей библиотеки, одна для специализированного доступа к знаниям и т. Д. Тогда у нас был бы отдельный проект для веб-приложения, и он мог бы быть для приложения инструментов командной строки, в конечном итоге другого веб-приложения и т. Д.

Какова рекомендуемая практика для этого и управления этим? Это Мэйвен? Можно ли все это эффективно сделать только с помощью Netbeans, просто создав отдельные проекты и установив зависимости одного проекта от файлов jar других?

Ответ №1:

Я бы согласился со Стивегом выше в использовании Maven2, чтобы помочь вам модульизировать базу кода, но я бы использовал Nexus в качестве локального репозитория для Maven вместо Archiva. У ребят из Sonatype также есть отличная (бесплатная html/pdf) книга о том, как использовать Maven, Nexus и интегрировать его в IDE.

Однако будьте осторожны с тем, как вы решите разделить свои проекты. Нет смысла чрезмерно усложнять свои зависимости только ради этого.

Ответ №2:

Я бы определенно сказал, что проверьте Maven(2). Это очень хорошо для такого рода вещей. Затем вы можете очень легко определить отдельные модели и версии. Netbeans также выполняет достойную работу по интеграции с.

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

Ответ №3:

Я бы создал сценарии ant для сборки частей и для развертывания. Тогда вы не зависите от своей среды разработки для сборки/развертывания.

Ответ №4:

Похоже, ваш код подходит к тому моменту, когда вы заканчиваете подход к ВОЙНЕ и входите в уровень УХА.

УХО-это просто еще один архив, содержащий все остальные банки и войны, которые объединяются для создания приложения. Существует четыре типа модулей, которые могут находиться внутри него: Web, EJB, Разъемы и утилиты. Большинство людей используют только веб и утилиты, поэтому они предпочитают использовать подход WEB-INF/lib.

Но если вы начинаете понимать множество взаимозависимостей, что вы делаете, создайте проект EAR и сделайте свой веб-проект его дочерним. Каждая утилита JAR, представляющая собой простой Java-код, используемый другими модулями, также становится дочерним элементом EAR. Наконец, в каждом из ваших проектов должен быть файл META-INF/manifest.mf, в котором просто указаны имена банок, от которых зависит JAR/WAR.

Я парень из eclipse, и большая часть этого решается для вас в eclipse, но я уверен, что netbeans обладает очень похожей функциональностью.

Теперь единственная проблема заключается в том, что вам нужно использовать полный сервер Java EE для развертывания EAR, поэтому я не думаю, что вы можете использовать Tomcat, если это то, что вы используете в настоящее время.

Комментарии:

1. Нет необходимости делать это, если это веб-проект только без какого-либо другого компонента JEE. Просто поместите ваши банки в каталог библиотеки веб-приложений проще, так как обновление манифеста не требуется. Даже если война развернется в УХЕ.